bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Van Ly]

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


After entering a line of text in two column mode the merge operation 
leaves the second column window showing

  . http://sdf.org/~van.ly/img/emacs-2C-merge--fails.jpg

Unexpected result in the above picture shows second column window.

Steps to reproduce

  . start "emacs -Q"
  . open file "/dev/shm/text.text"
  . enter two column mode by "F2 2"
  . enter a line of text in two column windows
  . merge the two column windows by "F2 1"

Expected result has one window with one line of text in two columns.

-- 
vl
 				 ALPINE 2.24 GNU Emacs 27.2 NetBSD 9.3

[-- Attachment #2: bug report --]
[-- Type: text/plain, Size: 3129 bytes --]

In GNU Emacs 28.1.91 (build 1, aarch64-unknown-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2022-08-08 built on charlie
Repository revision: 059ab47a0664012b4d8cf8cc36b7d8a28b80c614
Repository branch: main
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 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: Text

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
  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 dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-start
cus-load quail help-fns radix-tree help-mode cl-loaddefs cl-lib
two-column mule-util info 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
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 75069 6598)
 (symbols 48 8286 1)
 (strings 32 32837 1542)
 (string-bytes 1 832363)
 (vectors 16 16122)
 (vector-slots 8 226972 12552)
 (floats 8 31 50)
 (intervals 56 436 11)
 (buffers 992 15))

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Eli Zaretskii]

> Date: Fri, 12 Aug 2022 17:55:49 +0000 (UTC)
> From: Van Ly <van.ly@sdf.org>
> 
> After entering a line of text in two column mode the merge operation 
> leaves the second column window showing
> 
>   . http://sdf.org/~van.ly/img/emacs-2C-merge--fails.jpg
> 
> Unexpected result in the above picture shows second column window.
> 
> Steps to reproduce
> 
>   . start "emacs -Q"
>   . open file "/dev/shm/text.text"
>   . enter two column mode by "F2 2"
>   . enter a line of text in two column windows
>   . merge the two column windows by "F2 1"
> 
> Expected result has one window with one line of text in two columns.

Which part of the 2C mode documentation led you to expect to see just
one window after "F2 1"?

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Van Ly]

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

On Fri, 12 Aug 2022, Eli Zaretskii wrote:

>>
>> Expected result has one window with one line of text in two columns.
>
> Which part of the 2C mode documentation led you to expect to see just
> one window after "F2 1"?
>

The documentation says the following.

```

      When you have edited both buffers as you wish, merge them with ‘<F2>
   1’ or ‘C-x 6 1’ (‘2C-merge’).  This copies the text from the right-hand
   buffer as a second column in the other buffer.  To go back to two-column
   editing, use ‘<F2> s’.

```

Documentation  and  actual behavior  drift  apart  is a  common  place
expectation in  software.  My familiarity  with C-x 1 carried  over to
C-x 6 1.

-- 
vl
 				 ALPINE 2.24 GNU Emacs 27.2 NetBSD 9.3

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Eli Zaretskii]

> Date: Fri, 12 Aug 2022 19:10:40 +0000 (UTC)
> From: Van Ly <van.ly@sdf.org>
> cc: 57161@debbugs.gnu.org
> 
> > Which part of the 2C mode documentation led you to expect to see just
> > one window after "F2 1"?
> 
> The documentation says the following.
> 
> ```
> 
>       When you have edited both buffers as you wish, merge them with ‘<F2>
>    1’ or ‘C-x 6 1’ (‘2C-merge’).  This copies the text from the right-hand
>    buffer as a second column in the other buffer.  To go back to two-column
>    editing, use ‘<F2> s’.
> 
> ```

Where does this say that the other window gets deleted?

> Documentation  and  actual behavior  drift  apart  is a  common  place
> expectation in  software.  My familiarity  with C-x 1 carried  over to
> C-x 6 1.

In this case, extrapolating from "C-x 1" leads to incorrect
expectations.

I see no bug in the current behavior of "F2 1".

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Van Ly]

On Fri, 12 Aug 2022, Eli Zaretskii wrote:

>
> Where does this say that the other window gets deleted?
>

I expect F2 2, F2 1 will get me back to the frame and window 
layout at the moment before F2 2.

>> Documentation  and  actual behavior  drift  apart  is a  common  place
>> expectation in  software.  My familiarity  with C-x 1 carried  over to
>> C-x 6 1.
>
> In this case, extrapolating from "C-x 1" leads to incorrect
> expectations.
>
> I see no bug in the current behavior of "F2 1".
>

I see.

Before pressing F2 2, a new file called "text.text" is in text mode.

Pressing F2  2, F2 1,  leaves the  file in Text  2C mode and  that 2nd
column window is  pushed to the side.   Is there a way to  get back to
plain text mode  and the original one window?   M-x normal-mode won't.
M-x text-mode won't.   The modeline shows "2C".  I don't  know what to
do with that marginal window.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Eli Zaretskii]

