GNU bug report logs - #68514
30.0.50; minibuffer-choose-completion + elisp-c-a-p delete next sexp when completing after open paren

Previous Next

Full log

Message #23 received at 68514 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: dmitry <at> gutov.dev, 68514 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#68514: 30.0.50; minibuffer-choose-completion + elisp-c-a-p
 delete next sexp when completing after open paren
Date: Wed, 17 Jan 2024 12:20:06 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> If point is already at the start of a sexp (e.g. immediately after an
>> open paren) then backward-sexp will not move point and the beginning
>> of the completion region would (correctly) be the original point.
>>
>> forward-sexp, in this case, will move over the next sexp after point
>> and include it in the completion region, even if it's a string or
>> list.
>
> The fact that it did not move point is not really the problem.

Yes, I agree that's not a problem - it's not something my patch changes.
My patch just causes the completion region to not include unrelated
lists/strings.  (although it can still include whitespace or comments -
but deleting those might actually arguably be correct)

> The problem is that point may be just before something like whitespace,
> so the
>
>                          (member (char-syntax (char-after beg))
>                                  '(?\" ?\())
>
> doesn't notice that `forward-sexp` will actually jump over a list or
> some other such uncompletable sexp.
>
> I suggest the patch below instead (which also uses `min` to try to make
> sure we don't return a BEG..END which doesn't contain point).
>
>
>         Stefan
>
>
> -	    (unless (or (eq beg (point-max))
> -			(member (char-syntax (char-after beg))
> -                                '(?\" ?\()))
> +	    (unless (or (>= beg (point-max))
> +		        (not (memq (char-syntax (char-after beg))
> +		                   '(?w ?\\ ?_))))

This prevents completion from happening at all when point is right after
an open paren and right before whitespace, which currently works, though
it has this bug.  That doesn't seem like an improvement, and also it
reverts 0db2126d7176b0bd1b13d4b0d1cd958c8cf55714 which explicitly did
the opposite.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.