On Wednesday, June 24, 2015 at 5:12:01 AM UTC-5, Roland Eggner wrote: > > There are more cases, where vim tries to fix “errors” or “irregularities” of > files and thereby damages them, unless “++binary” has been included in the > reading command. Just two examples: > > (1) viminfo files with register contents resulting from alternating > fileencondings, e.g. utf-8, latin1, latin9: When viewing or editing > such > viminfo files, including “++binary” in the reading command avoids data > damage.
First of all, .viminfo files are not really intended to be hand-edited, although the format is simple enough that it's certainly possible most of the time. However, you're expecting something fairly unreasonable. Vim has no way of marking different regions of a file as having different encodings. In fact I am not aware of any text editors that DO allow this. How does the editor know what encoding to apply to any new text? How are the regions delimited, especially if the delimiter could have different representations in different encodings? In the case that you have multiple encodings in a file, the file really and truly *IS* a binary file. But why do you have multiple encodings in the file? The encoding of text in the _viminfo file should only depend on the 'encoding' option of Vim, it should not depend on the fileencoding option of the various files. Are you setting 'encoding' differently as you open files in different files? You should not be doing that...you should keep 'encoding' set to utf-8 and change 'fileencoding' as needed. > How can I specify the binary attribute, when vim tries to restore > this register contents in a later session? vim-7.4 appears to ignore > the > line “*encoding=utf-8“ on reading of viminfo files. Vim does not, by default, detect any encoding from any text in the file, except for reading a BOM to detect certain Unicode encodings. For that, you need a plugin. I am fond of Autofenc: http://www.vim.org/scripts/script.php?script_id=2721 > (2) The patch file resulting from the diff between old and new files after > a command similar to “iconv -f ISO-8859-1 -t utf-8 …” usually needs to > be > treated as binary. vim damages such patch files on writing, unless the > reading command includes “++binary”. > See above. Such a file *is* a binary file, it cannot be anything else. If you forget to read it with ++binary in the first place, you can always ":e ++binary" after loading. > A concept which can be reused _consistently_ for the solution of all > problems > of this class probably can save a lot of future work time. > I disagree that these problems are in the same class at all, but the option for preventing such issues already exists: ":e ++binary". The binary option tells Vim not to mess with any of the bytes in the file. That's what you want, right? Is something wrong with this option? > Transparent decompression and compression of *.gz *.bz2 … files is > implemented > with certain autocommands. This autocommands require much less lines of code > than the patch proposed by Pavel. Why not solving the “missing trailing EOL” > problem with similar autocommands? Less lines of code means less time to > wait > until Bram can merge this and other patches. > The autocmds to prevent messing with the EOL are here: http://vim.wikia.com/wiki/Preserve_missing_end-of-line_at_end_of_text_files > Are the more lines of code of Pavels patch outweight by better reusability, > compared to autocommands? > ":set respecteol" is much easier for the end user than installing a plugin or writing a few dozen lines of vimscript to work around the editor's lack of an option to turn off an undesired behavior. And probably less fragile as well, since it will be baked into the editor code. And autocmds can be bypassed or interfere with each other. And see the discussion on that link about weird behavior with respect to undo for the autocmds...that's not very comforting that we never figured that out. -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
