>> But something I really do think is worth changing because it's really >> confusing, is ++enc. Why do we call this ++enc not ++fenc which would >> make a huge amount more sense, and be more consistent with ++ff and >> ++bin which both set their namesake options? We see evidence of people >> getting 'enc' and 'fenc' confused on a regular basis, and this feature >> naming really doesn't help matters. What would you think of changing >> this, Bram? Perhaps making it officially ++fenc but accepting ++enc >> for compatibility with old scripts (and old users!)? > > These are not really option names, although I can see that they are so > similar that people might think that. They are options for the command. > Offering more alternatives isn't going to make it simpler. We also > don't have 'fbin' for reading a file in binary mode.
Yes, I realise they're not option names, but they undeniably do look like it, and time and time again we see people getting 'fenc' and 'enc' confused, and ++ff sets 'ff' when reading, ++bin sets 'bin', but ++enc sets 'fenc'. This is only confusing because there *is* an option called 'enc'. If there weren't, as there isn't a 'fbin' option, nor a 'format' option, it would be no problem. But, hey, it's not too important. I just thought I'd throw it out there, as I think it has potential to help a lot of users avoid confusion. Maybe I'm wrong. It would be interesting to hear what others think. >> Also, I wonder whether it might be worth adding a 'best practices' >> section to mbyte.txt and referring to it in such places as 'enc' >> (probably mostly there) which explains the basics in a few short >> paragraphs: set 'enc' in your .vimrc (recommend utf-8), 'tenc' if your >> terminal/locale is different (unneeded in GUI), use ++fenc if a file >> is read with wrong encoding detected, 'fenc' to change what encoding >> to write a file with for future writes. This sort of material is >> repeated frequently on the mailing lists which suggests users aren't >> finding it easily in the help (though it is all there, it is somewhat >> spread around, etc.). Do others think this might or something similar >> might be a good idea? > > It will certainly help to update the documentation to explain common > pitfalls. Writing this in a nice way, without becoming too verbose and > putting it in the right place is not easy. If you or someone else can > suggest a patch that would be great. I agree. Terseness is definitely not my strength, though, so I might leave this to someone else to have a try if anyone is willing. Volunteers? Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
