[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Sep 10 08:46:21 1993 
Subject:Re: emacs & ved; flame-bait. 
From:"A.Sloman" 
Volume-ID:930910.02 

Hello Andy,

> +  And a regular  expression handler. At  all!!! You have  no idea how
> pissed off I was when I discovered that ved had no isearch, and no way
> to  search for a  regexp (and "beginning of  line" and "end  of  line"
> don't  count. And I   know I could   run  a grep  process,  but that's
> cheating...)

Having met regular expressions when I used "ed" I disliked them so much
that I preferred always to write a tiny VED program to do anything more
complex than anchored search. Of course that's just another personal
preference! But I agree REs are highly desirable because so many people
want them, and I assume that Jon Meyer's RE matcher will be available in
V14.5??? (and perhaps later built deeper in to VED).

JULIAN CAN YOU CONFIRM??

> Oh, and  *why*, except for implementation reason,   does  ved hae this
> fetish for line-orientation?

What does that mean? You want vertical lines of text as well as
horizontal ones, or what?

> And... wait for it... NO UNDO!!! Until you have to  put up with a yank
> which calls  itself undo you  have no  idea how irritating  it is. But
> I've had this argument before.....

I think I could produce ergonomic arguments (which would have to be
backed up by empirical research of course) that rather than having a
single UNDO an editor should have a collection of different categories
of UNDO each with its own user-settable memory size (i.e. number of
UNDOs allowed). Thus I should be able to undo the last rectangular
block cut without having to undo the line deletion that I did after
it.

I once started designing a set if undo-categories for VED, but as usual
pressures of other work, etc. got in the way. Of course it's silly that
there's currently only a single part-line-undo (yankw) that can't
distinguish between wordleftdelete, clearhead, etc., and silly that each
of vveddump, vvedlinedump, vvedworddump, vvedblockdump, vvedcut_dump,
each stores only ONE item that can be retrieved, i.e. the last thing
deleted, cut, copied etc. I accept blame for that.

I don't find it surprising that there are quite a lot of people who
are annoyed at the lack of more general undo (e.g. undoing a global
edit).

What I do find surprising is that most users have not screamed for this.
If they had, ISL would have pressed for it.

As regards incremental search, someone at Sussex many years ago provided
lib ved_incsearch which does exactly that. It was announced, and I even
remember trying it for a while, but hardly anyone showed any interest in
using it. So it never got taken up. Maybe it should be resurrected, or
posted to pop-forum? It's very simple (about 87 lines of code). It's
just one of those many things that show how different individual
preferences are regarding editors. After using it for a while I lost
interest and never missed it!

Incidentally, it's trivial to write an undo for global edits which is
not particularly efficient, but enables disaster recovery. Simply define
a procedure that saves the whole file in a temporary file, then calls
ved_gs (or ved_gsr, ved_gsl, ved_gsp, etc.) as required. Perhaps
that should be in the library. (I find that lib ved_autosave does
what I need in that regard.)

Finally one undo that I started missing over the last year and a half
was an undo for accidentally invoked ved_y, ved_t, ved_ti, etc. I.e.
all the things that insert text from vveddump (which is not really well
documented either in REF VEDVARS or in REF VEDCOMMS, which says which
procedures create it but not which ones "yank" it.)

So I wrote a little procedure called ved_uny, which I'll append. I have
used it many times, but I expect other people have different patterns of
use, and might never need it. That's the problem with any GENERAL "undo"
facility, as opposed to programmable, tailorable, undos of different
categories. Alas, we are all different!

Aaron

define ved_uny();
	;;; ENTER uny -- opposite of ENTER y
	;;; Remove text following current line matching contents of vveddump
	;;; Could be modifed to search for any unmarked range matching
	;;; contents of vveddump and offer the option of removing it.
	lvars string;

	dlocal vvedlinedump;	;;; ensure this is restored afterwards.

	vedchardown();

	for string in vveddump do
		unless(string = veddecodetabs(vedthisline())) then
			vederror('Line in -vveddump- missing');
		endunless;

		vedlinedelete()
	endfor;

	vedcharup();
enddefine;