unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@jurta.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Occur stack
Date: Tue, 21 Jan 2014 09:51:40 +0200	[thread overview]
Message-ID: <87lhy9zsab.fsf@mail.jurta.org> (raw)
In-Reply-To: <jwv61pghey6.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Sat, 18 Jan 2014 21:45:32 -0500")

>> 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.

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



  reply	other threads:[~2014-01-21  7:51 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-14 16:24 Occur stack Tom
2014-01-14 16:35 ` Nicolas Richard
2014-01-14 16:57   ` Tom
2014-01-14 17:00     ` Tom
2014-01-14 17:07     ` Juanma Barranquero
2014-01-14 17:12       ` Tom
2014-01-14 17:21         ` Lars Magne Ingebrigtsen
2014-01-14 20:30           ` Tom
2014-01-14 20:40             ` Tom
2014-01-14 21:08           ` Daniel Colascione
2014-01-14 21:24             ` John Yates
2014-01-14 21:32             ` Drew Adams
2014-01-14 21:26           ` Stefan Monnier
2014-01-14 17:41         ` Allen S. Rout
2014-01-15  8:27       ` Juri Linkov
2014-01-15  9:06         ` David Kastrup
2014-01-16  7:57           ` Juri Linkov
2014-01-16  8:53             ` David Kastrup
2014-01-16  9:46               ` Lars Ingebrigtsen
2014-01-16 10:36                 ` David Kastrup
2014-01-16 13:47                   ` Stefan Monnier
2014-01-16 13:54                     ` David Kastrup
2014-01-17 15:52                       ` Lars Ingebrigtsen
2014-01-15 18:52 ` Andreas Röhler
2014-01-15 20:16   ` Tom
2014-01-16 17:19     ` Tom
2014-01-17  8:24       ` Andreas Röhler
2014-01-17 13:24         ` Tom
2014-01-19 14:50           ` Andreas Röhler
2014-01-19 16:03             ` Tom
2014-01-17 17:19         ` Tom
2014-01-18 17:01           ` Tom
2014-01-19  2:39             ` Stefan Monnier
2014-01-19  6:40               ` Tom
2014-01-19  7:12                 ` Daniel Colascione
2014-01-19 14:38                 ` Stefan Monnier
2014-01-19 15:56                   ` Tom
2014-01-18 17:04           ` Lars Ingebrigtsen
2014-01-19  2:45             ` Stefan Monnier
2014-01-21  7:51               ` Juri Linkov [this message]
2014-01-21  9:05                 ` joakim
2014-01-22  8:03                   ` Juri Linkov
2014-01-21 19:42               ` Lars Ingebrigtsen
2014-01-22  1:27                 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lhy9zsab.fsf@mail.jurta.org \
    --to=juri@jurta.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).