Loading ...
Sorry, an error occurred while loading the content.

RE: utf-8, combining characters, and 'x' -- a workaround for Hebr ew/Arabic, etc...

Expand Messages
  • Bram Moolenaar
    ... Well, it can be done with a few :split commands. I didn t see a reason to add yet another feature. It s difficult to do it in one command though, some
    Message 1 of 10 , Dec 29, 2000
      Ron Aaron wrote:

      > > > OK. I'll wait for 6.0r before I start working on this.
      > >
      > > 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.

      Well, it can be done with a few :split commands. I didn't see a reason to add
      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,
      > 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...

      That's a completely different feature. You would also need to take care of
      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 took
      > 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.

      Most time is spent on restoring the window contents, not on parsing the
      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 a
      > > 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)?

      You write when called. The buffering is already done before calling
      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 font
      > 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.

      I don't think including a font with Vim is a good idea. Unicode fonts tend to
      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) should
      > 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).

      Testing new (and existing) features is still in the todo list. We need more
      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 way
      > around it, since it really, truly, sucks. On the other hand, correct
      > display is more important that ugly code :-)

      Certainly! But ugly code often causes bugs, thus it needs to be avoided too.

      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 ///
    Your message has been successfully submitted and would be delivered to recipients shortly.