* Awful completion buffer behaviour [not found] <878rwdtjum.fsf.ref@yahoo.com> @ 2021-12-22 3:10 ` Po Lu 2021-12-22 8:54 ` Juri Linkov ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Po Lu @ 2021-12-22 3:10 UTC (permalink / raw) To: emacs-devel Pressing tab in the minibuffer when a completions buffer is visible used to scroll the window containing that buffer. In Emacs 29, it selects that window instead, and moves point to the next visible completion. That behaviour is horrid, and even worse, I didn't find a NEWS entry detailing how to turn it off (it should be off by default anyway). Please remove the offending change or put it behind a switch. Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 3:10 ` Awful completion buffer behaviour Po Lu @ 2021-12-22 8:54 ` Juri Linkov 2021-12-22 9:25 ` Po Lu 2021-12-22 10:39 ` Po Lu 2021-12-22 12:53 ` Eli Zaretskii 2 siblings, 1 reply; 14+ messages in thread From: Juri Linkov @ 2021-12-22 8:54 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > Pressing tab in the minibuffer when a completions buffer is visible used > to scroll the window containing that buffer. > > In Emacs 29, it selects that window instead, and moves point to the next > visible completion. Maybe TAB should not try to switch to the completions buffer when it's already visible. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 8:54 ` Juri Linkov @ 2021-12-22 9:25 ` Po Lu 2021-12-22 17:56 ` Juri Linkov 0 siblings, 1 reply; 14+ messages in thread From: Po Lu @ 2021-12-22 9:25 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel Juri Linkov <juri@linkov.net> writes: >> Pressing tab in the minibuffer when a completions buffer is visible used >> to scroll the window containing that buffer. >> >> In Emacs 29, it selects that window instead, and moves point to the next >> visible completion. > > Maybe TAB should not try to switch to the completions buffer > when it's already visible. I think TAB should scroll the window containing the buffer, and if it is not visible, it should make the buffer visible without selecting it. Otherwise, you have to press C-x o if you want to continue typing without selecting anything. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 9:25 ` Po Lu @ 2021-12-22 17:56 ` Juri Linkov 0 siblings, 0 replies; 14+ messages in thread From: Juri Linkov @ 2021-12-22 17:56 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel >>> Pressing tab in the minibuffer when a completions buffer is visible used >>> to scroll the window containing that buffer. >>> >>> In Emacs 29, it selects that window instead, and moves point to the next >>> visible completion. >> >> Maybe TAB should not try to switch to the completions buffer >> when it's already visible. > > I think TAB should scroll the window containing the buffer, and if it is > not visible, it should make the buffer visible without selecting it. > > Otherwise, you have to press C-x o if you want to continue typing > without selecting anything. Please note that auto-selecting the completions buffer might still be useful when using completion-at-point (C-M-i) in any buffer because there is no easy-to-type key to select it. So would be nice if 'completion-auto-select' allowed auto-selection only for completion-at-point. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 3:10 ` Awful completion buffer behaviour Po Lu 2021-12-22 8:54 ` Juri Linkov @ 2021-12-22 10:39 ` Po Lu 2021-12-22 12:53 ` Eli Zaretskii 2 siblings, 0 replies; 14+ messages in thread From: Po Lu @ 2021-12-22 10:39 UTC (permalink / raw) To: emacs-devel Po Lu <luangruo@yahoo.com> writes: > Pressing tab in the minibuffer when a completions buffer is visible used > to scroll the window containing that buffer. > > In Emacs 29, it selects that window instead, and moves point to the next > visible completion. > > That behaviour is horrid, and even worse, I didn't find a NEWS entry > detailing how to turn it off (it should be off by default anyway). > > Please remove the offending change or put it behind a switch. Thanks. If nobody minds, I will add a NEWS entry about `completion-auto-select' and disable it by default. Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 3:10 ` Awful completion buffer behaviour Po Lu 2021-12-22 8:54 ` Juri Linkov 2021-12-22 10:39 ` Po Lu @ 2021-12-22 12:53 ` Eli Zaretskii 2021-12-22 12:56 ` Po Lu 2021-12-22 17:40 ` Juri Linkov 2 siblings, 2 replies; 14+ messages in thread From: Eli Zaretskii @ 2021-12-22 12:53 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > From: Po Lu <luangruo@yahoo.com> > Date: Wed, 22 Dec 2021 11:10:57 +0800 > > Pressing tab in the minibuffer when a completions buffer is visible used > to scroll the window containing that buffer. > > In Emacs 29, it selects that window instead, and moves point to the next > visible completion. > > That behaviour is horrid, and even worse, I didn't find a NEWS entry > detailing how to turn it off (it should be off by default anyway). > > Please remove the offending change or put it behind a switch. Thanks. I agree that this new behavior is an unpleasant surprise for me. I'm not sure I understand the purpose of the month-long experiment with turning this on by default. Is it to decide whether it will stay on in Emacs 29? If so, the experiment can be terminated now: we will not make this the default, certainly not in Emacs 29, and maybe not even in Emacs 30. It is too radical departure of age-old Emacs behavior in the default completion commands. If the reason for the experiment is to decide whether to revert this change because this behavior is hated too much, we can continue with the experiment, of course. But I don't see why we shouldn't offer this as optional behavior anyway, so I think the experiment is not needed, and the best way ahead is to document this as optional behavior, and turn it off by default. Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 12:53 ` Eli Zaretskii @ 2021-12-22 12:56 ` Po Lu 2021-12-22 13:35 ` Po Lu 2021-12-22 14:00 ` Eli Zaretskii 2021-12-22 17:40 ` Juri Linkov 1 sibling, 2 replies; 14+ messages in thread From: Po Lu @ 2021-12-22 12:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I agree that this new behavior is an unpleasant surprise for me. > > I'm not sure I understand the purpose of the month-long experiment > with turning this on by default. Is it to decide whether it will stay > on in Emacs 29? If so, the experiment can be terminated now: we will > not make this the default, certainly not in Emacs 29, and maybe not > even in Emacs 30. It is too radical departure of age-old Emacs > behavior in the default completion commands. Thanks, will you mind if I install a change that documents the option in the NEWS entry and changes its default value to nil now? Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 12:56 ` Po Lu @ 2021-12-22 13:35 ` Po Lu 2021-12-22 14:03 ` Eli Zaretskii 2021-12-22 14:00 ` Eli Zaretskii 1 sibling, 1 reply; 14+ messages in thread From: Po Lu @ 2021-12-22 13:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Po Lu <luangruo@yahoo.com> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >> I agree that this new behavior is an unpleasant surprise for me. >> >> I'm not sure I understand the purpose of the month-long experiment >> with turning this on by default. Is it to decide whether it will stay >> on in Emacs 29? If so, the experiment can be terminated now: we will >> not make this the default, certainly not in Emacs 29, and maybe not >> even in Emacs 30. It is too radical departure of age-old Emacs >> behavior in the default completion commands. > > Thanks, will you mind if I install a change that documents the option > in the NEWS entry and changes its default value to nil now? > > Thanks. Oops, I pushed that by accident when pushing a fix to pgtkterm.c, but I think it's appropriate anyway, so I'm not going to revert it unless someone says so. Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 13:35 ` Po Lu @ 2021-12-22 14:03 ` Eli Zaretskii 0 siblings, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2021-12-22 14:03 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: emacs-devel@gnu.org > Date: Wed, 22 Dec 2021 21:35:32 +0800 > > > Thanks, will you mind if I install a change that documents the option > > in the NEWS entry and changes its default value to nil now? > > > > Thanks. > > Oops, I pushed that by accident when pushing a fix to pgtkterm.c Too bad. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 12:56 ` Po Lu 2021-12-22 13:35 ` Po Lu @ 2021-12-22 14:00 ` Eli Zaretskii 2021-12-22 14:55 ` Philip Kaludercic 1 sibling, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2021-12-22 14:00 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: emacs-devel@gnu.org > Date: Wed, 22 Dec 2021 20:56:00 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > I agree that this new behavior is an unpleasant surprise for me. > > > > I'm not sure I understand the purpose of the month-long experiment > > with turning this on by default. Is it to decide whether it will stay > > on in Emacs 29? If so, the experiment can be terminated now: we will > > not make this the default, certainly not in Emacs 29, and maybe not > > even in Emacs 30. It is too radical departure of age-old Emacs > > behavior in the default completion commands. > > Thanks, will you mind if I install a change that documents the option > in the NEWS entry and changes its default value to nil now? I'd like to hear from Juri and Philip first. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 14:00 ` Eli Zaretskii @ 2021-12-22 14:55 ` Philip Kaludercic 0 siblings, 0 replies; 14+ messages in thread From: Philip Kaludercic @ 2021-12-22 14:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Po Lu, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Po Lu <luangruo@yahoo.com> >> Cc: emacs-devel@gnu.org >> Date: Wed, 22 Dec 2021 20:56:00 +0800 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > I agree that this new behavior is an unpleasant surprise for me. >> > >> > I'm not sure I understand the purpose of the month-long experiment >> > with turning this on by default. Is it to decide whether it will stay >> > on in Emacs 29? If so, the experiment can be terminated now: we will >> > not make this the default, certainly not in Emacs 29, and maybe not >> > even in Emacs 30. It is too radical departure of age-old Emacs >> > behavior in the default completion commands. >> >> Thanks, will you mind if I install a change that documents the option >> in the NEWS entry and changes its default value to nil now? > > I'd like to hear from Juri and Philip first. The idea was to gather feedback, and this thread is one form of feedback. If the feature is as intrusive as described here (for which I would like to apologise), then it seems like it should be disabled. -- Philip Kaludercic ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 12:53 ` Eli Zaretskii 2021-12-22 12:56 ` Po Lu @ 2021-12-22 17:40 ` Juri Linkov 2021-12-23 9:06 ` Robert Pluim 1 sibling, 1 reply; 14+ messages in thread From: Juri Linkov @ 2021-12-22 17:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Po Lu, emacs-devel > I'm not sure I understand the purpose of the month-long experiment > with turning this on by default. Is it to decide whether it will stay > on in Emacs 29? If so, the experiment can be terminated now: we will > not make this the default, certainly not in Emacs 29, and maybe not > even in Emacs 30. It is too radical departure of age-old Emacs > behavior in the default completion commands. > > If the reason for the experiment is to decide whether to revert this > change because this behavior is hated too much, we can continue with > the experiment, of course. But I don't see why we shouldn't offer > this as optional behavior anyway, so I think the experiment is not > needed, and the best way ahead is to document this as optional > behavior, and turn it off by default. Like Philip already said the idea was to gather feedback, both positive and negative, to decide how to develop this feature further. Note that no one complained about the default value of another variable 'completion-wrap-movement' that is enabled now too. So now it's clear we have two possible directions: try to find such new keys that don't get in the way in the long-standing usage scenarios, and provide more variables (possibly optional) for customization. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-22 17:40 ` Juri Linkov @ 2021-12-23 9:06 ` Robert Pluim 2021-12-23 17:27 ` Juri Linkov 0 siblings, 1 reply; 14+ messages in thread From: Robert Pluim @ 2021-12-23 9:06 UTC (permalink / raw) To: Juri Linkov; +Cc: Po Lu, Eli Zaretskii, emacs-devel >>>>> On Wed, 22 Dec 2021 19:40:00 +0200, Juri Linkov <juri@linkov.net> said: Juri> Note that no one complained about the default value of another variable Juri> 'completion-wrap-movement' that is enabled now too. I donʼt see that in NEWS. Robert -- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Awful completion buffer behaviour 2021-12-23 9:06 ` Robert Pluim @ 2021-12-23 17:27 ` Juri Linkov 0 siblings, 0 replies; 14+ messages in thread From: Juri Linkov @ 2021-12-23 17:27 UTC (permalink / raw) To: Robert Pluim; +Cc: Po Lu, Eli Zaretskii, emacs-devel >>>>>> On Wed, 22 Dec 2021 19:40:00 +0200, Juri Linkov <juri@linkov.net> said: > > Juri> Note that no one complained about the default value of another variable > Juri> 'completion-wrap-movement' that is enabled now too. > > I donʼt see that in NEWS. I agree it should be mentioned in NEWS. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-12-23 17:27 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <878rwdtjum.fsf.ref@yahoo.com> 2021-12-22 3:10 ` Awful completion buffer behaviour Po Lu 2021-12-22 8:54 ` Juri Linkov 2021-12-22 9:25 ` Po Lu 2021-12-22 17:56 ` Juri Linkov 2021-12-22 10:39 ` Po Lu 2021-12-22 12:53 ` Eli Zaretskii 2021-12-22 12:56 ` Po Lu 2021-12-22 13:35 ` Po Lu 2021-12-22 14:03 ` Eli Zaretskii 2021-12-22 14:00 ` Eli Zaretskii 2021-12-22 14:55 ` Philip Kaludercic 2021-12-22 17:40 ` Juri Linkov 2021-12-23 9:06 ` Robert Pluim 2021-12-23 17:27 ` Juri Linkov
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.