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

[Ludovic Courtès]

Hi Alex,

Alex Kost <address@hidden> skribis:

> 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+()

To me that’s a feature, because in Scheme ‘+’ is acceptable within
identifiers, so there’s no reason to automatically insert a space after
‘+’.

> 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.

Do you think .dir-locals.el could perform this change in a buffer-local
fashion?

Thanks for explaining!

Ludo’.