> Date: Fri, 12 Aug 2022 19:43:01 +0000 (UTC)
> From: Van Ly <van.ly@sdf.org>
> cc: 57161@debbugs.gnu.org
> 
> On Fri, 12 Aug 2022, Eli Zaretskii wrote:
> 
> >
> > Where does this say that the other window gets deleted?
> 
> I expect F2 2, F2 1 will get me back to the frame and window 
> layout at the moment before F2 2.

That's not what "F2 1" does.

> Before pressing F2 2, a new file called "text.text" is in text mode.
> 
> Pressing F2  2, F2 1,  leaves the  file in Text  2C mode and  that 2nd
> column window is  pushed to the side.   Is there a way to  get back to
> plain text mode  and the original one window?

Yes: "C-x 1".

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I expect F2 2, F2 1 will get me back to the frame and window 
>> layout at the moment before F2 2.
>
> That's not what "F2 1" does.

I've never used this mode before, and I'm kinda flabbergasted that
something as esoteric as this is bound to <f2> by default.

Anyway, I don't really see how the current <f2> 1 action makes much
sense -- it merges the two buffers, but then keeps displaying the
rightmost window, but extremely narrowly?  I'm not sure why that's
useful.

(I'd expect, like Van Ly, this command to remove that window.)

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've never used this mode before, and I'm kinda flabbergasted that
> something as esoteric as this is bound to <f2> by default.

Esoteric is understating the case, but yes that keybinding should be
freed up (if nothing else, to avoid users accidentally activating
2C-mode).

> Anyway, I don't really see how the current <f2> 1 action makes much
> sense -- it merges the two buffers, but then keeps displaying the
> rightmost window, but extremely narrowly?  I'm not sure why that's
> useful.

It gets even worse: when you repeat <f2> 2 <f2> 1 <f2> 2, etc., you
start accumulating windows to the right.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 13 Aug 2022 14:47:42 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Van Ly <van.ly@sdf.org>, 57161@debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > I've never used this mode before, and I'm kinda flabbergasted that
> > something as esoteric as this is bound to <f2> by default.
> 
> Esoteric is understating the case, but yes that keybinding should be
> freed up (if nothing else, to avoid users accidentally activating
> 2C-mode).

No, we won't "free it up", not on my watch, not unless we are
deleting the mode which uses it since Emacs 19.

> It gets even worse: when you repeat <f2> 2 <f2> 1 <f2> 2, etc., you
> start accumulating windows to the right.

"Doctor, it hurts when I do so-and-so" -- "Well, then don't do that!"

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Van Ly]

On Sat, 13 Aug 2022, Stefan Kangas wrote:

>
> Esoteric is understating the case, but yes that keybinding should be
> freed up (if nothing else, to avoid users accidentally activating
> 2C-mode).
>

I am  a traditionalist  and prefer F2  to stay were  it is.   Maybe it
gravitational  lenses  back  to  a time  when  Liberal  Arts  students
programmed  and   wrote  marginalia  or  translations   between  human
languages.  Academic papers are printed in two-column.

2C-mode needs a tutorial style introduction for newbs.

-- 
vl

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Esoteric is understating the case, but yes that keybinding should be
> freed up (if nothing else, to avoid users accidentally activating
> 2C-mode).

The saving grace here is that <f2> on its own does nothing, and there's
approx. zero chance of somebody stabbing `2' after the <f2>, so it's not
that serious.

So the normal user reaction to <f2> is probably "uhm... `C-g'...  Emacs
sucks..."

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Van Ly <van.ly@sdf.org>,
>   57161@debbugs.gnu.org
> Date: Mon, 15 Aug 2022 07:58:41 +0200
> 
> So the normal user reaction to <f2> is probably "uhm... `C-g'...  Emacs
> sucks..."

