but shouldn't the shortest path win for second :[table] match?
It depends what you expect to terminate this path to give you the "shortest path". Should the shortest path cut off when there is a whitespace character? Or maybe the next line? These options are all useful, but quite different. In comby the meaning (semantics) of :[hole] is to match everything (all characters, including spaces and newlines) until the part that comes right after the hole. In your original example, there is nothing that comes right after the hole (not even whitespace). It is empty. With an empty string, we can either match nothing (that would not be useful) or continue matching to the end of the file (because the part after the hole is interpreted as "end of file). Note that the other hole kinds exist when you don't want this behavior, and instead something like matching words, or lines.
Second :[table] also doesn't match if I add ( instead of space
This is by design: it is not possible to use or match dangling parentheses in the source code. Well, there are exceptions I won't go into, but the idea is that you shouldn't use dangling parentheses to match/rewrite because that could make it easy to mess up things. The approach I would recommend is to match all such syntactic expressions, and just rewrite them without changing, like CREATE TABLE :[table] (:[body]). (example: https://bit.ly/2NLJWli)
:[hole] matching is logical. Maybe unusual for a regexp user where "match everything" is always non-conditional explicit element. Now it is clear why there is a separate explanation about whitespace for :[hole]s. With "match all until current context" there will be a lot of work to filter out all whitespace that matched and concentrate only on things that have meaning other than "delimiter".
0.13.1: https://github.com/comby-tools/comby/releases/tag/0.13.1. You can either grab it from source, docker, or binaries from that release page (which or may not work for your platform). It'll take probably until the end of the week to show up in brew. Example in live environment: https://bit.ly/2UmkK8P
const, and then reference that const later on.
@d4hines ah, yeah that use case makes sense. I think I'll tweak it so that you can reference to the same ID generated by passing your own label to id(). So you could do something like
const anon_:[id(my_label)] = ...;
anon_:[id(my_label)](...);where using my_label substitutes the same hash. Give me a couple of days :)
Ok, here's one I'm not sure how to tackle: I've got a list of ES module imports at the top of my file. They're all jumbled up:
import { get } from "lodash";
import { Foo } from "./foo";
import { uuid } from "uuid/v4";but I want to sort them like so:
// external library imports
import { get } from "lodash";
import { uuid } from "uuid/v4";
// internal imports
import { Foo } from "./foo";Can comby do this for me?
-newline-separated option) which becomes your "set", then doing the computation for sorting (with sort or a scripting language or such), and then substituting the imports back. But there isn't a direct way to the 'substituting back' part for this use case, so that would also need something else. You could, e.g., use comby to write the imports to a separate file, use comby to erase the imports for the current file, and then prepend the sorted output to substitute it all back. So it's possible to do this, but the number of hoops to jump through means it's not well suited to the task.
:[id(label)] addition, that'll be merged/released by Monday :-) comby-tools/comby#169
:[ leading_indentation]but fails to match bit.ly/2uUkEej
Hey @abitrolly. So in general comby can't do indentation-sensitive matching. The :[ leading_whitespace] hole would not apply to the whole :[body] and would only, in the best case, match the leading indentation of the first line after :[name]. This is a known limitation and I need to add a feature (it is planned) to allow indentation-sensitive block matching.
If you are OK with only matching the leading indentation of the line after :[name], then you can use bit.ly/2V1cyeO but as you can see it doesn't preserve the relative indentation of the body, and I don't think it solves your problem.
YAML has come up quite often so maybe I should just prioritize this. The idea is that you would just do
name: :[[name]]
:[body]and comby would know that if you are targeting YAML, to match everything at the indentation level of :[body], and when you put <space>:[body] in the rewrite, it would add <space> to every line. But this doesn't exist yet unfortunately.
True. Well, you can already add line-based indentation with arewrite ... rule, like so:
where rewrite
:[body] { ":[line\\n]" -> " :[line]" }The idea with YAML would be to intelligently match blocks, and indent without a rewrite rule.
' and " double quotes with a single rule? I've run into this a few times when I want to rewrite some Python but I end up having to create two rules that match strings of each delimiter type. Maybe something like a language-aware "match a string with its delimiters" would be a nice feature to have?
hey @hofstee. This is a good use case that isn't available generally yet. A hole that does "match a string with its delimiters" is the right thing to support. A related issue has come up where you'd want a different kind of hole to match "a sequence of strings with balanced delimiters", i.e., match (foo), foo(), foo(bar(), baz), but not foo() bar(), using a single kind hole. I have been working on a way to introduce this so that the hole syntax doesn't get out of control (more updates soon). So your use case will get incorporated into that. The basic idea is to support a syntax that lets you optionally specify the semantics, so a syntax like :[x:string] would match what you want for the language.
For now, there is one possible workaround, but I'm not confident it'll work for you in the general case. Basically, you can match on every line in the file and then use a rewrite rule to rewrite each matching case (whether it is single or double quotes): https://bit.ly/2TiThCT
Hello! :wave: Thanks for your work on comby, it looks really great! I was wondering if it was possible to make a pattern that could work across any number of matches? My case is that we have a couple of different ways of writing calls to _.get and I'd like to make those consistent. So I could write a pattern like:
_.get(':[a].:[b]', :[c])then convert it:
_.get([':[a]', ':[b]'], :[c])Which would produce:
_.get('foo.bar', x);
_.get(['foo', 'bar'], x)But would it be possible to work with any number of segments?
Hi! Just to clarify first :) What are the variations that you want to handle? Cases where foo.bar occurs in another argument position? like
_.get(a, 'foo.bar', b);
_.get(a, b, 'foo.bar', ....);or variations where you have foo.bar.baz and break that up to ['foo', 'bar', 'baz'], or both? or something else?
rewrite rules. But it may not fit your use case perfectly depending on some things, so it'd be great to know what some of the variations are.
So you can have a rule like
where
rewrite :[1] { ":[[a]].:[[b]]" -> "':[[a]]', ':[[b]]'" },
rewrite :[1] { "':[[a]]'.':[[b]]'" -> "':[[a]]', ':[[b]]'" },
rewrite :[1] { "':[[a]]'.:[[b]]" -> "':[[a]]', ':[[b]]'" }Basically, each rule here performs a 'reduction' of the original string to some comma separation. In this case I needed three rules to catch all the cases.