From: Stefan Kangas <stefankangas@gmail.com>
To: Matt Armstrong <matt@rfc20.org>
Cc: 58801@debbugs.gnu.org
Subject: bug#58801: [PATCH] Autoload the `calc-eval-error' variable
Date: Fri, 11 Nov 2022 05:16:42 -0800 [thread overview]
Message-ID: <CADwFkmmzf+ho6_KqO1Avyz6pcNrzTydngz5q6DdkgZs5frBWOQ@mail.gmail.com> (raw)
In-Reply-To: <87fsfaa56t.fsf@rfc20.org> (Matt Armstrong's message of "Wed, 26 Oct 2022 10:02:50 -0700")
Matt Armstrong <matt@rfc20.org> writes:
> From 526d0b31e0d836e7a3c21d831849b8c50da2420e Mon Sep 17 00:00:00 2001
> From: Matt Armstrong <matt@rfc20.org>
> Date: Wed, 26 Oct 2022 09:46:37 -0700
> Subject: [PATCH] Autoload the `calc-eval-error' variable
>
> * lisp/calc/calc-aent.el: Autoload the `calc-eval-error' variable,
> because it is documented as a lisp level option of the `calc-eval'
> function, which is also autoloaded. Otherwise, even (require 'calc)
> is not enough to get the variable defined; `calc-eval' must actually
> be evaluated. This squashes byte compiler warnings in code using the
> variable.
I don't necessarily object strongly or anything, but should we really
autoload a variable just to squash byte compiler warnings?
I think the usual way to do that is to say
(defvar calc-eval-error)
in the calling code.
> ---
> lisp/calc/calc-aent.el | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lisp/calc/calc-aent.el b/lisp/calc/calc-aent.el
> index ef3e0d4b67..59692beff7 100644
> --- a/lisp/calc/calc-aent.el
> +++ b/lisp/calc/calc-aent.el
> @@ -252,6 +252,7 @@ calc-do-calc-eval
> res (cdr res)))
> buf)))))))))
>
> +;;;###autoload
> (defvar calc-eval-error nil
> "Determines how calc handles errors.
> If nil, return a list containing the character position of error.
next prev parent reply other threads:[~2022-11-11 13:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 17:02 bug#58801: [PATCH] Autoload the `calc-eval-error' variable Matt Armstrong
2022-11-11 13:16 ` Stefan Kangas [this message]
2022-11-15 18:24 ` Matt Armstrong
2022-11-15 18:42 ` Eli Zaretskii
2022-11-24 19:50 ` Stefan Kangas
2022-11-26 16:58 ` Matt Armstrong
2023-09-07 7:51 ` Stefan Kangas
2023-11-05 16:38 ` Stefan Kangas
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=CADwFkmmzf+ho6_KqO1Avyz6pcNrzTydngz5q6DdkgZs5frBWOQ@mail.gmail.com \
--to=stefankangas@gmail.com \
--cc=58801@debbugs.gnu.org \
--cc=matt@rfc20.org \
/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.