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

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

[Van Ly]

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


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

[-- Attachment #2: Type: text/plain, Size: 3517 bytes --]

In GNU Emacs 28.0.90 (build 1, aarch64-unknown-linux-gnu, X toolkit, cairo version 1.16.0)
 of 2021-12-04 built on charlie
Repository revision: f38dfa56a0cfef77c2b0d8bb2869642a4e3b2ae4
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure
 --prefix=/usr/X/Applications/emacs-2021-12-04
 --with-x-toolkit=lucid --without-toolkit-scroll-bars --without-xft
 --with-native-compilation --without-compress-install'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF X11 XAW3D
XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_AU.UTF-8
  value of $LANG: en_AU.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs
auth-source eieio eieio-core eieio-loaddefs password-cache json map
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils apropos add-log log-view pcvs-util vc-mtn vc-hg
vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc vc-git diff-mode
vc-dispatcher bug-reference comp comp-cstr warnings subr-x rx cl-seq
cl-macs cl-extra help-mode noutline outline easy-mmode view dired-aux
cl-loaddefs cl-lib dired dired-loaddefs bookmark seq byte-opt gv
bytecomp byte-compile cconv text-property-search pp iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 120043 7661)
 (symbols 48 9875 1)
 (strings 32 33160 2738)
 (string-bytes 1 1039522)
 (vectors 16 21671)
 (vector-slots 8 393225 15191)
 (floats 8 64 32)
 (intervals 56 1208 0)
 (buffers 992 18))

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

[Eli Zaretskii]

> Date: Mon, 10 Jan 2022 14:20:25 +0000 (UTC)
> From: Van Ly <van.ly@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.

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

[Van Ly]

On Mon, 10 Jan 2022, Eli Zaretskii wrote:

>> Date: Mon, 10 Jan 2022 14:20:25 +0000 (UTC)
>> From: Van Ly <van.ly@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

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

[Juri Linkov]

> 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.

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

[Eli Zaretskii]

> Date: Mon, 10 Jan 2022 19:36:43 +0000 (UTC)
> From: Van Ly <van.ly@sdf.org>
> cc: 53158@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.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  53158@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.

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

[Juri Linkov]

>> 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.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: van.ly@sdf.org,  53158@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.

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

[Van Ly]

On Mon, 10 Jan 2022, Eli Zaretskii wrote:

>> Date: Mon, 10 Jan 2022 19:36:43 +0000 (UTC)
>> From: Van Ly <van.ly@sdf.org>
>> cc: 53158@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

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

[Eli Zaretskii]

> Date: Mon, 10 Jan 2022 20:59:00 +0000 (UTC)
> From: Van Ly <van.ly@sdf.org>
> cc: 53158@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.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@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

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

[Van Ly]

On Thu, 13 Jan 2022, Lars Ingebrigtsen wrote:

> Juri Linkov <juri@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

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

[Howard Melman]

Van Ly <van.ly@sdf.org> writes:

> On Thu, 13 Jan 2022, Lars Ingebrigtsen wrote:
>
>> Juri Linkov <juri@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