Why lua? or questions about yzis
Matej Cepl
I am not sure, whether comments regarding yzis development are
appropriate here (if not, please, me point me into the right
direction), but I have not found a better NG for this
(gmane.editors.yzis.user seems to be dead).
I just want to vent my frustration with state of vim on KDE. I hoped that in
the Unix world we will get sooner or later even in GUI world to the
situation equivalent to the one at console, where you have your $EDITOR set
and everything just works (of course, I have it empty, so vim is what I
get). However, as far as I can tell I have these options at the present
(using KDE 3.3.2):
1) suck it up and use native KWrite & co. Not that this option wouldn't have
some temptation for me (coming originally from M$-Windows, although many
years ago, I still feel rather well with Shift+arrows, Ctrl+[xcvspo]), but
there are two things missing:
a) scripting -- although Kate is going to have support for KJS Very
Soon(TM) it will take years (if ever) to have so developed base of
scripts as there is currently available for vim (and Emacs, but my
religious needs are well satsfied by my Lord Jesus Christ, I do not
need any other religion, thank you :-)). Currently I am getting
really
dependenent on VimOutliner (I am a Debian maintainer of its
package),
I am in the process of developing Qualitative analysis tools based
on Vim (and some Qt-C++ dialogs, maybe later KDE, but I have to
learn
programming with KDE and C++ first), I have ongoing flirt with
vim-latexsuite, etc.
b) and it wouldn't help me anyway, because there are so many
programs
which don't use kpart technology for the editing (KMail, KNode --
that
one at least is willing to open external editor in new window, how
is the situation with editing box in Konqueror?); shoot! I know
about
<http://groups-beta.google.com/group/linux.debian.maint.kde\
/browse_thread/thread/d8863e0dd351e54> and that it is certainly not
KVim's developers' fault, but it seems to me that non-availability
of
any good KDE vim editor doesn't help (see below).
2) Forget about KDE-only solution and use GVim for Gnome (which is what I do
now). Aside from being plain ugly
(<http://www.ceplovi.cz/matej/tmp/gvim-baghira.png>, sorry, I am used to
KDE look&feel; consider my brain to be degenerated if you are Gnome user),
I get really crappy support for vimpart (it basically doesn't work at all)
and of course full power of vim (whic is what matters most, so I am
grinding my teeth and hold it).
3) Hope for something better.
The most frustrating part of this situation is that there doesn't seem to be
any good solution coming, so #3 sucks a lot. KVim is officially dead
(although it sucked in many ways, it was by far the best solution to at
least some of my problems and I was its somehow happy user, until it was
eliminated from Debian) and there doesn't seem to be any replacement
coming.
Now, we are getting to yzis. Of course, that I know about that, but I am
afraid it won't be answer to my problems. I have tried to install M3++
(from the package 20050430-1) and I found it to be somehow nice but alpha
quality. Nothing bad about that (I have a four month daughter, so I know
that we were all young and we all did mess into diapers), but worse thing
is that kyzis doesn't seem to be much promising.
However, before saying anything else, let me note one more thing. This
message is about personal gripes and I do not want to say that you should
even react to them -- I perfectly understand that you are volunteers doing
what matters to you and you have no obligation towards me whatsoever. Let
me just vent my frustration, please.
a) NIH syndrom everywhere -- why in the h..ll, it is not just a KDE C++
clone of vim? Why it is not compatible with vim's syntax files and scripts?
The most important reason, why I am not using Kate/KWrite/etc. is that I
have all these scripts available for vim. And I do not think, that anybody
will redevelop VimOutliner, and myriad other small scripts in Lua, just
because it is theoretically better language than the vimscript one (and I
don't like it that much, but it doesn't matter -- Perl is also ugly as hell
and yet how succesfull it is). Have you ever saw a list of Emacs clones
(<http://www.finseth.com/emacs.html> or
<http://www.faqs.org/faqs/emacs-implementations/>)? It is quite long and
impressive list of totally dead projects, and they are all dead, because
Gnus doesn't work there (or Calc, or AucTeX, or PSGML, or fill-in any other
popular Emacs mode). And BTW, elvis and vile are IMHO not doing that well
against vim either (whenever, I ask something about vi, it is assumed I
mean vim), but I may be terribly wrong in this respect.
Or in other words, isn't creating yet another vi clone with GUI extension,
something similar to rewriting program (actually, it _is_ rewriting a
program)? For that see, of course,
<http://www.joelonsoftware.com/articles/fog0000000069.html> and
<http://news.com.com/2100-1023-980492.html> or
<http://www.jwz.org/gruntle/nomo.html>.
Although I am not programmer, so I cannot comment much about reasons why
KVim was killed, I still do not feel right about it. After all, it DID
work. Poorly, but at least as a proof of concept it was persuasive enough
to make it work well, wasn't it? Now, we will have to wait for couple of
years before yzis stabilize, before we can repeat argument on
KMail/KNode/etc. people to finally use kpart for editor, and even after
that the result will be suboptimal to well working kvim. Oh, well.
Any comments? Is there a better NG to post this?
Best,
Matej
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
There are lies, damned lies, and quotes from literary icons.
Preben 'Peppe' Guldberg
> I am not sure, whether comments regarding yzis development are
> appropriate here (if not, please, me point me into the right
> direction), but I have not found a better NG for this
> (gmane.editors.yzis.user seems to be dead).
I suppose this is as good as place as any then. (That is, after I
googled up yzis :-)
> I just want to vent my frustration with state of vim on KDE.
[...]
> 2) Forget about KDE-only solution and use GVim for Gnome (which is what I do
> now).
Just thought I'd point out that GVim is not Gnome specific. At least in
general use it is merely a graphical version of vim. That is, it is not
vim as used in a terminal. Gvim has some extra bells and whistles, but
as far as possible these are the same on any platform and for any
graphical toolkit used (Motif, Athena, GTK, Carbon, etc.)
As for the rest, I don't really have much to say. At least not that I
have the time for, nor would it probably be particularly ontopic here.
Peppe
--
se nocp cpo=BceFsx!$ hid bs=2 ls=2 hls ic " P. Guldberg /bin/v...@wielders.org
se scs ai isf-== fdo-=block cino=t0,:0 hi=100 ru so=4 noea lz|if has('unix')
se sh=/bin/sh|en|syn on|filetype plugin indent on|ono S V/\n^-- $\\|\%$/<CR>
cno <C-A> <C-B>|au FileType vim,mail se sw=4 sts=4 et|let&tw=72+6*(&ft=~'v')
Matej Cepl
> Just thought I'd point out that GVim is not Gnome specific. At least in
> general use it is merely a graphical version of vim. That is, it is not
> vim as used in a terminal. Gvim has some extra bells and whistles, but
> as far as possible these are the same on any platform and for any
> graphical toolkit used (Motif, Athena, GTK, Carbon, etc.)
Well, I was mostly after things which are not common -- using vim as a
vimpart, session management, follwoing the KDE look&feel, etc.
Matěj
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
I've just learned about his illness. Let's hope it's nothing
trivial.
-- Irvin S. Cobb
Preben 'Peppe' Guldberg
> Preben 'Peppe' Guldberg wrote:
> > Just thought I'd point out that GVim is not Gnome specific. At least in
> > general use it is merely a graphical version of vim. That is, it is not
> > vim as used in a terminal. Gvim has some extra bells and whistles, but
> > as far as possible these are the same on any platform and for any
> > graphical toolkit used (Motif, Athena, GTK, Carbon, etc.)
> Well, I was mostly after things which are not common -- using vim as a
> vimpart, session management, follwoing the KDE look&feel, etc.
I get that. Still, it looked to me like you were linking GVim with
Gnome, the same way as KVim is linked to KDE - and as that is not the
case, I thought I'd mention. (There may be efforts to work on
integrating Vim in some Gnome specific setting that I'm not aware of,
but I would think it would really lead to confusion if it was called
GVim).
Matej Cepl
>> Well, I was mostly after things which are not common -- using vim as a
>> vimpart, session management, follwoing the KDE look&feel, etc.
Just to make some self-promotion -- there is a version of my original post
on my blog at <http://www.ceplovi.cz/matej/blog/computer/why-yzis.html>.
Matěj
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
I love deadlines. I like the whooshing sound they make as they
fly by.
-- Douglas Adams
Joseph H Allen
In particular, mouse support for console programs is in a terrible state.
I've tried to improve the situation by sending a patch to the owner of Xterm
which allows console programs to have full mouse support.
(It allows cut & paste, cursor positioning, window resizing, wheel-based
scrolling, and auto-select (where window scrolls when mouse goes past the
edge), all while maintaining left-click for select and middle-click for
paste).
It is probably a lot easier to rewrite Konsole than graft VIM into each
GUI library that comes along.
--
/* jha...@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Matej Cepl
> Why not use VIM in console mode? Could it be that Konsole sucks?
Konsole rocks! But program in konsole won't work well as a kpart :-) I use
KMail and KNode for my emails/news (and I like them a lot!), so I would
prefer something which would make vim part of my KMail. Also it would be
handy to have vim in Konqueror -- and yes, Lynx is nice, but not that
useful anymore :-).
> It is probably a lot easier to rewrite Konsole than graft VIM into each
> GUI library that comes along.
I don't think so -- the world has changed and there are now GUI
(non-console) programs which are really useful.
Matěj
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
Q: Is vi an easy editor to learn, is it intuitive?
A: Yes, some of us think so. But most people think that we are
crazy.
-- vi FAQ
Mikolaj Machowski
> I just want to vent my frustration with state of vim on KDE. I hoped that in
> the Unix world we will get sooner or later even in GUI world to the
> situation equivalent to the one at console, where you have your $EDITOR set
> and everything just works (of course, I have it empty, so vim is what I
> get). However, as far as I can tell I have these options at the present
> (using KDE 3.3.2):
State of Vim in (on?) KDE.
Vim7 has option to --enable-gui=kde
Unfortunately there is no official maintainer (former kvim authors
declared non-commitment) and is very probably it will be removed from
final release of Vim7. Lack of maintainer is a cause of not working some
features in GUI like no highlighing for new spell features[1] or bad
encoding of menus[2].
[1] All logic and shortcuts (]s family) are working, fancy undercurl
syntax element isn't implemented.
[2] Could be fixed by a bit of VimL or
make scripting to convert menus to utf when gui_kde is used.
It work as old kvim was working - unpleasant delay between key press and
action - maybe it can vanish on really fast machines (my machine is
Sempron2200 slightly downgraded). I am also not programmer but
I understand it is caused by completely different ways how Qt and Vim
are treating actions (whatever that means).
KVim kpart was removed from CVS (currently SVN) and I suppose there is no
way in future versions will be possibility to embed kvim in KDE
applications. KDE users may use:
- Mac OS X style menu
- Toolbar with KDE icons
Not much but l&f is saved.
Cannot test net kio_slaves but netrw usually makes good work.
> Now, we are getting to yzis. Of course, that I know about that, but I am
> afraid it won't be answer to my problems. I have tried to install M3++
> (from the package 20050430-1) and I found it to be somehow nice but alpha
> quality. Nothing bad about that (I have a four month daughter, so I know
> that we were all young and we all did mess into diapers), but worse thing
> is that kyzis doesn't seem to be much promising.
>
> However, before saying anything else, let me note one more thing. This
> message is about personal gripes and I do not want to say that you should
> even react to them -- I perfectly understand that you are volunteers doing
> what matters to you and you have no obligation towards me whatsoever. Let
> me just vent my frustration, please.
>
> a) NIH syndrom everywhere -- why in the h..ll, it is not just a KDE C++
> clone of vim?
Because it is really, really hard?
> Why it is not compatible with vim's syntax files and scripts?
They decided to start from ground and get some shortcuts by reusing
technology existing in kdelibs (syntax) and Lua (scripting language).
Unfortunately you are right about legacy scripts and more. Incoming Vim7
will be really powerful and will give giant leap for Vim script authors.
Already are written plugins showing this.
selfplug:
http://skawina.eu.org/mikolaj/vst.html
http://skawina.eu.org/mikolaj/vst.vim
This script is turning Vim7 in WYSIWYMean editor for HTML and LaTeX.
> Although I am not programmer, so I cannot comment much about reasons why
> KVim was killed, I still do not feel right about it.
Not a programmer but I read discussion about that:
Putting Vim actions in Qt event-loop is a nightmare. KVim developers
managed to do that but maintaining and expanding that was horrible. Also
both parties: Qt and Bram Moolenaar strongly rejected any ideas to make
it easier. Of course both had good reasons but it didn't make work for
KVim team easier. This was ca. 2 years ago. I understand KVim team
shortly after that discussion decided to stop work on KVim and start
yzis. Recent decision about inclusion of KDE gui in Vim7 was too late
for them.
m.
Preben 'Peppe' Guldberg
> Preben 'Peppe' Guldberg wrote:
> >> Well, I was mostly after things which are not common -- using vim as a
> >> vimpart, session management, follwoing the KDE look&feel, etc.
Actually I quoted you for writing that.
Matej Cepl
> Matej Cepl scripsit:
Is it latin? It's a cool idea!
> Vim7 has option to --enable-gui=kde
Well, but I am afraid even if it made it to the final version of vim, no
maintainer of packages for different distribution (nobse in my case of
Debian) will make kvim packages. Oh well.
> Unfortunately there is no official maintainer (former kvim authors
> declared non-commitment) and is very probably it will be removed from
> final release of Vim7. Lack of maintainer is a cause of not working some
> features in GUI like no highlighing for new spell features[1] or bad
> encoding of menus[2].
And these are just first signs of bitrot.
> KVim kpart was removed from CVS (currently SVN) and I suppose there is no
> way in future versions will be possibility to embed kvim in KDE
> applications. KDE users may use:
Shoot.
>> a) NIH syndrom everywhere -- why in the h..ll, it is not just a KDE C++
>> clone of vim?
>
> Because it is really, really hard?
I meant functional clone, which boils down to basically using vim syntax
files and scripts. And of course the latter are more important than former.
>> Why it is not compatible with vim's syntax files and scripts?
>
> They decided to start from ground and get some shortcuts by reusing
> technology existing in kdelibs (syntax) and Lua (scripting language).
I understand that, but that is exactly what I meant when reminding about
long line of already-dead emacs clones -- they took advantage of already
existing technologies (like perlmacs -- but maybe I am wrong here; it seems
to be dead, but it might be built in standard Emacs via Lisp macros, I am
not sure), which made them incompatible with the already existing standard
and they are long time dead. Sometimes, the easiest way is not the best
one, IMHO (and IANAP -- I am not a programmer).
> This script is turning Vim7 in WYSIWYMean editor for HTML and LaTeX.
Wov!
> Not a programmer but I read discussion about that:
[...]
> Recent decision about inclusion of KDE gui in Vim7 was too late
> for them.
I heard about these too, which was the reason, why I was so cautious about
saying anything more about supporting real kvim (i.e., vim for KDE).
However, the argument for yzis' compatibility with vim on script/syntax
level.
Matěj
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
He has Van Gogh's ear for music.
Mikolaj Machowski
> Mikolaj Machowski wrote:
>> Matej Cepl scripsit:
>
> Is it latin? It's a cool idea!
:)
>
>> Vim7 has option to --enable-gui=kde
>
> Well, but I am afraid even if it made it to the final version of vim, no
> maintainer of packages for different distribution (nobse in my case of
> Debian) will make kvim packages. Oh well.
Why not? It will be just another binary.
>
>>> a) NIH syndrom everywhere -- why in the h..ll, it is not just a KDE C++
>>> clone of vim?
>> Because it is really, really hard?
>
> I meant functional clone, which boils down to basically using vim syntax
> files and scripts. And of course the latter are more important than former.
I am not sure. Vim syntax library is one of the richest and best.
>
>>> Why it is not compatible with vim's syntax files and scripts?
>> They decided to start from ground and get some shortcuts by reusing
>> technology existing in kdelibs (syntax) and Lua (scripting language).
>
> I understand that, but that is exactly what I meant when reminding about
> long line of already-dead emacs clones -- they took advantage of already
> existing technologies (like perlmacs -- but maybe I am wrong here; it seems
> to be dead, but it might be built in standard Emacs via Lisp macros, I am
> not sure), which made them incompatible with the already existing standard
> and they are long time dead. Sometimes, the easiest way is not the best
> one, IMHO (and IANAP -- I am not a programmer).
I agree. With keeping only kdelibs based syntax files it will be poor.
I checked some file types in Kate and its syntax files are generally
inferior to that of Vim (not even mentioning number of them).
m.
Matej Cepl
>> Well, but I am afraid even if it made it to the final version of vim, no
>> maintainer of packages for different distribution (nobse in my case of
>> Debian) will make kvim packages. Oh well.
>
> Why not? It will be just another binary.
Because I do not think they would put into Debian something which is
actually not maintained anymore.
>> I meant functional clone, which boils down to basically using vim syntax
>> files and scripts. And of course the latter are more important than
>> former.
>
> I am not sure. Vim syntax library is one of the richest and best.
That may be true -- I was thinking just that it is simpler to rewrite syntax
files than actual scripts. But you may be right.
Matěj
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
He is a self-made man and worships his creator.
-- John Bright
Joseph H Allen
Matej Cepl <ce...@surfbest.net> wrote:
>Joseph H Allen wrote:
>> Why not use VIM in console mode? Could it be that Konsole sucks?
>Konsole rocks! But program in konsole won't work well as a kpart :-)
Well why not? Isn't there a terminal emulator kpart? A KDE program should be
able to invoke a terminal emulator running a specific program, just as it's
able to run a widget/kpart specifically designed for KDE. With a few
enhancements, mouse support will be the same. Menu support will not be
quite as good, but then this is for VI...
Dan Doel
> Well why not? Isn't there a terminal emulator kpart? A KDE program
> should be able to invoke a terminal emulator running a specific program,
> just as it's
> able to run a widget/kpart specifically designed for KDE. With a few
> enhancements, mouse support will be the same. Menu support will not be
> quite as good, but then this is for VI...
Consider replacing the text area in a web form with an embedded konsole
running vi.
With an embedded vi/yzis part, this is theoretically possible (the yzis
website even has a screenshot of that happening, although I don't know how
they did it). With an embedded konsole part, it'd be much more painful, I
suspect (keeping a magic temporary file around and somehow getting its
contents back to the browser...).
The trouble comes not when simply using vi with a KDE look to it, but
embedding the vi part into other embedded text area places (so you don't
need to switch your brain between vi-editing mode and generic-editing
mode).
Joseph H Allen
Dan Doel <do...@case.edu> wrote:
>Joseph H Allen wrote:
>> Well why not? Isn't there a terminal emulator kpart? A KDE program
>> should be able to invoke a terminal emulator running a specific program,
>> just as it's
>> able to run a widget/kpart specifically designed for KDE. With a few
>> enhancements, mouse support will be the same. Menu support will not be
>> quite as good, but then this is for VI...
>Consider replacing the text area in a web form with an embedded konsole
>running vi.
>With an embedded vi/yzis part, this is theoretically possible (the yzis
>website even has a screenshot of that happening, although I don't know how
>they did it). With an embedded konsole part, it'd be much more painful, I
>suspect (keeping a magic temporary file around and somehow getting its
>contents back to the browser...).
Well as you say, it's theoretically possible. I think it would be
worthwhile to go ahead and make it happen. Why invent an entirely new
framework (kde/kpart) without integrating with the rest of UNIX?
I think the temporary file is minor issue: JOE can read/write to
stdin/stdout. VIM can read from stdin, but not write to stdout. Adding
this feature to VIM is probably not hard. Actually using temporary files is
not so bad either, and has the advantage of being totally generic.
The real issue is the event signaling: when the user sends the form, you
need to tell the editor to write the file, wait for it to complete and only
then send the form. The mechanics of the signaling is solvable problem (use
fake key sequences).
However, I don't know enough KDE/Qt to know if you can put an arbitrary
delay in the middle of button press event (or the get contents of edit
buffer method of kedit). Perhaps the button event sends a close event to
the editor instance(s), then each of them sends a response: only when all
response events are received is the form finally sent.
:-) We should take it one step further: have the whole X server emulated in
a frame. Then you could run X applications like "xfig" from within a form.
>The trouble comes not when simply using vi with a KDE look to it, but
>embedding the vi part into other embedded text area places (so you don't
>need to switch your brain between vi-editing mode and generic-editing
>mode).
So you want VIM, but not always the vi key sequences?
Matej Cepl
>>The trouble comes not when simply using vi with a KDE look to it, but
>>embedding the vi part into other embedded text area places (so you don't
>>need to switch your brain between vi-editing mode and generic-editing
>>mode).
>
> So you want VIM, but not always the vi key sequences?
no, AFAIU he wants the same key sequences everywhere -- be it CUA or vim. I
tend to agree with him in this respect very much.
Matej
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
My point was simply that such tax proposals [for Pigovian taxes
compensating for the transaction costs] are the stuff that dreams
are made of. In my youth it was said, that what was too silly to
be said may be sung. In modern economics it may be put into
mathematics.
-- Ronald Coase
Notes on the Problem of Social Cost
Mikolaj Machowski
> With an embedded vi/yzis part, this is theoretically possible (the yzis
> website even has a screenshot of that happening, although I don't know how
> they did it).
Patches to kdelibs/konqueror to use kpart. Also similar set to download
for KMail. Didn't test it because yzis is not ready yet for me :)
m.
Dan Doel
> Well as you say, it's theoretically possible. I think it would be
> worthwhile to go ahead and make it happen. Why invent an entirely new
> framework (kde/kpart) without integrating with the rest of UNIX?
I'm not sure what you mean by this exactly. If you want something to be
easily embeddable in a KDE application, you pretty much have to make it a
kpart. KDE has kparts, Gnome has Bonobo, and so on. Perhaps it's
unfortunate that they use different libraries for the same type of thing,
but considering they use totally different underlying libraries, I imagine
it'd be hard to reconcile (although I think there has been talk about
embedding Gnome/GTK things in KDE/Qt applications; I don't know what came
of it).
For what it's worth, Yzis seems to take what I, personally, feel is a nice
approach to this sort of thing. They seem to have written the underlying
editing engine portably, and allow different front-ends. For example, I can
type 'yzis' in the console and get a vim-like editor running in curses
mode. However, kyzis is a KDE front-end that supports things like KDE
toolbars and so on. I'm sure you could write a Gnome front-end or a raw
Xlib front end as well, just like gvim.
> I think the temporary file is minor issue: JOE can read/write to
> stdin/stdout. VIM can read from stdin, but not write to stdout. Adding
> this feature to VIM is probably not hard. Actually using temporary files
> is not so bad either, and has the advantage of being totally generic.
>
> The real issue is the event signaling: when the user sends the form, you
> need to tell the editor to write the file, wait for it to complete and
> only
> then send the form. The mechanics of the signaling is solvable problem
> (use fake key sequences).
Well, this isn't that much of an issue really. However you implement the vim
part (whether kpart or the bonobo equivalent or whatever), it has to
'look' (API wise) like a text part. Otherwise it's not able to be
transparently substituted for the other text parts. Whatever it actually
does, it will have to respond to some function like, getText(), at which
point it does all that stuff you listed.
My only complaint is that feels a bit icky to simply dress up a konsole part
in a text editor facade. It'd be better to make a text editor part that
would communicate directly with some vim core engine, which is basically
what kyzis is (from what I understand).
> So you want VIM, but not always the vi key sequences?
As Matej Cepl said, I'd like the same key sequences everywhere for editing.
I'm more of an emacs user currently (which means there's about a 0% chance
of there actually being a kpart to suit me :)), but I can't tell you how
many times I edit web forms and press, for example, C-p, expecting to go to
the previous line, but instead bringing up the print dialog. I imagine
long-time vim users are in a similar situation. I'd much rather be able to
edit text the same way everywhere.
Cheers,
Dan Doel
Philippe Fremy
Hi,
As you said, kvim worked poorly. You were lucky if you could use it
without eating 100% of your CPU because of the polling that vim imposes
on us. And it required a fucking lot of work from us to get it to work
poorly. Vim is unfotunetely a huge pile of pre-ansi C code, very
difficult to modify. Vim was designed around the concept of console
editor and it is very difficult to make it work as an embedded editor.
We tried hard for 4 years and we failed.
You can add to that that Bram has been very irresponsive. It took him
two years to integrate a patch of 10 lines that would add a new command
line option to vim. Nothing that would break it, just a new command line
option. And two years to get that approved.
So, the message was clear. On one side, it is very hard to work with
vim. On the other side, the author of Vim has no time for us.
I am the first one to say that it is a bad idea to write a free software
program when you have one that already does the job. If you cite me the
most useless free software project to start, I would immediately say
"Editor", because there are tons of working editor already.
But, when you say "I want a vi kpart", then the answer is that there is
none, and that vim is _never_ going to become one, both for technical
and social reasons.
So, we started yzis, with several requirements in mind:
- use clean easy to maintain C++
- isolate features in class, so that people can easily contribute to one
part of yzis without understanding the whole picture
- use modern development tools: subversion, wiki, bug tracking software
- use as much existing project as we can. The idea is to leverage the
work of others, like we should always do in software development. This
lead to a few choices:
. Qt: we are very good at Qt and Qt has excellent base classes (unicode
strings, efficient lists, arrays, hash tables)
. lua: more on this later
. kate syntax highlighting: kate already has a good syntax highlighting
engine, based on _easy to understand_ xml files. So, we benefit from
kate's popularity. Have you tried to write vim syntax files ? If you
did, you are a hero to me. I tried several times and did not understand
a thing (reading doc, reading files, ...). With Kate's syntax
highlighting, it is really easy to write syntax files. Moreoever, it
seems to me that their concept of syntax highlighting based on context
is more powerful than vim's because it allows an infinite level of
recursion (think javascript inside html pages, or doxygen doc inside C++
code).
. ncurses: for nyzis, we use ncurses. Vim uses its own termcap analyser
if I remember correctly
. KDE: we use a modern graphical toolkit for the graphical version of
yzis. Have you looked at the code of graphical gvim ? It is really
frightening.
- isolate the yzis engine, so that the project could be used in other
project, and that we could benefit from the interest of others.
- be very open to new developers: when somebody proposes a patch, it
usually gets integrated during the next week. And he gets a subversion
account. Have you seen how vim development works ? Bram keeps full
control over it and nobody has access to its source tree.
So, about lua. Why code a script engine when there are a lot of very
good script engines, which have been developed by very skilled people
for many years, and are already widely used ? It took us about an hour
to get lua working in yzis. How long do you think it would have taken us
to get a vim compatible script engine ? In addition to being a very good
and clean scripting language, lua has a user and _developer_ community,
excellent documentation, lot of outside libraries and is easy to use by
a developer.
Javascript would have been a good contender too. I love python as well,
but integrating it into foreign code is such a knightmare that I am glad
we did not do it.
With the design decision that we have made for yzis, I am very confident
that we could more forward quicker than vim, and that we will get a
better editor in the end.
Yzis can be embedded into kdevelop and quanta. That's already more than
vim ever does.
How long do you think it would take for somebody to write from scratch a
vim editor ? Then consider how long it took us to do that, by using the
work of others and you know why yzis has a bright future.
I love vim really. But the editor is based on outdated decisions and the
maintainer is not willing to open up. Too bad for him, good for us.
Regarging your beloved vim script, I am going to have a look at it. It
usually takes a few hours to convert a vim script to clean lua code.
I'll report on the progress.
Philippe
Matej Cepl
> So, the message was clear. On one side, it is very hard to work with
> vim. On the other side, the author of Vim has no time for us.
I did not know about problems with Bram, I knew about problems with C-only
(& do everything yourself) problems with vim design. Moreover, as I said, I
am not a programmer, so I cannot argue with that. However, there are still
two questions, which remains:
a) gvim/GTK,GNOME -- it exists and works pretty well for me (well, as well
as GTK application could work :-)) despite my suspicion, that its
developers had to fight the same battles you lost. Is it because we are
that much C++-centric?
b) kvim -- despite all your evidence to the contrary, there WAS kvim working
on my computer. If there were problems with vim's core, why not to fix it
and make a patch. I know that it is difficult to maintain a big patch, but
would it be really that more difficult than writing a new editor from
scratch (even using all goodies Qt, KDE, Kate, etc. provides)? And if it is
successful (and kvim even in its pitiful state was successful), then maybe
even Bram would take notice.
> . kate syntax highlighting: kate already has a good syntax highlighting
> engine, based on _easy to understand_ xml files. So, we benefit from
> kate's popularity. Have you tried to write vim syntax files ? If you
> did, you are a hero to me. I tried several times and did not understand
> a thing (reading doc, reading files, ...). With Kate's syntax
> highlighting, it is really easy to write syntax files. Moreoever, it
> seems to me that their concept of syntax highlighting based on context
> is more powerful than vim's because it allows an infinite level of
> recursion (think javascript inside html pages, or doxygen doc inside C++
> code).
Well, my experience again is just an opposite -- I've managed to write (I
admit very simple) syntax files for vim, but I have never managed to write
email syntax file for kwrite (before humbly returning to vim, I thought
that kwrite/kate could be made into something useful).
> - isolate the yzis engine, so that the project could be used in other
> project, and that we could benefit from the interest of others.
How much is lua embeded into libyzis (or whatever is its name)? Could it be
possible to make kvim-yzis (i.e., something similar ncurses- and KDE-
version of yzis, which would include vim-like scripting engine)?
> - be very open to new developers: when somebody proposes a patch, it
> usually gets integrated during the next week. And he gets a subversion
> account. Have you seen how vim development works ? Bram keeps full
> control over it and nobody has access to its source tree.
This is serious reason and I admit it without hesitation -- open source
project which is not open socially has a big problems on its hand.
> Javascript would have been a good contender too.
Being so much KDE-centric, why have you decided against KJS?
> With the design decision that we have made for yzis, I am very confident
> that we could more forward quicker than vim, and that we will get a
> better editor in the end.
In year 2010? :-)
> Regarging your beloved vim script, I am going to have a look at it. It
> usually takes a few hours to convert a vim script to clean lua code.
> I'll report on the progress.
Just to let URL stand here -- <http://www.vimoutliner.org>.
Matej
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
His mother should have thrown him away and kept the stork.
-- Mae West
Joseph H Allen
Dan Doel <do...@case.edu> wrote:
>My only complaint is that feels a bit icky to simply dress up a konsole
>part in a text editor facade. It'd be better to make a text editor part
>that would communicate directly with some vim core engine, which is
>basically what kyzis is (from what I understand).
Who cares if it's icky, as long as it works properly from the user's point
of view.
>> So you want VIM, but not always the vi key sequences?
>As Matej Cepl said, I'd like the same key sequences everywhere for editing.
>I'm more of an emacs user currently (which means there's about a 0% chance
>of there actually being a kpart to suit me :)), but I can't tell you how
>many times I edit web forms and press, for example, C-p, expecting to go to
>the previous line, but instead bringing up the print dialog. I imagine
>long-time vim users are in a similar situation. I'd much rather be able to
>edit text the same way everywhere.
Well there you go. If a kpart which could run UNIX console editors were
created, you could run gnu-emacs itself in any random text box if you want.
Joseph H Allen
Philippe Fremy <ph...@freehackers.org> wrote:
>So, the message was clear. On one side, it is very hard to work with
>vim. On the other side, the author of Vim has no time for us.
I can't exactly blame Bram for being unhappy about having to support yet
another environment. Remeber VIM already supports DOS, Windows-console,
Windows, UNIX, Cygwin, and X (and VMS?).
The C vs. C++ issue is difficult. Dropping C means dropping support for old
versions of UNIX, which makes vim no longer a UNIX editor. Also there was a
long period of time when C++ and its associated libraries were in a big
state of flux (especially for g++): VIM was written in the early 90s. I
agree that we are now past all of that, but an argument can be made that it
is still useful to have editors which have very low dependencies...
>So, we started yzis, with several requirements in mind:
>...
Ok, so just use jedit :-)
>Have you seen how vim development works ? Bram keeps full
>control over it and nobody has access to its source tree.
Yes, you have to be nuts not to at least use CVS/sourceforge (soon to offer
subversion).
I still want a kpart which can run UNIX console editors. You could then run
vim, gnu-emacs, joe, jedit, jed, mc, jove, pico, nano, nvi, stevie, etc.,
heck you could even run original wordstar in dosemu, or ITS teco-emacs in a
dec-20 emulator, in any random text field if you want. It seems like such a
project would get much more bang from the given amount of programming effort
required.
On the other hand, you are not a real programmer until you've written your
own text editor so go for it :-) (Lua is nice, but it lacks continuations
:-)
Stefan Lang
[...]
> . kate syntax highlighting: kate already has a good syntax highlighting
> engine, based on _easy to understand_ xml files. So, we benefit from
> kate's popularity. Have you tried to write vim syntax files ? If you
> did, you are a hero to me. I tried several times and did not understand
> a thing (reading doc, reading files, ...). With Kate's syntax
> highlighting, it is really easy to write syntax files. Moreoever, it
> seems to me that their concept of syntax highlighting based on context
> is more powerful than vim's because it allows an infinite level of
> recursion (think javascript inside html pages, or doxygen doc inside C++
> code).
Full ACK.
nyzis already looks nice, but I couldn't find docs on how write an
equivalent of a .vimrc.
Thank you for your work on yzis!
Stefan
Philippe Fremy
> a) gvim/GTK,GNOME -- it exists and works pretty well for me (well, as well
> as GTK application could work :-)) despite my suspicion, that its
> developers had to fight the same battles you lost. Is it because we are
> that much C++-centric?
No, but we have higher standards. GVim in Gnome version just uses Gtk.
You can not embed it into a Gnome application. So, this is the
equivalent of kvim.
We had higher expectations than just vim running with the KDE toolkit.
We wanted a KDE kpart, which is a lot more difficult. It is not linked
to C++ but to the architecture of vim.
> b) kvim -- despite all your evidence to the contrary, there WAS kvim working
> on my computer. If there were problems with vim's core, why not to fix it
> and make a patch.
1. vim is very difficult to fix
2. there was no such a patch that could fix the problem. It is tied to
the architecture of vim. We suggest many times that this architecture
could be changed, but Bram refused, for very good reasons. Vim is
stable, he does not want to introduce instability for something which he
finds not useful.
3. even if we proposed a patch, it would not be integrated. It took 2
years to integrate a trivial patch, if a patch touches the core, it will
probably be rejected because Bram does not like (righfully) changing the
core of vim.
> I know that it is difficult to maintain a big patch, but
> would it be really that more difficult than writing a new editor from
> scratch
Yes it would. It is 100% easier to write a new editor from scratch and
having such incredible things like access to the source code with a
source control tool, or architecture made of independant components.
> (even using all goodies Qt, KDE, Kate, etc. provides)? And if it is
> successful (and kvim even in its pitiful state was successful), then maybe
> even Bram would take notice.
Bram is not interested in a KPart vim. That's the core of the problem.
He sees no interest for it and he much rather spend time on improving
vim than on this funky thing.
>>- isolate the yzis engine, so that the project could be used in other
>>project, and that we could benefit from the interest of others.
>
>
> How much is lua embeded into libyzis (or whatever is its name)? Could it be
> possible to make kvim-yzis (i.e., something similar ncurses- and KDE-
> version of yzis, which would include vim-like scripting engine)?
lua is not integrated into libyzis. There is only one files that
performs the binding between lua and libyzis. So the integration is
light and easy.
Regarding vi scripting engine, the syntax is different (and in my
opinion, sometimes braindead). You can not extract the scripting engine
from vim to make it an independant component. If that was possible, we
would have gladly done it. But vim is quite monolithic.
As for recoding a scripting engine compatible with vi, I consider that
we have more interesting things to do than writing a scripting engine.
Some people are very good at this and have written for example lua.
I am aware that we lose all the existing scripts of vim. But there is
not solution at the moment. Note that we would welcome any contribution
of the vim scripting engine. If Bram would just take the time to
refactor a bit the code inside vim so that one can use it outside vim,
that would be nice. But it won't happen.
> >- be very open to new developers: when somebody proposes a patch, it
> >usually gets integrated during the next week. And he gets a subversion
> >account. Have you seen how vim development works ? Bram keeps full
> >control over it and nobody has access to its source tree.
>
> This is serious reason and I admit it without hesitation -- open source
> project which is not open socially has a big problems on its hand.
Yes. Luckily, vim is a good software and is very popular. So, the
existing developer base deals with this problem, but Bram does not even
realise how much contributions he loses because of his close development
model.
> >Javascript would have been a good contender too.
> Being so much KDE-centric, why have you decided against KJS?
Lua was integrated in a few hours. We did not even had time to look at
another scripting engine, this one was already working fine. I suspect
that integrating KJS would be more complicated but we did not have a
look at it.
>>With the design decision that we have made for yzis, I am very confident
>>that we could more forward quicker than vim, and that we will get a
>>better editor in the end.
>
>
> In year 2010? :-)
Anyway, if we submit patches to vim, they won't be integrated before
year 2010.
Actually, with the development process of vim, if we wanted to move
forward, it was clear that a fork was needed. But a fork useless. The
interest of working with vim is its popularity, and the drawbacks is its
horrible source code. By forking, we would lose all the advantages, and
have only the drawbacks.
Restarting with a clean base is a better idea.
Yzis is moving really fast. It will be useful long before 2010 although
it will certainly take some time before we can reach the level of
features that vim provides.
regards,
Philippe
Philippe Fremy
>
> I can't exactly blame Bram for being unhappy about having to support yet
> another environment. Remeber VIM already supports DOS, Windows-console,
> Windows, UNIX, Cygwin, and X (and VMS?).
There was 0 impacts on the existing environments. But if he does not
want to make it portable, why integrate so many gui ?
Actually, I understand Bram and his decision and I have no resent. The
ground of the problem is that Bram does not see the interest of what we
are doing.
Vim is a very good console based editor and will remain so. It has some
gui sugar but nothing that can match the power of a full graphical editor.
> The C vs. C++ issue is difficult. Dropping C means dropping support for old
> versions of UNIX, which makes vim no longer a UNIX editor. Also there was a
> long period of time when C++ and its associated libraries were in a big
> state of flux (especially for g++): VIM was written in the early 90s. I
> agree that we are now past all of that, but an argument can be made that it
> is still useful to have editors which have very low dependencies...
I am perfectely ok with that. Our goals did not match vim's goals. So we
started a new project.
> Ok, so just use jedit :-)
jedit has not vim keybindings, has it ?
> I still want a kpart which can run UNIX console editors.
Technically, it is not difficult. There is a konsole kpart. All you
would have to do is inherit from this kpart, and provide the editor
services which are about positionning the cursor and getting the current
text, selection or cursor position.
You have to find a bidirectional communication way between vim executed
in your kpart konsole and the kpart itself. Vim's server commands are
nice but not sufficent. I mentionned this to Bram and he said that he
will think about it. I don't know the current state but I don't think it
has improved.
Mickael did integrate dcop to solve this. But the patch would most
likely be rejected by Bram.
> You could then run
> vim, gnu-emacs, joe, jedit, jed, mc, jove, pico, nano, nvi, stevie, etc.,
indeed. Except that for each of these editors, you would have to find a
communication system. The editor kpart is not just about "edit this
file", it is also about "what is current selection ?", "put the cursor
here!", "what is the content of line 25" ?
When using the editor kpart inside kdevelop or quanta, this makes a lot
more sense.
It is a bit ugly however, from a graphical point of view to use a
console and a console editor. You also lose all the advantage of a
grpahical editor: scrollbars, buttons, toolbars, dialogs, good mouse
support, interactive selection, popup menu, respect of the gui style.
regards,
Philippe
Matej Cepl
> Yzis is moving really fast. It will be useful long before 2010 although
> it will certainly take some time before we can reach the level of
> features that vim provides.
Thanks a lot for your answers -- looking forward for the moment when kyzis
will be useful for me.
Matej
--
Matej Cepl, http://www.ceplovi.cz/matej
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488
We are told that [St. Anthony] once fell into dejection, finding
uninterrupted contemplation above his strength; but was taught to
apply himself at intervals to manual labour by a vision of an
angel who appeared platting mats of palm-tree leaves, then rising
to pray, and after some time sitting down again to work; and who
at length said to him, "Do thus, and thou shalt be saved."
-- Life of St. Anthony
Ángel
> 3. even if we proposed a patch, it would not be integrated. It took 2
> years to integrate a trivial patch, if a patch touches the core, it will
> probably be rejected because Bram does not like (righfully) changing the
> core of vim.
Fortunatelly. Vim is an excellent editor. I hope it never gets worst
just to allow an useless kpart to be made.
> Bram is not interested in a KPart vim. That's the core of the problem.
That's good to know. I hope he never will. I love using Vim as my
editor of choice in every system (FreeBSD, OpenBSD and Linux) I use. I
like it how it is now and hope it continues the same way.
> He sees no interest for it and he much rather spend time on improving
> vim than on this funky thing.
Which is very good, in my opinion.
--
Saludos,
Ángel
rob...@inf.puc-rio.br
Actually Lua has one-shot continuations. One-shot continuations are
good enough for mostly all real uses of continuations.
-- Roberto
Joseph H Allen
I used to agree with this statement, but I've found an application: use Lua
to run a multi-user web-page dialog server. Each time a user clicks "send",
the dialog is continued (the continuation is saved after each generated web
page fo the dialog). So far all of this can be done with co-routines or
one-shot continuations. However:
One feature of web-browsers is the back/fwrd buttons (think of these as
undo/redo for dialogs). So at any time the user can continue from any
previous point in the dialog (think especially if the web browser is just
caching the previous pages, so the page of the next "send" can be for any
random continuation). Multi-shot continuations model this situation.
Now suppose you want to add back/fwrd buttons to an editor's complex
dialogs/wizards... :-)
Are you the author of Lua? I released a language called "Ivy" right about
the same time as the first version of Lua, but then stopped working on it.
At the time Ivy was more powerful, but Lua has long since surpassed it.
I've been thinking about resurrecting Ivy, so naturally I've been studying
Lua. It's weird how similar the languages are. We've made very similar
design decisions. So, I've been thinking of making the next version of Ivy
just a little more LISP-like (by simplifying the syntax so that the parser
is somewhat more like a LISP reader- all complex statements become function
calls: I have to add some quoting to pull this off).
Giuseppe Bilotta
> lua is not integrated into libyzis. There is only one files that
> performs the binding between lua and libyzis. So the integration is
> light and easy.
Hi,
I'm following this thread with interest, because I use KDE on Linux
and the lack of a nicely integrated, VI-style editor was quite a pain
(and indeed, KVim was not really that much useable ... for example,
simply maximizing it would make it run amok).
I have a couple of questions, though:
1. (related to the quote above) Can yzis interface to other scripting
languages? Vim can lean on Perl, Python, Tcl, Ruby.
2. Is there a Win32 port of yzis?
3. Is there a DOS (maybe DPMI-based) port of yzis?
--
Giuseppe "Oblomov" Bilotta
"I'm never quite so stupid
as when I'm being smart" --Linus van Pelt
Philippe Fremy
Hi,
Giuseppe Bilotta wrote:
> I'm following this thread with interest, because I use KDE on Linux
> and the lack of a nicely integrated, VI-style editor was quite a pain
> (and indeed, KVim was not really that much useable ... for example,
> simply maximizing it would make it run amok).
Indeed.
>
> I have a couple of questions, though:
>
> 1. (related to the quote above) Can yzis interface to other scripting
> languages? Vim can lean on Perl, Python, Tcl, Ruby.
It could, but I don't think it would be a good idea. It is better to
foster scripts in only one language, so that the maximum amount of code
can be reused from scripts to script. However, lua allows to easily
execute an shell command, if you need the full processing power of let's
say perl.
Yzis is also just an engine. If you want to write a scriptable editor
with ruby support and vim key bindings, you could just integrate the
yzis engine into a ruby editor.
> 2. Is there a Win32 port of yzis?
I started something with Qt3 non commercial but I did not have time to
move much forwared. We are waiting for the release of Qt4 to give a new
boost to the windows version.
Yzis has an abstraction layer, so that you could port it to a new gui
quite easily. Any win32 port or other platforms would be welcome.
> 3. Is there a DOS (maybe DPMI-based) port of yzis?
The ncurses version runs in a cygwin terminal. That might run as well in
a dos window, who knows.
Philippe
Giuseppe Bilotta
> Giuseppe Bilotta wrote:
>> I have a couple of questions, though:
>>
>> 1. (related to the quote above) Can yzis interface to other scripting
>> languages? Vim can lean on Perl, Python, Tcl, Ruby.
>
> It could, but I don't think it would be a good idea. It is better to
> foster scripts in only one language, so that the maximum amount of code
> can be reused from scripts to script. However, lua allows to easily
> execute an shell command, if you need the full processing power of let's
> say perl.
Yes and no. That would require designing quite some glue on both sides
(to pass information from one language to the other). Reuse of
existing (not Vim-specific) scripts in the various languages is almost
instantaneous. But maybe I should take this to the Lua developers ...
> Yzis is also just an engine. If you want to write a scriptable editor
> with ruby support and vim key bindings, you could just integrate the
> yzis engine into a ruby editor.
Which would give me one language /instead/ of another.
>> 2. Is there a Win32 port of yzis?
>
> I started something with Qt3 non commercial but I did not have time to
> move much forwared. We are waiting for the release of Qt4 to give a new
> boost to the windows version.
Ok.
>> 3. Is there a DOS (maybe DPMI-based) port of yzis?
>
> The ncurses version runs in a cygwin terminal. That might run as well in
> a dos window, who knows.
I was actually looking for a pure DOS port, not a Win32 console
version.
--
Giuseppe "Oblomov" Bilotta
[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance? Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and
tyrants.
-- Thomas Jefferson, letter to Col. William S. Smith, 1787
rob...@inf.puc-rio.br
There are several "generic" situations that seem fit for multi-shot.
But when you get down the details, most of those situations don't work
properly.
For instance, how to handle side effects?
Once a forward button has done some side effects,
it is quite improbable that running again some old link (re-shooting
it)
will work as expected.
And the implementation of coroutines is so much simpler... :)
> Are you the author of Lua?
Yes.
Joseph H Allen
>There are several "generic" situations that seem fit for multi-shot. But
>when you get down the details, most of those situations don't work
>properly. For instance, how to handle side effects? Once a forward button
>has done some side effects, it is quite improbable that running again some
>old link (re-shooting it) will work as expected.
I agree that the problem is complex: the side effects have to be carefully
managed. Yet, there are "continuation based web frameworks" out there.
Seaside is Smalltalk based, some others are Scheme based.
Perhaps make it so that when a multi-shot continuation is triggered,
optional "undo" managers get executed for all of the contination points
between the trigger point and the last executed point. Likewise, have
"redo" managers for going forward:
begin
normal state-a-code
a: call/cc
first: normal state-a to state-b code
undo: state-b to state-a undo code
redo: state-a to state-b redo code
b: call/cc
first: normal state-b to state-c-code
undo: state-c to state-b undo code
redo: state-b to state-c redo code
c: call/cc
first: normal state-c to state-d-code
undo: done to state-c undo code
redo: state-c to done redo code
done
So if you're waiting in c, but you get continued at a, b's undo gets called,
then a's undo gets called, then a's redo gets called. This is clear with
linear code. I don't know if it makes any sense when the call/ccs are all
at different points in the subroutine call stack.