Baslinux mailing list

[Day Brown <daybrown AT hypertech.net>]

3aoo-cvfd AT dea.spamcon.org wrote:
> 
> Day Brown wrote:
> >
> > Its a chronic problem in open source,
> 
> It's not a problem, it's an advantage.  One of the best
> things about DOS (and earlier OS) was the diversity.
> Different programmers doing things in different ways.
> Variety and choice, it was great.
aint no free lunch. below, you cite the commands with grep and some
other tools, which are simple one key commands, which is nice, but how
do I remember them? The best system I've seen for that are the ansi
color scroll bar pulldowns. 
...
> > Because, when I want to look thru all of the dialogue of
> > a given character, to see if it is consistent, the search
> > thru a single long document is gonzo easier.
> 
> Not necessarily.  IIRC we were talking about text files
> (without much formatting).  There are tools available
> that search through every file in a directory (rather
> than being limited to a single long document).
There are dos tools for that too. But I dont care whats in the other
files. the ebook author usually has it all in just one file.

> > And sometimes, I remember something I want to insert,
> > but can only remember a relevant phrase to search for.
> 
> grep (in BL2) will find it in any file.  For example, I
> frequently use grep to search through every HOWTO on the
> Slackware CD.  It tells me the name of every file containing
> my target string and prints the lines containing that string.
The problem I've seen with linux documentation is that there is so much
of it, that it takes forever to pull up. Typically, with a dos app,
there is the 'file_id.diz' which is just a paragraph describing the app,
then the APP.DOC which tells how to work with that app. And typically,
both will be in the same directory, so that when the user wants some
info on how to use the app in question, it comes up immediately.
Typically as well, if the dos user wants help he either does alt-H or
hits F1.  
> > I've used DEXTER.EXE w/DR-DOS or FREEDOS, and seen it search
> > thru almost a meg of ascii in an eyeblink.
> 
> So does grep. The first search through the HOWTOs (13mb) takes
> a few seconds.  Every search after that is instantaneous.
I thought grep was just a search tool, not an editor.

> > The Linux editors which I have seen, aint nearly that fast.
> 
> What are the names of those editors?
vi, mac, elvis. Someone mentioned jed, which I'll havta look for. The
text mode linux editors which I have seen look like they were designed
for the 25 line monochrome monitor, and did not offer the functionality
of color clues.  
> > I also have copies of Edw. Gibbon, THE DECLINE & FALL OF THE
> > ROMAN EMPIRE, 1.6meg/volume, and again the DEXTER searches are
> > reasonably fast.
> 
> For searching such things, links (in BL2) is very fast.
> Execute d to start it in local mode, use the arrow keys
> to navigate through directories, press right-arrow when
> you find the target file,  press / to search.
The researcher would, at this point, want to cut a copy to paste in
another work. Another thing I liked about DEXTER was that I could split
the screen vertically, have gibbon open on the left, cut/copy whatever I
wanted out of it, while on the right side of the screen be able to
slide/page thru the document I was working on... all in text mode, with
only the top stat line, as compared to the gui menus which have sliders
and tool bars taking up so much space that only half, or less of the
total screen area shows me the text I am interested in.

None of the linux text mode editors made it obvious to me that they had
this capability. And given today's monitors, I dunno why they dont
default to 50 rather than 25 lines.

It is a chronic problem indicated by all the times someone responds to
the first paragraph without realizing that the issue is dealt with
further down in the document. but since the gui menu only lets them see
25, rather than 50 lines, they dont know this.