bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Elijah G.]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

Tags: patch

Hello,

this little patch allow insert any package keywords when using
auto-insert for insert elisp header lines.

This is more a bugfix, since there is a bug when using Vertico that get
stuck in the keywords part, that bug can also apply to other completion
UIs or frameworks.

Also there are some packages that uses non-standard keywords, i think it
would be better allowing insert other keywords.



In GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-05-23 built
 on AVALON
Repository revision: 64cced2c37a9926fe6ff1c6ad9b9540abd47e21c
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4046)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation --without-compress-install --with-tree-sitter CFLAGS=-O2'


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-insert-other-elisp-keywords-in-auto-insert.patch --]
[-- Type: text/patch, Size: 949 bytes --]

From 89f990c6393d90fd76efb4e3665f431d7c0300b3 Mon Sep 17 00:00:00 2001
From: "Elias G. Perez" <eg642616@gmail.com>
Date: Sat, 1 Jun 2024 16:51:54 -0600
Subject: [PATCH] Allow insert other elisp keywords in auto-insert

Allow to user confirm for insert other keywords than
default ones when using auto-insert in an elisp file.

* lisp/autoinsert.el (auto-insert-alist): Use 'confirm' instead
't' in completing-read REQUIRE-MATCH from Emacs Lisp header
template.
---
 lisp/autoinsert.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/autoinsert.el b/lisp/autoinsert.el
index f2631422c62..561626e474b 100644
--- a/lisp/autoinsert.el
+++ b/lisp/autoinsert.el
@@ -212,7 +212,7 @@ auto-insert-alist
 	   finder-known-keywords
 	   "\n"))
  ((let ((minibuffer-help-form v2))
-    (completing-read "Keyword, C-h: " v1 nil t))
+    (completing-read "Keyword, C-h: " v1 nil 'confirm))
     str ", ")
  & -2 "
 
-- 
2.44.0.windows.1

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Eli Zaretskii]

> From: "Elijah G." <eg642616@gmail.com>
> Date: Sat, 01 Jun 2024 18:17:42 -0600
> 
> this little patch allow insert any package keywords when using
> auto-insert for insert elisp header lines.
> 
> This is more a bugfix, since there is a bug when using Vertico that get
> stuck in the keywords part, that bug can also apply to other completion
> UIs or frameworks.
> 
> Also there are some packages that uses non-standard keywords, i think it
> would be better allowing insert other keywords.

I'm not sure why it makes sense to allow keywords that are not in
finder-known-keywords.  Such a keyword will never be used by any
finder commands.

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Elijah G.]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Elijah G." <eg642616@gmail.com>
>> Date: Sat, 01 Jun 2024 18:17:42 -0600
>> 
>> this little patch allow insert any package keywords when using
>> auto-insert for insert elisp header lines.
>> 
>> This is more a bugfix, since there is a bug when using Vertico that get
>> stuck in the keywords part, that bug can also apply to other completion
>> UIs or frameworks.
>> 
>> Also there are some packages that uses non-standard keywords, i think it
>> would be better allowing insert other keywords.
>
> I'm not sure why it makes sense to allow keywords that are not in
> finder-known-keywords.  Such a keyword will never be used by any
> finder commands.

You are right, I think I've found a better way for this bugfix.
Please see the new patch attached below, thanks.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-autoinsert.el-auto-insert-alist-Allow-empty-inp.patch --]
[-- Type: text/x-patch, Size: 827 bytes --]

From 2f7f3647e2f623f3fc20fab4d130a66e191f360d Mon Sep 17 00:00:00 2001
From: "Elias G. Perez" <eg642616@gmail.com>
Date: Sun, 2 Jun 2024 20:59:23 -0600
Subject: [PATCH] * lisp/autoinsert.el (auto-insert-alist): Allow empty input
 in elisp

Allow insert empty string as initial input.
This should fix bugs from 3rd-party completion UI.
---
 lisp/autoinsert.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/autoinsert.el b/lisp/autoinsert.el
index f2631422c62..9418590aaee 100644
--- a/lisp/autoinsert.el
+++ b/lisp/autoinsert.el
@@ -212,7 +212,7 @@ auto-insert-alist
 	   finder-known-keywords
 	   "\n"))
  ((let ((minibuffer-help-form v2))
-    (completing-read "Keyword, C-h: " v1 nil t))
+    (completing-read "Keyword, C-h: " v1 nil t nil nil ""))
     str ", ")
  & -2 "
 
