bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator

[João Távora]

Sorry, this flew under the radar.  I thought I had already pushed to master
but didn't.  So I went through the commits again, addressed your concerns, and
applied your suggestions.  Pushed to master now.



On Sat, Feb 3, 2024 at 7:10 AM Joseph Turner <joseph@ushin.org> wrote:


>> -[ \t]*%s\\([ \t;]+\\|$\\)")
>> -                           (regexp-opt (mapcar 'cadr fnlist) t)))
>> +[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)\\([ \t;]+\\|$\\)"))
>
> Would you explain what this regexp is intended to match?

A very complicated one, right?  Well ask the author, but I think it's intended
to find many definition-like forms.  No idea why this is  done with regexps and
not with 'read' as it is a classical parsing pitfall in the long run.
Maybe there
was a reason.

Anyway, I just added a bit of logic so that it considers
read-symbol-shorthands if
there are any.

> Are you able to reproduce this on your machine?

Yes, and I fixed it.

> ...then this form will allocate two strings almost as long as the file.
>
> Here's an alternative hack attempting to uncomment and read the minimum:

Thanks, I think that's a good idea and I added a commit in your name.

> A couple typo nits on the commit message of "Improve
> shorthands-font-lock-shorthands (bug#67390)":
>
> -  h//thingy     ; hilits "//"       reads to 'hyperdrive--thingy'
> +  h//thingy     ; hilits "h//"       reads to 'hyperdrive--thingy'
>
> -  Co-authored-by: João Távora <joaotavora@gmail.com>
> +  Co-authored-by: Joseph Turner <joseph@breatheoutbreathe.in>

I fixed these, too.  If you succesfully test this, I think we can close this bug
(and the other ones, too).

João