Hey @jensim, I can think of two ways to go about this. I think the easiest might be to do your changes and re-format the files for the appropriate indentation (I think you have lots of options here with existing tools).
There's probably a way to get comby to rewrite it while preserving whitespace, but it means you have to match carefully on tags or blocks to dance around rewriting things that could erase whitespace, here's some examples that might help your case: https://gist.github.com/rvantonder/324a4f1c3a46b15628b72745679bf821
5 replies
I'm not sure how far you can go with it
Hey @bentxt. I'm not really sure either :-) I think generating bindings could work, it all depends on how much you need to take into account for the use case (e.g., do the bindings need type info? something else?). You could use it for macros--I'm not sure that I would embed it in a language, but would work well for general search-replace things.
To execute a sequence of match/rewrites you could use a config file: https://comby.dev/docs/configuration#toml-format
Why do you have doubts about using as a macro (code transformation) tool?
I guess it depends where it fits into a toolchain :-) I think it fits well into a preprocessing script, standalone find-replace, or a custom template generation tool. If I were designing a language from scratch with a macro system though, I don't think it's best to, for example, use comby as an external dependency for implementing that macro system--in this case I would rather (eventually) write the macro system for such a language because it would probably be more powerful with language-specific taken into account. But comby could probably work well to prototype things at a very early stage.
Is it possible to recursively transform captured sections ('body' in this case)?
If I follow you correctly, sure, have a look at https://comby.dev/docs/advanced-usage#rewrite-expressions. rewrite expressions cannot nest themselves, but usually it's possible to do multiple rewrites to match on a subpart to change. Let me know if you have a specific example.
-match-newline-at-toplevelto your CLI command, you should get the same matching behavior as comby.live.
switch (maybeExisting) {
| Some(syncable) =>
let%Pom syncable = SyncableRepo.loadBlob(syncable);
resolved(syncable);
| None => Serbet.Abort.notFound("Syncable not found for user")
};let%Pom, and transforms all of the following lines in the block
None => Serbet....
None => case entirely
| inside them, it will match over the entire nested part (skipping any | inside it).
Explicit comment token missing?
Dear Rijnard van Tonder!
Thank you for comby!
It is a great idea to take the lexical similarities of computer languages
and put them into a usable tool.
Comby feels like the missing link between grep-like-tools and syntactic
and semantic AST rewriting tools (or at least it's cousin ;-).
Solving a problem I solved with other tools before (grep/sed/perl,
syntactic AST-rewriting, refactoring level plugin) is a good way for me
to get a feeling of a tool.
So I applied comby to migration of a java test suite from an older
test framework to a newer one.
Most of that works good with standard comment handling of tacking it to some
other match or leaving it alone outside some match.
The migration involves the following replacement problem adding an annotation:
Input:
class ATest extends SomeTestSupport {
/* my important test blabla /
public void testSomethhing() {
assertEquals(3, 1 + 2);
}
}
Output to reach:
class ATest extends SomeTestSupport {
/* my important test blabla /
@Test
public void testSomethhing() {
assertEquals(3, 1 + 2);
}
}
The only version that mostly worked implied starting with a generic hole ":[before]"
but for the known reasons that makes parsing of some other files far too slow.
I was not able to find any pattern to match the above inside "{" "}" so I used top level
patterns.
All usable patterns I found loose the comment before the method.
Do you have any trick for keeping the comment?
It would be nice to have a kind of epsilon token for a comment ":[mycomment#]" that
makes it able to name and reference the "room" between "real" (non-epsilon) tokens or white space.
Maybe ":[mycomment##]" for all comments at that location.
My experiments involved some explicit whitespace matching using regexp holes
but that seems to change the overall parsing behavior in ways not obvious ways for me.
That made me wonder if there should be a syntax to name and reference the standard whitespace "token"
of the current language: ":[myws ]".
And a combination of both with ":[myws# ]".
The online matching was a good help. I suggest giving it a more prominent place in the documentation
on the first sides or with some entry in the side menue.
Thank you for reading so far!
And hopefully you have a pattern tip for me.
cal
1 reply
export DEBUG_COMBY=1 has seemingly no effect. i always just get a message: Error attempting patch, command exited with -7.
Run the command again with DEBUG_COMBY=1 set in the environment for more info.
Press any key to continue, or exit now (Ctrl-C).
comby -review 'Some(:[x])' ':[x].?' src/test/scala/com/oanda/sfb/rates/CandleExchangeRatesSpec.scala
patch -p0, so there's some issue with that failing. Could you tell me what you see after you do this:comby 'Some(:[x])' ':[x].?' src/test/scala/com/oanda/sfb/rates/CandleExchangeRatesSpec.scala -diff > p.patch
patch -p0 --verbose < p.patch
comby -help | grep stdout, just the comby.dev search
