Date: Wed, 8 Feb 2023 17:16:40 +0200
Cc: 61361@debbugs.gnu.org
From: Dmitry Gutov <dgutov@yandex.ru>
On 08/02/2023 17:09, Eli Zaretskii wrote:
From: Xinyang Chen<chenxy@mit.edu>
Date: Wed, 8 Feb 2023 09:25:07 -0500
But the 'cursor' property just supplies the index in the display
string where your Lisp program wants to place the cursor. Emacs
cannot place point inside a display string. So the display engine
needs to find where that index is on display. And it cannot find that
place because there's no glyph that corresponds to the newline.
So, no chance of the display engine detecting that the same display
string with the 'cursor' property has a newline at that position?
"No chance" is too strong: this is software, after all.
But it's not easy to do that. It involves several places with tricky
code, that currently all work in unison, and make the same
assumptions:
. the decision where to place the cursor works on a screen-line
basis: as we perform layout of each screen line, we decide whether
the cursor should be in that line, and if so, on what glyph of
that line
. the decision whether a screen line is a candidate for showing the
cursor when that screen line ends in a newline from a display or
an overlay string, and/or when there's a gap in buffer positions
shown on the screen due to buffer text hidden by some feature
. the tricky (to say the least) code which finds the glyph where to
put the cursor on a given screen line when buffer positions change
non-monotonically with screen positions (due to bidirectional
text) and/or have gaps due to overlay and display strings (it is
here that the 'cursor' property is implemented)
Historically, the 'cursor' property is a relatively late addition to
the display engine, it was added in Emacs 22.1. It complicated the
display code a little, but then along came bidirectional display and
complicated that _a_lot_. So we are now at a place where the original
design of the Emacs 21 display never meant to be.
The entire design of overlay string display is problematic for adding
significant features, because when an overlay string is rendered, we
lose too much information about the original overlay (e.g., we don't
even record where in the buffer the overlay was positioned, nor the
overlay from which the string came). So any feature that needs to
support properties of overlay strings must actually go back to buffer
text and look up the overlays there to find the one we want!
That's unfortunate: that means we'll need to create some wonky
workaround for displaying a completion preview (in Company) when a
completion starts with a newline.
Yes, I know. If someone wants to work on lifting this limitation, I
can offer help, but I don't think I'll have time (nor motivation, to
say the truth) to work on this myself.