emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <dominik@science.uva.nl>
To: "Alan E. Davis" <lngndvs@gmail.com>
Cc: org-mode <emacs-orgmode@gnu.org>
Subject: Re: a small remember suggestion
Date: Sun, 22 Mar 2009 16:16:45 +0100	[thread overview]
Message-ID: <6E22B50C-E9E2-4F09-96EE-19F6BE4C7ABD@uva.nl> (raw)
In-Reply-To: <7bef1f890903211901g29bbc680r1547319ec608e942@mail.gmail.com>

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)
> 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 <samologist@gmail.com>  
> 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

  reply	other threads:[~2009-03-22 15:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-21 19:28 a small remember suggestion Samuel Wales
     [not found] ` <7bef1f890903211425p1b1329ebxd42b3d7c1a3a77d7@mail.gmail.com>
2009-03-22  2:01   ` Alan E. Davis
2009-03-22 15:16     ` Carsten Dominik [this message]
2009-03-22 17:03       ` Richard Riley
2009-03-22 20:36       ` Alan E. Davis
2009-03-24  3:29       ` Samuel Wales
2009-03-24  3:42         ` Samuel Wales
2009-03-24 11:29           ` Carsten Dominik
2009-03-24 11:29         ` Carsten Dominik
2009-03-24 14:22           ` Alan E. Davis
2009-03-25  8:22             ` Carsten Dominik
2009-03-25  4:46           ` Samuel Wales
2009-03-25  6:24             ` Alan E. Davis
2009-03-25  8:23               ` Carsten Dominik

Reply instructions:

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

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

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

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

  git send-email \
    --in-reply-to=6E22B50C-E9E2-4F09-96EE-19F6BE4C7ABD@uva.nl \
    --to=dominik@science.uva.nl \
    --cc=emacs-orgmode@gnu.org \
    --cc=lngndvs@gmail.com \


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


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