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

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

[Yilkal Argaw]

Hi Guys,

Today I compiled emacs from source and while using outline-minor-mode
it started replacing the first character with an arrow whenever I fold
the code. The characters remain  as arrows even when I disable outline
minor mode. To recreate the issue

   + emacs -q
   + open a source code file (I opened ruby,  python and elisp files)
   + outline-minor-mode
   + M-: (set outline-minor-mode-cycle t)
   + (outline-minor-mode-cycle-buffer)

The emacs version I use is   29.0.50 (build 4, x86_64-pc-linux-gnu)

wiith regards
Yilkal A.

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

[Eli Zaretskii]

> From: Yilkal Argaw <yilkalargawworkneh@gmail.com>
> Date: Fri, 29 Jul 2022 13:39:28 +0300
> 
> Today I compiled emacs from source and while using outline-minor-mode
> it started replacing the first character with an arrow whenever I fold
> the code. The characters remain  as arrows even when I disable outline
> minor mode. To recreate the issue
> 
>    + emacs -q
>    + open a source code file (I opened ruby,  python and elisp files)
>    + outline-minor-mode
>    + M-: (set outline-minor-mode-cycle t)
>    + (outline-minor-mode-cycle-buffer)
> 

You should be able to get back the old behavior by customizing
outline-minor-mode-use-buttons to the nil value.

P.S. Please don't cross post bug reports to emacs-devel.

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

[Lars Ingebrigtsen]

Yilkal Argaw <yilkalargawworkneh@gmail.com> writes:

> Today I compiled emacs from source and while using outline-minor-mode
> it started replacing the first character with an arrow whenever I fold
> the code.

I've now fixed this in Emacs 29.

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

[Yilkal Argaw]

> I've now fixed this in Emacs 29.

Thanks  that fixed the default behaviour but
outline-minor-mode-use-buttons option still has a weird bug because
when you use it with modes like python-mode and ruby-mode it replaces
the first character of the outline-regep which for the aforementioned
modes is strings like "module", "class", "def" etc... so when it
replaces the first character it renders the buffer unreadable. So it
might be better to insert the arrows in front of the first character
instead of replacing the first character.

There is also the issue of the arrows being displayed when
outline-minor-mode is disabled after folding and unfolding.

Sincerely and Gratefully
Yilkal

On Fri, Jul 29, 2022 at 2:22 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Yilkal Argaw <yilkalargawworkneh@gmail.com> writes:
>
> > Today I compiled emacs from source and while using outline-minor-mode
> > it started replacing the first character with an arrow whenever I fold
> > the code.
>
> I've now fixed this in Emacs 29.
>

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

[Jim Porter]

On 7/29/2022 8:27 PM, Yilkal Argaw wrote:
> Thanks  that fixed the default behaviour but
> outline-minor-mode-use-buttons option still has a weird bug because
> when you use it with modes like python-mode and ruby-mode it replaces
> the first character of the outline-regep which for the aforementioned
> modes is strings like "module", "class", "def" etc... so when it
> replaces the first character it renders the buffer unreadable. So it
> might be better to insert the arrows in front of the first character
> instead of replacing the first character.

Would it make sense to put the buttons on the fringe? I suppose other 
indicators might compete with the outline-minor-mode buttons then, but 
at least it wouldn't disrupt the buffer contents.

(Maybe some modes like help-mode would still want in-buffer buttons 
though...)

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

[Yilkal Argaw]

I think that would be a better approach. The fringe might be to narrow
and might be over crowded if there is another app using it but it
would not affect buffer content

On Sat, Jul 30, 2022 at 7:40 AM Jim Porter <jporterbugs@gmail.com> wrote:
>
> On 7/29/2022 8:27 PM, Yilkal Argaw wrote:
> > Thanks  that fixed the default behaviour but
> > outline-minor-mode-use-buttons option still has a weird bug because
> > when you use it with modes like python-mode and ruby-mode it replaces
> > the first character of the outline-regep which for the aforementioned
> > modes is strings like "module", "class", "def" etc... so when it
> > replaces the first character it renders the buffer unreadable. So it
> > might be better to insert the arrows in front of the first character
> > instead of replacing the first character.
>
> Would it make sense to put the buttons on the fringe? I suppose other
> indicators might compete with the outline-minor-mode buttons then, but
> at least it wouldn't disrupt the buffer contents.
>
> (Maybe some modes like help-mode would still want in-buffer buttons
> though...)

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

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

