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 #35 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 13:10:36 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> That doesn't seem like an improvement, and also it
>> reverts 0db2126d7176b0bd1b13d4b0d1cd958c8cf55714 which explicitly did
>> the opposite.
>
> Then maybe...
>
>
>         Stefan
>
>
> diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
> index 00910fb67c7..da0cb96e1cf 100644
> --- a/lisp/progmodes/elisp-mode.el
> +++ b/lisp/progmodes/elisp-mode.el
> @@ -657,12 +657,13 @@ elisp-completion-at-point
>  		    (save-excursion
>  		      (backward-sexp 1)
>  		      (skip-chars-forward "`',‘#")
> -		      (point))
> +		      (min (point) pos))
>  		  (scan-error pos)))
>  	   (end
> -	    (unless (or (eq beg (point-max))
> -			(member (char-syntax (char-after beg))
> -                                '(?\" ?\()))
> +	    (cond
> +	     ((and (< beg (point-max))
> +		   (memq (char-syntax (char-after beg))
> +		                   '(?w ?\\ ?_)))
>  	      (condition-case nil
>  		  (save-excursion
>  		    (goto-char beg)
> @@ -670,7 +671,11 @@ elisp-completion-at-point
>                      (skip-chars-backward "'’")
>  		    (when (>= (point) pos)
>  		      (point)))
> -		(scan-error pos))))
> +		(scan-error pos)))
> +             ((or (>= beg (point-max))
> +                  (memq (char-syntax (char-after beg))
> +		        '(?\) ?\s)))
> +              beg)))
>             ;; t if in function position.
>             (funpos (eq (char-before beg) ?\())
>             (quoted (elisp--form-quoted-p beg))

Yes, seems great, that seems like what
0db2126d7176b0bd1b13d4b0d1cd958c8cf55714 should have done in the first
place.

Incidentally, are these (point-max) checks necessary?  We're not doing
anything that can cause us to leave the narrowed region, I think.

Previous Next

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