lpb@cs.bham.ac.uk (Luc Beaudoin) writes:
> Organization: School of Computer Science, University of Birmingham, UK
> Date: Sun, 28 Feb 1993 21:01:07 GMT
>
> I've always wondered why I don't seem to be able to use 'ENTER /' (i.e.,
> ved_/()) to search for a string containing a line-feed and some other
> character (possibly another line feed).
You can, except that the model you are using is wrong. See below.
> E.g., if I executed ENTER /\^Ja in this file I should find the next
> character below, but I don't.
VED does not model the buffer as a continuous string with some
line-feed characters like a file, or like the text buffer in some
other editors. Rather it treats the buffer as a vector of separate
strings. This has some advantages and some disadvantages. The
main advantage is much reduced garbage collection overhead for
most purposes: only short strings need to be replaced during
edits on one line. Also it is very easy to jump around the
buffer on the basis of line numbers, by indexing into the vector.
instead of continually searching for newline characters, or
maintaining a table of locations of such characters.
VED's "anchored search" facilities are based on this model of
separate strings for each line, where each string has a beginning
and an end.
The patterns available for use in searching (and substitution) in
VED are described in HELP VEDSEARCH/'Search pattern elements'
The symbols most used are
@a beginning of line
@z end of line
@? any arbitrary character.
So
ENTER /@a> a
will find a line starting with the string '> a', like the one below.
> a
Beware, if you want to match a pattern include bits of consecutive
lines, you need to have "@z@a" for the line break, i.e. the end of
one line and the beginning of another must both be matched, although
you might think this is strictly redundant. Thus, to replace two
blank lines with one blank line do
ENTER s/@a@z@a@z//
i.e. replace two consecutive empty lines with one empty line.
There's a new regular expression matcher by Jon Meyer that uses
patterns analogous to ed, vi, and emacs, which provides more
sophisticated facilities. (We have it installed at Birmingham
as LIB REGEXP, see HELP REGEXP. I don't know if it will be included
in the next release of Poplog.)
> too bad we can't showlib ved_/.
I have been suggesting for the last few years (even before I knew I
was leaving Sussex) that Poplog should be distributed with sources
for anyone who wants them (but without the tools for rebuilding
Poplog). I do not believe if would be possible for anyone to make
use of the sources to create (and maintain) a rival system.
Having the sources available would overcome gaps and obscurities in
documentation. The counter-argument is that users would start
depending on undocumented features that could change, and complain
when they stop working, adding to the maintenance and support
headaches of the suppliers. I believe this risk would be minute
compared with the advantages.
There was once a hope that some people would pay large amounts of
extra money to get the Poplog sources (as some people used to do for
Unix sources). I believe the evidence is that nobody will, alas.
Aaron
--
Aaron Sloman,
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL A.Sloman@cs.bham.ac.uk OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711 Fax: +44-(0)21-414-4281
|