Allow me to follow up on myself, sharing the pleasure as I discover
> I recently started to play with the multi_byte feature, looking
> at or editing UTF-8 encoded files, and the choice of options and
> overall Vim behaviour is all very nice and natural, to me at least.
> Congratulations to all those who thought and designed this!
My associate is a linguist, and we have a few works on some African
languages. We were rather pleased to discover that Vim properly handle
multiple diacritic marks over/under a single letter. The font job is
approximative (we use `rxvt-unicode' for an X-terminal) but sufficient
for us to see what is going on.
Another tiny, but fun detail, is that I managed a Vim-Python function
which properly reset the `coding:' cookie at start of Python scripts
following a change of `fileencoding' in Vim. Quite convenient for me.
I should probably do something similar, one day, for XML files :-).
> [...] This triggered me into the Vim clientserver feature. Yet
> another piece of cake, nicely designed and easy to use. However,
> I noticed a few glitches, or feel in some need for advice, so this
> message. This is still all new to me, be patient!
> * I'm quite used at typing `:q' or `:xa' to get out of Vim, but if I
> want to keep one instance of Vim around as a server, I wonder how I
> could cut myself out of the habit of fully quitting Vim.
I found a way, and a rather simple one. While starting that Vim
instance to be used as a server, the command uses "... +'set modified'",
and since an unnamed buffer is now modified, Vim would not exit even
when routinely asked to do so, and despite `.vimrc' sets `autowriteall'.
> * In particular, EDITOR and VISUAL are `gvim --remote-wait-silent'
> for me [...], I ought to quit the buffer so it gets unloaded.
Merely doing `:e' (without argument) has the effect of unloading the
buffer and reloading it, effectively disconnecting the remote client.
That way of doing it has the advantage of keeping the relative size of
windows in the server.
> * Another detail which currently escape my understanding is that if
> I reply to a Mutt message using a Vim server [...] uses UTF-8 as an
> internal encoding for the message being composed, but displays each
> byte individually using Latin-1.
That particular problem disappeared since then, so I suspect an erring
operator (:-), or maybe some incomplete configuration which settled...
A few problems remain from my original message, and with some luck,
someone or I will find some easy solution. These are: how one should
handle Vim window unraising, and grab and later release input focus; and
also, how to make Vim command calls more compatible between using or not
using some `--remote' option, so making `--remote' more transparent.
François Pinard http://www.iro.umontreal.ca/~pinard