Re: Too many editor tabs?

> Date: Tue, 21 Mar 2006 10:40:42 +0200
> From: David Strupl <[email protected]>
> To: [email protected]
> Subject: Re: [nbui] Too many editor tabs?
> 
> I am quite strongly for the "history browsing
> GUI element" instead of "history browsing action". The action will be 
> never discovered by the user. We need some visual element - but this is 
> just IMHO.

I vote for this too.
    I've noticed thaht many NB developers mostly interact through the 
    keyboard only while I like pushing buttons and using menus. And
    I find the purely GUI interaction lacking. I don't think I'm 
    alone in this.
So a menu pulldown would be my preference.    

Marians proposal seems a lot like mine :-) with the main difference
being that I prefer a pulldown menu while he has a GUI list.

    The problem with the list is that you have to _scroll_ both
    horizontally and vertically and that's evil. A pulldown menu can
    accomodate width, and doesn't require vertical scrolling. It
    can align the names so that filename beginnigs are lined up:
    
    	          /export/home/ivan/project/a/t.c
    	                       /home/ivan/ref/g.h
    	                       /home/ivan/ref/kobbla.h
    	/export/home/ivan/project/a/subz/suby/quamali.c
    	
    You get a strong vertival line allowing you to zero in and
    quickly patternmatch on the filename.

> 
> I like the tabs idea (hmm, I have proposed it ;-) ) but if it is only 
> pop down (or pop up) somewhere it might be enough.
> 
> But I insist on debugger, search results and Ctrl-Click (and maybe some 
> other actions) opening the files in this temp area not to clutter the 
> "really" opened files area that we have on the top.

I think the boundry between "real/permanent" and "temp" is way
too fuzzy such that creating distinct concepts will add to the confusion.

For example ... to place a breakpoint you have to open a file. Is this
a permanent file or a temporary "debugger" file that gets closed when
the debug run is over?

As another example ... the standard _IDE_ model of debugging is such
that there is no debugger or debugging session. You place
bpts at any time and then "Start under debugger". The lifetime of
the debugging "mode" corresponds to the lifetime of the program being run.

start IDE ------ run for debug ================ done debugging --- done w/ IDE
            ^                                                   |
            |                                                   |
            +---------------------------------------------------+
            
Another model is that you decide to debug something (load a program, 
or designate a debugge) and then repeatedly run it. Here you
have a bona-fide debug session with which you can associate a cache
and other settings. 


start IDE ------ load for debug ==== run ====== done debugging --- done w/ IDE
            ^                     ^         |                   |
            |                     +---------+                   |
            +---------------------------------------------------+
            

Now consider ... if you're going to associate opened files with a debugger.
In the standard IDE model (the first one) everytime your process stops
what's going to happen? you're going to close all "debugger" files?
Only to want to reopen them when you rerun for debugging again?

So Romans (MArtins?) IZ 35586 talks about "temporary" but temporary with
respect to what?