[Oberon] Re: selecting all text in a viewer

Duke Normandin dukeofperl at ml1.net
Mon Sep 6 22:47:50 MEST 2010

On Sun, 5 Sep 2010, Chris Glur wrote:

> > > ... select large quantities of text. What a PITA though!
> > > I'm sooo used to ^A or in emacs ^spacebar+arrowDown.
> ETHO is easier hence superior, in that you don't need to
> 'associate a random-key with an action'.
> You can 'read' the instruction.
> I.e. it's easier to learn to push the button marked "sit",
> to do the action `sit`, that to have to remember if it's
> Ctrl/S or Alt/Z.

I see your point! BUT....

You first have to know _where_ all these commands live _before_ you
can 'read' them. If there existed a popup menu, or a Tool, or a Panel
containing _all_ text-file editing/manipulating commands that could
ever be dreamed of for use within NO, _then_ it would be a no-brainer
to go down the list and 'read' a command and 'klux' (whatever that's
an acronym for?) to your heart's content. In the meantime I have to
grope around and find some of these commands EditTool, e.g., or create
my own, I suppose.

However, after 20 years of using emacs, I'm pretty darn efficient with
it. And there's even a tutorial and menus just a keystroke away.

Not to say that the NO environment cannot become efficient for someone
- I'm sure it can, with time and practice (and Reiser's book) :)

> OTOH, the few clux-actions are random and should not be
> remembered, but should become instinctive, like riding a
> bicycle.

Emacs key-bindings likewise..

> Apparently the leading HCI experts have shown that the
> best is icons with 'popup explanation text when the cursor
> hovers over the icon for a short time'.  I'm infuriated that I
> don't know how to disable these mosquitoe-like popups
> on kde-3.0.

Yep! They can be a real PITA...

> Peter E. wrote
> > Making a "Select all" button for the pop-up menu in ET
> > is a good little programming exercise.
> Yes, but I prefer a M.P which is independant of ET.
> And I've just confirmed that:
>      CRGtrace.Font2MrkdVwr  Courier8.Scn.Fnt ~
> works with document frames too.

OK! Are you in the mood for sharing "CRGtrace.Font2MrkdVwr"? Sounds
like a swell little tool to me.

> Well that's what my previous post was about:
> * set the action once,
> * repeat single clux to select the args
> * until the 'mode' is reset to normal ETHO mode.
> eg.
> 1. klux = all subsequent selected [by MR on any char/s] words
>        [bounded by white-chars] are to take this font and colour.
> 2, 3...N = DoIt
> N+1 = restore system to normal ETHO-mode.

Don't get it!

> Of course Duke would know by now the more tedious manual
> way of make all text of a frame have a specific font and colour:-
>  select the whole text:
>      MR/select from the beginning to the end
>        if the total text exceeds a screen length, then
>         break it into 2 frames:
>            `Copy` to create the second frame
>      select the beginning of the text in the top frame with MR
>       hold <shift> while
>      selecting the end of the text in the bottom frame with MR
> Confirm that  the 'whole selection' is hi-lighted.

I _didn't_ realize that if the text was larger than what could _all_
fit in a "Viewer", that I had to make a copy to "see" the bitter
end. I thought that the "copy" was a destination viewer or
something. I did exactly like Chris Burrows recommended - I MR one
character at the beginning of the text in the 1st Viewer; I MR a
single character at the bitter end in the 2nd (copy)
Viewer. &^%$#$-all happened! I kluxed till the bloody cows came home,
and then threw the friggin mouse out the window, and went fishing :)

> ML/MR on the sample text anywhere on the screen which you want to
> have the selected text to copy the sample's font and colour.
> Using successive refinement, you off course, first confirm this on a small
> text selection.
> -----------
> The cited example based on *5*.Text is quite complex:
> * locate the frame which is 'marked'
> * change all of its text's font to the new font.
> I'm guessing that Duke didn't make appropriate multiple steps
> from 'hello world' to this utility, because he needs to have better
> viewing of the screen to make progress?

Yep! I missed the boat somewheres - and _that's a fact! BTW, have you
ever tried Modula-2? I'm kinda looking at GNU M2. ;)

> -----------
> Re. ETHO 'trap facility': this is astounding.
> I doubt that the M$ & C-boys have any thing similar.
> I won't mention the facility to 'go directly to the source error'
> because I've hardly used it; but the trap-format, where the
> sequence of procedure-calls, before the trap, is displayed
> with the local variables is very powerful !

I'm fairly sure that Mike Spivey's "obc" compiler ships with a GUI
debugger that does the very same thing.

More information about the Oberon mailing list