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

List:       vim-dev
Subject:    Re: Vim's future ?
From:       Bram Moolenaar <Bram () moolenaar ! net>
Date:       2002-11-05 21:49:14
[Download RAW message or body]


Gregory Seidman wrote:

> The problems with menus and the colon line and modal dialogs and all that
> stuff go away when you assume that only one toplevel window (which I will
> refer to from here on as frames; see my previous message on emacs parlance)
> has focus at any given time. There is already the assumption that only one
> vim window has focus at any given time, including the colon line.
> 
> There has been a push for buffer-specific menus, which makes sense to me
> since only one buffer (since it has to be in a window) can have focus at
> any given time. All this adds up to keeping the menus, colon lines,
> dialogs, etc. identical across all toplevel windows. That means that if a
> script is waiting for a response in the status line of one frame, having
> mucked with cpoptions, it is also waiting in the status lines of all other
> frames. It is application-modal, not frame-modal.

I don't quite understand your reasoning.  When there are multiple
toplevel windows, I certainly would not want that typing a ":" command
in one window would block commands in all other windows.  I would
quickly fall back to starting multiple Vims then.

When there are separate toplevel windows, they should behave like they
are separate editors, each with their own state (Normal, Insert, etc.).
I wouldn't accept anything else.  It would even be impossible to
copy/paste between the text of one window and the command line of
another.

> There are, indeed, choices to make. While I'm sure none of us are fans of
> emacs as an editor (or OS, as it often seems to be), I do respect the
> choices they have made with respect to the GUI. It's worth taking a lesson
> from the only other comparably functional editor; lots of people use it
> because they are happy with those choices. Granted, vim is based on making
> different choices in terms of keybindings, editing philosophy, extension
> mechanism, etc. but the UI is pretty similar between the two editors, and I
> don't think that has been by accident.
> 
> } Other editors don't have problems like this, because they don't offer
> } half the functionality of Vim.  When Vim would offer multiple toplevel
> } windows, it must work properly, we don't want a broken implementation.
> 
> I claim that the emacs implementation works properly and is, therefore,
> worth emulating/borrowing/stealing.

> [...]

> Let me reiterate that if we choose to steal from an editor, emacs is the
> one to steal from. It really does have an elegant way of dealing with
> buffers, windows, and frames. I don't want to use it for editing, but there
> are concepts embedded in it worth borrowing.

It's always good to learn from what others have made.  What is so good
about emacs what we should take over?  I didn't read a specific item in
your message.

-- 
SOLDIER: What? A swallow carrying a coconut?
ARTHUR:  It could grip it by the husk ...
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 ///  Bram Moolenaar -- Bram@moolenaar.net -- http://www.moolenaar.net  \\\
///          Creator of Vim - Vi IMproved -- http://www.vim.org          \\\
\\\           Project leader for A-A-P -- http://www.a-a-p.org           ///
 \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
[prev in list] [next in list] [prev in thread] [next in thread]