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 <samolog...@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
_______________________________________________
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
