Re: Don't change "+" syntax in guix/.dir-locals.el
Ludovic Courtès (2018-05-29 21:31 +0200) wrote: > Alex Kost 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
Re: Don't change "+" syntax in guix/.dir-locals.el
Hi Alex, Alex Kost skribis: > Ludovic Courtès (2018-05-28 11:34 +0200) wrote: > >> Alex Kost 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’.
Re: Don't change "+" syntax in guix/.dir-locals.el
Alex Kost writes: > 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. Agreed. -- Pierre Neidhardt signature.asc Description: PGP signature
Re: Don't change "+" syntax in guix/.dir-locals.el
Ludovic Courtès (2018-05-28 11:34 +0200) wrote: > Alex Kost 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
Re: Don't change "+" syntax in guix/.dir-locals.el
Alex Kost 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. I think it also allows #$ to be highlighted in a special way. HTH! Ludo’.
Re: Don't change "+" syntax in guix/.dir-locals.el
Ludovic Courtès (2018-05-23 14:33 +0200) wrote: > Hello! > > Alex Kost skribis: > >> Pierre Neidhardt (2018-05-20 21:57 +0200) wrote: >> >>> I recently noticed that guix-devel-mode misbehaved on packages ending >>> with a "+" (like my recent emacs-image+). >>> >>> See https://github.com/alezost/guix.el/issues/24 for more details. >>> >>> Alex Kost suggested we removed the syntax change in .dir-locals.el: >>> >>>;; This notably allows '(' in Paredit to not insert a space when the >>>;; preceding symbol is one of these. >>>(eval . (modify-syntax-entry ?~ "'")) >>>(eval . (modify-syntax-entry ?$ "'")) >>> - (eval . (modify-syntax-entry ?+ "'")) >> >> Here is my point: I believe (re-search-forward "\\s_" nil t) should find >> "+" character in lisp/scheme modes because it may be part of symbol >> names there. Even elisp manual mentions this fact: >> >> https://www.gnu.org/software/emacs/manual/html_node/elisp/Syntax-Class-Table.html#Syntax-Class-Table >> >> So I think that ".dir-locals.el" shouldn't break this default behavior. > > So, IIUC, we may have to sacrifice highlighting of #+ so that > ‘guix-guile-current-definition’ works well with symbols containing ‘+’, > right? 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?) -- Alex
Re: Don't change "+" syntax in guix/.dir-locals.el
Hello! Alex Kost skribis: > Pierre Neidhardt (2018-05-20 21:57 +0200) wrote: > >> I recently noticed that guix-devel-mode misbehaved on packages ending >> with a "+" (like my recent emacs-image+). >> >> See https://github.com/alezost/guix.el/issues/24 for more details. >> >> Alex Kost suggested we removed the syntax change in .dir-locals.el: >> >>;; This notably allows '(' in Paredit to not insert a space when the >>;; preceding symbol is one of these. >>(eval . (modify-syntax-entry ?~ "'")) >>(eval . (modify-syntax-entry ?$ "'")) >> - (eval . (modify-syntax-entry ?+ "'")) > > Here is my point: I believe (re-search-forward "\\s_" nil t) should find > "+" character in lisp/scheme modes because it may be part of symbol > names there. Even elisp manual mentions this fact: > > https://www.gnu.org/software/emacs/manual/html_node/elisp/Syntax-Class-Table.html#Syntax-Class-Table > > So I think that ".dir-locals.el" shouldn't break this default behavior. So, IIUC, we may have to sacrifice highlighting of #+ so that ‘guix-guile-current-definition’ works well with symbols containing ‘+’, right? That’d be fine with me. :-) Thank you! Ludo’.
Re: Don't change "+" syntax in guix/.dir-locals.el
Pierre Neidhardt (2018-05-20 21:57 +0200) wrote: > I recently noticed that guix-devel-mode misbehaved on packages ending > with a "+" (like my recent emacs-image+). > > See https://github.com/alezost/guix.el/issues/24 for more details. > > Alex Kost suggested we removed the syntax change in .dir-locals.el: > >;; This notably allows '(' in Paredit to not insert a space when the >;; preceding symbol is one of these. >(eval . (modify-syntax-entry ?~ "'")) >(eval . (modify-syntax-entry ?$ "'")) > - (eval . (modify-syntax-entry ?+ "'")) Here is my point: I believe (re-search-forward "\\s_" nil t) should find "+" character in lisp/scheme modes because it may be part of symbol names there. Even elisp manual mentions this fact: https://www.gnu.org/software/emacs/manual/html_node/elisp/Syntax-Class-Table.html#Syntax-Class-Table So I think that ".dir-locals.el" shouldn't break this default behavior. -- Alex