Masatake YAMATO <[EMAIL PROTECTED]> writes: > I have some comments about tla--dead-process-buffer-queue. > >> (kill-buffer (car tla--dead-process-buffer-queue)) > > I think this is a bit danger. > > How do you think introduce "*tla-trash*"?
This is exactly the purpose of tla--dead-process-buffer-queue ! That's a list of buffers that could have been killed already, but that we keep "just in case". Well, actually there's an implicit constraint here: tla-number-of-dead-process-buffer must be >= 2. This should be hardcoded somewhere. With that constraint, you have the guarantee that a process buffer will not be killed immediately. > *tla-trash* will become too long, however better than be lost, > especially for debugging. If you don't want to loose anything, you can set tla-number-of-dead-process-buffer to a very large number. We could also manage the value nil to mean "never kill the buffer". But your suggestion is a trash-inside-the-trash, I don't think it's usefull. Update: My last patch implements the two previous suggestions :-) > Now the queue is managed by the length. > How do you think use timer instead of timer? More complex to implement for a little benefit only, but no objection if you want to implement it. > The last is question. > As far as reading xtla-core.el, there is no relationship between the > buffer management codes and the process management codes. e.g. > buffers created by tla--new-process-buffer and tla--new-error-buffer > are not managed by tla--buffers-tree. Exact. Process buffers are killed after some time. tla--buffer-tree is for user buffers that are never killed automatically. > We need a kind of C-x C-b for xtla related buffers. > Masatake We actually need 2: One to navigate between process buffers, targetted to developpers, and another to navigate between process buffers. The last one could be displayed in the form of a tree ... with tla-browe ! -- Matthieu