> Would it make sense to put the buttons on the fringe? I suppose other
> indicators might compete with the outline-minor-mode buttons then, but
> at least it wouldn't disrupt the buffer contents.

Buttons in the fringe can be helpful, but can they be clicked?

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

[Yilkal Argaw]

Yes, you can do that.  The package hideshowvis has clickable buttons
on the fringe.

On Sat, Jul 30, 2022 at 2:52 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Jim Porter <jporterbugs@gmail.com> writes:
>
> > Would it make sense to put the buttons on the fringe? I suppose other
> > indicators might compete with the outline-minor-mode buttons then, but
> > at least it wouldn't disrupt the buffer contents.
>
> Buttons in the fringe can be helpful, but can they be clicked?

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

[Lars Ingebrigtsen]

Yilkal Argaw <yilkalargawworkneh@gmail.com> writes:

> Yes, you can do that.  The package hideshowvis has clickable buttons
> on the fringe.

Great!  Then I think that'll be a better solution for editable modes
than having the buttons in-buffer.  For non-editable modes (like *Help*)
having them in-buffer makes the most sense (because you can move to them
and hit RET on the button itself).

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

[Yilkal Argaw]

Sounds good!

On Sat, Jul 30, 2022 at 3:54 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Yilkal Argaw <yilkalargawworkneh@gmail.com> writes:
>
> > Yes, you can do that.  The package hideshowvis has clickable buttons
> > on the fringe.
>
> Great!  Then I think that'll be a better solution for editable modes
> than having the buttons in-buffer.  For non-editable modes (like *Help*)
> having them in-buffer makes the most sense (because you can move to them
> and hit RET on the button itself).
>
>

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

[Jim Porter]

On 7/30/2022 5:48 AM, Yilkal Argaw wrote:
> Yes, you can do that.  The package hideshowvis has clickable buttons
> on the fringe.
> 
> On Sat, Jul 30, 2022 at 2:52 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>>
>> Buttons in the fringe can be helpful, but can they be clicked?

Another good example of clickable buttons in the fringe (and a good 
example of where conflicts might arise) are the breakpoints you can set 
when running `M-x gdb' (I'm sure other debuggers have similar 
integrations). I'm not sure how bad these conflicts would be in 
practice, but it'd probably be worth testing this out to see if there 
are any rough edges.

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

[Juri Linkov]

> Thanks  that fixed the default behaviour but
> outline-minor-mode-use-buttons option still has a weird bug because
> when you use it with modes like python-mode and ruby-mode it replaces
> the first character of the outline-regep which for the aforementioned
> modes is strings like "module", "class", "def" etc... so when it
> replaces the first character it renders the buffer unreadable. So it
> might be better to insert the arrows in front of the first character
> instead of replacing the first character.

This patch could help to alleviate the problem by keeping
the first character displayed on the outline button:

```
diff --git a/lisp/outline.el b/lisp/outline.el
index 857ac9562f..498ea6fad4 100644
--- a/lisp/outline.el
+++ b/lisp/outline.el
@@ -1006,7 +1018,8 @@ outline--make-button-overlay
         (put-text-property (point) (1+ (point)) 'face (plist-get icon 'face)))
       (when-let ((image (plist-get icon 'image)))
         (overlay-put o 'display image))
-      (overlay-put o 'display (plist-get icon 'string))
+      (overlay-put o 'display (concat (plist-get icon 'string)
+                                      (string (char-after (point)))))
       (overlay-put o 'face (plist-get icon 'face)))
     o))
 
