Hi Pavel
On 2015-06-24 Wednesday at 11:12 -0700 Pavel Samarkin wrote: > … > I was aiming at something different. > Problem (as I see it): Vim is based on a fact that every text file is > POSIX-compliant > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 > > which is not necessarily true on all platforms supported by Vim. > > Because of that, some scenarios are not currently supported by Vim. > For example: > > Given: a text file in UTF-8 encoding, with BOM, with DOS line endings and > without trailing EOL. > > Scenario: edit the contents of this file preserving all the attributes > specified in Given. > > Real-world application: Microsoft Visual Studio project file in source > control. > > Solutions that Vim provides currently: > (1) regular :save - will add a trailing EOL; > (2) :w ++binary - will replace <CR><LF>s with <LF>s and lose BOM; > (3) Solution from vim.wikia - > > http://vim.wikia.com/wiki/Preserve_missing_end-of-line_at_end_of_text_files > - preserves <CR><LF>s, but loses BOM and adds some overhead to the > write process; > (4) vim -b <filename> - displays <CR>s and BOM as deletable characters and > disables some text-related options (like 'expandtab' and 'modeline'), so > it's not always applicable; > (5) some more complicated solutions I found on the Internet use external > scripts (Python or Perl) to remove EOL from already saved file, > which seems like an overkill to me - why to write and then remove > something if we don't need it originally? Besides, Python and Perl are > not always available on all platforms. > > Solution with my changes: > :set reol > :w > > In my particular case, adding the following to the .vimrc: > au BufWrite *.csproj set respecteol > will once and for all declare all *.csproj files as not necessarily > POSIX-compliant. > > > > I'm sorry if I confused anyone by my original message and I hope that my > point > is more clear now. Yes, now it is clear for me. Thank you for the detailed explanation. I assume, the *.csproj files are originally written arbitrarily sometimes without and sometimes with trailing EOL, and can imagine, how nasty this is in the context of version management. Would the following alternative solution work for you? (1) Add a make target to your source code projects, which reads the *.csproj files and writes shadow files *.csproj.EOL_fixed, thereby just adding the trailing EOL if it misses. The “workhorse” utility performing this file writing could be vim, or if the number of your *.csproj files is very large it could be a perl script or a small dedicated binary compiled from a few lines of C code written by you. Optionally if you want to hide the shadow files in directory listings, the make target could set the file attribute “hidden” usually available on Microsoft filesystems. (2) Add a pre-commit hook to the version management system, which calls this make target. (3) Add the shadow files *.csproj.EOL_fixed to the files tracked by the version management system, and add an ignore rule for *.csproj files. Considerations: • Solving problems as close to their source as possible usually results in the least effort required in the long run. • Adding trailing EOL to already saved files probably requires less effort than an editor builtin solution. Human worktime is more expensive than cputime. Thus it is very common in the software industry to save human worktime by combining some already built software modules, rather than to create a new monolithic solution which solves just a single problem. The former usually increases the productivity of software engineers, whereas the latter usually increases the profit of certain big market players. https://en.wikipedia.org/wiki/Unix_philosophy • With (1) … (3) you would be better prepared for the future: If Microsoft some day will break its own standards (already did so regarding other software products), and some of your business partners exchanging *.csproj files with you use a new, backwards incompatible release of the software writing this files, you could save the need to buy a license for the new release just by modifying the utility used by the make target in (1). • You can read a few more considerations near the end of my mail replying to Ben in this thread. Question: Is the patch you propose really the long-term-least-effort solution, or can (1) … (3) or something similar provide a satisfying solution for you with less effort? -- Best regards, Roland Eggner -- -- 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.
pgp8iKfrdaoUL.pgp
Description: PGP signature
