Occur stack

Occur stack

[Tom]

It often happens to me that I run an occur and when perusing
the results I need to do an other occur to follow up on some
of the matches. The problem is the second occurs clears out the
results of the first one, so I have to run that occur again.

It occurred to me it would be nice if occur had a history, a stack,
so that if I do an other occur then the previous results are stored
somewhere and I can go back to them after I finished processing
the latest occur results.

Re: Occur stack

[Nicolas Richard]

Tom <adatgyujto@gmail.com> writes:

> It often happens to me that I run an occur and when perusing
> the results I need to do an other occur to follow up on some
> of the matches. The problem is the second occurs clears out the
> results of the first one, so I have to run that occur again.

With M-x rename-buffer you can keep the *Occur* buffer around. Would
that be sufficient for your needs ?

-- 
Nico.

Re: Occur stack

[Tom]

Nicolas Richard <theonewiththeevillook <at> yahoo.fr> writes:
> 
> With M-x rename-buffer you can keep the *Occur* buffer around. Would
> that be sufficient for your needs ?
> 

Yes, I can do this manually if I remember to do it, but it would be nice
to have something like this builtin. It seems useful to me to navigate
occur result buffers back/forward like one does with a browser's
back/forward buttons.

Re: Occur stack

[Tom]

Tom <adatgyujto <at> gmail.com> writes:
> 
> Yes, I can do this manually if I remember to do it, but it would be nice
> to have something like this builtin. It seems useful to me to navigate
> occur result buffers back/forward like one does with a browser's
> back/forward buttons.
> 

So Occur could have a history not just for its inputs, but also for its
results.

Re: Occur stack

[Juanma Barranquero]

On Tue, Jan 14, 2014 at 5:57 PM, Tom <adatgyujto@gmail.com> wrote:

> Yes, I can do this manually if I remember to do it,

No need to do it by hand:

(add-hook 'occur-hook 'rename-uniquely)

Re: Occur stack

[Tom]

Juanma Barranquero <lekktu <at> gmail.com> writes:

> 
> On Tue, Jan 14, 2014 at 5:57 PM, Tom <adatgyujto <at> gmail.com> wrote:
> 
> > Yes, I can do this manually if I remember to do it,
> 
> No need to do it by hand:
> 
> (add-hook 'occur-hook 'rename-uniquely)

Of course, but it results in a proliferation of occur buffers. 
It would be nicer to have a single occur buffer where I could 
go back to previous results. 

Re: Occur stack

[Lars Magne Ingebrigtsen]

Tom <adatgyujto@gmail.com> writes:

> Of course, but it results in a proliferation of occur buffers. 
> It would be nicer to have a single occur buffer where I could 
> go back to previous results. 

Yeah.  Perhaps there should be a semi-general "buffer history"
functionality for these sorts of buffers?  eww has its own history, and
that's just a buffer-local variable that has a list of buffer
contents/points/etc, along with some history traversal commands.

I think that could be generalised to other modes that have similar
"remove everything in the buffer and display new data" ways of working.
Some modes might need more "restoring" code, though, so it should be
customisable by each mode...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Occur stack

[Allen S. Rout]

On 01/14/2014 12:12 PM, Tom wrote:
> Juanma Barranquero <lekktu <at> gmail.com> writes:
> 
>>
>> On Tue, Jan 14, 2014 at 5:57 PM, Tom <adatgyujto <at> gmail.com> wrote:
>>
>>> Yes, I can do this manually if I remember to do it,
>>
>> No need to do it by hand:
>>
>> (add-hook 'occur-hook 'rename-uniquely)
> 
> Of course, but it results in a proliferation of occur buffers. 
> It would be nicer to have a single occur buffer where I could 
> go back to previous results. 
> 

Instead of renaming uniquely, you could copy contents to a uniquely
named buffer.  There's a thread which discusses unique but topical
occurs buffers from 2005;  might help your code.

http://comments.gmane.org/gmane.emacs.devel/40135


- Allen S. Rout

Re: Occur stack

[Tom]

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> I think that could be generalised to other modes that have similar
> "remove everything in the buffer and display new data" ways of working.

