GNU bug report logs - #56820
outline-minor-mode replacing the first character with an arrow

Previous Next

Package: emacs;

Reported by: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>

Date: Fri, 29 Jul 2022 10:40:02 UTC

Severity: normal

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56820 in the body.
You can then email your comments to 56820 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Fri, 29 Jul 2022 10:40:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Yilkal Argaw <yilkalargawworkneh <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 29 Jul 2022 10:40:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org, Emacs Devel <emacs-devel <at> gnu.org>
Subject: outline-minor-mode replacing the first character with an arrow
Date: Fri, 29 Jul 2022 13:39:28 +0300
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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Fri, 29 Jul 2022 11:04:02 GMT) Full text and rfc822 format available.

Message #8 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
Cc: 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Fri, 29 Jul 2022 14:03:19 +0300
> From: Yilkal Argaw <yilkalargawworkneh <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Fri, 29 Jul 2022 11:23:01 GMT) Full text and rfc822 format available.

Message #11 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
Cc: 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Fri, 29 Jul 2022 13:21:57 +0200
Yilkal Argaw <yilkalargawworkneh <at> 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 marked as fixed in version 29.1, send any further explanations to 56820 <at> debbugs.gnu.org and Yilkal Argaw <yilkalargawworkneh <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 29 Jul 2022 11:23:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 30 Jul 2022 03:28:01 GMT) Full text and rfc822 format available.

Message #16 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Sat, 30 Jul 2022 06:27:27 +0300
> 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 <at> gnus.org> wrote:
>
> Yilkal Argaw <yilkalargawworkneh <at> 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.
>




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 30 Jul 2022 04:41:02 GMT) Full text and rfc822 format available.

Message #19 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Fri, 29 Jul 2022 21:40:44 -0700
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...)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 30 Jul 2022 09:25:01 GMT) Full text and rfc822 format available.

Message #22 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Sat, 30 Jul 2022 12:24:05 +0300
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 <at> 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...)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 30 Jul 2022 11:53:01 GMT) Full text and rfc822 format available.

Message #25 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Sat, 30 Jul 2022 13:52:08 +0200
Jim Porter <jporterbugs <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 30 Jul 2022 12:49:01 GMT) Full text and rfc822 format available.

Message #28 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Sat, 30 Jul 2022 15:48:37 +0300
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 <at> gnus.org> wrote:
>
> Jim Porter <jporterbugs <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 30 Jul 2022 12:55:02 GMT) Full text and rfc822 format available.

Message #31 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Sat, 30 Jul 2022 14:54:14 +0200
Yilkal Argaw <yilkalargawworkneh <at> 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).






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 30 Jul 2022 13:02:01 GMT) Full text and rfc822 format available.

Message #34 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Sat, 30 Jul 2022 16:00:59 +0300
Sounds good!

On Sat, Jul 30, 2022 at 3:54 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>
> Yilkal Argaw <yilkalargawworkneh <at> 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).
>
>




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 30 Jul 2022 19:28:01 GMT) Full text and rfc822 format available.

Message #37 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Sat, 30 Jul 2022 12:26:58 -0700
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 <at> 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 archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 28 Aug 2022 11:24:04 GMT) Full text and rfc822 format available.

bug unarchived. Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Wed, 31 Aug 2022 16:12:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Wed, 31 Aug 2022 16:22:01 GMT) Full text and rfc822 format available.

Message #44 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Wed, 31 Aug 2022 19:20:23 +0300
> 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))
 
