Essentially, I want to put control of such a feature into the hands of the Sugar developers - allowing us to control which delimiters are balanced with which *other* delimiters using the existing Syntax, or possibly the existing Itemizer functionality.
I thought this was the sort of stuff the cocoa api was for?
Not as I understand it. But you’d have to ask Jan.
Anyway, there should really be specific functionality relating to this, as it’s a very important feature that applies to nearly every language.
As Elliott said, this isn’t appropriate for the Cocoa API. In order to match delimiters with a plugin you’d have to figure out a way to log every character entered. This gets nasty quickly, particularly because there isn’t any current exposed API for doing it. Someone wrote a Coda plugin that balances quotation marks and curly braces, but it essentially uses the accessibility API rather than Coda’s.
It would be far faster and more flexible if Jan implemented an XML-driven way for Sugar authors to set this up, particularly because it is such a common need.
So, to copy-and-paste from my suggestions document linked above… (Because I really, really want this suggestion to gain eyes and maybe get implemented):
elliottcable - 17 December 2008 04:14 PM
Will there be delimiter-balancing functionality at some point? Perhaps similar to that in TextMate and Coda, where typing a opening delimiter automatically creates the closing delimiter, and and passing over a delimiter with your insertion point highlights the balancing delimiter elsewhere in the code?
If it is supported, will we be able to hook into it to inform Espresso which characters are ‘delimiters’ in a given context? It’d be very cool if any syntax zone or capture zone (I understand they work the same after parsing) with both .delimeter. and .begin. would ‘balance’ any zone with the exact same name but with .end. instead of .begin..
Will we be able to tell Espresso when not to read a character as a delimiter? For instance, it’s annoying in TextMate when you have a complicated regular expression that includes parenthesis, but they are escaped (thus a part of the match). TextMate gets all confused about which parenthesis balances which, and is quite likely to throw off your regex-fu.
This feature would really make my day. I don’t know about everyone else, but this is probably my most-requested thing at the moment.
Edit 1: Also, I’d like to point out that implementing it as I describe above in the second paragraph would reduce the need for the functionality described in the third paragraph - if syntax zones themselves described the delimiters, then places that those syntax zones are not valid / relevant (such as inside a regular expression) would not become a problem.
Edit 2: The more I think about this, the more power it gives you. You could use this to, say, balance HTML tags, as if they were delimiters themselves. And since each opening delimiter is unique to it’s closing delimiter, you’d know if things like ”” were unbalanced/irregularly-nested, thus giving you the opportunity to, say, highlight them as invalid.
I’d love to see this. I have a love/hate relationship with Textmate because I love that it autocloses my quotation marks, but I hate that it autocloses my quotation marks when I type something like “don’t” outside a tag (end up with “don’t’” if I’m going fast).
Being able to define auto-closing delimiters per-language and based on syntax zone in XML would be a fantastic feature.
I’d love to see this. I have a love/hate relationship with Textmate because I love that it autocloses my quotation marks, but I hate that it autocloses my quotation marks when I type something like “don’t” outside a tag (end up with “don’t’” if I’m going fast).
Being able to define auto-closing delimiters per-language and based on syntax zone in XML would be a fantastic feature.
Obviously per language because I don’t want <> auto-closing in php, but I’d want it in html. This could even be implemented for regex if we had control over it.
Obviously per language because I don’t want <> auto-closing in php, but I’d want it in html. This could even be implemented for regex if we had control over it.
Edit 1: Regex.sugar would have that working out of the box if it’s implemented as I described above. Delimiters are already described in a balance-able way there.
Here’s a question. What if we have nested delimiter zones?
For instance, ”<” is “tag.delimiter.open”, and ”<b>” is “style.bold.open” or whatever.
The user types ”<”, and sees ”<|>” (where ”|” is their cursor). Then they type “b” and see ”<b>|</b>”. Does that sound intuitive to anybody other than me? That’s two keys (and not even any hotkeys or actions involved!) to get a whole tag written.
1+ for delimiter-balancing. The user should definitely be able to override or otherwise turn it off, but a degree of control for sugar devs would be nice.
The user types ”<”, and sees ”<|>” (where ”|” is their cursor). Then they type “b” and see ”<b>|</b>”. Does that sound intuitive to anybody other than me? That’s two keys (and not even any hotkeys or actions involved!) to get a whole tag written.
It would need to be integrated with tag stops. So for instance, in HTML user would type ”<” and get ”<|>”. Then they type “b” and get ”<b|></b>”. Tab once to get <b>|</b>”, and once more to get ”<b></b>|”. Without tab stops you have the problem of what to do if they want to give the tag a class or whatever, and then how they get out of the tag if it isn’t at the end of the document/line.
Whether this is too intrusive or not I’ll leave as a discussion if/when delimiters are introduced to the program and people start coding them into sugars.
The user types ”<”, and sees ”<|>” (where ”|” is their cursor). Then they type “b” and see ”<b>|</b>”. Does that sound intuitive to anybody other than me? That’s two keys (and not even any hotkeys or actions involved!) to get a whole tag written.
It would need to be integrated with tag stops. So for instance, in HTML user would type ”<” and get ”<|>”. Then they type “b” and get ”<b|></b>”. Tab once to get <b>|</b>”, and once more to get ”<b></b>|”. Without tab stops you have the problem of what to do if they want to give the tag a class or whatever, and then how they get out of the tag if it isn’t at the end of the document/line.
Whether this is too intrusive or not I’ll leave as a discussion if/when delimiters are introduced to the program and people start coding them into sugars.
Good point. I had assumed you’d just choose the most important point - in this case, the inside of the tag. You’d have to hit the back arrow once to get back to editing the attributes, I guess.
The flexibility wouldn’t hurt though. That just complicates the implementation… a lot. If you’re worrying about tab stops, you can no longer just treat it like normal typing. Instead, you’ve got to treat it like an action of sorts. I dunno… we’ll see in any case.
Just a quick note that I’m keeping an eye on this thread. We definitely want to do delimiter balancing at some point, and the smarter the better. I personally don’t think it should go as far as handling entire HTML tags though, snippets are better suited for that.
Just a quick note that I’m keeping an eye on this thread. We definitely want to do delimiter balancing at some point, and the smarter the better. I personally don’t think it should go as far as handling entire HTML tags though, snippets are better suited for that.
I actually agree with you on not handling HTML tags; like Elliot said, supporting the tab stops which would be necessary to make auto-balanced delimiters from HTML would be a lot of complexity and no fun to set up.
My ideal wishlist as a potential sugar developer for defining custom delimiter balancing:
- Be able to define single-character delimiters that will auto-balance (classic example being I type `{` and get `{}`)
- Be able to restrict delimiter balancing to certain syntax zones; for instance, I almost always want single quotes to balance inside HTML tags, but not in text
- Be able to define automatic indentation for the delimiters if the user hits enter after the delimiter is auto-balanced
- Possibly be able to define regex-based delimiters; this would be an interesting way to handle arbitrary XML/HTML tags without needing to setup specific snippets for them or add them to autocomplete. For instance, maybe I define my opening delimiter as:
<([a-z_-]+)([^>]*)>
And my closing delimiter as:
</$1>
This would allow me to auto-balance a custom tag in an XML document by simply typing the opening tag, and would definitely be a nice addition to auto-balancing delimiters since I might only use that custom tag a few times (thus not worth adding to auto-complete list or snippets). (It also might be better to use syntax zones as delimiters rather than regex expressions; not familiar enough with the syntax definition system to make an intelligent request/suggestion.)
Whether or not you did the regex-based delimiters, I think basic text delimiters are definitely a must; surrounding code in curly braces and so forth is so standard that it makes little sense to leave this functionality out. It would also be nice if you supported smart delimiter handling like in Textmate. For instance, in Textmate I can type `function something(` and will end up with `function something()`. If I’m going fast and type the closing parenthesis without thinking about it Textmate just overwrites the closing delimiter so I still have `function something()`. I’ve found this really handy, and it would be nice if it were offered in any custom auto-closing delimiter system.
I don’t like the whole ’$1’ solution, but I really think this could work, overall. Jan?
My main request is that Espresso make no assumptions about what ‘a delimeter’ is. Ruby alone uses ’(|)’, ’[|]’, ’{|}’, ’|||’, ‘do|end’, and a lot more, all in different contexts. I’m going to have to describe all of this in detail in my Syntax anyway, seems like a waste to have to do it again.
Another situation worth consideing is Objective-C’s ’@”|“‘ construct. Again, not single character, but with the proper Sugar dev tools, could still benefit.
I don’t like the whole ’$1’ solution, but I really think this could work, overall.
And you don’t like standard regex back references why?
Depending on your flavor, maybe you’d be more used to `\1` or something; the point I was trying to make is that it might be nice with delimiters to be able to use back references for constructing the closing delimiter (specifically useful for HTML/XML; not sure if it would come in handy for programming/scripting languages).
Ah. I’ve never seen a system that uses ’$1’ instead of ’\d’, but maybe some of the odder engines do. In any case, my petition is to use standard already-in-place Syntax functionality to achieve this. If you want that functionality, ask that it be included in Syntaxes d-;
I forget which regex flavor uses $ backreferences instead of \ ones; might be Perl. You’ll also find that syntax in Apache mod_rewrite rules, which is the most recent place I was writing regex.
I remember when I first started coding regex the two places I was doing it were TextSoap and Textmate, and since they use different styles of backreferences my memory about which is more common is permanently scrambled.
