Re: Setting file encoding in a modeline

On 10/12/2020 17.03, Bram Moolenaar wrote:
> These days using utf-8 is the standard way. If you still have a file
> laying around in another encoding and you are OK editing it, it's easier
> to convert it to utf-8 then to add a modeline.

Unfortunately in some cases it's still necessary to keep using a
specific encoding, on files still being occasionally edited and for
which a modeline would work.
So, it would still be nice if it could be done.
The prospect of being able to declare the encodings in that way was
actually one of the main reasons for me to learn Vim, of course until I
found out it's the one thing that Vim's modelines absolutely cannot do...



> It's also easy to get wrong: If 'fenc' is set in the modeline, one can
> write the file in another encoding and mess it up.

I'm not sure what you mean (wouldn't that happen only if the user
changed 'fenc' manually?), but if this feature were to be implemented it
would absolutely make sense to do so through some new syntax instead of
changing how 'fenc' in the modeline is interpreted, because:
- changing that would easily cause hard-to-notice encoding problems if
one were to use an older Vim version on files with these 'fenc'
modelines (and it's not unusual to have to use older Vims from time to time)
- it's very hard to predict the effect of 'fenc' and the other current
encoding options

If it were implemented anyway it would seem reasonable to go check the
modeline before writing and ask for confirmation if the encoding
declared there didn't match the one about to be used.

---

I don't know if it would make more sense to introduce a
modeline-pseudo-option, for example "vim: expected-encoding=cp447", or a
completely new modeline type such as "encoding: cp447", of course that
could be used in addition to a normal modeline line.

For the pseudo-option alternative, this would not correspond in any way
to an actual Vim option, it would only be something recognized and
handled by the modeline interpreter.
This approach would have the effect of producing an "Unknown option"
warning on older Vim versions, which could be argued to be either a good
or a bad thing:
- good because you'd have a very visible warning of the encoding caveats
even on these older versions
- bad because it could be a nuisance to someone.
I would lend towards the "good" view.

For the new modeline alternative, it would have the pro/con of not
giving rise to warnings, it might be a little less confusing, and might
have the advantage of being easier to pick up and support by other
editors too.

Indeed it would be nice to have something agreed with other popular editors.

About that... couldn't we just support the Emacs thing?
-*- coding: cp437  -*-
works there
(https://www.gnu.org/software/emacs/manual/html_node/emacs/Specifying-File-Variables.html).
Of course just for the encoding, I'm not arguing for attempting to
support other Emac's file variables, and not necessarily all its coding:
values either.
Is this something completely inconceivable?

By the way, this Emacs thing also gives you an example of how the
feature can be implemented.

But maybe a completely new syntax for all editors and other software
would be fairer and easier to accept for everyone (though probably hard
to agree upon).



> If you really want to, you can make a BufReadPost autocommand that does
> it for you. You don't even need a modeline then, anything you can
> recognize the file by would do (e.g. path prefix or some text found in
> the file).

Hmm that's an option to keep in mind, but:
- it's quite a bit harder to use
- in the path prefix case, the encoding of a file is a property of that
file, "detaching" it and putting it in Vim's configuration in many cases
would be not very clean and more prone to lead to encoding mistakes.

I think that even in this era of convergence towards UTF-8 the ability
to declare the encoding would be useful to enough people to warrant an
easy-to-use feature, especially if it were something that could be
adopted by other programs too.


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/1398ea3d-1c97-787d-b78b-dbd50e4a90a9%40tiscali.it.