* Don't change "+" syntax in guix/.dir-locals.el @ 2018-05-20 19:57 Pierre Neidhardt 2018-05-21 18:31 ` Alex Kost 0 siblings, 1 reply; 9+ messages in thread From: Pierre Neidhardt @ 2018-05-20 19:57 UTC (permalink / raw) To: Guix-devel [-- Attachment #1: Type: text/plain, Size: 717 bytes --] 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: --8<---------------cut here---------------start------------->8--- ;; 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 ?+ "'")) --8<---------------cut here---------------end--------------->8--- I don't see how it affects Paredit. What do you think? -- Pierre Neidhardt [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Don't change "+" syntax in guix/.dir-locals.el 2018-05-20 19:57 Don't change "+" syntax in guix/.dir-locals.el Pierre Neidhardt @ 2018-05-21 18:31 ` Alex Kost 2018-05-23 12:33 ` Ludovic Courtès 0 siblings, 1 reply; 9+ messages in thread From: Alex Kost @ 2018-05-21 18:31 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: Guix-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Don't change "+" syntax in guix/.dir-locals.el 2018-05-21 18:31 ` Alex Kost @ 2018-05-23 12:33 ` Ludovic Courtès 2018-05-23 17:21 ` Alex Kost 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2018-05-23 12:33 UTC (permalink / raw) To: Alex Kost; +Cc: Guix-devel Hello! Alex Kost <alezost@gmail.com> 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’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Don't change "+" syntax in guix/.dir-locals.el 2018-05-23 12:33 ` Ludovic Courtès @ 2018-05-23 17:21 ` Alex Kost 2018-05-28 9:34 ` Ludovic Courtès 0 siblings, 1 reply; 9+ messages in thread From: Alex Kost @ 2018-05-23 17:21 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix-devel Ludovic Courtès (2018-05-23 14:33 +0200) wrote: > Hello! > > Alex Kost <alezost@gmail.com> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Don't change "+" syntax in guix/.dir-locals.el 2018-05-23 17:21 ` Alex Kost @ 2018-05-28 9:34 ` Ludovic Courtès 2018-05-29 9:16 ` Alex Kost 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2018-05-28 9:34 UTC (permalink / raw) To: Alex Kost; +Cc: Guix-devel Alex Kost <alezost@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. I think it also allows #$ to be highlighted in a special way. HTH! Ludo’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Don't change "+" syntax in guix/.dir-locals.el 2018-05-28 9:34 ` Ludovic Courtès @ 2018-05-29 9:16 ` Alex Kost 2018-05-29 9:20 ` Pierre Neidhardt 2018-05-29 19:31 ` Ludovic Courtès 0 siblings, 2 replies; 9+ messages in thread From: Alex Kost @ 2018-05-29 9:16 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix-devel Ludovic Courtès (2018-05-28 11:34 +0200) wrote: > Alex Kost <alezost@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Don't change "+" syntax in guix/.dir-locals.el 2018-05-29 9:16 ` Alex Kost @ 2018-05-29 9:20 ` Pierre Neidhardt 2018-05-29 19:31 ` Ludovic Courtès 1 sibling, 0 replies; 9+ messages in thread From: Pierre Neidhardt @ 2018-05-29 9:20 UTC (permalink / raw) To: Alex Kost; +Cc: Guix-devel [-- Attachment #1: Type: text/plain, Size: 286 bytes --] Alex Kost <alezost@gmail.com> 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Don't change "+" syntax in guix/.dir-locals.el 2018-05-29 9:16 ` Alex Kost 2018-05-29 9:20 ` Pierre Neidhardt @ 2018-05-29 19:31 ` Ludovic Courtès 2018-05-30 8:36 ` Alex Kost 1 sibling, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2018-05-29 19:31 UTC (permalink / raw) To: Alex Kost; +Cc: Guix-devel Hi Alex, Alex Kost <alezost@gmail.com> skribis: > Ludovic Courtès (2018-05-28 11:34 +0200) wrote: > >> Alex Kost <alezost@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’. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Don't change "+" syntax in guix/.dir-locals.el 2018-05-29 19:31 ` Ludovic Courtès @ 2018-05-30 8:36 ` Alex Kost 0 siblings, 0 replies; 9+ messages in thread From: Alex Kost @ 2018-05-30 8:36 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix-devel Ludovic Courtès (2018-05-29 21:31 +0200) wrote: > Alex Kost <alezost@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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-05-30 8:36 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-05-20 19:57 Don't change "+" syntax in guix/.dir-locals.el Pierre Neidhardt 2018-05-21 18:31 ` Alex Kost 2018-05-23 12:33 ` Ludovic Courtès 2018-05-23 17:21 ` Alex Kost 2018-05-28 9:34 ` Ludovic Courtès 2018-05-29 9:16 ` Alex Kost 2018-05-29 9:20 ` Pierre Neidhardt 2018-05-29 19:31 ` Ludovic Courtès 2018-05-30 8:36 ` Alex Kost
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.