emacs-devel
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]