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