David Moss replied to Steve Leach:
> Date: Sat, 2 Aug 2003 18:22:44 +0000 (UTC)
[DM]
> >>>Whilst doing my 1st year on AI & CS I got fed up with some (read most)
> >>>os the way [x]ved handles file editing... IMHO its even more painful
> >>>than vi!
> >
[SL]
> > Everyone has reservations about [X]Ved (and every other editor) but comparing
> > with vi seems a little unkind! Would you care to expand on the
> > particular issues that you have experienced with [X]Ved? I would
> > be interested to read about that.
Part of the problem is that most of the people teaching the first year
AI programming course are recent converts and are not themselves very
familiar with Ved or Xved, and therefore are not able to give students
much advice about how to tailor their environments. Some students ask
(e.g. via comp.lang.pop or by writing to me, or a local email list
poplog-users) and are at least made a little happier by the answers
they get. Many are not as experienced as David and so do not already
have strong expectations about a program development environment.
Some of them become quite expert in using Ved/XVed and tailoring it
to suit their preferences: insofar as I allows tailoring.
>
> No syntax colorizing has to be the top one, but also there is no code
> folding,
Providing syntax highlighting is not something a student has ever asked
me for previously, though I noticed that Brian Logan set that up in his
emacs environment for Xved.
I personally find that most unattractive and, moreover, if anyone else
designed the colours they would not work for me since I always use Ved
with white (or light grey) text on a black (or dark grey) background and
the colours chosen would probably not work in this context, quite apart
from my colour-blindness. (I can't understand why anyone prefers black
on white for text editing as it is so much more tiring ...)
Even the xterm text cursor does not work properly in this context and I
have to do this in my .Xdefaults to ensure that the cursor is always
visible with reverse video:
XTerm*cursorColor: red
Nevertheless I accept that some people like colours and syntax
highlighting.
My view is that we should not try to alter ved to do this, as it would
be far too much work (unless Jonathan Cunningham's Ved-in-rclib ever
takes off!). Instead we should make it easier for people to access
poplog from their preferred editor, as in David's case.
Occasionally folding is requested, and several of us have, at times,
make plans for a folded Ved, but getting the requirements right
is tricky (as Steve comments).
A partial alternative is to provide a lot of navigational aids
to programmers using Ved. There are many, but many students do
not read the manuals and discover them, not even the abbreviated manual
here:
http://www.cs.bham.ac.uk/research/poplog/teach/vednotes
E.g. The 'ENTER headers' command is very useful as it builds an index
of the procedures in the current file, which can be used to access them
quickly, using ENTER gp (goto procedure).
There are lots of other things, many of them accessible via the rcmenu
extensions to ved: try (at Birmingham) ENTER menu, and things documented
in HELP vedkeys and REF vedcomms, in the Aids to Programming section.
The rcmenus (See HELP ved_menu in the Bham installation) are still a
first draft (despite being several years old) and there are many
customisation options that have not been explored. I much prefer menus
that stay up till I dismiss them, especially command menus.
> the default key bindings are awkward
Part of the problem is that the defaults that come with the main poplog
system are inconsistent. I am trying to sort that out for Poplog Version
16.
One appalling inconsistency pointed out by Steve Leach is that, as
stated in HELP VEDKEYS one of the defaults is to make ESC O
invoke vedlinebelow, which is completely inconsistent with the
vt220 keyboard behaviour of the numeric keypad, several of whose
key sequences start with ESC O (e.g. ENTER is ESC O m).
I had not noticed because I have in any case over-ridden many of the
infelicitous key bindings in the Birmingham context.
> the focus model of the WM
> is overriden,
Ved does nothing about window focus: it's all up to the window manager.
Within a window if you have two ved buffers open you have to select
one into which you type. (E.g. using ESC x)
XVed allows you to specify which of various ved actions should over-ride
the window manager focus.
See REF vedwarpcontext.
You can turn off ALL warping by XVed if you do:
[] -> vedwarpcontext;
I expect the default needs looking at. I use
vedwarpcontext =
[vedsetonscreen
vedswapfiles
vedfileselect
ved_rb
ved_pop
ved_ved
ved
],
E.g. not vedquitfile
Most people who use 'ENTER ved name' to start up a new file
would like focus to be transferred to the new file's window. Likewise,
most people who use 'ESC x' or 'ENTER rb' to flip between windows would
like to have the focus flip as well. The REF entry explains how you can
select cases. People who write Ved extensions can extend the options.
Individual programs using XVed can of course use dlocal to change
the warping behaviour in certain contexts.
> the colors (in help/ref/teach files) look badly painted,
I wish the XVed developers had never introduced colours, or had at least
made it easy to turn them right off. I can reduce the impact in
Ved by putting this in my .Xdefaults:
*customization: -color
But there does not seem to be such a global colour switch for XVed alas.
(maybe I have not found it.)
> no tab-editing (for multiple buffers, i.e. you need different windows
> for each) and some other pithy complaints. Most of that is also true of
> vi, but at least the key-bindings are more straight forward.
When mozilla introduced tabs I thought I would use them a lot. I know
some people find them very useful.
In fact it turned out that I don't like them: I'd rather start a new
window which I can iconise or not, or change its size or location.
Then I have the option of having two visible at once, which tabs don't
allow. When programming using XVed I usually want at least three windows
visible simultaneously, e.g. one for the file of code being developed,
one for test commands and one for output. Often it is useful to have a
bit of of another window visible at the same time, e.g. a documentation
file (from which I may wish to copy something into the code file or the
test file).
But I can see that some people would like to have tabbed windows.
You can approximate this, by telling ved never to have more than
1 window on the screen. E.g. in .Xdefaults
XVed*MaxWindows: 1
Then you can cycle round open buffers using ENTER rb, or ESC e
(vedfileselect).
I guess it should be possible to use rclib to maintain a list
of the current buffers: Then clicking on one would make it occupy the
window. (I cant see the advantage this would have over ESC e, which
generates the list whenever I want it and then I type a number to select
the file. I don't have to waste effort or attention using the mouse,
which I prefer to touch as little as possible.)
It should not be difficult to extend XVed to specify that certain files
are allowed to make themselves visible only in certain windows. That
would be very useful.
(I set a limit of 8 windows for XVed, even though at times, e.g. while
searching documentation or mail files, or news files, or time-sharing
several tasks in a single poplog process, I may have 20 or more files
open.)
> also by making it a jedit plugin poplog gets access to all of the other
> jedit plugins (or should it be the other way around?)
I am sure this will be very valuable.
I am not actually saying that your complaints about Ved have no basis,
rather that you need to be clear about the difference between claims
about what *you* don't like and claims about what nobody would like.
Editors are notoriously a matter of taste and arguing about which is
best, or better, is generally pointless, except where one is a subset of
another.
E.g. people who have got used to Emacs generally dislike Ved, and people
who have got used to Ved generally dislike Emacs.
It sounds as if Jedit shares with both indefinite extendability by
programming. A plugin for Jedit would presumably be like a library
for Ved, e.g.
HELP dired
HELP vedblocks
HELP ved_getmail
HELP ved_reply
(I've just changed this to cope better with multiple names in
the Cc list)
HELP ved_attach
HELP ved_gn
(get news)
HELP ved_postnews
(which I am about to use...)
(Most of these have newer versions at Birmingham.)
> PS: I have a (almost) complete standalone version of the java-bound
> poplog incremental compiler. Will put in my website when its ready. The
> jedit plugin extensions will take a bit longer...
Many thanks for putting in this effort.
Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (ReadATas@please !)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/ (And free book on Philosophy of AI)
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
|