2012/2/6 Stephen J. Turnbull
<address@hidden>
Alin Soare writes:
> > > 3. when grep finds something, and the tab is hidden , the tab widget to
> > > change the color
> >
> > What sense does it make to have a hidden tab change color? And what
> > kind of event is this in your nomenclature?
Alin, in English the physical metaphor that "tab" invokes refers to
the small piece of a folder or notebook divider that sticks out where
you can find it in a stack. It specifically does *not* refer to the
content area that is linked with the tab. So if the tab is hidden
(eg, by another row of tabs), you can't see it change color! This
precise definition may be difficult to understand from the way native
speakers use the term, but I assure you your usage is confusing the
hell out of the native speakers here.
In 'konsole of KDE there are tabs. In each such tab can e run a process (not necessrily 'bash) .
In konsole, when a tab is hidden and its process gave output, the tab changed the color.
The same happens to alll chat programs.
As well as some of the non-native speakers, as I presume Martin is.
> Tabs should register a callback for an event , for example, when i/o
> arrives in the given process...
You're going around in circles. Martin knows how events and callbacks
work.
> Quite so, you can do this functionality using only M-x and calling lisp
> functions. Or menu entries. But I am sure most people would be happy to be
> able to define a tab that shows a 'grep process.
I doubt it. In real life as defined in the English language, a tab is
a way to quickly find a flat object in a neat stack of flat objects of
similar size and shape, such as pages of an address book or file
folders in a file cabinet. It is very similar to a bookmark (I mean
things the ribbon you find in a nicely bound book or some odd scrap of
paper, not the web browser sort), except that bookmarks are ad hoc and
tend to have no fixed relationship to the content that they mark,
while tabs are systematic, and have a fixed relationship to content.
Eg, a common tabbed object is an address book, and the tabs are small
areas that stick out, have labels such as "A", "B", "C", and the
related content is "names that start with A," and so on. Another
example is a product manual divided into sections, such as the well
known Unix manual with "Commands", "OS entry points", "Standard
library", and so on.
In computers, because software is more dynamic than printed books
(even looseleaf notebooks), tabs tend to be more ad hoc. Still,
they're really just glorified bookmarks, usually coming in sets with
some sort of relationship to each other.
So basically a tab control is just a set of windows (or frames) that
share the same screen real estate, with a visible but nonobtrusive GUI
to switch windows (frames) quickly.[1]
I can easily believe that *you* might use a tab to invoke a grep
process, and there's nothing wrong with that if you want that
.
However, that is not the way most people think of tabs. Most people
would invoke the grep process with M-! or a menu item or maybe a
toolbar button, and then -- if the output was to be referred to
frequently -- they *might* use a tab to navigate to *Shell Command
Output* buffer that holds that output. I doubt very many people would
find it natural to invoke commands with a tab.
In practice, the only things that a tab needs is a Lisp object to
represent it and to keep track of its screen real estate, and a small
API to control its appearance. Everything else can be defined in
terms of existing Lisp primitives (eg, your grep example with the tab
changing color when the associated process buffer receives output
could be implemented with a process sentinel).
I propose to find a definition of tabs, such they are programmablem and give whatever default behaviour of tabs you wish, give the LIBERTY to those programmers who wish to define other kind of tabs for themselves, to be able to do so.