```

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

[Juri Linkov]

> This patch could help to alleviate the problem by keeping
> the first character displayed on the outline button:

Pushed.

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

[Eli Zaretskii]

> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 56820@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 04 Sep 2022 20:02:48 +0300
> 
> > This patch could help to alleviate the problem by keeping
> > the first character displayed on the outline button:
> 
> Pushed.

This doesn't work well:

  . moving the mouse pointer on and off the button causes horizontal
    movement of both the arrow and the following character, the one
    that was added to the overlay's 'display' string (I guess this
    depends on the font used for the arrow characters?);
  . one cannot put the cursor on the first character that's displayed
    on the outline button

I very much hope we can improve the visuals here, because otherwise
the feature looks unfinished at best.

Some related questions:

  . do we really need to hide the first character of the line by the
    overlay? doesn't before-string work?
  . 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?

Thanks.

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

[Eli Zaretskii]

> Cc: larsi@gnus.org, yilkalargawworkneh@gmail.com, 56820@debbugs.gnu.org
> Date: Sun, 04 Sep 2022 21:09:14 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> This doesn't work well:
> 
>   . moving the mouse pointer on and off the button causes horizontal
>     movement of both the arrow and the following character, the one
>     that was added to the overlay's 'display' string (I guess this
>     depends on the font used for the arrow characters?);
>   . one cannot put the cursor on the first character that's displayed
>     on the outline button

Some more problems:

  . how does one turn the buttons on and off?  changing the value of
    outline-minor-mode-use-buttons seems to work only in one direction
    -- to turn them on, and even for that, I need to click "Show All"
    first?  I cannot seem to be able to turn the buttons off
    afterwards: even turning off outline-minor-mode doesn't remove
    them from display
  . it seems to be impossible to force Emacs to use emoji for buttons
    if the U+1F7E0 character doesn't have a font -- this is okay as
    the default, but if the user insists on using emoji and only
    emoji, why not let them?  (I wanted to try emoji because
    outline-minor-mode doesn't define the image alternative, and I
    don't like the way the symbol alternative looks on display)
  . the buttons have a dark gray background that doesn't look good.
    what's worse, they have a darker (black?) 2-pixel margins on left
    and right, which disappear when the mouse pointer hovers above the
    button and the button is shown in mouse-face.  the fact that these
    "margins" disappear explains why the arrow symbol moves
    horizontally when mouse pointer is moved across the button

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>   . 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?

Yes, in editing modes, the buttons should probably be fringe indicators
instead.

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

[Juri Linkov]

> This doesn't work well:
>
>   . moving the mouse pointer on and off the button causes horizontal
>     movement of both the arrow and the following character, the one
>     that was added to the overlay's 'display' string (I guess this
>     depends on the font used for the arrow characters?);
>   . one cannot put the cursor on the first character that's displayed
>     on the outline button
>
> I very much hope we can improve the visuals here, because otherwise
> the feature looks unfinished at best.
>
> Some related questions:
>
>   . 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?

>   . 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.

>   . the buttons have a dark gray background that doesn't look good.

The buttons that I see by default are much worse - their background is
glaring orange.

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:05:52 +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?

> >   . 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.

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?

> >   . the buttons have a dark gray background that doesn't look good.
> 
> The buttons that I see by default are much worse - their background is
> glaring orange.

So we need to make them more visually appealing.

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

[Juri Linkov]

>> >   . 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.

>> >   . 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.

> 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.

>> >   . the buttons have a dark gray background that doesn't look good.
>> 
>> The buttons that I see by default are much worse - their background is
>> glaring orange.
>
> So we need to make them more visually appealing.

Agreed.

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.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Even on GUI frames it would be handy to use the keyboard
> in addition to mouse.

Yes, that was one major reason to add buttons to outline -- to have
something that people can hit `RET' on.

But it doesn't really work well in editing modes -- it's too disruptive
for a minor mode to attempt to do something that works well across all
major modes in this way.  So for editing modes, I think we have to
abandon the convenient "hit `RET' on the button" interaction.

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

[Juri Linkov]

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

> 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.

This is an interesting question.  I tried to search how outlines look
in other IDEs, and found such a screenshot for VSCode.

IIUC, here the first column with a red circle for a breakpoint
corresponds to Emacs fringes, the second column with line numbers
is the same as display-line-numbers-mode, and the third column is
for outline arrows.

So the column for outline indicators could be implemented the same way
as display-line-numbers-mode.  Excuse my ignorance, is
display-line-numbers-mode implemented by using margins?


