cga2000 wrote:
On Mon, Jul 24, 2006 at 11:38:30PM EDT, A.J.Mechelynck wrote:
[..]
.. with all the goings-on in this thread I never had a chance to
mention the fact that I do not use gvim. I try to do everything in a
terminal (under gnu/screen) because text-mode apps were designed for
the keyboard so they work a lot better than gui's for those of us who
prefer not to use mice.
Gvim can use keyboard commands just like console Vim,
.. that's where I disagree.. either you stick with Vim commands and
":commands" and you don't need the gui.. or you you have to have a
mouse for company and you belong in Notepad hell. :-)
I need gvim for its display, not for its mouse. In fact I rarely use the
mouse in gvim.
Of course you can use the keyboard to navigate most modern gui's..
kinda works.. But, any routine action will always be not only
considerably slower in a gui than a terminal-based app but *also*
requires a lot more cycles of you own personal cpu, thus distracting you
from what you are doing. Now why would I put up with that ugly GTK
clutter that I never use when I can use a nice streamlined interface
that does not distract me from what I am doing?
I *much* prefer something simple like the bluez.vim color scheme that I
have slightly modified for my own use.
http://www.geocities.com/cga9999/vim.png
FYI - it took me more than five years before I began to suspect that
there had to be a better way to interface with the machine.. than the
gui, that is. Sure.. with non-gui stuff there is a learning curve.. but
as soon as you're over the top.. gee.. now I'm in heaven..
or mice-addicted
people can use that too. It has a lot more different coulours (typically
16 million rather than 16)
good point. A 256-color terminal is IMHO an absolute necessity. I
don't think more than that is any use in text-mode apps, though.
and it can change fonts on-the-fly (change
the font from Courier to Lucida to whatever, only through Vim keyboard
commands).
I would never want do that.. but just out of curiosity.. why would that
not be possible in an xterm?
because console Vim has no control over the xterm's fonts.
It can do "real" boldface and italics, as well as straight or
curly underlining.
That would be for highlighting stuff, right? So the same functionality
can be achieved with colors. And in a more pleasing manner IMHO.. the
color schemes that I have seen that use italics have not convinced me.
I do html a lot, and it helps me to see <i>italics, <b>bold italics,
<u>bold underlined italics,</u></b> <u>underlined
italics,</u></i><u>underlined</u> text all displayed like they should.
Of course colours can do it, but console vim has only 16 bg and 16 fg
colours: the list is soon over.
And it can use Unicode: see further down.
:echo has("multi_byte")
the answer should be 1. If it is zero, your version of gvim cannot
handle UTF-8.
Works fine if I switch my locale to UTF-8. Vim automatically figures
what I want and :dig displays the "o dans l'e" (both the lower and upper
case versions) among a gazillon other digraphs. Then I can use the
ususal Ctrl-K oe .. save the file.. pass this on to LaTeX and provided I
have the correct LaTeX statements to activate UTF-8 (that's what took
forever to figure out the other day..) I get my "coeurs", "voeux" and
"boeufs" rendered correctly in xdvi/gv .. *and* the the ensuing
printout looks great too.
The problem with this is that I haven't found a comfortable way to
run Vim in UTF-8 mode and the rest of my stuff in 8-bit mode.
Well, in an xterm (or konsole, or Windows Dos Box), console Vim is
dependent on xhatever charset the console is using. If you xterm (or
whatever) is in Latin1, you cannot use French oe anymore than you can
use Cyrillic or Greek. Gvim, on the other hand, can display anything for
which you have a glyph in a font.
hmm.. looks like with terminals you need to be 100% UTF-8.. locale..
font.. terminal.. vim encoding.. for it to work.
http://www.geocities.com/cga9999/vimgold.png
The silly sample text I wrote while practicing LaTeX clearly has
problems with the "o dans l'e" rendered as a ½ (latin9 encoding)..
garbled words are "coeur" and "oeufs"..
This is with a latin9 encoding.. If I switch to utf8 all the accented
letters are displayed as <e0> .. <e9> .. etc.
I'll have to bounce my X session some time tomorrow and switch back my
locale to UTF-8 fire up X and a uxterm and see what happens.
Where would I switch to UTF-8 in gvim.. Couldn't find the option in
the menus.. Maybe it just isn't there because my X session's locale is
set to en_US?
Ah shoot.. I had promised myself I wouldn't let myself be dragged into
another UTF-8 wild goose chase.. it's now past 2 A.M. .. and guess what
I'm doing..
:-)
[..]
So what is Unicode and what is UTF-8.
Unicode is a system to allow using *together* all writing systems known
to man. That's a lot. A "character space" with over 1 billion slots has
been set apart for all those characters.
Unicode is also a number of 'encodings' -- manners to represent that
data in memory or on a storage medium. The simplest of these encodings
is UTF-32 (aka UCS-4): use 32 bits for each characters, in the
endianness of your machine. The most economical is usually UTF-8, which
uses between one and four bytes per character; also, it represents 7-bit
ASCII identically as ASCII; characters 128-255 of the Latin1 encoding
have the same ordinal position in the scheme but are represented by two
bytes each. Also, of the 3 principal Unicode encodings, UTF-8 is the
only one which isn't subdivided into "big-endian" and "little-endian"
varieties. There is no risk of out-of-phase errors, because of the
allotment of the bytes: 0-0x7F are single-byte characters, 0x80-0xBF are
"trailing bytes" (any byte except the first in a multi-byte character),
0xC0-0xFF are "header bytes" (the first byte in a multibyte character)
and in addition, the header byte specifies how long the sequence is.
Vim can translate back and forth between Unicode and any other charset
quite easily, so (in gvim, or in Vim running in a Unicode terminal) you
may set 'encoding' to utf-8 and use ":setlocal fileencoding=latin1" for
Western Europe, ":setlocal fileencoding=sjis" for Japanese, etc., on a
file-by-file basis. All those files can coexist in a single instance of
gvim.
ok.. that's the crucial part.. this would work in a unicode terminal..
and it does..!
http://www.geocities.com/cga9999/vimgld2.png
.. what happened was that the other stuff I was looking at was running
in my regular non-unicode xterm/screen.. I had completely forgotten
about this other Vim session.. that's why I don't like having all these
windows all over the place.. When it's three in the morning or
thereabout and you need some sleep.. that's when you need a simple
streamlined environment..!
By using ":setlocal bomb" on a Unicode file, you can place at its
beginning the codepoint U+FEFF ZERO-WIDTH NO-BREAK SPACE which is then
used by other programs (or by Vim itself) to identify the fact that this
file is in Unicode, and in which particular Unicode encoding and endianness.
.. tomorrow.. :-)
I did do it on my unicode test file.. saved it somewhere.. read it in
my non-unicode Vim session.. and it's a total mess.. but very different
from the mess with the <e0> .. etc. I mentioned earlier..
To see a file in a non-unicode environment it should be saved in the
proper charset; for instance with ":setlocal fileencoding=latin9" (with
'fileencoding' in the singular) just before writing. But then to read it
back next time, vim must know the charset, either from ":e ++enc=latin9
filename", or from ":set fileencodings=ucs-bom,utf-8,latin9" prior to
reading. (The latter option has a plural name.)
Note: ":setl fenc=latin9" follows by ":setl fenc?" returns
"iso-8859-15". This is normal, they are two names for the same thing.
So this should help clarify the issue.
For more details, see
:help mbyte.txt
http://vim.sourceforge.net/tips/tip.php?tip_id=246
section 37 (last) of the Vim FAQ
http://vimdoc.sourceforge.net/htmldoc/vimfaq.html
http://www.unicode.org/
http://www.cl.cam.ac.uk/~mgk25/unicode.html
Ah.. heck.. the other urgent stuff can wait.. I'll have to look at this
tomorrow.
:-(
Thanks
cga
