bug#56820: outline-minor-mode replacing the first character with an arrow

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: yilkalargawworkneh@gmail.com,  larsi@gnus.org,  56820@debbugs.gnu.org
> Date: Tue, 06 Sep 2022 19:34:37 +0300
> 
> >> >   . do we really need to hide the first character of the line by the
> >> >     overlay? doesn't before-string work?
> >> 
> >> Does using before-string allows moving the cursor into the button
> >> displayed with before-string?
> >
> > I don't understand this question: currently the cursor cannot be moved
> > into the overlay anyway.  And if the first character of the buffer's
> > line is not hidden below an overlay, why would we need to move cursor
> > into the overlay to begin with?
> 
> Strange, this is not what I see: after 'C-h b' the cursor is moved to the
> overlay with the button where 'RET' could be typed to hide/show outlines.

You mean, you can place the cursor on the first character of the line
that we add to the button text?  I can only place the cursor after
it.  Which is expected, since Emacs doesn't let you place the cursor
inside an overlay string, unless it has the 'cursor' property.

> >> >   . wouldn't it be better if the arrow buttons were displayed in the
> >> >     window's margin, and would thus avoid indenting the characters on
> >> >     that line wrt the rest of the code?
> >> 
> >> Same problem: the cursor can't be moved into the fringe indicator
> >> to be able to type RET on it.
> >
> > I asked about the margins, not the fringe.
> 
> I don't know if the cursor can be moved to the window's margin.

It cannot.  But I don't see how that is a more serious problem than
the unpleasant display we have now.  This is supposed to be the Emacs
answer to the various IDEs being able to fold code, right?  Then let's
try to make it look like in those IDEs.

> > If you ask about RET, that is relevant for text-mode frames, where
> > buttons won't be used anyway, right?  On GUI frames, people are
> > expected to click on the buttons, right?
> 
> Even on GUI frames it would be handy to use the keyboard
> in addition to mouse.

I very much doubt that many users will want both to see the buttons
_and_ use the keyboard on those buttons.