Re: [orca-list] Another Suggestion for OpenOffice/Orca Improvement

[Jason White <jason jasonjgw net>]

On Sun, May 18, 2008 at 08:31:20PM -0700, Steve Holmes wrote:
> This issue of yous is one that bugged me ever since I started using
> any GUI based editors.  This is not confined to OO but extends to all
> Windows based text editors such as NoteTab, NotePad, Ultra Edit, and
> even Gedit over here on GNOME.  In order to select a block of text,
> you have to most likely hold down the shift key while arrowing around
> with the keys; this prevents you from using an alternative command
> such as search/find to find the end of the block of text you might
> want.  In emacs, I can begin the block with ctrl-space and then use
> ctrl-s to find the end of the block I want with specified text and
> then use the repective command to cut/copy to clipboard.  The same
> thing can be said for vim.  These GUI type editors need the ability to
> start marking a block of text and then allow for varied ways to
> navigate to the other end.  

It's worse than that: they don't allow you to move by sentence or paragraph,
or to specify numeric prefixes to control the number of
words/lines/sentences/paragraphs moved over. This is just the start; there are
many more limitations that you only notice once you've been using a good text
editor proficiently.
> I think another contention I have with GUI
> editors is the concept of line orientation is lost.  But then again,
> word processors don't really work at a line level anyway; do thay.

Correct, but documents have structure and a good editor would enable you to
navigate by document element.

When I am editing a LaTeX file in Emacs or Vim (I use both, but more often
Emacs due to its highly useful Auctex mode), all of the formatting commands
are included as part of the text of the document. There is no ambiguity
concerning what the structure of the document is, or what formatting commands
are specified. If I want to read the file without all that clutter, I can
convert it to HTML, or even to plain text.

The primary use for a graphical environment by many experienced Linux users is
simply to enable multiple terminal sessions to be displayed on screen
simultaneously. To this we can add a Web browser, possibly an audio/video
player, and perhaps graphics editors as required. However, the primary mode of
interaction is still through textual tools: the shell, editors such as Emacs
and Vim, etc.

I wouldn't be surprised if this is still true twenty years from now, although
I hope by that time the textual tools will be even better, with two more
decades behind them.