groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] 01/01: preconv: Support Emacs coding tags at file ends.


From: John Gardner
Subject: Re: [groff] 01/01: preconv: Support Emacs coding tags at file ends.
Date: Fri, 8 May 2020 17:30:40 +1000

> A non-Unix text editor which liked to do things its way, e.g. the
> three-byte ‘foo’ is a text file.  Putting how to read a file at the end
> of that file is such a daft idea when placed in a Unix context; it's
> alien and should not be encouraged.

That's an oversimplification. And Vim does this too
<https://vim.fandom.com/wiki/Modeline_magic#Examples>.

Emacs will read both the variable-line at the top of a file *and* the
variable-block at the bottom. As far as it's concerned, `coding` is just
another file-local variable that sets the buffer's encoding scheme
(specifically, the `buffer-file-coding-system` variable). The choice of
syntax is largely a matter of taste and author discretion (as well as
use-case; stuffing 10 local variables onto a single line isn't exactly
ergonomic).

That being said, if a variable is declared twice with different values,
Emacs will pick whichever comes first. For example, this

# -*- coding: utf-8; -*-

...

# Local Variables:
# coding: us-ascii
# End:


will open the file as UTF-8, rather than US-ASCII.

If we're extending preconv(1) to recognise editor-related settings, it
should be consistent with their behaviour. It also wouldn't hurt to add
support for .dir-locals.el
<https://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html>
and .editorconfig <https://editorconfig.org/> manifests, though that might
be edging on overkill.


On Fri, 8 May 2020 at 16:47, Ralph Corderoy <address@hidden> wrote:

> Hi Ingo,
>
> > but are we really sure that that nobody relies on the possibility to
> > run their own preprocessor before preconv(1)?
>
> They of course do.
>
> > And that nobody pipes input into groff(1) on stdin?
>
> All the time.
>
> > This is a more serious bug, a potential security vulnerability:
> > Use after free.
>
> And I can see a probable wandering off the end of the buffer too.
>
> > I'd suggest that we first decide whether we want to encourage people
> > to put the coding at the end even though that clearly reduces
> > robustness and possibly harms portability.
>
> It's a bad idea.  The clue is:
>
> > > +// Get coding tag from Emacs local variables list at end of file.
>
> A non-Unix text editor which liked to do things its way, e.g. the
> three-byte ‘foo’ is a text file.  Putting how to read a file at the end
> of that file is such a daft idea when placed in a Unix context; it's
> alien and should not be encouraged.
>
> --
> Cheers, Ralph.
>
>


reply via email to

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