GNU bug report logs - #79294
[PATCH] Add hideable indicators for hideshow.

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79294 <at> debbugs.gnu.org
Subject: Re: bug#79294: [PATCH] Add hideable indicators for hideshow.
Date: Sun, 24 Aug 2025 09:47:06 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 79294 <at> debbugs.gnu.org
> Date: Sat, 23 Aug 2025 23:15:00 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > So I think we should allow just two values: 'fringe' and 'margin', and
> > determine the left/right part from the actual text directionality.  In
> > the remote possibility that we would like to allow the indicators "on
> > the opposite part" of the display (but why? it sounds like unnecessary
> > feature to me), we could have values like 'opposite-fringe' etc.  The
> > main point is to avoid "left" and "right" when we choose which one to
> > use dynamically.
> 
> I agree, I have attempted to follow the same behavior as in flymake, but
> I think it is better to hardcode this.
> 
> Furthermore, since hideshow is intended to be used in programming
> language modes, I don't think it's necessary to change the orientation
> of the indicators for bidirectional text.

If Hideshow supports only modes for programming languages, then yes,
we only need the indicators on the left.

> >> +(defvar hs--indicators-rx
> >> +  `((hs-discard-indicator-overlays)
> >> +    (,(lambda (bound)
> >> +        (funcall hs-find-next-block-func
> >> +                 hs-block-start-regexp
> >> +                 bound
> >> +                 (unless (eq hs-show-indicators 'exclude-comments)
> >> +                   t)))
> >> +     0 (hs--add-indicators)))
> >> +  "Hideshow indicator regexp for `font-lock-keywords'.")
> >
> > Why do we need the value in a defvar, instead of invoking the function
> > directly?
> 
> I don't understand this, is not this how the keywords should be appended
> to font-lock-keywords?

font-lock-keywords supports elements that call functions, see the
ELisp manual where font-lock-keywords is described.

> > I think the fact that you modify overlays inside font-lock is the main
> > reason for this being slow: it requires an immediate second redisplay
> > cycle after a new window-full was displayed.  It's the same problem as
> > the one which made linenum-mode so slow.  Did you try using
> > pre-redisplay-function(s) for this purpose instead?
> 
> Thanks for the explanation, i will try to use `pre-redisplay-functions`
> instead, but i'm not sure how to add the indicators to only the visible
> part of the buffer (that is why I choose to use font-lock for this, so
> the performance would be somewhat normal).

You can use window-start and add the indicators to some reasonable
vicinity of it.  There's no need to do that _only_ in the visible part
(and using the font-lock machinery will not limit the indicators only
to the visible part, either).

Previous Next

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