Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[Basil L. Contovounesios]

luke.yx.lee@gmail.com (Luke Lee) writes:

> branch: master
> commit 87e7390aaef0978bdef6f3b73af43305fab7db21
> Author: Luke Lee <luke.yx.lee@gmail.com>
> Commit: Luke Lee <luke.yx.lee@gmail.com>
>
>     * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[...]

> -(defcustom hide-ifdef-expand-reinclusion-protection t
> +(defcustom hide-ifdef-expand-reinclusion-guard t

Does this need a define-obsolete-variable-alias for backward
compatibility?

> +(defcustom hide-ifdef-verbose nil
> +  "Show some defining symbols on hiding for a visible feedback."
> +  :type 'boolean
> +  :version "27.2")
> +
> +(defcustom hide-ifdef-evalulate-enter-hook nil
> +  "Hook function to be called when entering `hif-evaluate-macro'."
> +  :type 'hook
> +  :version "27.2")
> +
> +(defcustom hide-ifdef-evalulate-leave-hook nil
> +  "Hook function to be called when leaving `hif-evaluate-macro'."
> +  :type 'hook
> +  :version "27.2")

Should these :versions be "28.1"?

Thanks,

-- 
Basil

Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[Zhiwei Chen]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

hide-if still needs user to `hide-ifdef-define’ manually, could we use `lsp-mode’ to describe the macro to choose whether to hide or not?

--
Zhiwei Chen

[-- Attachment #2: Type: text/html, Size: 1171 bytes --]

Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[Luke Lee]

>Does this need a define-obsolete-variable-alias for backward
>compatibility?

You're right, I will add that in my next patch.

>> +(defcustom hide-ifdef-evalulate-leave-hook nil
>> +  "Hook function to be called when leaving `hif-evaluate-macro'."
>> +  :type 'hook
>> +  :version "27.2")
> 
>Should these :versions be "28.1"?

I originally planned to add it into emacs-27 branch but later found
in the contibution guide that 27.2 indicates a feature freeze branch.
Is there any way (or is it okay) to add it to emacs-27, if there is
an up-coming 27.3?  Or should I just leave it here in 28.1? Thanks.

Best regards,
Luke Lee

Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[Luke Lee]

> hide-if still needs user to `hide-ifdef-define’ manually, could we use
> `lsp-mode’ to describe the macro to choose whether to hide or not?

Personally I never use `hide-ifdef-define', it's what it originally was
so I kept it.  I only use `hide-ifdefs' and EmacsSession to save/restore
`hide-ifdef-env' as I described long ago in EmacsWiki
https://www.emacswiki.org/emacs/HideIfDef (haven't got
time to update it yet).  Plus the newly described method in the
comment of the beginning of hideif.el:
[...]
;;   $ gcc -dM -E hello.c -o hello.hh
[...]
Then I open the hello.hh and `hide-ifdefs' it.  With EmacsSession I only
need to do that once.  Next time when I launch Emacs it will automatically
bring back my earlier defines.  As EmacsSession is not standard thus I
didn't mention that in the hideif.el comment.  I am sure there are now
some other packages able to save/restore the global `hide-ifdef-env'.

Hope this helps.

Best regards,
Luke Lee

Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[Eli Zaretskii]

> From: Luke Lee <luke.yx.lee@gmail.com>
> Date: Thu, 03 Jun 2021 11:19:17 +0800
> Cc: emacs-devel@gnu.org
> 
> >> +(defcustom hide-ifdef-evalulate-leave-hook nil
> >> +  "Hook function to be called when leaving `hif-evaluate-macro'."
> >> +  :type 'hook
> >> +  :version "27.2")
> > 
> >Should these :versions be "28.1"?
> 
> I originally planned to add it into emacs-27 branch but later found
> in the contibution guide that 27.2 indicates a feature freeze branch.
> Is there any way (or is it okay) to add it to emacs-27, if there is
> an up-coming 27.3?  Or should I just leave it here in 28.1? Thanks.

It is unlikely there will be Emacs 27.3, so I think the latter is TRT.

Thanks.

Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[Eli Zaretskii]

> From: Luke Lee <luke.yx.lee@gmail.com>
> Date: Thu, 03 Jun 2021 11:38:43 +0800
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,
>  emacs-devel <emacs-devel@gnu.org>
> 
> Personally I never use `hide-ifdef-define', it's what it originally was
> so I kept it.  I only use `hide-ifdefs' and EmacsSession to save/restore
> `hide-ifdef-env' as I described long ago in EmacsWiki
> https://www.emacswiki.org/emacs/HideIfDef (haven't got
> time to update it yet).  Plus the newly described method in the
> comment of the beginning of hideif.el:
> [...]
> ;;   $ gcc -dM -E hello.c -o hello.hh
> [...]
> Then I open the hello.hh and `hide-ifdefs' it.  With EmacsSession I only
> need to do that once.  Next time when I launch Emacs it will automatically
> bring back my earlier defines.  As EmacsSession is not standard thus I
> didn't mention that in the hideif.el comment.  I am sure there are now
> some other packages able to save/restore the global `hide-ifdef-env'.

How about making hideif.el capable of running a GCC command such as
above automatically, and using the output to find which macros should
be defined and which shouldn't?

Btw, the example above is simplistic: you actually need to supply all
the relevant compiler switches on the GCC command" the -I switches,
the -D and -U switches, etc.; otherwise, the results will be
inaccurate.

As another "btw", we have cpp.el which provides a similar
functionality; perhaps hideif.el could learn something from there?

Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[Luke Lee]

Eli Zaretskii <eliz@gnu.org> writes:

>
> How about making hideif.el capable of running a GCC command such as
> above automatically, and using the output to find which macros should
> be defined and which shouldn't?
> [...]

Yes, actually that was in my TODO list including the nesting recursive
#include process; however that might take a long time to run for any
decent project.  The most important part is to set a configurable inclusion
path list to search, which also serves for GCC's "-I" arguments if it's
going to be executed automatically.

>
> As another "btw", we have cpp.el which provides a similar
> functionality; perhaps hideif.el could learn something from there?

Okay, I will take a look, meanwhile if you have a more specific item for
me to look please let me know. Thanks.

Best regards,
Luke Lee

Re: master 87e7390: * lisp/progmodes/hideif.el: update for new C++ standards and extensions

[Eli Zaretskii]

> From: Luke Lee <luke.yx.lee@gmail.com>
> Cc: chenzhiwei03@kuaishou.com,  contovob@tcd.ie,  emacs-devel@gnu.org
> Date: Thu, 03 Jun 2021 17:10:42 +0800
> 
> > As another "btw", we have cpp.el which provides a similar
> > functionality; perhaps hideif.el could learn something from there?
> 
> Okay, I will take a look, meanwhile if you have a more specific item for
> me to look please let me know. Thanks.

Sorry, I've misremembered: I meant cmacexp.el, not cpp.el.  Although
it could be that cpp.el will also prove useful for what you have in
mind.