Re: Don't change "+" syntax in guix/.dir-locals.el

[Alex Kost]

Ludovic Courtès (2018-05-28 11:34 +0200) wrote:

> Alex Kost <address@hidden> skribis:
>
>> Highlighting?  Sorry, I don't understand what you mean: highlighting
>> will not be effected in any way.  The problem is that those
>> 'modify-syntax-entry' lines in ".dir-locals.el" break the default syntax
>> table of scheme-mode, so "+", "$" and "~" characters are not considered
>> to be parts of symbols (variable names in particular), i.e.
>> (re-search-forward "\\s_" nil t) doesn't find them as it should.
>>
>> Since you added those lines, you probably know what Paredit problem you
>> fixed by that (perhaps this problem should be fixed in Paredit itself?)
>
> Yes, the comment gives an idea:
>
>    ;; This notably allows '(' in Paredit to not insert a space when the
>    ;; preceding symbol is one of these.
>
> Basically if you don’t have it, when you type “#$(foo)”, Paredit inserts
> a space before the opening parenthesis.

OK, I see now.  Paredit inserts a space ('paredit-space-for-delimiter-p'
does it) if the point is placed on a symbol.  So by fixing this gexp
stuff, you also break the default behavior of Paredit:

- the default paredit inserts a space after ‘foo+’ symbol: foo+ ()

- and with this dir-locals setting, it doesn't: foo+()

Now I understand why this problem should be fixed, but my opinion is
that ".dir-locals.el" *should not* break the default syntax table of
scheme-mode just to make one emacs package work as desired.

As for me, I find this whole "inserting a space" paredit feature very
unfriendly.  If anyone wants to disable it, you can do it like this:

  (setq paredit-space-for-delimiter-predicates '(ignore))

> I think it also allows #$ to be highlighted in a special way.

I am sure it doesn't.  I never use ".dir-locals.el" files, and I don't
have any problems with highlighting.

-- 
Alex