Nice idea. 

Another example which occurs to me is diff. It happens to me that
I diff two files, check the diff, do something else then diff two 
other files and then I need to check something with the first diff
again. In this case I rerun the diff, but I could simply go 
back in the diff buffer's history with this feature.

As you say this buffer history could be generic feature for commands
which reuse the same buffer to display daya. Such as occur, diff 
and there are  surely other examples.

Re: Occur stack

[Tom]

Tom <adatgyujto <at> gmail.com> writes:
> Such as occur, diff and there are  surely other examples.

grep, find

Re: Occur stack

[Daniel Colascione]

On 01/14/2014 09:21 AM, Lars Magne Ingebrigtsen wrote:
> Tom <adatgyujto@gmail.com> writes:
>
>> Of course, but it results in a proliferation of occur buffers.
>> It would be nicer to have a single occur buffer where I could
>> go back to previous results.
>
> Yeah.  Perhaps there should be a semi-general "buffer history"
> functionality for these sorts of buffers?  eww has its own history, and
> that's just a buffer-local variable that has a list of buffer
> contents/points/etc, along with some history traversal commands.
>
> I think that could be generalised to other modes that have similar
> "remove everything in the buffer and display new data" ways of working.
> Some modes might need more "restoring" code, though, so it should be
> customisable by each mode...

I'd also like some way of better managing dired buffers. Every time I 
try to use dired intensively instead of the shell, I end up with dozens 
of dired buffers laying around. I'd prefer everything to happen in a 
single dired buffer unless I explicitly "fork" my dired history. IOW, 
navigation in dired buffers, and eww buffers, and occur buffers, should 
work exactly like web browser pages with an "open in new tab" option.

Re: Occur stack

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

On Tue, Jan 14, 2014 at 4:08 PM, Daniel Colascione <dancol@dancol.org>wrote:
>
> IOW, navigation in dired buffers, and eww buffers, and occur buffers,
> should work exactly like web browser pages with an "open in new tab" option.
>

I would also like a back-in-other-window.  Or even better: detach
current-buffer from history, display it in other-window and expose contents
of preceding history entry in current-window.

/john

