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.
Best regards,
Tony.
--
An egg has the shortest sex-life of all: if gets laid once; it gets
eaten once. It also has to come in a box with 11 others, and the only
person who will sit on its face is its mother.
--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
