emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Occur stack


From: joakim
Subject: Re: Occur stack
Date: Tue, 21 Jan 2014 10:05:51 +0100
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

Juri Linkov <address@hidden> writes:

>>> Storing the command, too, is also nice, because then we can re-run the
>>> command with the `g' command.
>>
>> Yes, I like that too.  I actually want to move in that direction,
>> defining a way for a major mode to advertise how to rebuild the
>> "same" buffer.  Then special-mode could set revert-buffer-function to
>> a new function which would use this info, and bookmark.el could also use
>> that info.
>
> And in desktop.el it would be nice as well to save/restore
> non-persistent buffers like *Help*, *Occur*...
>
>>> However, re-running an external command will not, in general, give us
>>> the same buffer we had before.  Things change, and re-running (say) grep
>>> half an hour later might very well give us a different buffer than what
>>> we expected (because files have changed, etc).
>>
>> Indeed, that's a downside.  In the case of eww, for example, I find it
>> very important to be able to go back to a previous page's content
>> without re-contacting the web-server.  This would probably be true also
>> in some other cases, such as *vc-diff*.
>
> When I forget to rename-uniquely *vc-diff* and it gets overwritten
> by new content, I'm trying to do `undo' to restore it to the
> previous state.  If it's possible to combine the proposed feature
> of using strings with undo information, it could help to navigate
> the history of previous content of the buffer.
>
>>> Having a history that presents us with ever-changing output doesn't seem
>>> optimal.
>>
>> I think sometimes we want one and sometimes we want the other.  Not sure
>> how to reconcile this without exposing this choice to the user in an
>> annoying way.
>
> It seems there are three possible separate features
> and any combination of them can be used at the same time:
>
> 1. Rename uniquely each buffer whose content is going to be overwritten,
>    e.g. creating buffers like *Help: car*, *Help: cdr*, ...
>    This is useful, but should not be the default.
>
> 2. Keep previous content in buffer-local strings (like eww does).
>    Useful when auto-renaming buffers will produce too many buffers.

It seems to me that we could work on making it more convenient with many
buffers. There is already a mechanism to hide buffers, by having an
inital space in the name. Intuitively the overhead of many buffers is
not much more than the overhead of string storage.

At any rate, this is how I manage this problem locally at the moment. I
just rename grep buffers I want to remember.

> 3. Set a function to regenerate content (like *Help* currently does).
>    Useful for bookmarks, desktop.

This is also useful. I suppose I just wanted to say that I agree with
you, but perhaps the many buffers approach shouldnt necessarily be the
least attractive option.

-- 
Joakim Verona



reply via email to

[Prev in Thread] Current Thread [Next in Thread]