Comment delimiters matching

[Chris00]

I think it is a residue prior to the requirement of Emacs ≥ 24.4. I have removed it.

[Chris00]

I've tried to propose a more robust solution to comment delimiter matching... It's a bit frustrating that, in strings, sometimes braces are matched "()", mismatched "))", or do not trigger any error ")". Not sure there is a “right way” though.

[monnier]

I've tried to propose a more robust solution to comment delimiter matching... It's a bit frustrating that, in strings, sometimes braces are matched "()", mismatched "))", or do not trigger any error ")".

And almost every bug in this area can be construed as a feature. [ E.g. in ELisp I frequently find it convenient to have paren matching work on "parens inside strings" in cases like (concat "(" foo bar ")"), even though it relies fundamentally on a bug that treats the " foo bar " as if it were a string placed between the two parentheses. ]

Not sure there is a “right way” though.

There are various local maxima and you get to choose which one you try to provide.

[mattiase]

I agree with Stefan – there are merits both in matching the brackets in "(* tata *) and in not doing so. For some possible nuance, I'd prefer bracket matching inside string literals to be made entirely as if it were plain text, not OCaml code. Thus "(* tata *) would highlight the round brackets but not the stars, "[| tata |] the square brackets but not the pipes, and so on. Not sure how easy this would be to accomplish!

[Chris00]

prefer bracket matching inside string literals to be made entirely as if it were plain text,

I agree but for the Emacs functions I have tried (e.g. backward-list), (* and *) seem still to be considered comments inside strings. I guess looping on the chars of the string is quite inefficient.

[monnier]

Christophe Troestler [2021-09-13 07:13:27] wrote:

prefer bracket matching inside string literals to be made entirely as if it were plain text, I agree but for the Emacs functions I have tried (e.g. backward-list), (* and *) seem still to be considered comments inside strings.

Those functions presum the starting point is outside of comment/strings. You can try and get "better" behavior by checking first if the starting point is within a string and if so use with-syntax-table to switch the syntax table to one more appropriate for prose.

I'm not sure it's worth the trouble, tho.

[Chris00]

I'm not sure it's worth the trouble, tho.

Agreed. Let's leave it like that for now.