2011/10/11 "Martin J. Dürst" <[email protected]>: > > 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.
