unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 53526@debbugs.gnu.org
Subject: bug#53526: 29.0.50; macroexp-warn-and-return API change
Date: Tue, 25 Jan 2022 18:16:56 +0000	[thread overview]
Message-ID: <YfA+mJplNXm114qw@ACM> (raw)
In-Reply-To: <jwv4k5rdaa1.fsf@iro.umontreal.ca>

Hello, Stefan.

On Tue, Jan 25, 2022 at 11:56:22 -0500, Stefan Monnier wrote:
> Package: Emacs
> Version: 29.0.50


> The following change in `macroexp.el` on `master` is not backward
> compatible with the Emacs-28 API:

> -(defun macroexp-warn-and-return (msg form &optional category compile-only)
> +(defun macroexp-warn-and-return (arg msg form &optional category compile-only)

No, it isn't.  All the uses of the function are in lisp/emacs-lisp, and
I understood the function to be an internal one.

> I suspect that the `arg` should be added at the end instead.

The other functions (like byte-compile-warn-x) which have acquired this
extra argument need to have it at the start, since there are an
indeterminate number of &rest args going into a `format'.  So it seemed
better just to do the same with this function, to preserve a sort of
compatibility.

> While I'm here I also noticed that `byte-compile-form-stack` is a poor
> name for a variable declared in `macroexp.el`.

It's an integral part of bytecomp.el.  It got moved to macroexp.el
because it is used (twice) there, and that file is loaded into bootstrap
emacs before bytecomp.el.

There is precedent for this "mis"naming, namely
byte-compile-bound-variables.

> It should either be renamed to use the `macroexp-` prefix, or moved to
> `bytecomp.el` (and it probably should have a double-hyphen, since I
> think it's not meant to be used by anyone but us).

It started off life with a double hyphen in bytecomp.el.  But when it
started getting used in macroexp.el (during the expansion of a macro) it
lost the extra hyphen and got moved there.  It's no big deal, I think,
just that there's no completely neat way of doing this, so the
compromise actually used is pretty arbitrary.  If the variable were in
bytecomp.el, we'd probably need a boundp call in the two places we use
it in macroexp.el.

Whilst on the topic of macroexp-warn-and-return (and
macroexp--wrap-warn), I have to admit having difficulty understanding
these functions, both how they work and what they're for.

My impression up till a couple of days ago was that they were ways of
coping with the old warning position mechanism, and were intended to
compensate for its deficiencies.

Now, I'm much less sure.  Was I indeed mistaken?  If I was, what then is
the purpose of these functions, which defer warning messages in some
fashion?  If I was right, it would be a good thing to dismantle them,
since they are complicated and difficult, and no longer needed.  As I
said, I don't really understand them.

Thanks!

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2022-01-25 18:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 16:56 bug#53526: 29.0.50; macroexp-warn-and-return API change Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-25 18:16 ` Alan Mackenzie [this message]
2022-01-25 19:10   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-30 13:34     ` Alan Mackenzie
2022-01-30 17:01       ` 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=YfA+mJplNXm114qw@ACM \
    --to=acm@muc.de \
    --cc=53526@debbugs.gnu.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).