Re: about P1 part of BIDI alogrithm

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Tue, 11 Oct 2011 05:08:41 +0200

2011/10/11 "Martin J. Drst" <duerst_at_it.aoyama.ac.jp>:
>
> This is different from what you did in Emacs, which I'd call line-folding,
> i.e. cut the line after a paragraph is laid out and reordered completely as
> a single (potentially very long) line. This makes some sense in Emacs, where
> the basic assumption is that lines should fit into the width of the view.

The line-folding mode is no longer the unique view possible in Emacs.
Many Emacs implementations support the non-folded view, that can
scroll horizontally, and maintain vertical alignments of columns, for
exampel when working with flat database files with fields of fixed
lengths, as if you were using a spreadsheet. Lines can then be
arbitrarily long and not not required to fit the small width of the
view.
The same is true for adepts of vi (or Vim) that also offers now
various viewing modes, depending of the capabilities of the terminal
interface, which both editors can query in order to adapt the
presentation or accept easier input modes.
I have most often using a "wysiwyg" editor now, even within a basic
plain-text console or terminal emulation. The power of these editors
is about their support of complex editing operations and sometimes the
support of custom macros.

Emacs can also offer an interface with other softwares through lots of
user-configurable plugins (Emacs by itself is a very powerful
computing environement, nearly an OS, supporting things like
multitasking, mutlithreading, process control, asynchronous events and
I/O, and even capable of handling other objects than just plain-text,
in various views for the same "virtual" document which may be a remote
service or database for example, or a form processor, or a web
service, or collaboration tools and interactive or offline
communications between users, generation of graphics, playing videos
or audio...).

Many Emacs implementations do not have all these capabilities, even if
they offer similar key bindings when editing plain-texts. The true
power falls within the power of its Lisp engine and programmabilitity,
but people that are trained to it are becoming rare today and many of
those that were able to use it in the past have completely forgotten
the essentials because they use something else today, with which they
may be even more productive with less errors (the other reason is that
Emacs can be very slow for some operations; working with other
languages like Perl to create editing scripts may sometimes be easier
and much faster, due to the impressive collection of ready-made
libraries and tools available to work with it; and Emacs
initialization time is sometimes very slow, or it cannot always work
with very voluminous texts without excessive swap to disk, like what
you can do with much simpler tools like "sed").

Given the wide choice of text editors available today, many users will
alternate between editors depending on the work they have to do and
the ease they find a way to automate specific but repetitive (and
boring) tasks. This is not different when working with audio and video
editors, speadsheets, web site editors, databases, online
communication tools, document versioning systems: everyone wants
powerful tools, but only uses a small part of the functionalities. And
everyone will adopt sooner or later another tool, forgetting one that
he used a lot in the past, because the kind of documents they have to
work with have changed in form, volume, or frequency, or require new
maintenance tasks and quality assessments, or tracability, or have to
be worked on by larger teams of people trained differently.
Received on Mon Oct 10 2011 - 22:12:54 CDT

This archive was generated by hypermail 2.2.0 : Mon Oct 10 2011 - 22:12:56 CDT