From: "Alan E. Davis" <firstname.lastname@example.org>
Cc: org-mode <email@example.com>
Subject: Re: a small remember suggestion
Date: Sun, 22 Mar 2009 12:01:45 +1000 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 6346 bytes --]
[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.
(defadvice remember-finalize (before org-save-and-detach activate)
(setq buffer-file-name nil)))
(org-set-local 'change-major-mode-with-file-name nil)
(org-set-local 'remember-buffer (buffer-name)))
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." 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
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.
On Sun, Mar 22, 2009 at 5:28 AM, Samuel Wales <email@example.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.
"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
[-- Attachment #1.2: Type: text/html, Size: 7506 bytes --]
[-- Attachment #2: Type: text/plain, Size: 204 bytes --]
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
next prev parent reply other threads:[~2009-03-22 2:01 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] ` <firstname.lastname@example.org>
2009-03-22 2:01 ` Alan E. Davis [this message]
2009-03-22 15:16 ` Carsten Dominik
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
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 \
* 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).