Re: Dear Bram
> So basically backward compatibility and memory efficiency are whatI don't think anybody has refused the idea, and I don't think anybody
> hold vim back in 1970. You made a lot of good points and reasons for
> it to be so, but I'm always sad when good ideas are refused just
> because of old scenarios.
wants to keep Vim in the 1970s. We all want this. In fact, people who
don't want this probably wouldn't get involved in the discussion--unless
we looked like we were going to introduce some horribly backwardly
incompatible change that would affect them nastily.
So I would encourage you not to view this discussion as opposition to
the idea. Quite the reverse. This discussion is actually an important
part of making this idea happen. We need to discuss these things so we
can do it the best way possible, without *needlessly* breaking backward
compatibility, without *needlessly* or *significantly* lowering
efficiency, and without *unnecessarily* wasting people's time.
> That said, I think there is a compromise.Unless you saw something that I didn't see, I don't think there is any
resistance that necessitates a compromise.
I think it goes without saying that we'll need some kind of
compatibility mode, whether it's by means of a +feature, an 'option', or
just some carefully thought-out behaviours. Some of these issues have
already been raised and solutions brainstormed (including your recent
suggestions, as well as in earlier mails by me and others).
> Of course there's still all the issues discussed above to solve, butAs I said, I don't think there is any resistance to the idea. We're just
> at least I think with this proposal things we'll get less resistance
discussing how to do it. As someone suggested earlier, it would be best
to discuss and draft some documentation for this stuff before doing the
hard implementation work. Having something solid will help, and a
checklist of issues/concerns along with their solutions.
So, to move it to the next stage, is anyone in a position to volunteer
to write up a more specific design (which probably needs to be written
with reference both to this email discussion and the Vim source code)?
Also, is anyone in a position to volunteer to help with implementation
once we have a design?
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
- On Tue, 21 Oct 2014 20:49:40 +0200
Christian Brabandt <cblists@...> wrote:
> > In theory, yes. In practice, last time I looked xterm didn't do itpangoterm, or continue prodding at xterm until it does the right
> > quite right yet.
> > The setting is called modifyOtherKeys but the problem with is was
> > that it either modifies too little (leaving such pairs as Ctrl-a and
> > Ctrl-Shift-A indistinct), or modifies too much (using CSI u encoding
> > for a plain Ctrl-c keypress, thus meaning termios doesn't recognise
> > it and send a SIGTERM). I have re-raised this with Thomas just now;
> > I'll see if we can get to a point where it's just in the middle, and
> > therefore right.
> So what would be the preferred way to actually see those keys?
> Installing pangoterm?
Or provoke your preferred terminal's author into fixing it.
More consensus among terminals => better.
Paul "LeoNerd" Evans
http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS