Re: Keep/drop emacs variables in documentation sources?

On Fri, 26 Apr 2024 10:56:53 -0000 (UTC)
Guenter Milde via Docutils-develop
<[email protected]> wrote:

> Dear Branden,
> 
> On 2024-04-24, G. Branden Robinson wrote:
> > At 2024-04-24T19:06:23-0000, Guenter Milde via Docutils-develop
> > wrote:  
> >> So my question is:  
> 
> >> * Do we want to keep the emacs variables block?
> >>   Is anyone using emacs?  
> 
> > I tend to use Vim, but occasionally use emacs.  
> 
> >> * If yes, do we need the FORM FEED character
> >>   (it shows as ^L in my text editor).  
> 
> > As far as I know, this is not necessary.  As I recollect, GNU Emacs
> > scans backward through the last 3,000 bytes of the file attempting
> > to match the "Local variables:" pattern; the lack of a form feed
> > character before that text does not frustrate the search.  
> 


> AFAIK, the ^L (FORM FEED) is intended to hide the local variables away
> (maybe as a marker for some emacs-special functionality or simply by
> pushing the following lines out of view).

> If there are no objections, I would sacrifice the FORM FEED 
> in favour of a simple commit test for trailing whitespace.

I am no expert; note the emacs docs say:

The start of
the local variables list should be no more than 3000 characters from the
end of the file, and must be on the last page if the file is divided
into pages.
<snip>
   If some unrelated text might look to Emacs as a local variables list,
you can countermand that by inserting a form-feed character (a page
delimiter, see Pages) after that text.  Emacs only looks for
file-local variables in the last page of a file, after the last page
delimiter.

So my guess is that the line feed is a "guard" that allows RST
files to end in something that looks to emacs like a local variable
list, but is intended to be document text.  This does sound like
it could be useful in special edge cases.

Regards,

Karl <[email protected]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein