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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: eg642616 <at> gmail.com
Cc: 79294 <at> debbugs.gnu.org
Subject: Re: bug#79294: [PATCH] Add hideable indicators for hideshow.
Date: Sat, 06 Sep 2025 11:05:49 +0300

Ping!  How can we make some progress in this matter?

> Cc: 79294 <at> debbugs.gnu.org
> Date: Sun, 24 Aug 2025 09:47:06 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > 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.