Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix <nix@esperi.org.uk>]

On 8 Feb 2012, Alin Soare outgrape:

> I propose the following  [brief/ main steps of a] concrete solution for
> changing the color of a hidden tab whose process gave output in the
> meantime:
>
> 1. Every tab has a unique ID that can be read and not modified. This ID is
> dubbed by the system at the creation of the tab.

This is pointless. Window configurations don't need a 'unique ID',
neither does this. Just reify the tab: make it a unique Lisp object type
(again, like window-configurations). Now the tab object serves as its
own unique ID.

> 1' Every tab has an internal state. The tab can be seen as a dispather of
> messages (or actor) of scheme.

I don't understand. Are you saying that each tab is its own recursive
editing loop? Because that seems unnecessary (and likely to be very
confusing to users).

> 2. When the tab is created , it starts the process, and memorize the
> process in its internal state.

Tabs surely have nothing to do with processes. I expect most tabs to
contain buffers (or window configurations, perhaps). A constraint that
they all contain processes is surely impractical.

Do you mean that (create-tab ...) returns a 'tab process', much as
'make-network-process' does, and that this 'tab process' is then used to
receive events from the tab somehow (such as the user switching to it)?

That's reasonable, I suppose, though we'd need to define what that
process sentinel does. For network processes this is clear enough:
creation of a network connection, its breaking, and the reception of
data invoke the sentinel and optionally dump the data into a buffer.

This makes conceptual sense because network connections are like
processes in that they are things down which asynchronous bytestreams
are transmitted in both directions. None of this is true for tabs, as
far as I can see, so the process sentinel model isn't such a good fit.
(I can't think of anything that is a better fit, except perhaps
some hooks called from the C core whenever a tab is switched to. I would
strongly advise against any concept of tab-local variables: while they
make programming a tiny bit easier they make variable lookup slower and
much harder to get right. Frame-local variables have enough ugliness and
unfixable bugs that they are being removed. Let's not make it worse. I
know nobody has proposed this yet: I thought I'd just shoot it down
pre-emptively.)

> 3. we use the hooks from process , low level programming.

You need a lot more description than that. What does a tab sentinel
function do? Processes and network streams send and receive data. What
do tabs do?

> 4. we add a hook that calls a function like tabs-process-signals. This is
> either a function of the internal state of a tab, and in case must be
> generated for each tab, using the ID of a tab, or be in global environment,
> and loop over each tab.

The latter is unscalable, but there's no requirement for something in
the global environment to necessarily do any sort of loop. A tabs hook
function would probably be called with the tab object as a parameter.

> 5. this function (tabs--process-signals) either is generated separately for
> each tab, or loops over the list of tabs, and identify the tab whose
> process' buffer modified.

If you passed the tab object as a parameter, that would be entirely
unnecessary.

> If emacs had actors, a tab could be implemented directly. If not, the idea
> of internal state can be encoded somehow.

Er, yeah, quite a lot of things in Emacs have internal state. More
internal state than you can shake a stick at. :)

-- 
NULL && (void)