Re: Re: [nbdev] Too many editor tabs?

On Mar 20, 2006, at 6:16 PM, Ivan Soleimanipour wrote:

> If 'vi' manged w/o the concept how can it be a "key" part of the  
> user model?

I don't think it managed w/o the concept -- try ":help buffers" in vim.

By the way here's the vim definition of buffers:

"A buffer is a file loaded into memory for editing.  The original  
file remains
unchanged until you write the buffer to the file."

>
> I suppose as long as one needs to write out a file there is an  
> implicit
> notion of buffer but it was never made first class in vi.
> Once you do make it a first class notion, like in emcas then all
> kinds of unnatural stuff happens.

I don't have an original vi to try here, since on this OS vi maps to  
vim, but is it true that the original vi only supports a single open  
file? If not, it must support having edited files in memory. These  
are not identical to the disk version. That's what I'm calling a  
buffer, and it seems like a useful concept.

> For example,
>
> When I speak of the LRU list it's not the LRU list of "buffers" but
> the LRU list of "files I've edited" ... it includes files that
> have been saved and files that no-longer have a buffer associated with
> them.

I think having a recently open files menu, like the recently open  
projects menu, would be useful. This sounds a lot like the WorkShop  
picklist. I haven't actually missed it all that much, but I can see  
how it would be handy to have it for the occasional "take me back to  
foo.xml even though I just closed it."

I don't think this invalidates the buffer concept - I believe it's  
still there.

-- Tor