[TxMt] how do you close excess tabbed files?

[Xavier Noria]

On Jan 4, 2005, at 12:04 PM, Xavier Noria wrote:

> On Jan 4, 2005, at 10:35 AM, Sam Andrews wrote:
>
>> i often work with pretty bloated projects, and the tabs don't really 
>> work for me, either.  my personal preference would be for a list of 
>> active files displayed in the drawer - so split the drawer between 
>> that and the project file list, as shown in this mockup:
>>
>> http://dev.samandrews.com/misc/tm1.jpg (121k jpg)
>>
>> to further extend the functionality of this view, it might be 
>> desirable to indicate some basic metadata for open files such as last 
>> saved, number of bookmarks (useful if you use bookmarks to track your 
>> to-do items) and so forth. i think the spotlight-esque filter as 
>> xavier proposed could also be very useful.
>
> I second that proposal. In my daily experience the one row of tabs 
> (both in TextMate and Eclipse) just adds noise because you have just a 
> handful of opened files there, whereas I tipically have a lot more. 
> Because of that the tab selector is in fact useless most of the time, 
> and the interface it enforces makes looking for an opened file not in 
> the tabs something exceptional, I mean, it is not the default 
> interface, the easy one, but it is the one I normally need.

I have to add something there.

If I think further I believe the distinction between opened files and 
files in the project is artificial. It is a traditional distinction, 
but tradition sometimes can be improved as iTunes did. I think this 
intuition goes in the line of Fred's ideas.

I think what I really would like would be to eliminate that distinction 
from the end-user interface. For instance, just off the top of my head. 
There could be two ways to select a file in a project:

     1. Project-wide filtered textfield (shortcut/menu selection)
     2. Selection in the drawer (mouse/keyboard)

The editor then would take care of managing resources. It could have a 
hidden pool of opened files, so that the end user does not care whether 
the file is being opened or recovered from memory. The drawer could 
show files modified and not saved with an icon as Eclipse does for 
errors for instance (if there's an error in a file the icon is 
propagated to all the ancestors in the tree, so that you see it even if 
its branch is not expanded).

Then the editor could have configurable parameters, maximum of files in 
memory, saved files not consulted after certain expiration could be 
closed until next request, ....

Well, just some non-polished ideas thrown to the thread.

-- fxn