Hi David,
Thanks for your comments on Ved's shortcomings. I've got some of
thoughts on them - which appear to be general complaints rather than
specifically about "file handling" (which got me all excited).
It is fairly clear that your comments do not refer to the version
of "vi" that I grew up with. Mines the one where you need to
type i/a/o/O/etc before you are allowed to enter text. I'd be
interested to know which version of "vi" you had in mind?
>No syntax colorizing has to be the top one,
OK - not the "vi" I grew up with but one of the modern variants. I'm
not mad keen on syntax coloring myself, as it happens, but it would be
a nice generalization to make internally to Ved.
At the moment, Ved's character attribute info (which includes colour)
is saved as part of the file, effectively in-line with the character
codes. And that's bad news because the Pop-11 compiler does not
accept character streams with that info. So a syntax coloured file
couldn't be loaded :-(
So to make syntax colouring work you would need to write a decent
algorithm, which would be easy-peasey, and EITHER add a new flag to
Ved to say "don't bother saving character attribute info" OR add
a flag to say "save/restore character attribute info in/from a
separate file".
The syntax coloring algorithm would significantly benefit by being
given a FSM-state field for each line of the buffer. That would mean
that the algorithm would only have to be applied from dirtied lines
to where the state re-synchronizes.
Ved doesn't really support the concept of user-actions on dirtied lines
so a good first approximation would be to run the syntax colourer over
all the lines of the screen after every keystroke - with the above
line-based caching strategy the performance hit would be negligible
since it would typically do very little. [This isn't quite good enough
because of buffers with multiple windows and operations that scroll
"the other" window.]
Sounds like a weekend project to me. If someone else wants to tackle
the character attribute saving issue I'm prepared to implement the
colourer. And eat my own words, no doubt.
>but also there is no code folding,
True. I've wanted this for a long time myself. It is surprising
how few editors have taken this seriously. Of course you have the
same issue of where to save the folds since there is no uniform model
for saving meta-data across filing systems.
Hmmm. I've never seen a "vi" variant that does this. If you have,
let me know 'cos I would find this handy.
>the default key bindings are awkward
This definitely isn't a comparison against any version of "vi" that
I know :-)
Ved's default key bindings are modelled against emacs, as I recall, and
designed solely for "green field" environments.
> the focus model of the WM is overriden,
Of course it is configurable - the problem is that it does not
automatically adopt the choice of the WM. I agree that this has been
a weakness in XVed (rather than Ved) for ages.
On the other hand, the "vi" I know and love runs in a TTY, so Ved comes
out a winner here, too.
> the colors (in help/ref/teach files) look badly painted,
Interesting - I think you'll need to expand on this. The whole area
of colour attribute information is interesting. However, I note that
when I type "vi" I don't get any colours at all. Although my
tendency is to say "hurrah for vi, colours are evil", this doesn't
really reflect negatively on Ved or XVed.
>no tab-editing (for multiple buffers, i.e. you need different windows for each)
Personally I would love to see XVed adopt a hybrid tab + window model,
exactly the way Apple's Safari web browser does (which was ripped off
from Chimera).
My version of "vi", it must be said, only lets you run different windows
in, errm, different terminal windows. Not a model GUI citizen.
>and some other pithy complaints. Most of that is also true of vi, but at least the key-bindings are more straight forward.
Duh? On my version of "vi" I still navigate around by using "hjkl" for
left/down/up/right and you enter text mode with a command like i/a/o/O.
That's surely not what you mean?
In general, I thought these were interesting comments, many of which I
agree with in spirit. What would be nice would be to turn these from
general complaints into constructive proposals for what would be better.
For example, there are a couple of references to perceived inadequacies
in key bindings. I'm unclear on what this might mean. I've used "vi"
for over fifteen years, "Ved" for the same length of time, XVed for
less time of course, and I've done a recent evaluation of "JEdit" on
Mac OS X - so I would definitely expect to be able to understand an
explicit comparison of key-bindings.
From my viewpoint, the most exciting of these comments/suggestions is
to enhance XVed with tabbed windows. XVed's window management is a
poor fit with my own working style and tabbed windows would take away
a lot of my complaints. If it was a hybrid strategy, it would take
nothing away from other users and add something very attractive to me.
Syntax colouring is, to my way of thinking, something of a "gimmick".
So it is fascinating that you put it top of your list of priorities.
Do you think is it specifically syntax _colouring_ that you value
or would syntax _highlighting_ (differently weighted text) or simply
interactive syntax _checking_ be adequate?
In thinking about this, bear in mind that ~8% of Caucasian men are
dyschromatopic (i.e. colour-blind). That's 2.4 boys in a class of
30 boys, for example. Also today's monitors do not display mixed
color text at equal levels of readability - making it very wearing to
read for long periods of time. That's something I've come to appreciate
quite directly as my vision has declined naturally with age!
As far as appearance goes, the best program text editor I ever used
was Think Pascal's. The interesting thing about this editor was that
it completely took over the layout and styling of your program - you
simply picked the style of presentation you wanted. That meant that
when you read in someone else's horridly indented program it got
presented in your favourite style! I could go on for ages about what
they did right in this but ... I gotta dash.
Thanks again for your expanded comments.
--
Steve
|