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

[Alex Kost]

Ludovic Courtès (2018-05-29 21:31 +0200) wrote:

> Alex Kost <address@hidden> 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