2012/2/6 Stephen J. Turnbull > 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.