Re: Don't change "+" syntax in guix/.dir-locals.el

[Alex Kost]

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

[Ludovic Courtès]

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

[Pierre Neidhardt]

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

[Alex Kost]

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

[Ludovic Courtès]

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

[Alex Kost]

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

[Ludovic Courtès]

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

[Alex Kost]

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

Don't change "+" syntax in guix/.dir-locals.el

[Pierre Neidhardt]

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


signature.asc
Description: PGP signature