[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vim
Subject:    Playing with multi_byte, clientserver, and Mutt :-)
From:       François Pinard <pinard () iro ! umontreal ! ca>
Date:       2004-07-31 15:17:41
Message-ID: 20040731151741.GA7388 () titan ! progiciels-bpi ! ca
[Download RAW message or body]

First of all, before going any further, how I could say it: Vim is quite
impressive!

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!

So I decided to go UTF-8 for Mutt operations, and see how Mutt and
Vim inter-operate in that area.  Quite satisfactorily, Mutt also does
its good part in the share.  I know it is not going to last for very
long, but at least for a short little while, there is now some fun in
receiving Asiatic spam! :-)

Within Mutt, I often interact with Vim as an external editor.
Noticeable became the delay of starting Vim in X.  I do not know if
the 10646 font is making part of the delay, but some bulky Vim-Python
initialisation of mine surely is.  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.

* In particular, EDITOR and VISUAL are `gvim --remote-wait-silent' for
me (approximately, the details are more complex), I ought to quit the
buffer so it gets unloaded.  How can I do that easily in Vim, returning
back to the initial empty display?  I might try to get used to the
`:bunload' command, but best would be some way that would guarantee me
that I stay in Vim even if I routinely try to exit it, would it mean
using some special command to get out for real.

* When a client starts, the Vim server is effectively raised, but the
window manager I use (Openbox) does not select (or focus in) the Vim
window, which I have to do explicitly.  It might not be a Vim issue,
granted, yet maybe someone has a solution in his/her bag of tricks? :-)

* The ideal behaviour would be that, when in the Vim server, an attempt to
quit should ideally be intercepted in some way, per above, and then, the Vim
window should unraise (and unselect) automatically.

* Another detail which currently escape my understanding is that if I
reply to a Mutt message using a Vim server, the reply is opened into
Vim differently that if I was not using a server and launching a new
Vim application instead.  A new application uses UTF-8 as an internal
encoding and displays it correctly, so it is all transparent to me.  A
Vim server uses UTF-8 as an internal encoding for the message being
composed, but displays each byte individually using Latin-1.

* The fact that Vim with a `--remote' option starts the edition locally
if there is no other Vim around is a nice feature.  On faster machines,
I can theoretically go without a server without having to change any of
my scripts.  However, when a `--remote' option is used, the command line
syntax becomes limited, and extra care is then needed.  For example,
if I call the editor script without a file argument (would it be for
launching the initial server, say, or for getting some help file), the
`--remote' option apparently gets in the way, and I had to make my Vim
starting script a bit more complex because of this, I cannot blindly use
"$@" if I use `--remote'.  I wonder if some life-simplification would
not be possible in this area, yet without suggesting anything precise.

                                      Keep happy, everybody!

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard
[prev in list] [next in list] [prev in thread] [next in thread]