From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: a small remember suggestion Date: Sun, 22 Mar 2009 16:16:45 +0100 Message-ID: <6E22B50C-E9E2-4F09-96EE-19F6BE4C7ABD@uva.nl> References: <20524da70903211228o8ef4b21pc9a287ecd923383c@mail.gmail.com> <7bef1f890903211425p1b1329ebxd42b3d7c1a3a77d7@mail.gmail.com> <7bef1f890903211901g29bbc680r1547319ec608e942@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LlPPx-0005l1-5E for emacs-orgmode@gnu.org; Sun, 22 Mar 2009 11:16:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LlPPs-0005ka-Gf for emacs-orgmode@gnu.org; Sun, 22 Mar 2009 11:16:52 -0400 Received: from [199.232.76.173] (port=57695 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlPPs-0005kX-As for emacs-orgmode@gnu.org; Sun, 22 Mar 2009 11:16:48 -0400 Received: from mail-ew0-f160.google.com ([209.85.219.160]:50392) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LlPPr-0005gP-RN for emacs-orgmode@gnu.org; Sun, 22 Mar 2009 11:16:48 -0400 Received: by ewy4 with SMTP id 4so1732839ewy.42 for ; Sun, 22 Mar 2009 08:16:47 -0700 (PDT) In-Reply-To: <7bef1f890903211901g29bbc680r1547319ec608e942@mail.gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Alan E. Davis" Cc: org-mode On Mar 22, 2009, at 3:01 AM, Alan E. Davis wrote: > [I am reposting this to the list, as I'd intended. IOt turned out > I'd responded only to the OP.] > > > I posted regarding this problem in an earlier thread about losing > relatively large and complex *remember* buffers that I had forgotten > to save (C-c C-c). My usage has improved, and this has been much > less of a problem; however, after another, particularly painful > incident, I am again studying this problem. I have tested two > solutions that were presented earlier, but neither one of them > specifically solves this problem. Each of them is a workaround, and > either one is acceptable as such, but requires certain adjustments, > albeit this is only slightly annoying; I can learn to work around > them if need be. > > I may not have elucidated the problem clearly in the original > post. I use remember every day, and have at least 50 different > templates. I have gotten used to saving the notes with C-c C-c each > time; however, when I'm working late, am a bit tired, or the stress > from work has gotten to me, I might---as I did yesterday---spend a > couple of hours studying a problem and make a complex table of the > partition structure of my machine, only to realize after I had > changed buffers a couple of times, and used remember at least once > more, only to discover that the I had failed to save the *remember* > template buffer. Alas! I throw up my hands in despair, but > remembering that the digital computer, I search for a backup file. > Backups have saved me hundreds of hours, if not days, of work in the > past. Need I say more? > > The *remember* buffer is not saved or backed up in any way. The > ideal solution would be for this buffer to be automatically backed > up---to actually exist somewhere and be backed up just as a textmode > buffer is. > > Carsten earlier posted an at least partial solution to this problem. > #+BEGIN_SRC emacs-lisp > (defadvice remember-finalize (before org-save-and-detach activate) > (when buffer-file-name > (save-buffer) > (setq buffer-file-name nil))) > > (add-hook 'remember-mode-hook > (lambda () > (org-set-local 'change-major-mode-with-file-name nil) > (write-file "~/path/to/remember_backup.org") > (org-set-local 'remember-buffer (buffer-name))) > 'append) > #+END_SRC > > He said he would not include it in org-mode because one would be > "using remember out of its realm by making is a work buffer instead > of a quick capture-or-note buffer." Did I say that? :-) It turns out that I actually added the advice part, to when you assign a file name with the hook, the saving is automatic. Somehow, the current thread has changed my mind then. I have now added a variable `org-remember-backup-directory'. Set this to a directory, and every remember buffer you create will end up in a separate file, with date and time in the file name, so that you can always recover. That I actually find a lot more useful than saving to a single file name, because that would not help if you accidently call remember again.... Note that, if you use remember frequently, you will create a lot of these files. So maybe we need to think of an expiry mechanism? Like, remove any files older than a few days? - Carsten > I admit I have used a wrench as a hammer at times, to the chagrin of > the true mechanic. I have found remember a useful tool. I admit I > haven't understood its mechanism: I have even been confused by it. > I use the templates, but am still a novice: I have written fairly > complicated org-remember templates, but I still haven't gotten my > head entirely around what they can do. I have used it in whatever > manner seemed useful at the time. So it is actually helpful to see > how org-remember is intended to be used, that one should immediately > file his notes. But I have found this tool so useful (and my wrench > is always handier than my hammer!) in my own way, that I will > continue to operate in my unorthodox mode. > > All's the same, I hope a convincing argument to include this > solution. I would second the need to include a numbered backup > mechanism to cover recursive calls to org-remember. > > That being said, I have also started using "%!" in some templates. > It feels clumsy, but for the most part solves the problem, since I > seldom use the refiling options on the remember splash header. It > doesn't work as nicely with complicated templates with several > prompts, and it is capricious: for example, I don't understand how > to force the cursor to a particular position. > > This problem happens at such a low frequency, for me, that an > automatic backup mechanism would be sufficient, especially if it > recognized a second instance of the *remember* buffer. > > Something more transparent would be ideal. I'm not sure how to > organize that the *remember* buffer would automatically be saved as > a file transparently, with numbered backups for new *remember* > buffers. > > Remember rocks! > > Alan > > > > On Sun, Mar 22, 2009 at 5:28 AM, Samuel Wales > wrote: > org-remember -- use a file > > On more than one occasion, I have composed something using > org-remember, and mistakenly hit a key for killing the > buffer. With all buffers except org-remember, this kills a > buffer if it has no unsaved text, and asks what buffer to > kill if it does, at which point I quit. > > With org-remember, the buffer has unsaved text, but it is > not associated with a file, so it loses text. > > Text is probably lost upon a crash also. > > My suggestion is this. Perhaps org-remember can have a file > (this fixes the killing problem), and that file can be > autosaved (this fixes the crash problem).[fn:4] > > There is one more case in which text is lost. You might run > org-remember from org-remember and not undo. My existing > proposal is to allow calling o-r from o-r. I think that > solves it. In such a case, however, it will be necessary > to allow more than one such file. > > [fn:4] In principle, if the target location is known, the > file can be an indirect buffer into that buffer. This has > other advantages, including having all in-buffer settings > work, being able to isearch, having a crashed org-remember > stay where it is supposed to be (albeit unfinished) and so > on. But it wouldn't be necessary to get that fancy. Just > any file would work. > > -- > Myalgic encephalomyelitis denialism is causing death (decades early; > Jason et al. 2006) and severe suffering (worse than nearly all other > diseases studied; e.g. Schweitzer et al. 1995) and grossly corrupting > science. http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode > > > > -- > Alan Davis > > "An inviscid theory of flow renders the screw useless, but the need > for one non-existent." ---Lord Raleigh (John > William Strutt), or else his son, who was also a scientist. > > It is undesirable to believe a proposition when > there is no ground whatsoever for supposing it is true. > ---- Bertrand Russell > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode