Re: [Patch]: Allow overlay arrows to be inserted before the text at column zero rather than splatting it.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sun, Aug 18, 2019 at 19:29:37 +0300, Eli Zaretskii wrote:
> > Date: Sun, 18 Aug 2019 16:15:30 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > If you want the arrow be displayed before the line's text, why didn't
> > > you just put a before-string at the beginning of the line, instead of
> > > implementing this in the display engine?

> > I think it was to be able to use the same interface that the overlay
> > arrow already uses, without having to reimplement a lot of it using
> > before-strings.

> I think it's a general consensus that the "overlay arrow" feature
> should be walked away of, and at some point should be deprecated.  I'd
> prefer not to base new code on that kludge.

I don't think there's anything else in Emacs at the moment that could
take its place.  The essence here is being able to insert "=>" onto the
display _without_ disturbing the horizontal alignment, as needed by
debuggers.  Maybe, in addition to before-strings and after-strings we
need "overlay-strings" (with a better name than that), which would cover
up the underlying text.  Or do we already have something like that?

> > > AFAIU, that would give you most of the patch for free, e.g. you
> > > wouldn't need to mess with the set_cursor_from_row hair.

> > Yes, there was set_cursor_from_row which I had to change.  Somehow, only
> > partially initialised glyphs got into it; they pointed to lisp strings,
> > but with an offset of -1.  This caused an error to be thrown, and the
> > surrounding internal_condition_case_1 reentered the redisplay code in a
> > loop, causing Emacs to hang.  I'm not sure where they failed to get
> > initialised, but the function is probably better with the workaround I
> > put in.

> This might mean there's a bug in the code that generates those glyphs.
> One more reason not to implement this in the display code.

I'm convinced there's a bug in there, somewhere, but I couldn't discern
what the optimal place to complete the initialisation would be.

> > But it may be worthwhile to be able to use the overlay arrow
> > interface for "insertion type" arrows.

> Any particular reason why this might be worth our while?  Because I
> don't see any.

I'm a little less confused than a couple of hours ago.  The point is that
there are two types of "=>" that can go on a TTY screen: the "overlay
arrow" (as above) and the "before-string", which visibly displaces the
text on the line to the right.

On a GUI frame with left fringes, each of these distinct types of "=>" is
replaced by a fringe bitmap.  So, the fringe bitmap wants to be as close
as possible to two different TTY-style interfaces.  This isn't possible.

In extending the overlay arrow interface, I think I was subconciously
trying to make these three forms of arrows as close as possible to
eachother.  After all, the "overlay arrows" and "fringe bitmaps" are both
implemented directly by display_line, whereas "before-strings" are
handled by push_it and setting up the struct IT for a separate string.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).