[-- Attachment #2: vscode-outlines.png --]
[-- Type: image/png, Size: 89930 bytes --]

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: Wed, 07 Sep 2022 21:36:06 +0300
> 
> So the column for outline indicators could be implemented the same way
> as display-line-numbers-mode.

Yes, that's a possibility.

> Excuse my ignorance, is display-line-numbers-mode implemented by
> using margins?

No.  We simply usurp a few columns from the text area, on the layout
level of the display engine.

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

[Jim Porter]

On 9/7/2022 11:36 AM, Juri Linkov wrote:
>> 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.
> 
> This is an interesting question.  I tried to search how outlines look
> in other IDEs, and found such a screenshot for VSCode.
> 
> IIUC, here the first column with a red circle for a breakpoint
> corresponds to Emacs fringes, the second column with line numbers
> is the same as display-line-numbers-mode, and the third column is
> for outline arrows.

This is a good example of a potential conflict with putting the outline 
buttons in the fringe: line 10 has both an outline arrow *and* a 
breakpoint. (Emacs usually uses the fringe for breakpoints.) As far as I 
know, there's no way to show multiple fringe icons on a single line 
(other than using the right fringe, which would be odd in this case).

In this case, it looks like gdb-mi.el supports putting breakpoint icons 
in the margin, so the conflict could be avoided that way. Still, I'm not 
sure what the general answer should be. How should Emacs present buttons 
like this in a way where they don't conflict? For example, should there 
be a guideline about what kinds of icons/buttons "belong" in the fringe, 
and what kinds belong elsewhere? Note: this guideline could just inform 
the default configuration, and then users could customize things if they 
have different preferences.

Or maybe the fringe should be enhanced in some way where it can handle 
multiple fringe icons in the same position. I'm not sure how that would 
work though...

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

[Juri Linkov]

>> So the column for outline indicators could be implemented the same way
>> as display-line-numbers-mode.
>
> Yes, that's a possibility.
>
>> Excuse my ignorance, is display-line-numbers-mode implemented by
>> using margins?
>
> No.  We simply usurp a few columns from the text area, on the layout
> level of the display engine.

I counted ~100 occurrences of display_line_numbers in xdisp.c.
So I guess display_outlines could be added based on code
for display_line_numbers using the same strategy as
tab_line was added based on header_line.

If this is a good idea, I could look into doing this
after finishing all already opened issues, probably
around December.

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

[Juri Linkov]

> Or maybe the fringe should be enhanced in some way where it can handle
> multiple fringe icons in the same position. I'm not sure how that would
> work though...

I don't yet know the difference in implementation of fringes, margins and
display-line-numbers, and whether they all use columns from the text area,
and how easy would be to enhance their current implementation.

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: Thu, 08 Sep 2022 10:10:18 +0300
> 
> >> Excuse my ignorance, is display-line-numbers-mode implemented by
> >> using margins?
> >
> > No.  We simply usurp a few columns from the text area, on the layout
> > level of the display engine.
> 
> I counted ~100 occurrences of display_line_numbers in xdisp.c.
> So I guess display_outlines could be added based on code
> for display_line_numbers using the same strategy as
> tab_line was added based on header_line.
> 
> If this is a good idea, I could look into doing this
> after finishing all already opened issues, probably
> around December.

I don't think I understand what you mean by "same strategy" here, so I
cannot answer the question yet.

Vdisplay_line_numbers is used in xdisp.c for several purposes:

  . adjust layout calculations for the space taken by line numbers
  . disable some redisplay optimizations that cannot be used when line
    numbers (especially relative numbers) are displayed
  . produce and display the line numbers for relevant lines

Which one(s) are "strategy" for the purpose of this discussion?

I also don't think I understand which parts of the image you posted
you want to emulate.  In addition to outline-style widgets for folding
and un-folding buffer text, the image shows vertical lines that
delineate code blocks.  Those are shown in the same column as the
braces, and thus call for a different kind of implementation than the
line numbers.  I guess you didn't mean those?

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,
>   yilkalargawworkneh@gmail.com,  56820@debbugs.gnu.org
> Date: Thu, 08 Sep 2022 10:13:35 +0300
> 
> > Or maybe the fringe should be enhanced in some way where it can handle
> > multiple fringe icons in the same position. I'm not sure how that would
> > work though...
> 
> I don't yet know the difference in implementation of fringes, margins and
> display-line-numbers, and whether they all use columns from the text area,
> and how easy would be to enhance their current implementation.

In the interests of being on the same page wrt terminology:

  . "text area" doesn't include the margins
  . the fringes are a separate area of the display, also outside of
    the text area
  . display-line-numbers _does_ show the line numbers in the text area
  . a basic difference between the fringes and the margins is that
    margins are basically special-purpose areas for displaying text,
    whereas the fringes can only display images
  . the most important difference between display in the margins and
    display in the text area is that we don't support continuation in
    the margins: if the text written there is longer than the margin
    can display, the text is truncated, i.e. glyphs beyond what fits
    will not be visible

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

[Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Juri Linkov <juri@linkov.net> writes:

> Excuse my ignorance, is
> display-line-numbers-mode implemented by using margins?

No.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[Lars Ingebrigtsen]

Jim Porter <jporterbugs@gmail.com> writes:

>> This is an interesting question.  I tried to search how outlines
>> look
>> in other IDEs, and found such a screenshot for VSCode.
>> IIUC, here the first column with a red circle for a breakpoint
>> corresponds to Emacs fringes, the second column with line numbers
>> is the same as display-line-numbers-mode, and the third column is
>> for outline arrows.

Hm, interesting...  But having the outline arrows in a third column
(outside the text area) still doesn't let people use the keyboard on the
icons, so from that point of view, just using the fringe isn't any worse.

> This is a good example of a potential conflict with putting the
> outline buttons in the fringe: line 10 has both an outline arrow *and*
> a breakpoint.

But that's a good point.

Could we envision "blending" fringe markers?  They're pretty primitive,
so that's probably difficult to achieve.

In general, though, it'd be great if fringe markers could be more
normal.  That is, if we could display general images in that area,
instead of just the monocolour things, defined awkwardly, that we have
today.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  Eli Zaretskii <eliz@gnu.org>,
>   yilkalargawworkneh@gmail.com,  56820@debbugs.gnu.org
> Date: Thu, 08 Sep 2022 14:01:54 +0200
> 
> > This is a good example of a potential conflict with putting the
> > outline buttons in the fringe: line 10 has both an outline arrow *and*
> > a breakpoint.
> 
> But that's a good point.

Is it plausible that someone needs to see breakpoints when the code is
folded?

> In general, though, it'd be great if fringe markers could be more
> normal.  That is, if we could display general images in that area,
> instead of just the monocolour things, defined awkwardly, that we have
> today.

Why bother, since we already have the margins, where that is possible?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why bother, since we already have the margins, where that is possible?

Hm.  Could we do away with the fringes and just use the margins, long
term?

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jporterbugs@gmail.com,  juri@linkov.net,  yilkalargawworkneh@gmail.com,
>   56820@debbugs.gnu.org
> Date: Thu, 08 Sep 2022 15:40:39 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why bother, since we already have the margins, where that is possible?
> 
> Hm.  Could we do away with the fringes and just use the margins, long
> term?

Depends for what purposes.  The fringes generally take less space for
small enough images, and "other editors" provide similar features,
including for breakpoint markers.

My point is that if some Lisp program needs to display something
larger and more complex than a simple small image the fringes can
support, that Lisp program should simply use margins instead.

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

[Juri Linkov]

>> I counted ~100 occurrences of display_line_numbers in xdisp.c.
>> So I guess display_outlines could be added based on code
>> for display_line_numbers using the same strategy as
>> tab_line was added based on header_line.
>> 
>> If this is a good idea, I could look into doing this
>> after finishing all already opened issues, probably
>> around December.
>
> I don't think I understand what you mean by "same strategy" here, so I
> cannot answer the question yet.
>
> Vdisplay_line_numbers is used in xdisp.c for several purposes:
>
>   . adjust layout calculations for the space taken by line numbers
>   . disable some redisplay optimizations that cannot be used when line
>     numbers (especially relative numbers) are displayed
>   . produce and display the line numbers for relevant lines
>
> Which one(s) are "strategy" for the purpose of this discussion?

The strategy is to reuse the existing code that adjusts layout calculations
to display the line numbers, and to display outline arrows after line numbers.

> I also don't think I understand which parts of the image you posted
> you want to emulate.  In addition to outline-style widgets for folding
> and un-folding buffer text, the image shows vertical lines that
> delineate code blocks.  Those are shown in the same column as the
> braces, and thus call for a different kind of implementation than the
> line numbers.  I guess you didn't mean those?

I meant only outline arrows for folding and un-folding,
not vertical lines for code blocks.  I recall someone
provided some patches to implement crosshairs, but maybe
the existing display-fill-column-indicator-mode could be
adapted to display vertical lines for code blocks.

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: Thu, 08 Sep 2022 20:39:24 +0300
> 
> >> I counted ~100 occurrences of display_line_numbers in xdisp.c.
> >> So I guess display_outlines could be added based on code
> >> for display_line_numbers using the same strategy as
> >> tab_line was added based on header_line.
> >> 
> >> If this is a good idea, I could look into doing this
> >> after finishing all already opened issues, probably
> >> around December.
> >
> > I don't think I understand what you mean by "same strategy" here, so I
> > cannot answer the question yet.
> >
> > Vdisplay_line_numbers is used in xdisp.c for several purposes:
> >
> >   . adjust layout calculations for the space taken by line numbers
> >   . disable some redisplay optimizations that cannot be used when line
> >     numbers (especially relative numbers) are displayed
> >   . produce and display the line numbers for relevant lines
> >
> > Which one(s) are "strategy" for the purpose of this discussion?
> 
> The strategy is to reuse the existing code that adjusts layout calculations
> to display the line numbers, and to display outline arrows after line numbers.

So you are talking only about the first bullet above.

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

[Juri Linkov]

>> > Vdisplay_line_numbers is used in xdisp.c for several purposes:
>> >
>> >   . adjust layout calculations for the space taken by line numbers
>> >   . disable some redisplay optimizations that cannot be used when line
>> >     numbers (especially relative numbers) are displayed
>> >   . produce and display the line numbers for relevant lines
>> >
>> > Which one(s) are "strategy" for the purpose of this discussion?
>> 
>> The strategy is to reuse the existing code that adjusts layout calculations
>> to display the line numbers, and to display outline arrows after line numbers.
>
> So you are talking only about the first bullet above.

Sharing the existing code for the first bullet indeed.
Then implementing the display of images for relevant outlines.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Hm.  Could we do away with the fringes and just use the margins, long
>> term?
>
> Depends for what purposes.  The fringes generally take less space for
> small enough images, and "other editors" provide similar features,
> including for breakpoint markers.

I meant whether we could get rid of the current fringe implementation
(which doesn't allow displaying normal images) and just use the margin
code for the fringes instead.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jporterbugs@gmail.com,  juri@linkov.net,  yilkalargawworkneh@gmail.com,
>   56820@debbugs.gnu.org
> Date: Fri, 09 Sep 2022 19:04:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Hm.  Could we do away with the fringes and just use the margins, long
> >> term?
> >
> > Depends for what purposes.  The fringes generally take less space for
> > small enough images, and "other editors" provide similar features,
> > including for breakpoint markers.
> 
> I meant whether we could get rid of the current fringe implementation
> (which doesn't allow displaying normal images) and just use the margin
> code for the fringes instead.

We could, but why would we want to?  If we want to display other types
of (small) images on the fringes, it should be almost straightforward
to implement.  The actual code that draws the bitmaps on the fringes
is specific to the terminal, and we have separate implementations for
X, w32, Cairo, etc.  It shouldn't be too hard to support other images
there.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I meant whether we could get rid of the current fringe implementation
>> (which doesn't allow displaying normal images) and just use the margin
>> code for the fringes instead.
>
> We could, but why would we want to?  If we want to display other types
> of (small) images on the fringes, it should be almost straightforward
> to implement.  The actual code that draws the bitmaps on the fringes
> is specific to the terminal, and we have separate implementations for
> X, w32, Cairo, etc.  It shouldn't be too hard to support other images
> there.

If it's easier to extend the image support in the fringe code instead,
then that's fine.  It'd be nice to have the entire image/face machinery
working, though, so we'd be able to specify colours (for SVGs, for
instance) in the same way we do everywhere else.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jporterbugs@gmail.com,  juri@linkov.net,  yilkalargawworkneh@gmail.com,
>   56820@debbugs.gnu.org
> Date: Sat, 10 Sep 2022 06:36:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I meant whether we could get rid of the current fringe implementation
> >> (which doesn't allow displaying normal images) and just use the margin
> >> code for the fringes instead.
> >
> > We could, but why would we want to?  If we want to display other types
> > of (small) images on the fringes, it should be almost straightforward
> > to implement.  The actual code that draws the bitmaps on the fringes
> > is specific to the terminal, and we have separate implementations for
> > X, w32, Cairo, etc.  It shouldn't be too hard to support other images
> > there.
> 
> If it's easier to extend the image support in the fringe code instead,
> then that's fine.  It'd be nice to have the entire image/face machinery
> working, though, so we'd be able to specify colours (for SVGs, for
> instance) in the same way we do everywhere else.

I'm saying we should keep both.  Fringes are fine for displaying small
images, and look well on display.  They are also familiar to anyone
who used some other IDE.  Larger images and more complex stuff should
use the margins.  Having both gives us certain flexibility.

Using margins for everything has the disadvantage that other features
will have trouble using the margins at the same time (which reminds me
that we still lack a protocol for sharing the margins between several
Lisp programs).