We don't need any steenking "normal" users to know that Emacs sucks.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Van Ly <van.ly@sdf.org>,  57161@debbugs.gnu.org
> Date: Sat, 13 Aug 2022 14:23:25 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I expect F2 2, F2 1 will get me back to the frame and window 
> >> layout at the moment before F2 2.
> >
> > That's not what "F2 1" does.
> 
> I've never used this mode before, and I'm kinda flabbergasted that
> something as esoteric as this is bound to <f2> by default.
> 
> Anyway, I don't really see how the current <f2> 1 action makes much
> sense -- it merges the two buffers, but then keeps displaying the
> rightmost window, but extremely narrowly?  I'm not sure why that's
> useful.
> 
> (I'd expect, like Van Ly, this command to remove that window.)

I presume that this mode does have its regular users, and so it would
be unthinkable to change this behavior because we are "flabbergasted".
I can see a certain logic behind what "F2 1" does, and since neither
of us uses this mode, I don't think our opinions otherwise matter.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I can see a certain logic behind what "F2 1" does, and since neither
> of us uses this mode, I don't think our opinions otherwise matter.

We have one known user of this mode, and 100% of that one user says that
what `<f2> 1' does doesn't make much sense, so perhaps we should listen
to that user?

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've never used this mode before, and I'm kinda flabbergasted that
> something as esoteric as this is bound to <f2> by default.

That whole 2C library is a bit esoteric.

If you edit the remaining narrow window and try to merge (again), the
second column is actually doubled in the original buffer.  That narrow
window is useless, it's even harmful!

BTW, I tried a buffer with this contents:

1 11
2 22
3 33

If you place the cursor before the separator (space char) instead of
after it, C-x 6 s infloops.  Not nice.


I then though: Do these narrow windows maybe suggest that one can
iterate 2C processing to conveniently edit more than two columns?  But
no, that just messes the original buffer if you try.


So this bug report is one detail.  The whole library doesn't look very
intuitive and user friendly.  Maybe 0.02 users in the world understand
it and make good use of it.  Or maybe it has never been a good package.

I have tried to use it multiple times and was always disappointed about
the experience.  It gives an unfinished impression.  Seems not good that
it occupies F2, and also not good that it's built in.

Michael.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Van Ly <van.ly@sdf.org>,
>   57161@debbugs.gnu.org
> Date: Tue, 16 Aug 2022 03:24:56 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > I've never used this mode before, and I'm kinda flabbergasted that
> > something as esoteric as this is bound to <f2> by default.
> 
> That whole 2C library is a bit esoteric.
> 
> If you edit the remaining narrow window and try to merge (again), the
> second column is actually doubled in the original buffer.  That narrow
> window is useless, it's even harmful!
> 
> BTW, I tried a buffer with this contents:
> 
> 1 11
> 2 22
> 3 33
> 
> If you place the cursor before the separator (space char) instead of
> after it, C-x 6 s infloops.  Not nice.
> 
> 
> I then though: Do these narrow windows maybe suggest that one can
> iterate 2C processing to conveniently edit more than two columns?  But
> no, that just messes the original buffer if you try.
> 
> 
> So this bug report is one detail.  The whole library doesn't look very
> intuitive and user friendly.  Maybe 0.02 users in the world understand
> it and make good use of it.  Or maybe it has never been a good package.
> 
> I have tried to use it multiple times and was always disappointed about
> the experience.  It gives an unfinished impression.  Seems not good that
> it occupies F2, and also not good that it's built in.

I'm sorry to be blunt, but to me, this and other similar postings
sound like shooting first and painting the target around the shot
afterwards.

IOW, there's no need for a long report of "findings" if all you want
to say is "I don't use this and I don't like how it works".  It is
shorter and much more clear to say the latter.  Also more direct.

If people want to deprecate/obsolete and eventually remove this
package if no one uses it, I'm perfectly okay with starting that
process now.  Then, when we eventually delete it, or maybe even after
enough years in lisp/obsolete/, we can "free" the F2 binding.  But
doing this abruptly, right now, just because we never before looked at
the package, is a non-starter: that's not how we obsolete and remove
old stuff in Emacs.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> IOW, there's no need for a long report of "findings" if all you want
> to say is "I don't use this and I don't like how it works".  It is
> shorter and much more clear to say the latter.  Also more direct.

Sorry for being verbose.  My intention was actually to hint at the idea
that there might be no good reason for some aspects of the behavior of
this package, and it might be wasted time to spend too much energy here.
I only gave those examples to avoid the impression that I just find the
package suspect and actually never had tried it or so...that's not the
case.

Michael.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Van Ly]

On Wed, 17 Aug 2022, Michael Heerdegen wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>           "I don't use this and I don't like how it works" 
>

I want to use this and I haven't figured out how it works.

My knowledge transfer from "buffer narrow" and "buffer widen" function
doesn't translate to "F2  2" and "F2  1". Doing it wrong means  I keep
creating those secondary column windows I can hide with C-x 1.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Lars Ingebrigtsen]

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

> I want to use this and I haven't figured out how it works.

I think Michael's findings show that it just doesn't.

Not very well, at least.

The question is then what to do about it -- spend time, trying to fix
it, or just decide to deprecate it.

bug#57161: 28.1.91; two column windows merge leaves 2nd column window showing

[Van Ly]

On Fri, 12 Aug 2022, Eli Zaretskii wrote:

>> I expect F2 2, F2 1 will get me back to the frame and window
>> layout at the moment before F2 2.
>
> That's not what "F2 1" does.
>

Maybe "F2 1" is  a midway stage in the workflow, one  then uses "F2 s"
to resume two-column editing, the narrowed secondary window is brought
back to visual balance by "C-x +" ; I've always wanted to take control
in the two-column mode but have left it in the too hard basket because
of the narrowed window.

>> Before pressing F2 2, a new file called "text.text" is in text mode.
>>
>> Pressing F2  2, F2 1,  leaves the  file in Text  2C mode and  that 2nd
>> column window is  pushed to the side.   Is there a way to  get back to
>> plain text mode  and the original one window?
>
> Yes: "C-x 1".
>

Ah.  That makes sense.  Thanks!