[-- Attachment #2: Type: text/html, Size: 774 bytes --]

Re: Occur stack

[Stefan Monnier]

> I think that could be generalised to other modes that have similar
> "remove everything in the buffer and display new data" ways of working.

Like *Help*, indeed.


        Stefan

RE: Occur stack

[Drew Adams]

> I'd also like some way of better managing dired buffers. Every time
> I try to use dired intensively instead of the shell, I end up with
> dozens of dired buffers laying around. I'd prefer everything to happen
> in a single dired buffer unless I explicitly "fork" my dired history.
> IOW, navigation in dired buffers, and eww buffers, and occur buffers,
> should work exactly like web browser pages with an "open in new tab"
> option.

You can of course use `C-x C-v' to change directories without multiplying
buffers.

Being able to not multiply Dired buffers seems to be a pretty common
request (not necessarily on emacs-devel, but in general).

For that, Dired+ offers command `diredp-toggle-find-file-reuse-dir'. 
It toggles whether Dired `find-file' commands, such as `dired-find-file',
reuse directories.  A negative prefix arg means do not reuse buffers; a
non-negative prefix arg means reuse.

For reusing, this essentially substitutes `find-alternate-file' for
`find-file' whenever the argument is a directory.

http://www.emacswiki.org/DiredPlus

Re: Occur stack

[Juri Linkov]

>> Yes, I can do this manually if I remember to do it,
>
> No need to do it by hand:
>
> (add-hook 'occur-hook 'rename-uniquely)

Or (add-hook 'occur-hook (lambda () (occur-rename-buffer t)))

In addition, for more convenience of switching related buffers
we could group occur buffers in the window-local tab-bar,
so it will display the history of *Occur* buffers.
In *Help* it could display the history of help topics,
in Dired the history of directories visited with `a'
(dired-find-alternate-file), etc.

Re: Occur stack

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>>> Yes, I can do this manually if I remember to do it,
>>
>> No need to do it by hand:
>>
>> (add-hook 'occur-hook 'rename-uniquely)
>
> Or (add-hook 'occur-hook (lambda () (occur-rename-buffer t)))
>
> In addition, for more convenience of switching related buffers
> we could group occur buffers in the window-local tab-bar,
> so it will display the history of *Occur* buffers.
> In *Help* it could display the history of help topics,
> in Dired the history of directories visited with `a'
> (dired-find-alternate-file), etc.

For things like an occur or grep buffer, I don't think it is necessary
to keep the actual contents around.  They can be regenerated from
scratch fast enough, so just keeping the history and possibly a somewhat
robust cursor location should be enough.  It becomes trickier with stuff
like grep-find which may run for a while.  Still, having the command
history to some depth available conveniently is cheap and useful,
certainly much cheaper than keeping the buffers.

-- 
David Kastrup

Re: Occur stack

[Andreas Röhler]

Am 14.01.2014 17:24, schrieb Tom:
> It often happens to me that I run an occur and when perusing
> the results I need to do an other occur to follow up on some
> of the matches. The problem is the second occurs clears out the
> results of the first one, so I have to run that occur again.
>
> It occurred to me it would be nice if occur had a history, a stack,
> so that if I do an other occur then the previous results are stored
> somewhere and I can go back to them after I finished processing
> the latest occur results.
>
>
>

Being able to jump back or read occur-history like M-x browse-kill-ring would be great.

Andreas

Re: Occur stack

[Tom]

Andreas Röhler <andreas.roehler <at> online.de> writes:
> 
> Being able to jump back or read occur-history like 
> M-x browse-kill-ring would be great.
> 

I created a simple proof of concept implementation, so it can
be tested in practice.

It can be activated by adding this to the occur hook and then
it saves the last 10 occur results:

(add-hook 'occur-hook 'buffer-history-save)


If you do some occuring and then run M-x buffer-history-list
in the occur buffer then it lists the stored occur sessions
and you can press RET on any of them to restore it in 
the occur buffer.

The code is generic, so in theory it can work for other
commands too, but I only tested it with occur.


Note that it's a very simple implementation, it only restores
the stored contents in the occur buffer, so it requires 
a live occur buffer. For this reason it begins with an occur
advice which prevents occur from killing the occur buffer
if there are no matches.


Here's the code: 



;; this is needed to prevent occur from killing the buffer
;; when there are no matches
(defadvice occur (around my-occur-advice activate)
  (flet ((kill-buffer (buf)
                      (bury-buffer buf)))
    ad-do-it))


(setq buffer-history nil)


(defun buffer-history-save ()
  (let ((entry (assoc major-mode buffer-history)))
    (unless entry
      (setq entry (cons major-mode '()))
      (push entry buffer-history))
    (push (buffer-substring (point-min) (point-max))
          (cdr entry))
    (if (> (length (cdr entry)) 10)
        (setcdr entry (butlast (cdr entry))))))


(setq buffer-history-target-buffer nil)

(defun buffer-history-list ()
  (interactive)
  (let ((entry (assoc major-mode buffer-history)))
    (unless entry
      (error "No buffer history here."))

    (setq buffer-history-target-buffer (current-buffer))

    (pop-to-buffer "*buffer history*")
    (let ((inhibit-read-only t))
      (erase-buffer))

    (dolist (item (cdr entry))
      ;; assuming the first line describes the contents
      (assert (string-match ".*?\n" item))
      (let ((start (point)))
        (let ((line (match-string 0 item)))
          (set-text-properties 0 (length line) nil line)
          (insert line))
        (put-text-property
         start (1+ start)
         'buffer-history-contents item)))

    (goto-char (point-min))
    (local-set-key (kbd "RET") 'buffer-history-restore)))


(defun buffer-history-restore ()
  (interactive)
  (let ((contents (get-text-property (line-beginning-position)
                                     'buffer-history-contents)))
    (pop-to-buffer buffer-history-target-buffer)
    (let ((inhibit-read-only t))
      (erase-buffer)
      (insert contents))
    (goto-char (point-min))))

Re: Occur stack

[Juri Linkov]

> For things like an occur or grep buffer, I don't think it is necessary
> to keep the actual contents around.  They can be regenerated from
> scratch fast enough, so just keeping the history and possibly a somewhat
> robust cursor location should be enough.  It becomes trickier with stuff
> like grep-find which may run for a while.  Still, having the command
> history to some depth available conveniently is cheap and useful,
> certainly much cheaper than keeping the buffers.

After editing an occur or grep buffer (e.g. removing unnecessary lines
with `flush-lines' or adding more highlighting with `highlight-regexp')
all such changes will be gone.

Re: Occur stack

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> For things like an occur or grep buffer, I don't think it is necessary
>> to keep the actual contents around.  They can be regenerated from
>> scratch fast enough, so just keeping the history and possibly a somewhat
>> robust cursor location should be enough.  It becomes trickier with stuff
>> like grep-find which may run for a while.  Still, having the command
>> history to some depth available conveniently is cheap and useful,
>> certainly much cheaper than keeping the buffers.
>
> After editing an occur or grep buffer (e.g. removing unnecessary lines
> with `flush-lines' or adding more highlighting with `highlight-regexp')
> all such changes will be gone.

Sure, as will changes due to editing the actual files or buffers.  Of
course, editing occur/grep buffers necessitates toggling the read-only
flag so its presence/absence can be taken as an indicator for the
preciousness of such a buffer.  And of course, you can always
rename-uniquely to save a buffer.

My point, namely that an easibly accessible history regenerated
transparently is much cheaper than buffers to keep around.

-- 
David Kastrup

Re: Occur stack

[Lars Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

> My point, namely that an easibly accessible history regenerated
> transparently is much cheaper than buffers to keep around.

I doubt that's correct.  Putting the text of the buffer into a string
(and recovering it) when you hit `l' is much cheaper than running
"grep".

There will be an increased memory usage, of course, but we can limit the
history depth to something reasonable.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Occur stack

[David Kastrup]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> My point, namely that an easibly accessible history regenerated
>> transparently is much cheaper than buffers to keep around.
>
> I doubt that's correct.  Putting the text of the buffer into a string
> (and recovering it) when you hit `l' is much cheaper than running
> "grep".
>
> There will be an increased memory usage, of course, but we can limit the
> history depth to something reasonable.

You are aware that you are in agreement with me?  The increased memory
usage is _exactly_ why one would have to limit the history depth "to
something reasonable".

I see no actual point moving the history into strings from buffers and
back again: easier to just keep the buffers.  Also much more transparent
to reclaim memory if you run out of it: you can find and delete large
buffers, but you won't easily figure out that some history string is
eating all your memory.

-- 
David Kastrup

Re: Occur stack

[Stefan Monnier]

> I see no actual point moving the history into strings from buffers and
> back again: easier to just keep the buffers.

The problem is that Emacs doesn't have anonymous buffers, so all those
buffers will appear in your buffer list and C-x b completion and ...
Better keep strings.


        Stefan

Re: Occur stack

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I see no actual point moving the history into strings from buffers and
>> back again: easier to just keep the buffers.
>
> The problem is that Emacs doesn't have anonymous buffers, so all those
> buffers will appear in your buffer list and C-x b completion and ...

The last time I looked, buffers with names starting with a space were
pretty discrete about that.

> Better keep strings.

If you keep large buffer contents in strings, you won't be able to
figure out where your memory went.

-- 
David Kastrup

Re: Occur stack

[Tom]

Tom <adatgyujto <at> gmail.com> writes:
> 
> The code is generic, so in theory it can work for other
> commands too, but I only tested it with occur.
> 

I tried it with grep too, specifically grep-find. You need to
add  the saving function to compilation-finish-functions:


(defun buffer-history-grep-save (buf result)
  (if (and (eq major-mode 'grep-mode)
           (equal result "finished\n"))
      (buffer-history-save)))
           
(add-hook 'compilation-finish-functions 'buffer-history-grep-save)


If you do some grepping and then run M-x buffer-history-list
in the *grep* buffer then you can see your previous greps
and you can restore them.

The listing is not as useful as with occur, because this
simple implementation only takes the first line of the
output, assuming it describes the contents which is true
for occur, but not really true for grep-find. It only gives
you the directory, so a proper implementation should be more
clever about that, it should have a way to retrieve the relevant
inputs from the target command.

Another thing is that unlike occur it does not work seamlessly
if you do grep-find in different directories, because the
results are displayed as relative file names, so default-directory
should be restored too.

A proper implementation should restore the buffer local variables too
in addition to the buffer contents.

Re: Occur stack

[Andreas Röhler]

Am 16.01.2014 18:19, schrieb Tom:
> Tom <adatgyujto <at> gmail.com> writes:
>>
>> The code is generic, so in theory it can work for other
>> commands too, but I only tested it with occur.
>>
>
> I tried it with grep too, specifically grep-find. You need to
> add  the saving function to compilation-finish-functions:
>
>
> (defun buffer-history-grep-save (buf result)
>    (if (and (eq major-mode 'grep-mode)
>             (equal result "finished\n"))
>        (buffer-history-save)))
>
> (add-hook 'compilation-finish-functions 'buffer-history-grep-save)
>
>
> If you do some grepping and then run M-x buffer-history-list
> in the *grep* buffer then you can see your previous greps
> and you can restore them.
>
> The listing is not as useful as with occur, because this
> simple implementation only takes the first line of the
> output, assuming it describes the contents which is true
> for occur, but not really true for grep-find. It only gives
> you the directory, so a proper implementation should be more
> clever about that, it should have a way to retrieve the relevant
> inputs from the target command.
>
> Another thing is that unlike occur it does not work seamlessly
> if you do grep-find in different directories, because the
> results are displayed as relative file names, so default-directory
> should be restored too.
>
> A proper implementation should restore the buffer local variables too
> in addition to the buffer contents.
>
>
>

Hi Tom,

works for me, great, thanks!

BTW needed a (require 'cl) still.

In cases where a plenty of occur-calls is done, maybe the discussion WRT to memory pertains?

Andreas

Re: Occur stack

[Tom]

Andreas Röhler <andreas.roehler <at> online.de> writes:
> 
> In cases where a plenty of occur-calls is done, maybe 
> the discussion WRT to memory pertains?

The aim of this little experimental code is only to demonstrate
how this feature could work, not to be an optimal implementation.

But it only stores the last 10 occur buffers, so memory may not
be a real concern (most occur buffers are not huge in
my experience) and if the user uses occur frequently then
every buffer is pushed out of this stored history after a while
and the garbage collector can do its job.

Re: Occur stack

[Lars Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

> If you keep large buffer contents in strings, you won't be able to
> figure out where your memory went.

If you kill the buffer where the buffer-local history is, the memory
will be reclaimed.  Having a bazillion unfindable buffers hidden doesn't
really help much with anything.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Occur stack

[Tom]

Andreas Röhler <andreas.roehler <at> online.de> writes:
> 
> In cases where a plenty of occur-calls is done, 
> maybe the discussion WRT to memory pertains?

Here's an other experimental code which does it the other way:
it does not store buffer contents, it reruns the command
instead.

This way memory is not an issue, because it only stores
a short description and a restore function, but in this case
it requires explicit support from the involved commands,
they need to supply the function for restoring the results.

(The code again is simple, so it stores the live buffer
pointers of the occur target buffers, it does not reopen 
the target buffer if it has been closed after running occur.)




(setq buffer-history nil)


(defun buffer-history-save (description restore-function)
  (let ((entry (assoc major-mode buffer-history)))
    (unless entry
      (setq entry (cons major-mode '()))
      (push entry buffer-history))
    (push (list 'description description
                'restore-function restore-function)
          (cdr entry))))


(defun buffer-history-list ()
  (interactive)
  (let ((entry (assoc major-mode buffer-history)))
    (unless entry
      (error "No buffer history here."))

    (pop-to-buffer "*buffer history*")
    (let ((inhibit-read-only t))
      (erase-buffer))

    (dolist (item (cdr entry))
      (let ((start (point)))
        (insert (plist-get item 'description) "\n")
        (put-text-property
         start (1+ start)
         'buffer-history-restore-function
         (plist-get item 'restore-function))))

    (goto-char (point-min))
    (local-set-key (kbd "RET") 'buffer-history-restore)))


(defun buffer-history-restore ()
  (interactive)
  (funcall (get-text-property (line-beginning-position)
                              'buffer-history-restore-function)))
    


(defun buffer-history-save-occur ()
  (let* ((regexp (car occur-revert-arguments))
         (buffers (car (cddr occur-revert-arguments)))
         (restore-fun 
          (cond ((eq this-command 'occur)
                 (eval `(let ((buffer (car buffers))
                              (regexp regexp))
                          (lambda ()
                            (with-current-buffer buffer
                              (occur regexp))))
                       t))

                ((eq this-command 'multi-occur)
                 (eval `(let ((buffers buffers)
                              (regexp regexp))
                          (lambda ()
                            (multi-occur buffers regexp)))
                       t)))))

    (if (not restore-fun)
        (unless (eq this-command 'buffer-history-restore)
          (message "buffer-history: unsupported occur command '%s'"
                   this-command))

      (set-text-properties 0 (length regexp) nil regexp)

      (buffer-history-save
       (format "'%s' in %s"
               regexp
               (mapconcat (lambda (buffer)
                            (buffer-name buffer))
                          buffers
                          ", "))
       restore-fun))))


(add-hook 'occur-hook 'buffer-history-save-occur)

Re: Occur stack

[Tom]

Tom <adatgyujto <at> gmail.com> writes:
> 
> Here's an other experimental code which does it the other way:
> it does not store buffer contents, it reruns the command
> instead.
> 
> This way memory is not an issue, because it only stores
> a short description and a restore function, but in this case
> it requires explicit support from the involved commands,
> they need to supply the function for restoring the results.

I added grep-find support too as a test and it was pretty
straightforward. The same method should work for grep too,
only the called function name has to be changed:


(defun buffer-history-save-grep-find ()
  (when (eq this-command 'grep-find)
    (buffer-history-save
     (format "in directory '%s': %s"
             default-directory command-args)
     (eval `(let ((dir default-directory)
                  (args command-args))
              (lambda ()
                (let ((default-directory dir))
                  (grep-find args))))
           t))))


(add-hook 'grep-mode-hook 'buffer-history-save-grep-find)

Re: Occur stack

[Lars Ingebrigtsen]

Tom <adatgyujto@gmail.com> writes:

> Here's an other experimental code which does it the other way:
> it does not store buffer contents, it reruns the command
> instead.

Storing the command, too, is also nice, because then we can re-run the
command with the `g' command.

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

Having a history that presents us with ever-changing output doesn't seem
optimal. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Occur stack

[Stefan Monnier]

>      (eval `(let ((dir default-directory)
>                   (args command-args))
>               (lambda ()
>                 (let ((default-directory dir))
>                   (grep-find args))))
>            t))))

Yuck!


        Stefan

Re: Occur stack

[Stefan Monnier]

>> Here's an other experimental code which does it the other way:
>> it does not store buffer contents, it reruns the command
>> instead.
> 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.

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

Hmm...

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


        Stefan

Re: Occur stack

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> >      (eval `(let ((dir default-directory)
> >                   (args command-args))
> >               (lambda ()
> >                 (let ((default-directory dir))
> >                   (grep-find args))))
> >            t))))
> 
> Yuck!
> 

This is the first time I used closures, so it may be crude.

Is there a simpler way to write this? First I tried to
set default-directory in the outer let, but then it had
apparently no effect on grep-find.

Hmm, I tried it again and it worked, so I must have had
some other error when I wrote this.

Is this the simplest way then? Or can it be simplified more?

     (eval `(let ((default-directory default-directory)
                  (args command-args))
              (lambda ()
                (grep-find args)))
           t))))

Re: Occur stack

[Daniel Colascione]

On 01/18/2014 10:40 PM, Tom wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>
>>>       (eval `(let ((dir default-directory)
>>>                    (args command-args))
>>>                (lambda ()
>>>                  (let ((default-directory dir))
>>>                    (grep-find args))))
>>>             t))))
>>
>> Yuck!
>>
>
> This is the first time I used closures, so it may be crude.
>
> Is there a simpler way to write this? First I tried to
> set default-directory in the outer let, but then it had
> apparently no effect on grep-find.

That's because default-directory is marked special and so we don't close 
over its value.

> Hmm, I tried it again and it worked, so I must have had
> some other error when I wrote this.
>
> Is this the simplest way then? Or can it be simplified more?
>
>       (eval `(let ((default-directory default-directory)
>                    (args command-args))
>                (lambda ()
>                  (grep-find args)))
>             t))))

What about this? (Untested.)

(let ((dd-value default-directory))
   (lamda () (let ((default-directory dd-value))
               (grep-find args))))

Re: Occur stack

[Stefan Monnier]

> This is the first time I used closures, so it may be crude.

The yucky part is the use of "eval".


        Stefan

Re: Occur stack

[Andreas Röhler]

Am 17.01.2014 14:24, schrieb Tom:
> Andreas Röhler <andreas.roehler <at> online.de> writes:
>>
>> In cases where a plenty of occur-calls is done, maybe
>> the discussion WRT to memory pertains?
>
> The aim of this little experimental code is only to demonstrate
> how this feature could work, not to be an optimal implementation.
>
> But it only stores the last 10 occur buffers, so memory may not
> be a real concern (most occur buffers are not huge in
> my experience) and if the user uses occur frequently then
> every buffer is pushed out of this stored history after a while
> and the garbage collector can do its job.
>
>
>
>

For me it's fine as is, thanks again.

WRT memory, what about checking for maximal buffer length-limit before storing - and in (seldom) cases saving instead some message like "Not stored because volume 
surpasses..."?

Andreas

Re: Occur stack

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> > This is the first time I used closures, so it may be crude.
> 
> The yucky part is the use of "eval".
> 

I see. I haven't yet read up on the full implications of turning
on lexical binding for the whole file, so I thought it was
simpler to use eval, since I needed it only for the closure.

Re: Occur stack

[Tom]

Andreas Röhler <andreas.roehler <at> online.de> writes:
> 
> WRT memory, what about checking for maximal buffer 
> length-limit before storing - and in (seldom) cases
> saving instead some message like "Not stored because volume 
> surpasses..."?

It seems to be a reasonable idea.

Undo also has such a limit and storing past buffers is also
a kind of undo, so it is similar to that.

Re: Occur stack

[Juri Linkov]

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

Re: Occur stack

[joakim]

Juri Linkov <juri@jurta.org> 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

Re: Occur stack

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

I think the way eww stores the history feels quite natural as a user.  I
can hit `l' a few times to go back (and I'm presented exactly with what
I had, and it's an instantaneous command), and then when I'm on the page
I wanted, I can hit `g' to get a refresh.

I think that model would feel natural in most of these buffers.  The
"instantaneous" bit is quite important in grep buffers, for instance,
since rerunning the command may take quite a bit of time, and you don't
want to trigger the command in the buffers you're just visiting as
you're searching for the right buffer with `l'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Occur stack

[Stefan Monnier]

> I think the way eww stores the history feels quite natural as a user.
> I can hit `l' a few times to go back (and I'm presented exactly with
> what I had, and it's an instantaneous command), and then when I'm on
> the page I wanted, I can hit `g' to get a refresh.

Indeed, that seems to combine the best of both options.


        Stefan

Re: Occur stack

[Juri Linkov]

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

More than that, I create a new buffer on all invocations of
`compile' or `grep' with

  (setq compilation-buffer-name-function
        (lambda (mode-name)
          (generate-new-buffer-name
           (concat "*" (downcase mode-name) "*"))))

and have absolutely no problems with a large number of buffers.

OTOH, I think as the default behavior this is not too nice,
so better would be to keep the previous content in strings
accessible for navigation with `l' or from the window-local tab-bar.