[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alin Soare
Subject: Re: Tabs are ready? -> Let us give a definition of tabs.
Date: Mon, 6 Feb 2012 15:34:10 +0200

2012/2/6 martin rudalics <address@hidden>
> 1. at initialization it starts a grep and looks for something in background

How do you communicate to the tab what the "something" is?

execute 'grep -i foo *' in background , example

> 2. The 'show event should commute to the buffer *grep*

This is the standard buffer switching functionality.

I know how to commute a buffer. In this case of tab, I want the show event to commute to a given buffer.

> 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?

Tabs should register a callback for an event , for example, when i/o arrives in  the given process...

> 4. The 'close event should kill the *grep* buffer, and the process , if it
> had not finished yet

>  Could you do this using buttons in toolbar or menubar, as you insist ?

So far I'd only insist that saving and restoring window configurations
should be done with the menubar rather than with a tab.  I never ever
use toolbars but I think that mail handling routines using the toolbar
(could) do such things routinely (inform of new mail, kill a buffer and
remove the associated button when mail has been sent , ...).

Why do you change the subject of discussion ? saving and restoring window configurations concerns other type of tab, not this one I am talking here.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]