GNU bug report logs - #48752
28.0.50; Feature request: Hook hide-ifdef into font-lock

Previous Next

Package: emacs;

Reported by: Ergus <spacibba <at> aol.com>

Date: Sun, 30 May 2021 20:27:01 UTC

Severity: wishlist

Found in version 28.0.50

Full log


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

From: Ergus <spacibba <at> aol.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48752 <at> debbugs.gnu.org
Subject: Re: bug#48752: 28.0.50; Feature request: Hook hide-ifdef into
 font-lock
Date: Mon, 31 May 2021 16:29:59 +0200
On Mon, May 31, 2021 at 03:01:42PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 30 May 2021 22:26:06 +0200
>> From:  Ergus via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> The use of hide-ifdef is a bit outdated and it requires to manually
>> call: `M-x hide-ifdefs` to update the buffer
>>
>> #if 0
>> <CODE>
>> #endif
>>
>> M-x hide-ifdef-mode
>> M-x hide-ifdef-toggle-shadowing
>>
>> does not shadows/hides the region <CODE>.
>>
>> It requires to explicitly call: M-x hide-ifdefs.
>
>Did you try customizing hide-ifdef-initially to a non-nil value?
>
>> Then if we change #if 0 -> #if 1;
>>
>> the shadow does not disappears/appears either until we call: M-x
>> hide-ifdefs again.
>>
>> This part may be automatized. Calling hide-ifdefs every time is annoying
>> and unneeded. Vim and most of other editors already do the
>> re-fontification automatically. So we can take that behavior as a good
>> starting point.
>
>As mentioned on emacs-devel, how exactly to automate this should be
>carefully thought-out, because blindly using the JIT font-lock
>mechanism will cause code blocks to appear and disappear several time
>as long as the user types the preprocessor directive.  It sounds like
>a no-brainer for a simple "#if 0" (which btw is rarely if ever used in
>real-life production code), but think about typing something like
>this:
>
>  #if (defined __has_attribute \
>       && (!defined __clang_minor__ \
>	   || 3 < __clang_major__ + (5 <= __clang_minor__)))
>
>(This is a real-life example from our conf_post.h, and there are a lot
>like it all over our code.)  Depending on how each of the symbols are
>defined, the block under this could appear and disappear several times
>until you end typing.  I'm quite sure we want to avoid this annoying
>effect as much as possible.

Hi Eli:

I understand that emacs tries to do something smarter than what vim and
the other editors do, but this is limiting the basic trivial use case. I
don;t actually think many people are using the hide-ifdef
package... specially not new users.

In the general case I understand that the block under this could appear
and disappear, but that will be also a feedback for the user to know if
the region will be enabled or not.

For example in the case we have 

#if

#else

#endif

That may be also very useful to know which branch will be compiled. I
don't intend to get something very complex here, but at least the most
basic highlight with trivial symbols may work.

We use emacs to develop code, so, our code is not really production most
of the time. And the #if 0 is very common in many code I have seen
around.

While the

/*
<CODE>
// */

Approach I use is not common at all.




This bug report was last modified 4 years and 21 days ago.

Previous Next


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