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