```




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sun, 04 Sep 2022 17:04:01 GMT) Full text and rfc822 format available.

Message #47 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Yilkal Argaw <yilkalargawworkneh <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sun, 04 Sep 2022 18:10:02 GMT) Full text and rfc822 format available.

Message #50 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Sun, 04 Sep 2022 21:09:14 +0300
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56820 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sun, 04 Sep 2022 18:56:02 GMT) Full text and rfc822 format available.

Message #53 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: juri <at> linkov.net, larsi <at> gnus.org
Cc: yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Sun, 04 Sep 2022 21:54:38 +0300
> Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
> Date: Sun, 04 Sep 2022 21:09:14 +0300
> From: Eli Zaretskii <eliz <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Mon, 05 Sep 2022 11:09:02 GMT) Full text and rfc822 format available.

Message #56 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Mon, 05 Sep 2022 13:08:33 +0200
Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Tue, 06 Sep 2022 16:19:02 GMT) Full text and rfc822 format available.

Message #59 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Tue, 06 Sep 2022 19:05:52 +0300
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Tue, 06 Sep 2022 16:29:02 GMT) Full text and rfc822 format available.

Message #62 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Tue, 06 Sep 2022 19:28:04 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: yilkalargawworkneh <at> gmail.com,  larsi <at> gnus.org,  56820 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Tue, 06 Sep 2022 16:36:01 GMT) Full text and rfc822 format available.

Message #65 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
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.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Tue, 06 Sep 2022 16:46:02 GMT) Full text and rfc822 format available.

Message #68 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Tue, 06 Sep 2022 19:45:30 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: yilkalargawworkneh <at> gmail.com,  larsi <at> gnus.org,  56820 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Wed, 07 Sep 2022 12:47:01 GMT) Full text and rfc822 format available.

Message #71 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, yilkalargawworkneh <at> gmail.com,
 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Wed, 07 Sep 2022 14:46:07 +0200
Juri Linkov <juri <at> 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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Wed, 07 Sep 2022 18:40:01 GMT) Full text and rfc822 format available.

Message #74 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Wed, 07 Sep 2022 21:36:06 +0300
[Message part 1 (text/plain, inline)]
> 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?

[vscode-outlines.png (image/png, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Wed, 07 Sep 2022 18:52:02 GMT) Full text and rfc822 format available.

Message #77 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Wed, 07 Sep 2022 21:50:26 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: yilkalargawworkneh <at> gmail.com,  larsi <at> gnus.org,  56820 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Wed, 07 Sep 2022 20:02:02 GMT) Full text and rfc822 format available.

Message #80 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character with
 an arrow
Date: Wed, 7 Sep 2022 13:01:50 -0700
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...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 07:32:02 GMT) Full text and rfc822 format available.

Message #83 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org, 56820 <at> debbugs.gnu.org,
 yilkalargawworkneh <at> gmail.com
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 07:32:02 GMT) Full text and rfc822 format available.

Message #86 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 10:10:18 +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.

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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 08:33:01 GMT) Full text and rfc822 format available.

Message #89 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 11:32:31 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: yilkalargawworkneh <at> gmail.com,  larsi <at> gnus.org,  56820 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 08:38:01 GMT) Full text and rfc822 format available.

Message #92 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: jporterbugs <at> gmail.com, larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com,
 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 11:37:17 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  larsi <at> gnus.org,
>   yilkalargawworkneh <at> gmail.com,  56820 <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 12:03:01 GMT) Full text and rfc822 format available.

Message #95 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, yilkalargawworkneh <at> gmail.com,
 56820 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 14:01:54 +0200
Jim Porter <jporterbugs <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 12:12:02 GMT) Full text and rfc822 format available.

Message #98 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Akib Azmain Turja <akib <at> disroot.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org, 56820 <at> debbugs.gnu.org,
 yilkalargawworkneh <at> gmail.com
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 17:45:36 +0600
[Message part 1 (text/plain, inline)]
Juri Linkov <juri <at> 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 <at> 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
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 13:40:02 GMT) Full text and rfc822 format available.

Message #101 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jporterbugs <at> gmail.com, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 16:39:17 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Juri Linkov <juri <at> linkov.net>,  Eli Zaretskii <eliz <at> gnu.org>,
>   yilkalargawworkneh <at> gmail.com,  56820 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 13:41:02 GMT) Full text and rfc822 format available.

Message #104 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 15:40:39 +0200
Eli Zaretskii <eliz <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 14:04:02 GMT) Full text and rfc822 format available.

Message #107 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jporterbugs <at> gmail.com, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 17:03:28 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: jporterbugs <at> gmail.com,  juri <at> linkov.net,  yilkalargawworkneh <at> gmail.com,
>   56820 <at> debbugs.gnu.org
> Date: Thu, 08 Sep 2022 15:40:39 +0200
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 17:43:01 GMT) Full text and rfc822 format available.

Message #110 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
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.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 17:47:01 GMT) Full text and rfc822 format available.

Message #113 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 20:45:55 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: yilkalargawworkneh <at> gmail.com,  larsi <at> gnus.org,  56820 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Thu, 08 Sep 2022 19:39:02 GMT) Full text and rfc822 format available.

Message #116 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Thu, 08 Sep 2022 22:32:43 +0300
>> > 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Fri, 09 Sep 2022 17:05:02 GMT) Full text and rfc822 format available.

Message #119 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Fri, 09 Sep 2022 19:04:00 +0200
Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Fri, 09 Sep 2022 18:03:02 GMT) Full text and rfc822 format available.

Message #122 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jporterbugs <at> gmail.com, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Fri, 09 Sep 2022 21:01:56 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: jporterbugs <at> gmail.com,  juri <at> linkov.net,  yilkalargawworkneh <at> gmail.com,
>   56820 <at> debbugs.gnu.org
> Date: Fri, 09 Sep 2022 19:04:00 +0200
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 10 Sep 2022 04:37:02 GMT) Full text and rfc822 format available.

Message #125 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Sat, 10 Sep 2022 06:36:07 +0200
Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56820; Package emacs. (Sat, 10 Sep 2022 06:23:02 GMT) Full text and rfc822 format available.

Message #128 received at 56820 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jporterbugs <at> gmail.com, yilkalargawworkneh <at> gmail.com, 56820 <at> debbugs.gnu.org,
 juri <at> linkov.net
Subject: Re: bug#56820: outline-minor-mode replacing the first character
 with an arrow
Date: Sat, 10 Sep 2022 09:21:54 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: jporterbugs <at> gmail.com,  juri <at> linkov.net,  yilkalargawworkneh <at> gmail.com,
>   56820 <at> debbugs.gnu.org
> Date: Sat, 10 Sep 2022 06:36:07 +0200
> 
> Eli Zaretskii <eliz <at> 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).




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 08 Oct 2022 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 172 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.