bug#18793: 24.4; zero width rectangular selection displaces text

bug#18793: 24.4; zero width rectangular selection displaces text

[Carlos Pita]

1) Put the point at the beginning of the following sequence of a's.
2) Start a rectangular selection with C-x Space.
3) Move the point one char to the right.
4) Move it one char to the left so that it returns to the left margin.
5) Repeat 3 and 4 a number of times.

aaaaaaaaaaa

Do you see how the sequences of a's moves back and forward? This is not
nice and the example is not that artificial. Having lines separated by
empty lines is very common, so:

1) Put the point at the beginning of the following sequence of a's.
2) Start a rectangular selection with C-x Space.
3) Move the point one char to the right to make the selection width = 1.
4) Move the point down 5 times to extend the selection up to the line of c's.

aaaaaaaaaaa

bbbbbbbbbbb

ccccccccccc

Text looks like jelly, doesn't it? I understand that having a visual
indicator of the empty selection is a good thing but what about the
following alternatives:

a) Keep the thin line near the fringe even when the selection is not
zero width, so no displacement will happen. Or,

b) Use the fringe instead of the buffer.








In GNU Emacs 24.4.1 (i686-pc-linux-gnu, GTK+ Version 3.12.2)
 of 2014-10-22 on carlos
Windowing system distributor `The X.Org Foundation', version 11.0.11502000
Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LC_COLLATE: C
  value of $LC_TIME: es_AR.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Article

Minor modes in effect:
  show-paren-mode: t
  shell-dirtrack-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  ido-ubiquitous-mode: t
  ido-everywhere: t
  winner-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <down-mouse-4> <mouse-4> <double-down-mouse-4> 
<double-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <triple-down-mouse-4> <triple-mouse-4> 
<triple-down-mouse-4> <triple-mouse-4> <triple-down-mouse-4> 
<triple-mouse-4> <down-mouse-5> <mouse-5> <double-down-mouse-5> 
<double-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <down-mouse-5> 
<mouse-5> <double-down-mouse-5> <double-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> <triple-down-mouse-5> <triple-mouse-5> 
<triple-down-mouse-5> <triple-mouse-5> <triple-down-mouse-5> 
<triple-mouse-5> C-x k <return> <down> <down> <down> 
<down> <down> <up> <up> C-x SPC <up> <up> <right> <right> 
<right> <right> <right> <right> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<up> <up> <up> <up> <up> <up> <up> <up> C-g <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <up> <up> <up> <up> <up> <up> <up> <up> <prior> 
<prior> <up> <up> <up> <up> C-SPC <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <up> <up> 
<up> C-x SPC <down> <down> <down> <down> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<down> <down> <up> <right> <right> <right> <left> <left> 
<down> <right> <down> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> C-g <up> M-x r e p o r t - 
e m a c s <tab> <return>

Recent messages:
byte-code: Beginning of buffer
Contacting host: www.google.com.ar:80
byte-code: End of buffer [4 times]
Mark set
Mark set (rectangle mode)
Quit
End of buffer [2 times]
scroll-down-command: Beginning of buffer
Mark set
Rectangle-Mark mode enabled
Quit

Load-path shadows:
~/.emacs.d/lisp/rmail hides /usr/share/emacs/24.4/lisp/mail/rmail

Features:
(shadow emacsbug sendmail rect url-queue timezone shr-color color
url-http url-gw url-auth eww mm-url shr sort smiley gnus-cite mail-extr
gnus-async gnus-bcklg gnus-ml disp-table gnus-topic nndraft nnmh
nnfolder utf-7 gnutls network-stream starttls nnimap parse-time tls utf7
netrc gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp
gnus-cache google-contacts-gnus gnus-art mm-uu mml2015 mm-view mml-smime
smime dig gnus-sum nnoo gnus-group gnus-undo nnmail mail-source
google-contacts-message google-contacts xml url-cache url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
mailcap url-util url-parse auth-source eieio byte-opt bytecomp
byte-compile cconv eieio-core password-cache url-vars google-oauth
gnus-start gnus-spec gnus-int gnus-range message idna rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems
nnheader gnus-util mail-utils mm-util mail-prsvr wid-edit vc-git
epa-file epa derived epg server paredit edmacro kmacro paren cl-macs
ob-python ob-R org org-macro org-footnote org-pcomplete org-list
org-faces org-entities noutline outline easy-mmode org-version
ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys
ob-comint ob-core ob-eval org-compat org-macs org-loaddefs find-func
cal-menu calendar cal-loaddefs ess-toolbar ess-mouse mouseme thingatpt
browse-url ess-menu ess-swv ess-noweb ess-noweb-font-lock-mode
ess-bugs-l essd-els ess-sas-d ess-sas-l ess-sas-a shell pcomplete
ess-sta-d ess-sta-l cc-vars cc-defs make-regexp ess-sp6-d ess-sp3-d
ess-julia ess-r-d compile ess-tracebug format-spec ess-roxy hideshow
ess-help ess-developer ess-r-args eldoc ess-s-l ess ess-inf comint
ansi-color ess-mode ess-noweb-mode ess-utils time-date ess-custom
executable ess-compat ess-site yasnippet help-mode cl gv ido-ubiquitous
cl-loaddefs cl-lib advice help-fns imenu-anywhere imenu ido windmove
winner ring info easymenu package epg-config wombat-theme tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 8 329590 34438)
 (symbols 24 43603 0)
 (miscs 20 317 1004)
 (strings 16 96587 8119)
 (string-bytes 1 3029362)
 (vectors 8 43899)
 (vector-slots 4 1544164 30648)
 (floats 8 797 571)
 (intervals 28 539 279)
 (buffers 512 31)
 (heap 1024 70848 1737))

bug#18793: 24.4; zero width rectangular selection displaces text

[Stefan Monnier]

> Text looks like jelly, doesn't it? I understand that having a visual
> indicator of the empty selection is a good thing but what about the
> following alternatives:

Using the fringe is kind of problematic since the fringe may not be
displayed, and it also mean it's displayed "elsewhere", which is
less convenient.

Keeping the thin line is an alternative I hadn't considered, since
I think this thin line is a problem.  But indeed maybe the movement is
worse than the thin line itself, so maybe keeping the thin line is
a better option.

FWIW, I think the better option is to provide a way to draw a thin line
that does not shift the rest of the text.  But I think that requires
changes in the redisplay code.


        Stefan

bug#18793: 24.4; zero width rectangular selection displaces text

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 22 Oct 2014 13:29:30 -0400
> Cc: 18793@debbugs.gnu.org
> 
> FWIW, I think the better option is to provide a way to draw a thin line
> that does not shift the rest of the text.

You could change the cursor to a vertical bar, and change its color to
match the color of the region.

Another possibility is to make a composition of the character at point
and some zero-width character (which we display as a thin space).  The
display engine already supports compositions, so the only problem is
to create one that will look "right", and solve the color issue in
some reasonable way.

Yet another possibility is to have a new cursor type that would
display a small portion of the block in another color.  This does
require changes to C code, but they are relatively simple and
straightforward.

bug#18793: 24.4; zero width rectangular selection displaces text

[Stefan Monnier]

> You could change the cursor to a vertical bar, and change its color to
> match the color of the region.

The main use is not when the rectangle is completely empty (i.e. when
mark = point) but when the rectangle has 0 width, so you see where the
mark is and you see on each line the 0-width boundary of the rectangle.

So changing the cursor doesn't quite give me what I want.

> Another possibility is to make a composition of the character at point
> and some zero-width character (which we display as a thin space).

Hmm... that's a possibility.  Sounds costly (compared to "draw a line"),
but maybe it could work.


        Stefan

bug#18793: 24.4; zero width rectangular selection displaces text

[Lars Ingebrigtsen]

Carlos Pita <carlosjosepita@gmail.com> writes:

> 1) Put the point at the beginning of the following sequence of a's.
> 2) Start a rectangular selection with C-x Space.
> 3) Move the point one char to the right.
> 4) Move it one char to the left so that it returns to the left margin.
> 5) Repeat 3 and 4 a number of times.
>
> aaaaaaaaaaa
>
> Do you see how the sequences of a's moves back and forward? 

I can confirm that this behaviour is still present in Emacs 29.

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

bug#18793: 24.4; zero width rectangular selection displaces text

[Eli Zaretskii]

> Cc: 18793@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 05 May 2022 15:16:40 +0200
> 
> Carlos Pita <carlosjosepita@gmail.com> writes:
> 
> > 1) Put the point at the beginning of the following sequence of a's.
> > 2) Start a rectangular selection with C-x Space.
> > 3) Move the point one char to the right.
> > 4) Move it one char to the left so that it returns to the left margin.
> > 5) Repeat 3 and 4 a number of times.
> >
> > aaaaaaaaaaa
> >
> > Do you see how the sequences of a's moves back and forward? 
> 
> I can confirm that this behaviour is still present in Emacs 29.

AFAIU, that's a feature: we are trying to indicate the existence of
the selection, even though its width is zero.  Type "M-x
describe-text-properties RET" at the first character.  The indication
must take up some space on display, so it moves the following text to
the right.

bug#18793: 24.4; zero width rectangular selection displaces text

[Drew Adams]

> > > 1) Put the point at the beginning of the following sequence of a's.
> > > 2) Start a rectangular selection with C-x Space.
> > > 3) Move the point one char to the right.
> > > 4) Move it one char to the left so that it returns to the left
> margin.
> > > 5) Repeat 3 and 4 a number of times.
> > >
> > > aaaaaaaaaaa
> > >
> > > Do you see how the sequences of a's moves back and forward?
> >
> > I can confirm that this behaviour is still present in Emacs 29.
> 
> AFAIU, that's a feature: we are trying to indicate the existence of
> the selection, even though its width is zero.  Type "M-x
> describe-text-properties RET" at the first character.  The indication
> must take up some space on display, so it moves the following text to
> the right.

Some indication that the selection is active and
rectangular is needed - that's a good idea.

But this slight movement isn't the greatest way
to indicate this.  It's barely noticeable (but
it helps IMO, and is better than nothing).

We do also show a message when you turn on
Rectangle-Mark mode (with `C-x SPD').  That's OK.

