GNU bug report logs - #53158
28.0.90; TAB, RET key behave differently for Git-Log-View, Outline View mode

Previous Next

Package: emacs;

Reported by: Van Ly <van.ly <at> sdf.org>

Date: Mon, 10 Jan 2022 14:22:02 UTC

Severity: normal

Tags: wontfix

Found in version 28.0.90

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53158 in the body.
You can then email your comments to 53158 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 14:22:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Van Ly <van.ly <at> sdf.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 10 Jan 2022 14:22:02 GMT) Full text and rfc822 format available.

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

From: Van Ly <van.ly <at> sdf.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.90; TAB, RET key behave differently for Git-Log-View, Outline
 View mode
Date: Mon, 10 Jan 2022 14:20:25 +0000 (UTC)
[Message part 1 (text/plain, inline)]
Hello,

The TAB and RET key behave differently for Git-Log-View mode and 
Outline View mode.  If TAB will consistently expand and collapse the 
bullet point on the tree and RET will consistently do across the two 
modes whatever the similar thing is, that will improve the UI.

Having consistent keybindings in modes for navigating bullet points 
on trees in general will greatly improve the UI experience.

A under Git-Log-View mode
* TAB (translated from <tab>) runs the command log-view-msg-next
* RET (translated from <return>) runs the command log-view-toggle-entry-display

B under Outline View mode
* TAB (translated from <tab>) runs the command outline-cycle
* RET (translated from <return>) runs the command View-scroll-line-forward

steps to reproduce in Git-Log-View mode
* open emacs by 'emacs -Q'
* goto emacs source directory
* apply C-x v l runs the command vc-print-log
* goto the first line with a bullet point
* goto A and perform TAB, RET

steps to reproduce in Outline View mode
* open emacs by 'emacs -Q'
* view file emacs/admin/README
* apply C-c C-t runs the command outline-hide-body
* goto the first line with a bullet point
* goto B and perform TAB, RET

observed behavior
* TAB, RET key behave differently for expanding and collapsing the bullet point in the two modes

expected behavior
* TAB, RET key behave consistently on bullet point headlines across the two modes

