[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Small correction to commit ae2463796f236b8ee2cef3b5e38bffa13abd2233
From: |
Eli Zaretskii |
Subject: |
Re: Small correction to commit ae2463796f236b8ee2cef3b5e38bffa13abd2233 |
Date: |
Fri, 06 Sep 2024 14:04:10 +0300 |
> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Fri, 6 Sep 2024 10:13:20 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>
> I've continued thinking about this and have come up with:
>
> Make sure this
> evaluation does not load any files, or call functions like
> @code{posn-at-point} or @code{window-in-direction}, which themselves
> evaluate the mode line, as doing so could cause infinite recursion.
>
> or
>
> Make sure evaluating @var{form} does not load any files, or call functions
> like
> @code{posn-at-point} or @code{window-in-direction}, which themselves
> evaluate the mode line, as doing so could cause infinite recursion.
The current text says
Make sure this evaluation neither loads any files nor calls functions
like @code{posn-at-point} or @code{window-in-direction}, which
themselves evaluate the mode line, as doing so could cause infinite
recursion.
which I think is equivalent to what you suggest, but slightly less
ambiguous, grammar-wise.
> I personally would highlight this. Putting that in a separate paragraph may
> help
> or adding a bold *CAVEAT* before. My feeling is that being in the paragraph
> dilutes the importance of this kind of advices, not only here, but also in
> other
> places in the manuals. I know this can may take long, but IMHO this would
> improve
> the manuals a lot.
I don't see a reason to make each caveat in the manual stand out.
There are too many of them.