Hi Alex,
Alex Kost <alez...@gmail.com> skribis:
> Ludovic Courtès (2018-05-28 11:34 +0200) wrote:
>
>> Alex Kost <alez...@gmail.com> 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’.
