RE: utf-8, combining characters, and 'x' -- a workaround for Hebr ew/Arabic, etc...
- Ron Aaron wrote:
> > > OK. I'll wait for 6.0r before I start working on this.Well, it can be done with a few :split commands. I didn't see a reason to add
> > I'll get it out when I finish the work on sessions (vertical
> > split, local option values).
> Halelujah! I was looking into the session issue, and it seemed like a
> Difficult Thing to figure out the correct window restore code.
> Which brings me to a side-issue: if we had a (n eval) function,
> getwinlayout(), which would return a string which when 'exe'd would restore
> that exact screen layout, it would be very useful. Among other things, the
> session code could write out a line like:
> exe 'that string...'
> instead of multiple ^W... things.
yet another feature. It's difficult to do it in one command though, some
option values need to be set to known values and the current window must be
resized to make sure there is enough room.
> Also, it would then be trivial to write a 'zoom/unzoom window' command,That's a completely different feature. You would also need to take care of
> where pressing a key would remove all the windows and 'zoom' the current
> window to use all the vim window, and pressing the key again would restore
> the window layout. This is one of the nice things Brief had which I haven't
> seen since...
side effects when closing a window (some autocommands delete buffers, for
example). You could save a session, do ":only" and restore the session, but
it's not guaranteed you really get the same things back. It comes close.
> It would be even nicer if there were a 'setwinlayout()' function which tookMost time is spent on restoring the window contents, not on parsing the
> said string, and did the right thing; in that case, the return from
> getwinlayout() wouldn't have to have ex commands, just information (so it
> would be smaller), and the setwinlayout() would work much more quickly than
> the individual ex commands.
commands. You need to edit the files, execute autocommands and modelines,
source syntax files, etc... Perhaps some of this could be skipped for the
zoom/unzoom functionality, but at least some things are stored with the
window, thus closing the window will delete them.
> > We could start by collecting a sequence of characters in aYou write when called. The buffering is already done before calling
> > buffer and calling ExtTextOutW() once. Then check what happens with
> > double-wide and composing characters. Might have to break the sequence
> > there.
> I think this would be a Good Thing. How would we know when to actually do
> the screen write, though? A special call? Would this work similarly for
> e.g. the GTK version (which also has display speed issues)?
gui_write(). gui_outstr_nowrap() may need a little work though. In case
extra buffering is really needed, gui_mch_flush() can flush out any buffered
I'm not aware of display speed issues with GTK. On my old 200 MHz machine it
didn't show a delay. Syntax highlighting is the largest performance eater.
> It gets worse: I was contemplating the feasability of making a bitmap fontI don't think including a font with Vim is a good idea. Unicode fonts tend to
> for distribution with vim, that would ensure we could display utf... It
> would be pretty easy to use a bitmap font (just at one resolution!), and
> there are some good starts-of-fonts out there (unifont? I think is one
> example). I guess I'm looking for ways vim can be universally, maximally,
> useable without forcing people to install all sorts of other stuff.
be big and change often. If there is an obvious good choice for such a font,
then why doesn't everybody have it already?
> If I could just make the *printing* issue easier ...I'm still open to include some way to print directly from Vim. Preferably
with syntax colors included (otherwise any external printing program would
do). Since internet explorer is standard on most Windows systems, perhaps we
can use the conversion to HTML and print with explorer somehow? Another
solution would be the PostScript way, but that wouldn't work well on Windows.
On Unix there isn't a standard way to print more than plain text anyway.
> Perhaps we need a code-coverage suite, which everyone (in vim-dev) shouldTesting new (and existing) features is still in the todo list. We need more
> run on their systems when they have made a new version of vim. Ensure that
> all the new features are covered. I know there are tests, but there are
> many things one has to *look* at... Or perhaps, you should assign specific
> areas to test to specific (active) vim-devvers, to help ensure coverage.
> There are a *lot* of features new to 6.0, and I know that I personally have
> not used all of them (or am even familiar with all of them).
automatic tests for advanced features (like the virtual editing mode). Code
coverage might help a bit, but since setting an option may make a big
difference it won't help much. Not mentioning how the contents of the file
can affect the testing... (I just found a but in the UTF-8 detection which
failed when a multi-byte character was read right at the 8192 byte border).
Adding a test to check if Vim displays the right things could be added too. A
framework for this needs to be setup then.
> Arrgh. I hated adding 'RevOut()', and I am *actively* looking for some wayCertainly! But ugly code often causes bugs, thus it needs to be avoided too.
> around it, since it really, truly, sucks. On the other hand, correct
> display is more important that ugly code :-)
hundred-and-one symptoms of being an internet addict:
144. You eagerly await the update of the "Cool Site of the Day."
/// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
\\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///