[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Sep 11 14:42:28 1993 
Subject:Re: emacs & ved; flame-bait. 
From:Steve Knight 
Volume-ID:930911.02 

A few comments on Andy Holyer's posting:

> Regexps: OK, I've never tried Jon's package. I should, I admit.

I'd like to recommend Jon's package.  I sincerly hope it goes into
Poplog 14.5.  It is excellent.  I've used it for a while and have no 
problems at all.  Regular expressions, however, aren't for beginners
or non-mathematically minded people -- so they should be a preference
option.

Come again, a "preference option"?  My own complaint is that VED and
Poplog has an enormous space of customisation but no uniform way of
doing it.  The Poplog UI is a step in the right direction -- but it
needs much, much more fleshing out.


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

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.  I think
the distinction between these two is rather annoying -- I'd like to
see the marked range as an alternative way of selecting text.  I
also think that there is a confusion between selection of text and 
copying to the clipboard.  These concepts should be clearly separated.  
[Andy states this himself, later in his posting.]

[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.  In my view,
this is a connection that has no support.  By contrast, 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.  With the advances in VDU technology, this 
decision should be revisited.]


> : > 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.....
> 
> [Aaron's long and valuable discourse on undo...]

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).

This supports both Andy's way of working and Aaron's way of working.
Unlimited levels of undo should be supported, modulo storage requirements.
See the postscript for details on how this might be done.

Steve

P.S.  
To correctly implement this type of storage management a new kind of
temporary property (or reference) needs implementation -- a sticky 
property.  Sticky properties temporary properties that can lose entries
that AREN'T garbage.  Very stickly properties hang onto their entries
quite strongly -- until the garbage collector struggles.  Unsticky properties
are like "tmpclr" properties -- they forget their entries at any garbage
collection.

Sticky properties are very useful indeed.  They are the kind of properties
that are best used for memoisation, for example, and other kinds of 
sophisticated memory management.  I've put in an enhancement request
asking for sticky properties to be added to Poplog.


P.P.S.
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.  In my view,
this is a connection that has no support.  By contrast, 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.  With the advances in VDU technology, this
decision should be revisited.