:: Re: [Dng] OT: separate GUI from com…
Top Page
Delete this message
Reply to this message
Author: Roger Leigh
Date:  
To: dng
Subject: Re: [Dng] OT: separate GUI from commands
On 27/05/2015 14:54, Laurent Bercot wrote:
> On 27/05/2015 12:12, Hendrik Boom wrote:
>> I'm in the process of writing (yet) a(nother) editor and output
>> formatter,
>> and on reading this, I started to wonder -- just how could one separate
>> a command-line version from the UI? I can see that the output
>> formatter can be so separated (and very usefully), but the actual
>> editing?
>
> Maybe I'm misunderstanding the question, as I'm unfamiliar with the
> internal of editors. But IIUC, an editor is, by definition, a user
> interface, so the command-line / UI separation looks impossible or
> irrelevant to me here.


No, it's still very much needed here as well.

You have the data model (buffer of file contents, likely as separate
lines) and the view of the data (presentation in UI) in any editor worth
its salt. As an example, take Emacs where you can have multiple
windows/split windows with one or several views of a single file, each
with its own current position and view in the file. Doing this requires
the data be completely separated from the view. And this then lets
macros manipulate the underlying data without any need for the UI--which
is exactly what all the Emacs macros are doing under the hood e.g. M-x
replace-regexp etc. They might take input from the UI--current point,
selection range etc., but the underlying implementation of the macro
functionality is then operating on the data model.

Even a humble terminal emulator has (or should have) a model/view in its
implementation, called the data layer and presentation layer,
respectively. See e.g. ECMA-35/48. This is used for example to render
and manipulate bidirectional script--the data layer is the logical
order; the presentation layer is the rendered visible order. Commands
allow nagivation in either layer with the cursor.


Regards,
Roger