-- 
vl
[bug-gnu-emacs-28.0.90.text (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 17:55:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van Ly <van.ly <at> sdf.org>
Cc: 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90;
 TAB, RET key behave differently for Git-Log-View, Outline View mode
Date: Mon, 10 Jan 2022 19:54:01 +0200
> Date: Mon, 10 Jan 2022 14:20:25 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> 
> observed behavior
> * TAB, RET key behave differently for expanding and collapsing the bullet point in the two modes
> 
> expected behavior
> * TAB, RET key behave consistently on bullet point headlines across the two modes

There's absolute no guarantee in Emacs that a key behaves the same in
tow different modes.  Even if those two modes can be argued to be
similar in some sense.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 19:37:01 GMT) Full text and rfc822 format available.

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

From: Van Ly <van.ly <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Mon, 10 Jan 2022 19:36:43 +0000 (UTC)
On Mon, 10 Jan 2022, Eli Zaretskii wrote:

>> Date: Mon, 10 Jan 2022 14:20:25 +0000 (UTC)
>> From: Van Ly <van.ly <at> sdf.org>
>>
>> observed behavior
>> * TAB, RET key behave differently for expanding and collapsing the bullet point in the two modes
>>
>> expected behavior
>> * TAB, RET key behave consistently on bullet point headlines across the two modes
>
> There's absolute no guarantee in Emacs that a key behaves the same in
> tow different modes.  Even if those two modes can be argued to be
> similar in some sense.
>

Yes, I know.  Emacs unboxes with unpleasant defaults.  I was 
pleasantly surprised TAB expands and collapses the bullet point in 
Outline View mode.  If memory serves.  I used to have to look up 
how to do that.  What key to use.  Maybe the TAB behavior was 
pulled from Org mode to Outline mode.  Having the same key to expand, 
collapse the bullet point headline is the "Right thing to do(R)[TM]".

Perhaps, there could be configuration infrastructure policy overlay 
for having bullet points expand, collapse with the same key.  I would 
use that to page up/down View mode with B and SPC everywhere.

possible expand, collapse keybindings for bullet point headline
* TAB
* RET
* SPC

CORRECTION
> steps to reproduce in Git-Log-View mode
> * open emacs by 'emacs -Q'
> * goto emacs source directory
  * apply C-x v L runs the command vc-print-root-log
> * goto the first line with a bullet point
> * goto A and perform TAB, RET

-- 
vl





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 19:54:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Van Ly <van.ly <at> sdf.org>
Cc: 53158 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Mon, 10 Jan 2022 21:52:44 +0200
> Emacs unboxes with unpleasant defaults.  I was pleasantly
> surprised TAB expands and collapses the bullet point in Outline View mode.
> If memory serves.  I used to have to look up how to do that.  What key to
> use.  Maybe the TAB behavior was pulled from Org mode to Outline mode.
> Having the same key to expand, collapse the bullet point headline is the
> "Right thing to do(R)[TM]".
>
> Perhaps, there could be configuration infrastructure policy overlay for
> having bullet points expand, collapse with the same key.  I would use that
> to page up/down View mode with B and SPC everywhere.

We were hit by this unpleasant problem in diff-mode with outline-minor-mode.
In diff-mode TAB moves point to the next hunk, because in browsers TAB moves
to the next link.  But in outline-minor-mode TAB should expand and collapse
on the heading because TAB does this in Org mode.

So we were forced to add such filter:

  (defcustom outline-minor-mode-cycle-filter nil
    "Filter out positions on the heading available for cycling."
    :type '(choice (const :tag "Everywhere" nil)
                   (const :tag "At line beginning" bolp)
                   (const :tag "Not at line beginning"
                          (lambda () (not (bolp))))
                   (const :tag "At line end" eolp)

Then you can choose: when point is at the beginning of the outline heading,
TAB can expand and collapse outlines, when point is not at the line beginning,
TAB moves to the next hunk.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 20:00:03 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van Ly <van.ly <at> sdf.org>
Cc: 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Mon, 10 Jan 2022 21:59:30 +0200
> Date: Mon, 10 Jan 2022 19:36:43 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: 53158 <at> debbugs.gnu.org
> 
> > There's absolute no guarantee in Emacs that a key behaves the same in
> > tow different modes.  Even if those two modes can be argued to be
> > similar in some sense.
> >
> 
> Yes, I know.  Emacs unboxes with unpleasant defaults.

Is that some new way of convincing the maintainers to be more amenable
to your opinions and suggestions?  If so, it isn't working.

> I was pleasantly surprised TAB expands and collapses the bullet
> point in Outline View mode.  If memory serves.  I used to have to
> look up how to do that.  What key to use.  Maybe the TAB behavior
> was pulled from Org mode to Outline mode.  Having the same key to
> expand, collapse the bullet point headline is the "Right thing to
> do(R)[TM]".
> 
> Perhaps, there could be configuration infrastructure policy overlay 
> for having bullet points expand, collapse with the same key.  I would 
> use that to page up/down View mode with B and SPC everywhere.
> 
> possible expand, collapse keybindings for bullet point headline
> * TAB
> * RET
> * SPC
> 
> CORRECTION
> > steps to reproduce in Git-Log-View mode
> > * open emacs by 'emacs -Q'
> > * goto emacs source directory
>    * apply C-x v L runs the command vc-print-root-log
> > * goto the first line with a bullet point
> > * goto A and perform TAB, RET

A TAB as a means to cycle visibility could be a natural thing in
outline modes, but log-view-mode is not an outline mode, it's derived
from different parents.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 20:07:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: van.ly <at> sdf.org, 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Mon, 10 Jan 2022 22:06:27 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  53158 <at> debbugs.gnu.org
> Date: Mon, 10 Jan 2022 21:52:44 +0200
> 
> Then you can choose: when point is at the beginning of the outline heading,
> TAB can expand and collapse outlines, when point is not at the line beginning,
> TAB moves to the next hunk.

FWIW, I consider this not a good UI.  Having point one column to the
left or to the right of where you want to be is quite frequent, so
making a key sequence produce a very different effect depending on
that is far from being the best idea, IMO.

To me, this tells that these two modes, and the user expectations and
habits to go with them, are simply incompatible, and we shouldn't try
mixing them.  If someone wants a diff-mode-like outline mode, let's
make such a mode, and leave the original diff-mode alone.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 20:20:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: van.ly <at> sdf.org, 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Mon, 10 Jan 2022 22:18:40 +0200
>> Then you can choose: when point is at the beginning of the outline heading,
>> TAB can expand and collapse outlines, when point is not at the line beginning,
>> TAB moves to the next hunk.
>
> FWIW, I consider this not a good UI.  Having point one column to the
> left or to the right of where you want to be is quite frequent, so
> making a key sequence produce a very different effect depending on
> that is far from being the best idea, IMO.

Of course, it's not a good UI - it's a trade-off.

> To me, this tells that these two modes, and the user expectations and
> habits to go with them, are simply incompatible, and we shouldn't try
> mixing them.  If someone wants a diff-mode-like outline mode, let's
> make such a mode, and leave the original diff-mode alone.

This problem is not specific to diff-mode.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 20:23:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: van.ly <at> sdf.org, 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Mon, 10 Jan 2022 22:22:04 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: van.ly <at> sdf.org,  53158 <at> debbugs.gnu.org
> Date: Mon, 10 Jan 2022 22:18:40 +0200
> 
> > To me, this tells that these two modes, and the user expectations and
> > habits to go with them, are simply incompatible, and we shouldn't try
> > mixing them.  If someone wants a diff-mode-like outline mode, let's
> > make such a mode, and leave the original diff-mode alone.
> 
> This problem is not specific to diff-mode.

It was just an example.  There's no limit on the number of modes we
can have in Emacs.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Mon, 10 Jan 2022 21:00:02 GMT) Full text and rfc822 format available.

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

From: Van Ly <van.ly <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Mon, 10 Jan 2022 20:59:00 +0000 (UTC)
On Mon, 10 Jan 2022, Eli Zaretskii wrote:

>> Date: Mon, 10 Jan 2022 19:36:43 +0000 (UTC)
>> From: Van Ly <van.ly <at> sdf.org>
>> cc: 53158 <at> debbugs.gnu.org
>>
>>> There's absolute no guarantee in Emacs that a key behaves the same in
>>> tow different modes.  Even if those two modes can be argued to be
>>> similar in some sense.
>>>
>>
>> Yes, I know.  Emacs unboxes with unpleasant defaults.
>
> Is that some new way of convincing the maintainers to be more amenable
> to your opinions and suggestions?  If so, it isn't working.
>

A pearl comes from an irritant in the shell.

>
> A TAB as a means to cycle visibility could be a natural thing in
> outline modes, but log-view-mode is not an outline mode, it's derived
> from different parents.
>

Having the same keybinding function on the aster at position one on 
the line to unroll/rollup the headline/detail is an opportunity 
for improving the UI intuitivity across these two modes.  From an 
enduser perspective.

-- 
vl





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Tue, 11 Jan 2022 03:26:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van Ly <van.ly <at> sdf.org>
Cc: 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Tue, 11 Jan 2022 05:25:12 +0200
> Date: Mon, 10 Jan 2022 20:59:00 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: 53158 <at> debbugs.gnu.org
> 
> >> Yes, I know.  Emacs unboxes with unpleasant defaults.
> >
> > Is that some new way of convincing the maintainers to be more amenable
> > to your opinions and suggestions?  If so, it isn't working.
> >
> 
> A pearl comes from an irritant in the shell.

Only from some irritants.

> > A TAB as a means to cycle visibility could be a natural thing in
> > outline modes, but log-view-mode is not an outline mode, it's derived
> > from different parents.
> 
> Having the same keybinding function on the aster at position one on 
> the line to unroll/rollup the headline/detail is an opportunity 
> for improving the UI intuitivity across these two modes.  From an 
> enduser perspective.

I'm an end-user as well, please don't forget that.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Thu, 13 Jan 2022 09:06:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Van Ly <van.ly <at> sdf.org>, Eli Zaretskii <eliz <at> gnu.org>,
 53158 <at> debbugs.gnu.org
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Thu, 13 Jan 2022 10:05:43 +0100
Juri Linkov <juri <at> linkov.net> writes:

> We were hit by this unpleasant problem in diff-mode with outline-minor-mode.
> In diff-mode TAB moves point to the next hunk, because in browsers TAB moves
> to the next link.  But in outline-minor-mode TAB should expand and collapse
> on the heading because TAB does this in Org mode.

I think it's unfortunate that outline minor mode uses TAB, because it
crashes with so much else we're using that key for.  But I guess
there's not much we can do about it at this point.

> So we were forced to add such filter:
>
>   (defcustom outline-minor-mode-cycle-filter nil
>     "Filter out positions on the heading available for cycling."
>     :type '(choice (const :tag "Everywhere" nil)
>                    (const :tag "At line beginning" bolp)
>                    (const :tag "Not at line beginning"
>                           (lambda () (not (bolp))))
>                    (const :tag "At line end" eolp)
>
> Then you can choose: when point is at the beginning of the outline heading,
> TAB can expand and collapse outlines, when point is not at the line beginning,
> TAB moves to the next hunk.

Yup.  So I think that's the workaround here, and there's nothing really
to be done in this bug report, so I'm closing it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 13 Jan 2022 09:06:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 53158 <at> debbugs.gnu.org and Van Ly <van.ly <at> sdf.org> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 13 Jan 2022 09:06:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Thu, 13 Jan 2022 09:33:01 GMT) Full text and rfc822 format available.

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

From: Van Ly <van.ly <at> sdf.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 53158 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#53158: 28.0.90; TAB, RET key behave differently for
 Git-Log-View, Outline View mode
Date: Thu, 13 Jan 2022 09:32:45 +0000 (UTC)
On Thu, 13 Jan 2022, Lars Ingebrigtsen wrote:

> Juri Linkov <juri <at> linkov.net> writes:
>
>> We were hit by this unpleasant problem in diff-mode with outline-minor-mode.
>> In diff-mode TAB moves point to the next hunk, because in browsers TAB moves
>> to the next link.  But in outline-minor-mode TAB should expand and collapse
>> on the heading because TAB does this in Org mode.
>
> I think it's unfortunate that outline minor mode uses TAB, because it
> crashes with so much else we're using that key for.  But I guess
> there's not much we can do about it at this point.
>

I think outline minor mode and org mode should coordinate to work 
well with diff-mode TAB moves.  Use TAB and S-TAB for moving forward 
and backward to points of interest.  Use ` immediately above the TAB 
for operating on that context.  What you can do is have a file for 
design language roadmap guidance forward to overtime have 
contributors align how the TAB is to be used and phase in new 
behavior.  Give it 18-months to align and grandfather in old behavior 
people have grown callous for and are insensitive to pain point.

-- 
vl





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53158; Package emacs. (Fri, 14 Jan 2022 15:37:01 GMT) Full text and rfc822 format available.

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

From: Howard Melman <hmelman <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#53158: 28.0.90;
 TAB, RET key behave differently for Git-Log-View, Outline View mode
Date: Fri, 14 Jan 2022 10:36:21 -0500
Van Ly <van.ly <at> sdf.org> writes:

> On Thu, 13 Jan 2022, Lars Ingebrigtsen wrote:
>
>> Juri Linkov <juri <at> linkov.net> writes:
>>
>>> We were hit by this unpleasant problem in diff-mode with
>>> outline-minor-mode.  In diff-mode TAB moves point to the
>>> next hunk, because in browsers TAB moves to the next
>>> link.  But in outline-minor-mode TAB should expand and
>>> collapse on the heading because TAB does this in Org
>>> mode.
>>
>> I think it's unfortunate that outline minor mode uses
>> TAB, because it crashes with so much else we're using
>> that key for.  But I guess there's not much we can do
>> about it at this point.
>>
>
> I think outline minor mode and org mode should coordinate
> to work well with diff-mode TAB moves.  Use TAB and S-TAB
> for moving forward and backward to points of interest.
> Use ` immediately above the TAB for operating on that
> context.  What you can do is have a file for design
> language roadmap guidance forward to overtime have
> contributors align how the TAB is to be used and phase in
> new behavior.  Give it 18-months to align and grandfather
> in old behavior people have grown callous for and are
> insensitive to pain point.

When I originally proposed the outline cycling commands I
suggested C-TAB and S-TAB which I've been using for several
years.  C-TAB was rejected because it doesn't work in the
terminal.  I'm GUI only (macport) and haven't tried Emacs 28
yet, but if I find TAB conflicting with things, I hope it's
easy for me to change it to C-TAB and have it work anywhere
on the line.

I understand not wanting terminal to be a second-class
citizen (and that it has many users), but I wish its
limitations weren't so constraining on the GUI.

-- 

Howard





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 12 Feb 2022 12:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 45 days ago.

Previous Next


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