Apologies for accidentally appending some bits of Steve's message
to my previous message (about RHM).
Here's a comment on Andy's and Steve's comments on VED's alleged
emphasis on lines.
Andyh:
> > : > Oh, and *why*, except for implementation reason, does ved hae this
> > : > fetish for line-orientation?
Steve:
> It doesn't. Indeed, Andy points this out himself when discussing
> XVED.
>
> If you are using XVED then you'll find that there is
> a general text selection region as well as marked ranges.
It is also often forgotten that there are several VED operations that
work between arbitrary locations saved on the "push" stack. E.g. see
ved_cut (and ved_splice.).
Also ved_ds, invoked as
ENTER ds <string>,
defined in terms of ved_cut, allows you to delete an arbitrary chunk of
text, starting from the current cursor location, which could be anywhere
in the line, to just before the next occurrence of the search string,
which could be in the middle of a line further down the file. ENTER dsb
is analogous but deletes back to the previous occurrence. ENTER splice
or ENTER yds can be used to undo.
Another aspect of VED that isn't line oriented is the collection of
utilities described in HELP VEDBLOCKS, which allows you to manipulate
arbitrary rectangular blocks of text specified by using PUSKEY at a pair
of diagonally opposite corners of the block. (It's a pity there's no
visible indication of the relevant rectangle, but it would be easy to
write a procedure to make the cursor jump back and forth between the two
corners, i.e. the top two locations on vedpositionstack, for example.)
Examples of the facilities provided include
-- Copying or moving a text-block
-- <ENTER> dtb
-- <ENTER> sdtb
-- <ENTER> mtb
-- <ENTER> smtb
-- <ENTER> ttb
-- <ENTER> stb
-- Re-inserting text previously stored
-- <ENTER> ytb
-- <ENTER> sytb
-- <ENTER> yotb
-- Insert spaces into a text-block
-- <ENTER> itb
-- <ENTER> sitb
(Details in HELP VEDBLOCKS). "stb" is analogous to "ved_copy", which
saves a copy of the marked range. "stb" makes a copy of the text block,
i.e. Saves it. Apart from that command, in all the others "tb" means
"text block" "s" means static (i.e. leaving all other text unchanged, as
opposed to shifted left or right.) "d" means delete. "m" means "move".
"t" means transcribe, "y" means "yank" (= undo in some cases), "o" means
overlay which means that spaces allow old text to show through.
HELP VEDBLOCKREPEATER shows how you can create a character repeater from
a text block (e.g. use ved_stb to save it into vvedblockdump then
use vedblockrepeater to create the character repeater from the vector of
strings.
The help file shows how easy it then is to define a procedure
ved_addblock to add up all the numbers that occur in the text block. (I
use this a lot in preparing grant proposals!). Equally it is simple to
compile a text block, etc.
No doubt Emacs has similar facilities. I merely cite all this to show
that VED is not totally line oriented in the sense that Andy complained
about.
Chris Thornton had a much more sophisticated library of procedures for
operating on rectangular blocks of text, in his chunks library. Perhaps
he should get it added to $popcontrib.
Steve:
> [I'll also note that Andy's interpretation of marked ranges
> being the most common unit of selection in VED has absolutely nothing
> to do with the line-based implementation of VED buffers.
I agree. The implementation of VED buffers as a vector of strings rather
than as a single huge string (a decision originally taken by Steve Hardy
and myself) was purely a matter of programming convenience and
efficiency.
I suspect that any implementation using a single string will inevitably
cause a lot more garbage collection, even if you use the trick of
keeping some spare space in the string around the "current" cursor
location to allow inserts and deletions without having to create a whole
new string. (Think of all the character shuffling that has to be done as
you jump from one part of of the file to another to make changes.)
Every now and again the gap is not big enough and you have to make a new
copy of the string with a new gap. For a big file this would (in the
1980s, when memory was very expensive) have had an unacceptable GC
overhead. In VED, instead for the current line the string is extended a
bit on the right while you are working on it, and if the extension is
not big enough it's only THAT string that you have to copy and extend,
not the whole file. (That's why changing vedline directly, without
calling vedtrimline is undesirable.) Also if the vector is too small,
you can enlarge it without having to make copies of all the strings: you
merely move the old strings into the new vector. (Maybe a list would
have been better, in terms of increased flexibility, but some
operations would then have required counting list links instead of
using a vector offset.)
Incidentally, instead of the single string or vector of lines it would
be possible to have a collection of chained pointers into a "virtual"
big string or a file, so that insertions and deletions were done merely
by manipulating these pointers. This would save garbage collection (and
possibly memory) at the cost of considerably complicating operations
like moving to the next line, searching for strings, copying the current
line into a string, etc.
This technique was used in the "PED" editor implemented around 1973 in
Pop2 in Edinburgh by J.S.Moore and Bob Boyer (who subsequently became
famous for their Lisp theorem prover and their string searching
algorithms. The first implementation of the Boyer-Moore string search
algorithm was in the Ped editor in Pop2! I remember discussing it with
Bob walking along the seafront in Edinburgh....)
Ped was a line-oriented editor, as it preceded the days of VDUs, and
was originally used only on paper on teletypes.
A pop-11 version was produced at Sussex some years ago. I think there is
still exactly one very distinguished user, who happens to be a Fellow of
the Royal Society and who doesn't like using new-fangled things that
don't really help his science, when the old ones work perfectly well.
You don't really need to see the edits you are doing if you have a clear
enough head.
Returning to Ved and Emacs:
Apart from the efficiency issues, I am sure there are some procedures
for which a vector of strings is more natural (e.g. return the n'th line
of the file), and some for which a single string is more natural (e.g. a
regular expression matcher.). But neither is inherently limiting.
It's all just a huge bit vector anyway.
Steve:
> .....I know that a
> key element in the decision to use marked ranges was the inability
> to highlight an arbitrary selection range on many TTYs. As a compromise,
> I believe, the selection of lines was supported and the visible mark in
> column 1 was provided.
But, as I explained above, there is support in VED for more than just
blocks of lines. People tend to learn about subsets of commands
and stick with them.
> ....With the advances in VDU technology, this
> decision should be revisited.]
Perhaps. There are still occasions when people are accessing poplog and
Ved via pretty dumb terminal emulators over kermit and such things.
Steve:
> There's no controversy. VED should support arbitrary
> undo operations. These operations should be categorised. The user
> should be given two ways of interacting with the undo-list -- through
> sequential ordering (undo the last done thing) and through category
> (undo the last line deletion).
Yes. I forgot to mention that both should be provided when I explained
the category based method.
Steve:
> This supports both Andy's way of working and Aaron's way of working.
> Unlimited levels of undo should be supported, modulo storage requirements.
The easiest way is to write the file at every change!
Aaron.
PS
I like Steve's suggestion of sticky properties. I presume there
would be degrees of stickiness, but I don't know whether only
a property would have a degree, or whether each entry would have
a degree. I suspect you meant the former.
|