-- 
2.44.0.windows.1

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Eli Zaretskii]

> From: "Elijah G." <eg642616@gmail.com>
> Cc: 71313@debbugs.gnu.org
> Date: Sun, 02 Jun 2024 21:14:34 -0600
> 
> >> From: "Elijah G." <eg642616@gmail.com>
> >> Date: Sat, 01 Jun 2024 18:17:42 -0600
> >> 
> >> this little patch allow insert any package keywords when using
> >> auto-insert for insert elisp header lines.
> >> 
> >> This is more a bugfix, since there is a bug when using Vertico that get
> >> stuck in the keywords part, that bug can also apply to other completion
> >> UIs or frameworks.
> >> 
> >> Also there are some packages that uses non-standard keywords, i think it
> >> would be better allowing insert other keywords.
> >
> > I'm not sure why it makes sense to allow keywords that are not in
> > finder-known-keywords.  Such a keyword will never be used by any
> > finder commands.
> 
> You are right, I think I've found a better way for this bugfix.
> Please see the new patch attached below, thanks.

Thanks, but how will an empty string "fix bugs from 3rd-party
completion UI"?  What am I missing here?

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Elijah G.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Elijah G." <eg642616@gmail.com>
>> Cc: 71313@debbugs.gnu.org
>> Date: Sun, 02 Jun 2024 21:14:34 -0600
>>
>> >> From: "Elijah G." <eg642616@gmail.com>
>> >> Date: Sat, 01 Jun 2024 18:17:42 -0600
>> >>
>> >> this little patch allow insert any package keywords when using
>> >> auto-insert for insert elisp header lines.
>> >>
>> >> This is more a bugfix, since there is a bug when using Vertico that get
>> >> stuck in the keywords part, that bug can also apply to other completion
>> >> UIs or frameworks.
>> >>
>> >> Also there are some packages that uses non-standard keywords, i think it
>> >> would be better allowing insert other keywords.
>> >
>> > I'm not sure why it makes sense to allow keywords that are not in
>> > finder-known-keywords.  Such a keyword will never be used by any
>> > finder commands.
>>
>> You are right, I think I've found a better way for this bugfix.
>> Please see the new patch attached below, thanks.
>
> Thanks, but how will an empty string "fix bugs from 3rd-party
> completion UI"?  What am I missing here?

When using Completions UI such as Vertico or Helm, there is no way to
exit from Keyword Section to go to next auto-insert Sections unless the
user press a key sequense, for auto-insert input a empty string allow
close Keyword section without cancelling the next auto-insert actions.

