From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 21466@debbugs.gnu.org
Subject: bug#21466: [PATCH] Avoid defining (temporarily) vars and functions
Date: Tue, 11 May 2021 18:03:38 -0400 [thread overview]
Message-ID: <jwvlf8llyt3.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <YJrqVlJR4iMvf2s1@ACM> (Alan Mackenzie's message of "Tue, 11 May 2021 20:34:30 +0000")
> There are little things I'm unhappy about with the patch: it
> explicitly tests (featurep 'xemacs), which is not done in CC Mode,
> being regarded as somewhat vulgar. Instead specific functionalities
> are always tested for.
I use (featurep 'xemacs) because it results in cleaner byte-code because
the compiler replaces it with nil. It also usually results in fewer
spurious warnings (because of the removal of XEmacs-only code).
[ I believe the same holds on XEmacs where (featurep 'xemacs) is
optimized to t, which removes Emacs-only code. ]
But that's just my favorite bikeshed color, it's not crucial for the patch.
> Also, in place of cc-bytecomp-defun is proposed declare-function.
> However this is in an inconsistent state, with the documentation
> requiring a FILE argument, but Stefan's patch supplying nil.
`declare-function` says:
The FILE argument is not used by the byte-compiler, but by the
`check-declare' package, which checks that FILE contains a
definition for FN.
So indeed, a real FILE argument would be preferable, but passing nil
works fine (it will simply prevent `check-declare` from making sure
that file indeed defines that function, which is no different than what
we have now with `cc-bytecomp-defun` which `check-declare` also
ignores).
If you want the "better" option, then it will require changing
`cc-bytecomp-defun` so it takes a FILE arg.
Stefan
next prev parent reply other threads:[~2021-05-11 22:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-12 3:36 bug#21466: [PATCH] Avoid defining (temporarily) vars and functions Stefan Monnier
2015-10-29 13:09 ` Stefan Monnier
2019-11-06 1:29 ` Stefan Kangas
2021-05-10 11:45 ` Lars Ingebrigtsen
2021-05-11 20:34 ` Alan Mackenzie
[not found] ` <YJrqVlJR4iMvf2s1@ACM>
2021-05-11 22:03 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-07-23 13:14 ` Lars Ingebrigtsen
2021-07-23 15:01 ` Glenn Morris
2021-07-24 10:26 ` Lars Ingebrigtsen
2022-03-23 20:13 ` Lars Ingebrigtsen
2022-03-25 21:09 ` Alan Mackenzie
2022-03-26 14:45 ` Alan Mackenzie
2022-03-26 16:47 ` Lars Ingebrigtsen
2022-03-26 19:51 ` Alan Mackenzie
2022-03-29 12:26 ` Lars Ingebrigtsen
2022-03-29 21:02 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvlf8llyt3.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=21466@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).