Ludovic Courtès (2018-05-29 21:31 +0200) wrote: > Alex Kost <alez...@gmail.com> skribis: > >> Ludovic Courtès (2018-05-28 11:34 +0200) wrote: [...] >>> 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
A feature of "dir-locals"? > , because in Scheme ‘+’ is acceptable within > identifiers, so there’s no reason to automatically insert a space after > ‘+’. So do you think that inserting a space after ‘+’ is a Paredit misfeature? Then maybe it should be reported upstream. Anyway, I just want to say, ".dir-locals.el" should not modify the default syntax table, because all emacs packages and Emacs itself can rely on it. For example, evaluate the following 2 definitions with Geiser: (define foo 1) (define foo+ 2) Now if you put the point on ‘foo’, the minibuffer will show you “(guile-user):foo => 1”. And it shows the similar message for ‘foo+’, but if you use "dir-locals", you will not see “(guile-user):foo+ => 2”. So if the intention is to fix paredit, I think "dir-locals" should change paredit, not scheme-mode. >> 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? The only other way I see, is to set ‘paredit-space-for-delimiter-predicates’ variable. The easy way is to replace those 3 ‘modify-syntax-entry’ lines in "dir-locals" with: (paredit-space-for-delimiter-predicates ignore) But ‘ignore’ predicate is too strict: the space will never be inserted not only for ‘foo+’ but also for ‘foo’. Maybe, a better predicate can be chosen, but I don't have a wish to think about it more, sorry :-) -- Alex