all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ergus via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 48752@debbugs.gnu.org
Subject: bug#48752: 28.0.50; Feature request: Hook hide-ifdef into font-lock
Date: Mon, 31 May 2021 16:29:59 +0200	[thread overview]
Message-ID: <20210531142959.3sjh4g5ucu5xc4of@Ergus> (raw)
In-Reply-To: <83eedn2jtl.fsf@gnu.org>

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





  reply	other threads:[~2021-05-31 14:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210530202606.qlopn6lmwzfa75z5.ref@Ergus>
2021-05-30 20:26 ` bug#48752: 28.0.50; Feature request: Hook hide-ifdef into font-lock Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-31 12:01   ` Eli Zaretskii
2021-05-31 14:29     ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-05-31 15:44     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210531142959.3sjh4g5ucu5xc4of@Ergus \
    --to=bug-gnu-emacs@gnu.org \
    --cc=48752@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=spacibba@aol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.