Masatake YAMATO <[EMAIL PROTECTED]> writes: > Xtla creates too many buffers.
True. > And there is no way to go back buffers. Not so true. > e.g. > Typing c in *tla-inventory*, and ++log buffer opens. > Then typing C-cC-c in ++log after writing logs, and *tla-process* buffer and > tips buffer open. There is no way to go back the original > *tla-inventory*. With my configuration, pressing `q' in *tla-process* kills this buffer and goes back to the inventory buffer. The ideal behavior would be to (set-window-configuration tla-precommit-window-configuration) or something like that. Shouldn't be too hard to implement. > Normally, I guess the user wants to type < in *tla-inventory* to sync the > mirror > just after committing with C-cC-c. This is much better done in ~/.arch-params/hook > The good solution provides the generic `go-back' function in all > xtla buffers. Perhaps what I describe above could be generalized to all other functions (in each tla process buffer, have a local variable that is the window configuration at the time of launching the process, and `q' would return to that configuration). Having many buffers is not the problem. Gnus opens a lot of buffers also, they just don't disturb me because they're well organized. > (I think ?h(home) is a good keybind for the function.) However, I > don't have time to implement. I may do this tonight. > How about next function? > > (defun tla-tips-popup-number (number) > (tla--message-with-rolling "***Tips*** %s " > (replace-in-string > (tla-tips-message-number number) > "\n" " " ))) I have no objection to provide this as a default, but personnaly, I find `tla--message-with-rolling' very hard to read, so, it's OK for very occasionnal message (very nice for the current usage, IMHO), but I would desactivate it for the tips. Also keep in mind that the number of tips is finite, so, users will want to disable it after some time. -- Matthieu
