* Occur stack @ 2014-01-14 16:24 Tom 2014-01-14 16:35 ` Nicolas Richard 2014-01-15 18:52 ` Andreas Röhler 0 siblings, 2 replies; 44+ messages in thread From: Tom @ 2014-01-14 16:24 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 16:24 Occur stack Tom @ 2014-01-14 16:35 ` Nicolas Richard 2014-01-14 16:57 ` Tom 2014-01-15 18:52 ` Andreas Röhler 1 sibling, 1 reply; 44+ messages in thread From: Nicolas Richard @ 2014-01-14 16:35 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 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 0 siblings, 2 replies; 44+ messages in thread From: Tom @ 2014-01-14 16:57 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 16:57 ` Tom @ 2014-01-14 17:00 ` Tom 2014-01-14 17:07 ` Juanma Barranquero 1 sibling, 0 replies; 44+ messages in thread From: Tom @ 2014-01-14 17:00 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 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-15 8:27 ` Juri Linkov 1 sibling, 2 replies; 44+ messages in thread From: Juanma Barranquero @ 2014-01-14 17:07 UTC (permalink / raw) To: Tom; +Cc: Emacs developers 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) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 17:07 ` Juanma Barranquero @ 2014-01-14 17:12 ` Tom 2014-01-14 17:21 ` Lars Magne Ingebrigtsen 2014-01-14 17:41 ` Allen S. Rout 2014-01-15 8:27 ` Juri Linkov 1 sibling, 2 replies; 44+ messages in thread From: Tom @ 2014-01-14 17:12 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 17:12 ` Tom @ 2014-01-14 17:21 ` Lars Magne Ingebrigtsen 2014-01-14 20:30 ` Tom ` (2 more replies) 2014-01-14 17:41 ` Allen S. Rout 1 sibling, 3 replies; 44+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-01-14 17:21 UTC (permalink / raw) To: Tom; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 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:26 ` Stefan Monnier 2 siblings, 1 reply; 44+ messages in thread From: Tom @ 2014-01-14 20:30 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 20:30 ` Tom @ 2014-01-14 20:40 ` Tom 0 siblings, 0 replies; 44+ messages in thread From: Tom @ 2014-01-14 20:40 UTC (permalink / raw) To: emacs-devel Tom <adatgyujto <at> gmail.com> writes: > Such as occur, diff and there are surely other examples. grep, find ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 17:21 ` Lars Magne Ingebrigtsen 2014-01-14 20:30 ` 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 2 siblings, 2 replies; 44+ messages in thread From: Daniel Colascione @ 2014-01-14 21:08 UTC (permalink / raw) To: Lars Magne Ingebrigtsen, Tom; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 21:08 ` Daniel Colascione @ 2014-01-14 21:24 ` John Yates 2014-01-14 21:32 ` Drew Adams 1 sibling, 0 replies; 44+ messages in thread From: John Yates @ 2014-01-14 21:24 UTC (permalink / raw) To: Daniel Colascione; +Cc: Lars Magne Ingebrigtsen, Tom, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: Occur stack 2014-01-14 21:08 ` Daniel Colascione 2014-01-14 21:24 ` John Yates @ 2014-01-14 21:32 ` Drew Adams 1 sibling, 0 replies; 44+ messages in thread From: Drew Adams @ 2014-01-14 21:32 UTC (permalink / raw) To: Daniel Colascione, Lars Magne Ingebrigtsen, Tom; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 17:21 ` Lars Magne Ingebrigtsen 2014-01-14 20:30 ` Tom 2014-01-14 21:08 ` Daniel Colascione @ 2014-01-14 21:26 ` Stefan Monnier 2 siblings, 0 replies; 44+ messages in thread From: Stefan Monnier @ 2014-01-14 21:26 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: Tom, emacs-devel > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 17:12 ` Tom 2014-01-14 17:21 ` Lars Magne Ingebrigtsen @ 2014-01-14 17:41 ` Allen S. Rout 1 sibling, 0 replies; 44+ messages in thread From: Allen S. Rout @ 2014-01-14 17:41 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 17:07 ` Juanma Barranquero 2014-01-14 17:12 ` Tom @ 2014-01-15 8:27 ` Juri Linkov 2014-01-15 9:06 ` David Kastrup 1 sibling, 1 reply; 44+ messages in thread From: Juri Linkov @ 2014-01-15 8:27 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Tom, Emacs developers >> 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-15 8:27 ` Juri Linkov @ 2014-01-15 9:06 ` David Kastrup 2014-01-16 7:57 ` Juri Linkov 0 siblings, 1 reply; 44+ messages in thread From: David Kastrup @ 2014-01-15 9:06 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-15 9:06 ` David Kastrup @ 2014-01-16 7:57 ` Juri Linkov 2014-01-16 8:53 ` David Kastrup 0 siblings, 1 reply; 44+ messages in thread From: Juri Linkov @ 2014-01-16 7:57 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-16 7:57 ` Juri Linkov @ 2014-01-16 8:53 ` David Kastrup 2014-01-16 9:46 ` Lars Ingebrigtsen 0 siblings, 1 reply; 44+ messages in thread From: David Kastrup @ 2014-01-16 8:53 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-16 8:53 ` David Kastrup @ 2014-01-16 9:46 ` Lars Ingebrigtsen 2014-01-16 10:36 ` David Kastrup 0 siblings, 1 reply; 44+ messages in thread From: Lars Ingebrigtsen @ 2014-01-16 9:46 UTC (permalink / raw) To: emacs-devel 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/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-16 9:46 ` Lars Ingebrigtsen @ 2014-01-16 10:36 ` David Kastrup 2014-01-16 13:47 ` Stefan Monnier 0 siblings, 1 reply; 44+ messages in thread From: David Kastrup @ 2014-01-16 10:36 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-16 10:36 ` David Kastrup @ 2014-01-16 13:47 ` Stefan Monnier 2014-01-16 13:54 ` David Kastrup 0 siblings, 1 reply; 44+ messages in thread From: Stefan Monnier @ 2014-01-16 13:47 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-16 13:47 ` Stefan Monnier @ 2014-01-16 13:54 ` David Kastrup 2014-01-17 15:52 ` Lars Ingebrigtsen 0 siblings, 1 reply; 44+ messages in thread From: David Kastrup @ 2014-01-16 13:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-16 13:54 ` David Kastrup @ 2014-01-17 15:52 ` Lars Ingebrigtsen 0 siblings, 0 replies; 44+ messages in thread From: Lars Ingebrigtsen @ 2014-01-17 15:52 UTC (permalink / raw) To: emacs-devel 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/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-14 16:24 Occur stack Tom 2014-01-14 16:35 ` Nicolas Richard @ 2014-01-15 18:52 ` Andreas Röhler 2014-01-15 20:16 ` Tom 1 sibling, 1 reply; 44+ messages in thread From: Andreas Röhler @ 2014-01-15 18:52 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-15 18:52 ` Andreas Röhler @ 2014-01-15 20:16 ` Tom 2014-01-16 17:19 ` Tom 0 siblings, 1 reply; 44+ messages in thread From: Tom @ 2014-01-15 20:16 UTC (permalink / raw) To: emacs-devel 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)))) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-15 20:16 ` Tom @ 2014-01-16 17:19 ` Tom 2014-01-17 8:24 ` Andreas Röhler 0 siblings, 1 reply; 44+ messages in thread From: Tom @ 2014-01-16 17:19 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-16 17:19 ` Tom @ 2014-01-17 8:24 ` Andreas Röhler 2014-01-17 13:24 ` Tom 2014-01-17 17:19 ` Tom 0 siblings, 2 replies; 44+ messages in thread From: Andreas Röhler @ 2014-01-17 8:24 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-17 8:24 ` Andreas Röhler @ 2014-01-17 13:24 ` Tom 2014-01-19 14:50 ` Andreas Röhler 2014-01-17 17:19 ` Tom 1 sibling, 1 reply; 44+ messages in thread From: Tom @ 2014-01-17 13:24 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-17 13:24 ` Tom @ 2014-01-19 14:50 ` Andreas Röhler 2014-01-19 16:03 ` Tom 0 siblings, 1 reply; 44+ messages in thread From: Andreas Röhler @ 2014-01-19 14:50 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-19 14:50 ` Andreas Röhler @ 2014-01-19 16:03 ` Tom 0 siblings, 0 replies; 44+ messages in thread From: Tom @ 2014-01-19 16:03 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-17 8:24 ` Andreas Röhler 2014-01-17 13:24 ` Tom @ 2014-01-17 17:19 ` Tom 2014-01-18 17:01 ` Tom 2014-01-18 17:04 ` Lars Ingebrigtsen 1 sibling, 2 replies; 44+ messages in thread From: Tom @ 2014-01-17 17:19 UTC (permalink / raw) To: emacs-devel 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) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-17 17:19 ` Tom @ 2014-01-18 17:01 ` Tom 2014-01-19 2:39 ` Stefan Monnier 2014-01-18 17:04 ` Lars Ingebrigtsen 1 sibling, 1 reply; 44+ messages in thread From: Tom @ 2014-01-18 17:01 UTC (permalink / raw) To: emacs-devel 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) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-18 17:01 ` Tom @ 2014-01-19 2:39 ` Stefan Monnier 2014-01-19 6:40 ` Tom 0 siblings, 1 reply; 44+ messages in thread From: Stefan Monnier @ 2014-01-19 2:39 UTC (permalink / raw) To: Tom; +Cc: emacs-devel > (eval `(let ((dir default-directory) > (args command-args)) > (lambda () > (let ((default-directory dir)) > (grep-find args)))) > t)))) Yuck! Stefan ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 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 0 siblings, 2 replies; 44+ messages in thread From: Tom @ 2014-01-19 6:40 UTC (permalink / raw) To: emacs-devel 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)))) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-19 6:40 ` Tom @ 2014-01-19 7:12 ` Daniel Colascione 2014-01-19 14:38 ` Stefan Monnier 1 sibling, 0 replies; 44+ messages in thread From: Daniel Colascione @ 2014-01-19 7:12 UTC (permalink / raw) To: Tom, emacs-devel 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)))) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 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 1 sibling, 1 reply; 44+ messages in thread From: Stefan Monnier @ 2014-01-19 14:38 UTC (permalink / raw) To: Tom; +Cc: emacs-devel > This is the first time I used closures, so it may be crude. The yucky part is the use of "eval". Stefan ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-19 14:38 ` Stefan Monnier @ 2014-01-19 15:56 ` Tom 0 siblings, 0 replies; 44+ messages in thread From: Tom @ 2014-01-19 15:56 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-17 17:19 ` Tom 2014-01-18 17:01 ` Tom @ 2014-01-18 17:04 ` Lars Ingebrigtsen 2014-01-19 2:45 ` Stefan Monnier 1 sibling, 1 reply; 44+ messages in thread From: Lars Ingebrigtsen @ 2014-01-18 17:04 UTC (permalink / raw) To: emacs-devel 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/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-18 17:04 ` Lars Ingebrigtsen @ 2014-01-19 2:45 ` Stefan Monnier 2014-01-21 7:51 ` Juri Linkov 2014-01-21 19:42 ` Lars Ingebrigtsen 0 siblings, 2 replies; 44+ messages in thread From: Stefan Monnier @ 2014-01-19 2:45 UTC (permalink / raw) To: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-19 2:45 ` Stefan Monnier @ 2014-01-21 7:51 ` Juri Linkov 2014-01-21 9:05 ` joakim 2014-01-21 19:42 ` Lars Ingebrigtsen 1 sibling, 1 reply; 44+ messages in thread From: Juri Linkov @ 2014-01-21 7:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-21 7:51 ` Juri Linkov @ 2014-01-21 9:05 ` joakim 2014-01-22 8:03 ` Juri Linkov 0 siblings, 1 reply; 44+ messages in thread From: joakim @ 2014-01-21 9:05 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-21 9:05 ` joakim @ 2014-01-22 8:03 ` Juri Linkov 0 siblings, 0 replies; 44+ messages in thread From: Juri Linkov @ 2014-01-22 8:03 UTC (permalink / raw) To: joakim; +Cc: Stefan Monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-19 2:45 ` Stefan Monnier 2014-01-21 7:51 ` Juri Linkov @ 2014-01-21 19:42 ` Lars Ingebrigtsen 2014-01-22 1:27 ` Stefan Monnier 1 sibling, 1 reply; 44+ messages in thread From: Lars Ingebrigtsen @ 2014-01-21 19:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Occur stack 2014-01-21 19:42 ` Lars Ingebrigtsen @ 2014-01-22 1:27 ` Stefan Monnier 0 siblings, 0 replies; 44+ messages in thread From: Stefan Monnier @ 2014-01-22 1:27 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2014-01-22 8:03 UTC | newest] Thread overview: 44+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.