[Oberon] minor tuning of TUI?

[Douglas G. Danforth]

In Component Pascal (a superset of Oberon)
the connection between a document (file) and
its view is retained.  If one attempts to open the
document again one is directed back to the open
view.  One can have two views of the same document
but they are identical.  If one changes the document
in one view it is changed in the other view.  For example
if the first view is looking at the start of the document
and the second and the end of the document then a change
at either place will make itself known when one scrolls the
view to that location. Closing the (last) view will ask you if you
want to save the changed document.  That happens even when
you exit the system without explicitly closing the document.
-Doug Danforth


On 6/11/2016 10:19 AM, Richard Hable wrote:
> Am 2016-06-10 um 14:54 schrieb eas lab:
>
> [...]
>> ETHO can give bad results, if you hadn't saved the hidden Frame-A
>> before you "just temporarily?" Grew Frame-E to full Track;
>> and then made changes to the newly re-fetched old Frame-A.
> Yes, that's a real problem. Back when I was using the Oberon System, I
> repeatedly fell into the trap of either closing the last viewer of a
> document with unsaved changes or overwriting changes due to separately
> opened viewers from the same file.
>
>> Can't ETHO just scan the Frame tree, before loading a Frame
>> from file, and if the Frame is already open, then move it to
>> foreground.    wily also puts the cursor to the just loaded Frame.
> I tried to find a solution for that, but came to no satisfying solution:
> once a viewer has been opened based on a file's content, it is
> independent from this file. The user may or may not save the document by
> clicking on the store command, he may change its name in the menu and
> then store, and possibly overwrite a different document, etc.
>
> There is no one-to-one relationship between documents stored in files
> and documents shown in one or more viewers. Therefore, we can't really
> scan the tree of open viewers and find out what belongs together.
>
> I think, in order to solve the problem it would be necessary to have an
> additional layer between files and viewers: something which handles a
> list of open documents, with references to files and viewers. All the
> editors would have to be changed to use this layer to open, store,
> rename etc. documents.
>
> Of course, this is not possible without creating a completely different
> version/distribution of the Oberon System. IMO this shows that, while
> the Oberon System is rightfully called an "extensible system"--you can
> easily create new, extended versions of tools like editors and
> compilers--, it is not an "adaptable system", because you can not change
> the behavior of the base modules.
>
> Richard
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>