Repository: mawww/kakoune

Issue #4081: wrong indentation in Lisps when comments contain unmatched brackets
Created: 2021-03-02T16:56:31Z
Steps 
Create file bug.lisp with the following contents:
(defun foo (bar)
  ;; comment with unclosed {
  bar)
Open it and press: gho
Outcome 
Note the indentation:

Expected 

This happens in all Lisp related filetypes: lisp, clojure, scheme, fennel. This doesn't happen in c-like languages:

Duplicate issue #4188: Making parenthesis text objects context sensitive to strings
Created: 2021-05-05T12:31:43Z
Feature
Currently, text objects such as b (parenthesis) and commands like m do not take into account that strings in code are semantically different from the structure in the code itself. Allowing syntax highlighting to semantically define regions like inside strings as "dead" and making the objects not take into account things inside "dead" blocks would allow these objects to work more effectively on the structure of the code, rather than the literal contents.
Usecase 
Editing the following code:

and pressing m, the following gets selected:

This is certainly not what the user wanted, the closing parenthesis inside the string does not semantically close any opening parenthesis, and instead the following should have been selected:

Additional use cases
By having a general way of syntax definitions marking regions as "dead", you could additionally solve the following problem, with matching angle brackets being confused for <aaa>-style tags:

which selects

upon doing m.
By marking the angle brackets as dead, only in comparisons, one could have the above example working, while not sacrificing the ability to select the angle brackets in eg. Vec<X>.
Potential issues
Adding this would create a dependency between syntax highlighting and navigation, which is a bit of a unorthogonal design to have. Ideally, syntax highlighting would only be used in the rendering of the code, and navigation would be agnostic of that.
This would be a breaking change which could disrupt some plug-ins and macros relying on the current behaviour. However, I would be surprised if this turned out to be a problem as I cannot think of any use case for this particular behaviour inside a plug-in.
For me personally, the fact that Kakoune works the same across many different types of files is a big plus, and having text objects depend differently across file types might create confusion. However, the behaviour described here I would argue is rather intuitive. The current behaviour might make sense on a literal level, but having the text objects reflect the structure of the code is not counter-intuitive at all.

Closing comment (2021-05-05T14:27:23Z): Related to #4081 , which is about brackets in comments (but also when there are brackets in quotes).
To add to potential issues:
It is common to have large strings with code in them, and some implementations of this would nerf m inside code strings.  It might not be usable for shell code in kakrc, for example.
Some languages have code escapes inside quotes, and the code can have quoted strings.  It becomes more "brackets have to match something on the same semantic layer" and less a binary of whether an area is dead or not.
Here's a terrible example:
Hello!
<% 1.upto(if x > 10 then 10 else x) { |n| %> this is } iteration <%=n%> } <%
Goodbye

I would like to eventually see some kind of highlighting-like layer for semantic annotation of code in Kakoune that can handle arbitrarily complex code - assuming there's a parser for it - and answer questions like these.  BUT...
I've also tried to work out a kind of mask register idea where Kakoune can be ignorant of the language syntax and a script can store mask areas into a register, and m and things like [b will ignore things inside that register.  For sake of argument will call the register m, code can do something like:
execute-keys '%s"([^\\]|\\.)*"<ret>"mZm'

I've lost my notes from trying to work that out, apparently.  I ran into some issues, but I can't reproduce them now.