On Jan 17, 8:03 pm, Tony Mechelynck <[email protected]> wrote: > On 18/01/10 01:15, AndyHancock wrote: > > > > > On Sun, Jan 17, 2010 at 6:46 PM, Tony Mechelynck > > <[email protected]> wrote: > >> On 17/01/10 23:55, AndyHancock wrote: > > >>> I am finally following up on the solution below for using bullets > >>> corresponding to Windows-1252 code 149 (0x95). I put the script in > >>> vimrc, issues "gvim Temp.txt" from the bash command line (Temp.txt is > >>> nonexistent), and got no warning about missing multi_byte capability > >>> [ not surprising since ":echo has('multi_byte')" yields 1 ]. However, > >>> I'm still not getting the bullet. I tried a few ways. > > >>> First, I created a bullet in one of a couple of Windows app (Firefox, > >>> Palm Desktop) using the usual method: Alt-0149 on the number pad. > >>> (Actually, it's a laptops, so I had to use "num lk", which locks some > >>> of the qwerty keys into a number pad function). Then I copied and > >>> pasted the bullet into gvim (mouse middle-button to paste, since it's > >>> X-windows). It pastes as a question-mark character. > > >>> I then tried Alt-0149 directly in gvim while in insert mode. No joy, > >>> as this translates into four characters, corrersponding to Alt-0 Alt-1 > >>> Alt-4 Alt-9. > > >>> Finally, in insert mode, I did Ctrl-V 149, which simply inserts a > >>> character with hex code ox95. I literally shows up as a blue-coloured > >>> "<95>" without quotes. The "ga" command shows this to be a character > >>> with hex code 0x95. I thought that the last method above might be > >>> fine, and perhaps it just wasn't showing up in the gvim window due > >>> some reason related to X-windows fonts. So I copied and pasted the > >>> text into a Windows app...the result was a space in place of the > >>> bullet. Note that the bullet 0x95 copies successfully between windows > >>> apps, and between windows apps and windows-based gvim (as opposed to > >>> cygwin gvim). > > >>> I also tried the alternative bullet 0xB7, but that's almost invisible > >>> in Palm Desktop. Better to use an asterisk (which is highly > >>> nonideal). > > >>> To troubleshoot the script, I tried querired the following options, > >>> with the shown results: > > >>> Encoding > >>> -------- > >>> set encoding > >>> Ans: encoding=utf-8 > > >>> setlocal encoding > >>> Ans: encoding=utf-8 > > >>> setglobal encoding > >>> Ans: encoding=utf-8 > > >>> This make sense, since encoding is global. > > >>> Fileencoding > >>> ------------ > >>> set fileencoding > >>> Ans: fileencoding= > > >>> setlocal fileencoding > >>> Ans: fileencoding= > > >> 'fileencoding' empty means that the file will be recorded in the same > >> charset as 'encoding', i.e., UTF-8. In that charset, 0x95 (or 149 decimal) > >> is a non-printable control character. Since this control character has no > >> representation in Windows-1252, you cannot convert to Windows-1252 an UTF-8 > >> buffer which contains it (and remember, 'encoding', not 'fileencoding', > >> defines how Vim represent the data in memory). > > >> As I said in my previous post, to generate a file encoded on disk in > >> Windows-1252 with a Windows-1252 bullet (0x95 on disk) in it, you must: > > >> 1) keep 'encoding' to UTF-8 as above > > >> 2) :setlocal fileencoding=cp1252 " (or: :setlocal fenc=windows-1252 ) > > >> 3) Enter the character into Vim as the Unicode representation of the > >> equivalent character, i.e. U+2022. To do that, in Insert mode, type (with > >> no > >> intervening spaces, I add them here only for legibility): Ctrl-V u 2 0 2 2 > >> (but if your Ctrl-V has been remapped to the Paste operation, use Ctrl-Q > >> instead). > > >> See > >> :help i_CTRL-V_digit > >> :help i_CTRL-Q > >> :help CTRL-V-alternative > > > Actually, I'm just discovering this from reading at the same time you > > responded. What happened was that I suspected the bullet wasn't > > getting properly copied over by the bridge between the Windows cut/ > > paste buffer and X-windows's cut/paste buffer. So on the Windows > > side, I used Notepad to save a text file containing the desired > > bullet. Then I opened it using Vim, but I had to set encoding=utf-8 > > for the bullet to show properly. "ga" revealed the 4-digit hex code, > > which was no longer decimal x95, but the help showed how to enter 4- > > digit hex codes. If I originated the file from the unix/cygwin/gvim > > side, I'd have to be sure to set fileformat=dos before I could see the > > bullet. > > > All this to say that if I want to use Vim to work on text from the > > Palm Desktop, I need to save it to a DOS text file by pasting into > > Notepad first. Ah well. A bit more buttonology won't kill me, though > > I have to admit it's not convenient. However, it isn't inconvenient > > enough for me to install the Windows version of gvim -- that would be > > so overkill. > > > Thanks, Tony. > > To save a file in dos fileformat (i.e., with CR-LF ends of lines), use > > :setlocal ff=dos > > before you save the file. > > To have Vim _recognize_ that an existing file is in dos fileformat when > reading, be sure that the 'fileformats' (plural) option contains "dos", e.g. > > :set ffs=dos,unix > > Note that if the file contains some lines with CR-LF and some without CR > (which also applies if the last line has no end-of-line at all), Vim > will prefer Unix to Dos (and show carriage returns as ^M) unless you use > ++ff=dos (see :help ++enc); this ++ff modifier wasn't always handled > correctly before Vim 7.2.040. > > If you force Dos fileformat with ++ff=dos, then on _reading_ the file a > linefeed preceded or not by a carriage return will terminate the line, > but on _writing_ it *every* line will get both CR and LF at the end. > > The 'fileformat' option concerns _only_ the ends-of-lines; not the way > some character (such as the bullet) is represented inside the file.
Yes, got it. Just checked. I will need set ff=dos because the main reason for using this bullet is so that I have a decent vim editor when editor text from the Palm Desktop. For this purpose, even if I create a new spanking file, I need to save it a DOS file and open it with Notepad. Simply because the bridge between X-windows cut/paste and Windows cut/paste doesn't preserve the bullet. And thanks for the tidbits on forced (temporary) setting of ff for a single write command.
-- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