This can be more a problem with `completing-read' than Completions UI,
that is why setting an empty string as default value fix this and can
fix this similar issue to other completions packages.

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Elijah,

"Elijah G." <eg642616@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: "Elijah G." <eg642616@gmail.com>
>>> Cc: 71313@debbugs.gnu.org
>>> Date: Sun, 02 Jun 2024 21:14:34 -0600
>>>
>>> >> From: "Elijah G." <eg642616@gmail.com>
>>> >> Date: Sat, 01 Jun 2024 18:17:42 -0600
>>> >>
>>> >> this little patch allow insert any package keywords when using
>>> >> auto-insert for insert elisp header lines.
>>> >>
>>> >> This is more a bugfix, since there is a bug when using Vertico that get
>>> >> stuck in the keywords part, that bug can also apply to other completion
>>> >> UIs or frameworks.
>>> >>
>>> >> Also there are some packages that uses non-standard keywords, i think it
>>> >> would be better allowing insert other keywords.
>>> >
>>> > I'm not sure why it makes sense to allow keywords that are not in
>>> > finder-known-keywords.  Such a keyword will never be used by any
>>> > finder commands.
>>>
>>> You are right, I think I've found a better way for this bugfix.
>>> Please see the new patch attached below, thanks.
>>
>> Thanks, but how will an empty string "fix bugs from 3rd-party
>> completion UI"?  What am I missing here?
>
> When using Completions UI such as Vertico or Helm, there is no way to
> exit from Keyword Section to go to next auto-insert Sections unless the
> user press a key sequense, for auto-insert input a empty string allow
> close Keyword section without cancelling the next auto-insert actions.

FWIW, I'm not sure I understand the problem: I just tried using Vertico
to fill in a new .el file with auto-insert, and ISTM that in the
Keywords step both C-M-m and C-M-c already work as expected and let you
continue to the next step.


Best,

Eshel

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Eli Zaretskii]

> From: "Elijah G." <eg642616@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  71313@debbugs.gnu.org
> Date: Tue, 04 Jun 2024 18:54:19 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, but how will an empty string "fix bugs from 3rd-party
> > completion UI"?  What am I missing here?
> 
> When using Completions UI such as Vertico or Helm, there is no way to
> exit from Keyword Section to go to next auto-insert Sections unless the
> user press a key sequense, for auto-insert input a empty string allow
> close Keyword section without cancelling the next auto-insert actions.

But why would the user want to exit the Keyword Section without
inputting keywords?  And why are Vertico and Helm special in this
regard?

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Elijah G]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

El mié., 5 de junio de 2024 5:32 a. m., Eli Zaretskii <eliz@gnu.org>
escribió:

> > From: "Elijah G." <eg642616@gmail.com>
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  71313@debbugs.gnu.org
> > Date: Tue, 04 Jun 2024 18:54:19 -0600
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > Thanks, but how will an empty string "fix bugs from 3rd-party
> > > completion UI"?  What am I missing here?
> >
> > When using Completions UI such as Vertico or Helm, there is no way to
> > exit from Keyword Section to go to next auto-insert Sections unless the
> > user press a key sequense, for auto-insert input a empty string allow
> > close Keyword section without cancelling the next auto-insert actions.
>
> But why would the user want to exit the Keyword Section without
> inputting keywords?  And why are Vertico and Helm special in this
> regard?
>

I didn't mean to exit without input any keyword, after inserting the
keyword it will ask again for add more keywords, the problem is that It's
an infinite loop that it's not possible exit without pressing any
keybinding for insert an empty string (e.g. M-RET in Vertico), AFAIK
Vertico (and helm according to some commentaries) have this problem because
they use strictly the completing-read completion table for their candidates
when require-match is non-nil, the patch can be applied since it is just a
little change without any side-effect.

I think i will need to change the commit message for the patch, because it
can misunderstand.

>

[-- Attachment #2: Type: text/html, Size: 2465 bytes --]

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Thierry Volpiatto]

Elijah G <eg642616@gmail.com> writes:

> El mié., 5 de junio de 2024 5:32 a. m., Eli Zaretskii <eliz@gnu.org>
> escribió:
>
>     > From: "Elijah G." <eg642616@gmail.com>
>     > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 
> 71313@debbugs.gnu.org
>     > Date: Tue, 04 Jun 2024 18:54:19 -0600
>     >
>     > Eli Zaretskii <eliz@gnu.org> writes:
>     >
>     > > Thanks, but how will an empty string "fix bugs from 3rd-party
>     > > completion UI"?  What am I missing here?
>     >
>     > When using Completions UI such as Vertico or Helm, there is no
> way to
>     > exit from Keyword Section to go to next auto-insert Sections
> unless the
>     > user press a key sequense, for auto-insert input a empty string
> allow
>     > close Keyword section without cancelling the next auto-insert
> actions.
>    
>     But why would the user want to exit the Keyword Section without
>     inputting keywords?  And why are Vertico and Helm special in this
>     regard?
>
> I didn't mean to exit without input any keyword, after inserting the
> keyword it will ask again for add more keywords, the problem is that
> It's an infinite loop that it's not possible exit
> without pressing any keybinding for insert an empty string (e.g. M-RET
> in Vertico), AFAIK Vertico (and helm according to some commentaries)
> have this problem because they use strictly the
> completing-read completion table for their candidates when
> require-match is non-nil, the patch can be applied since it is just a
> little change without any side-effect.

You can exit the minibuffer with empty string in Helm with C-RET.

-- 
Thierry

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Elijah G]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]

I think this can be closed since this is more a problem with Vertico (and
probably Helm) as far as i could see.

[-- Attachment #2: Type: text/html, Size: 134 bytes --]

bug#71313: [PATCH] Allow insert other elisp keywords in auto-insert

[Eli Zaretskii]

> From: Elijah G <eg642616@gmail.com>
> Date: Fri, 7 Jun 2024 22:32:47 -0600
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 71313@debbugs.gnu.org
> 
> I think this can be closed since this is more a problem with Vertico (and probably Helm) as far as i could see.

Thanks, done.