But then when you move point to select more than
an empty selection the text moves back again
(reverse slight motion).

So this "jiggle" indicates change to and from an
empty selection, not whether rectangle mark mode
is on or off.  That's fine, but there's no msg
or other indication (apart from the jiggle) for
change to/from an empty rectangular selection.

I think we could do better.
___

Here's one possibility:

With minor mode `modeline-region-mode', from
`modeline-region.el', the region state is shown
in the mode-line whenever the region is active.

E.g., with point at the start of that line of
aaaaaaaaaaa, after using `C-x SPC' you see this in
the mode-line, highlighted with face `mlr-region'
(by default it looks the same as face `region'):

  1 rows, 0 cols

That is, in rectangle-mark mode, the size
indication shows the region size as the number of
rows and columns.

Following the OP recipe with this:

aaaaaaaaaaa

bbbbbbbbbbb

ccccccccccc

When the first column is selected across all rows,
you see this in the mode-line:

  7 rows, 1 cols

If you then use C-x SPC to turn off rectangle-mark
mode, the mode-line indication changes to this:

  7 lines, 40 chars

There are multiple ways to indicate the selection
status in the mode line.  Those 2 are the defaults.

The code is here:

https://www.emacswiki.org/emacs/download/modeline-region.el

Library description is here:

https://www.emacswiki.org/emacs/ModeLineRegion

bug#18793: 24.4; zero width rectangular selection displaces text

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIU, that's a feature: we are trying to indicate the existence of
> the selection, even though its width is zero.  Type "M-x
> describe-text-properties RET" at the first character.  The indication
> must take up some space on display, so it moves the following text to
> the right.

Yes.  Various things were suggested in the bug report, like a new
facility to draw a vertical line through a character, for instance, to
allow indicating stuff like this without the (very slightly) disturbing
horizontal shift.  I think that sounds like a good idea (and I could see
it being useful in general -- for instance, with a mode that indicates
the fill column, perhaps).

It doesn't sound very complicated to implement -- a new text/overlay
property, I guess?

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

bug#18793: 24.4; zero width rectangular selection displaces text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  carlosjosepita@gmail.com,
>   18793@debbugs.gnu.org
> Date: Fri, 06 May 2022 12:26:23 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIU, that's a feature: we are trying to indicate the existence of
> > the selection, even though its width is zero.  Type "M-x
> > describe-text-properties RET" at the first character.  The indication
> > must take up some space on display, so it moves the following text to
> > the right.
> 
> Yes.  Various things were suggested in the bug report, like a new
> facility to draw a vertical line through a character, for instance, to
> allow indicating stuff like this without the (very slightly) disturbing
> horizontal shift.  I think that sounds like a good idea

I'm not sure: how would such a vertical line indicate that it's
region?  And how will it be visible, given that the cursor is
displayed on that same character?  Or maybe I don't understand what
you mean by "a vertical line through a character"?

bug#18793: 24.4; zero width rectangular selection displaces text

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure: how would such a vertical line indicate that it's
> region?

The same way the current one-pixel-wide thing does?  I.e., not very
well.

> And how will it be visible, given that the cursor is displayed on that
> same character?  Or maybe I don't understand what you mean by "a
> vertical line through a character"?

The cursor usually blinks, so the line will be somewhat visible.

But I was thinking that perhaps the box cursor would also react to that
line in some way, for instance by using a reverse colour where the
vertical line is.

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

bug#18793: 24.4; zero width rectangular selection displaces text

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But I was thinking that perhaps the box cursor would also react to that
> line in some way, for instance by using a reverse colour where the
> vertical line is.

(Perhaps we could even reuse some of the painting logic used by the bar
cursor (but I haven't looked at the code at all).)

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

bug#18793: 24.4; zero width rectangular selection displaces text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  carlosjosepita@gmail.com,  18793@debbugs.gnu.org
> Date: Fri, 06 May 2022 13:05:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure: how would such a vertical line indicate that it's
> > region?
> 
> The same way the current one-pixel-wide thing does?  I.e., not very
> well.

The current one-pixel thing is displayed outside of the character
cell, and it has the color of the region face.

> > And how will it be visible, given that the cursor is displayed on that
> > same character?  Or maybe I don't understand what you mean by "a
> > vertical line through a character"?
> 
> The cursor usually blinks, so the line will be somewhat visible.

Usually, but not always.  More generally, I'm not sure the visual
effect will be satisfactory, when it blinks.

> But I was thinking that perhaps the box cursor would also react to that
> line in some way, for instance by using a reverse colour where the
> vertical line is.

That'd mean we need to display the cursor specially there.  IOW, it is
no longer a simple face.

It might be better and easier to introduce a defcustom that disables
the visualization of zero-width rectangles.  Was that considered as a
solution to this issue?

bug#18793: 24.4; zero width rectangular selection displaces text

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It might be better and easier to introduce a defcustom that disables
> the visualization of zero-width rectangles.  Was that considered as a
> solution to this issue?

I think we wanted to keep that?

I'm not suggesting that it's worth implementing something as complex as
this just for this feature, but like I said -- I think something like
this may be useful, in general, for marking things, and if we had it, it
would be natural to use it here, too.

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

bug#18793: 24.4; zero width rectangular selection displaces text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  carlosjosepita@gmail.com,  18793@debbugs.gnu.org
> Date: Fri, 06 May 2022 13:33:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It might be better and easier to introduce a defcustom that disables
> > the visualization of zero-width rectangles.  Was that considered as a
> > solution to this issue?
> 
> I think we wanted to keep that?

I'm not sure.  This was supposed to be a nifty feature.  If some users
are annoyed by its effect, the easy way to handle that is to let those
users disable the cause of the annoyance.  After all, we don't show
anything comparable for non-rectangular regions, do we?

> I'm not suggesting that it's worth implementing something as complex as
> this just for this feature, but like I said -- I think something like
> this may be useful, in general, for marking things, and if we had it, it
> would be natural to use it here, too.

What other uses could this have, except fill-column indication, which
is another minor feature?

Adding capabilities to the Emacs display that operate on
sub-character-cell resolution will mean serious complications.  For
example, what would we do when displaying color Emoji at that place?
Or what about images?  Or what if the character in question is
currently highlighted by mouse-face?

IOW, I'm asking whether these marginal features are worth a serious
surgery and complications in the display engine, which currently has
the canvas-based design?

bug#18793: 24.4; zero width rectangular selection displaces text

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure.  This was supposed to be a nifty feature.  If some users
> are annoyed by its effect, the easy way to handle that is to let those
> users disable the cause of the annoyance.  After all, we don't show
> anything comparable for non-rectangular regions, do we?

That's a good point.

> What other uses could this have, except fill-column indication, which
> is another minor feature?
>
> Adding capabilities to the Emacs display that operate on
> sub-character-cell resolution will mean serious complications.  For
> example, what would we do when displaying color Emoji at that place?
> Or what about images?  Or what if the character in question is
> currently highlighted by mouse-face?
>
> IOW, I'm asking whether these marginal features are worth a serious
> surgery and complications in the display engine, which currently has
> the canvas-based design?

display-fill-column-indicator-mode was the only one that sprang
immediately to mind, but I think it could be useful when displaying
tabular data, and you want to mark boundaries without taking up extra
space, for instance.

And speaking off the fill indicator -- bug#54598 talks a bit about the
problems with the current implementation.  But that mode does show how a
box cursor and a region could behave with these vertical lines.

And I don't think colour emojis or images would represent that much of a
problem -- I think we'd draw the line on top of the glyph?

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

bug#18793: 24.4; zero width rectangular selection displaces text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  carlosjosepita@gmail.com,  18793@debbugs.gnu.org
> Date: Fri, 06 May 2022 14:52:25 +0200
> 
> > Adding capabilities to the Emacs display that operate on
> > sub-character-cell resolution will mean serious complications.  For
> > example, what would we do when displaying color Emoji at that place?
> > Or what about images?  Or what if the character in question is
> > currently highlighted by mouse-face?
> >
> > IOW, I'm asking whether these marginal features are worth a serious
> > surgery and complications in the display engine, which currently has
> > the canvas-based design?
> 
> display-fill-column-indicator-mode was the only one that sprang
> immediately to mind, but I think it could be useful when displaying
> tabular data, and you want to mark boundaries without taking up extra
> space, for instance.

I think trying to display text in tables without taking space for the
borders will introduce significant complications into our display
code.  Text in a table and its borders need to be aligned separately.

> And speaking off the fill indicator -- bug#54598 talks a bit about the
> problems with the current implementation.

Sure, there are limitations to how we can stretch our current display
code.  But the solution is not to stretch it more, IMNSHO, it's to
replace it with a completely new and different design, which could
allow that much more easily.

> But that mode does show how a box cursor and a region could behave
> with these vertical lines.

It does?  AFAIK, we don't show the vertical line when there's a
character at that column, and consequently displaying the cursor
doesn't need to cope with any issues caused by that.

> And I don't think colour emojis or images would represent that much of a
> problem -- I think we'd draw the line on top of the glyph?

The line itself is not the problem; the problem is the color of that
line.  How do you draw a vertical line of a given color over images
and Emoji that have their inherent colors?  Do we just overwrite those
colors?  Won't that be ugly?

There will also be complications with characters whose glyphs "invade"
cells of neighboring characters: Emacs draws characters one by one, so
adding such vertical lines will need to come back after text was drawn
and draw the line, as opposed to doing that as part of drawing
individual glyphs that we do now.

Bottom line: it sounds like a lot of complications for a minor issue
with a minor feature.

bug#18793: 24.4; zero width rectangular selection displaces text

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> It does?  AFAIK, we don't show the vertical line when there's a
> character at that column, and consequently displaying the cursor
> doesn't need to cope with any issues caused by that.

Point before the indicator:


[-- Attachment #2: Type: image/png, Size: 3540 bytes --]

[-- Attachment #3: Type: text/plain, Size: 26 bytes --]


Point on the indicator:


[-- Attachment #4: Type: image/png, Size: 2507 bytes --]

[-- Attachment #5: Type: text/plain, Size: 105 bytes --]



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

bug#18793: 24.4; zero width rectangular selection displaces text

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Point on the indicator:

D'oh!  Sorry; that's not special handling at all -- it's just the normal
point-on-character handling.

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

bug#18793: 24.4; zero width rectangular selection displaces text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlosjosepita@gmail.com,  monnier@iro.umontreal.ca,  18793@debbugs.gnu.org
> Date: Sat, 07 May 2022 12:18:44 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Point on the indicator:
> 
> D'oh!  Sorry; that's not special handling at all -- it's just the normal
> point-on-character handling.

More accurately, we display the indicator instead of a stretch glyph
that stands for the newline or the empty space after EOL.

bug#18793: 24.4; zero width rectangular selection displaces text

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca,  carlosjosepita@gmail.com,  18793@debbugs.gnu.org
> Date: Sat, 07 May 2022 12:11:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It does?  AFAIK, we don't show the vertical line when there's a
> > character at that column, and consequently displaying the cursor
> > doesn't need to cope with any issues caused by that.
> 
> Point before the indicator:

We are mis-communicating, I think.  I meant to say that when there's a
character at the fill-column position (i.e., the line is longer than
fill-column), we display the character there, not the indicator.  What
you show is what happens when the fill-column is after EOL, in which
case there's no character shown at the fill-column, and no problem to
display the indicator instead of that no-character.

bug#18793: 24.4; zero width rectangular selection displaces text

[Drew Adams]

> Adding capabilities to the Emacs display that operate on
> sub-character-cell resolution will mean serious complications.  For
> example, what would we do when displaying color Emoji at that place?
> Or what about images?  Or what if the character in question is
> currently highlighted by mouse-face?
> 
> IOW, I'm asking whether these marginal features are worth a serious
> surgery and complications in the display engine, which currently has
> the canvas-based design?

None of what you guys have suggested so far
is a good solution to the problem reported.

I suggested a simple solution that provides
feedback not only that an empty rectangle is
selected but continual feedback about any
rectangle selection.

It's about informing users.  No special
display gimmicks are needed for that.

bug#18793: 24.4; zero width rectangular selection displaces text

[Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Drew Adams <drew.adams@oracle.com> writes:

> I suggested a simple solution that provides
> feedback not only that an empty rectangle is
> selected but continual feedback about any
> rectangle selection.

I like the idea of using the mode line.

Then, what can one do with a zero-width region?  If just C-x r t, then
we could (and should) indicate the region as multiple cursors, like
other editors do.

Either way, +1 for no jiggle.

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

bug#18793: 24.4; zero width rectangular selection displaces text

[Drew Adams]

> Drew Adams <drew.adams@oracle.com> writes:
> 
> > I suggested a simple solution that provides
> > feedback not only that an empty rectangle is
> > selected but continual feedback about any
> > rectangle selection.
> 
> I like the idea of using the mode line.
> 
> Then, what can one do with a zero-width region?  If just C-x r t, then
> we could (and should) indicate the region as multiple cursors, like
> other editors do.
> 
> Either way, +1 for no jiggle.

The answer is in `modeline-region.el', here:

https://www.emacswiki.org/emacs/download/modeline-region.el

It's described here:

https://www.emacswiki.org/emacs/ModeLineRegion

As for what indication you get for an empty but
active region: that's controlled by user option
`mlr-empty-region-flag'.  By default its value
is non-nil, which means that you see this in
the mode-line:

  0 lines, 0 chars

That's highlighted there with face `mlr-region',
which by default just inherits from face `region'.

If you customize the option to nil then you see
no mode-line indication that the region is empty
and activated.

(You still get the message "Mark set", of course,
when you use `C-SPC', so at least you get some
notification of that action.)