From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alan E. Davis" Subject: Re: a small remember suggestion Date: Sun, 22 Mar 2009 12:01:45 +1000 Message-ID: <7bef1f890903211901g29bbc680r1547319ec608e942@mail.gmail.com> References: <20524da70903211228o8ef4b21pc9a287ecd923383c@mail.gmail.com> <7bef1f890903211425p1b1329ebxd42b3d7c1a3a77d7@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0455988290==" Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LlD0b-0004DH-6u for emacs-orgmode@gnu.org; Sat, 21 Mar 2009 22:01:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LlD0W-0004BN-DY for emacs-orgmode@gnu.org; Sat, 21 Mar 2009 22:01:52 -0400 Received: from [199.232.76.173] (port=38690 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlD0W-0004BE-8c for emacs-orgmode@gnu.org; Sat, 21 Mar 2009 22:01:48 -0400 Received: from wf-out-1314.google.com ([209.85.200.169]:45191) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LlD0V-0006nJ-Cw for emacs-orgmode@gnu.org; Sat, 21 Mar 2009 22:01:47 -0400 Received: by wf-out-1314.google.com with SMTP id 23so1985710wfg.24 for ; Sat, 21 Mar 2009 19:01:45 -0700 (PDT) In-Reply-To: <7bef1f890903211425p1b1329ebxd42b3d7c1a3a77d7@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 Cc: org-mode --===============0455988290== Content-Type: multipart/alternative; boundary=000e0cd17488354d6f0465ab887a --000e0cd17488354d6f0465ab887a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [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." 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 --000e0cd17488354d6f0465ab887a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [I am reposting this to the list, as I'd intended.=A0 IOt turned out I&= #39;d responded only to the OP.]=A0


=
I posted regarding this problem in an earli= er thread about losing relatively large and complex *remember* buffers that I had forgotten to save (C-c C-c).=A0 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. =A0 I have tested two solutions that were presented earlier, but neither one of them specifically solves this problem.=A0 Each of them is a workaround, and either one is acceptable as such, but requires certain adjustments, albeit this is only slightly annoying;=A0 I can learn to work around them if need be.

I=A0 may not have elucidated the problem clearly in the original post.=A0 I use remember every day, and have at least 50 different templates.=A0 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.=A0 Alas!=A0 I throw up my hands in despair, but remembering that the digital computer, I search for a backup file.=A0 Backups have saved me hundreds of hours, if not days, of work in the past.=A0 Need I say more?

The *remember* buffer is not saved or backed up in any way.=A0 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.=A0

Carsten earlier posted an at least partial solution to this= problem.
#+BEGIN_SRC emacs-lisp
=A0=A0=A0 (defadvice remember-finali= ze (before org-save-and-detach activate)
=A0=A0=A0=A0=A0 (when buffer-fi= le-name
=A0=A0=A0=A0=A0=A0=A0 (save-buffer)
=A0=A0=A0=A0=A0=A0=A0 (setq buffer-f= ile-name nil)))
=A0=A0=A0
=A0=A0=A0 (add-hook 'remember-mode-hoo= k
=A0=A0=A0=A0=A0=A0 (lambda ()
=A0=A0=A0=A0=A0=A0=A0=A0 (org-set-loc= al 'change-major-mode-with-file-name nil)
=A0=A0=A0=A0=A0=A0=A0=A0 (= write-file "~/path/to/remember_backup.org")
=A0=A0=A0=A0=A0=A0=A0=A0 (org-set-local 'remember-buffer (buffer-name))= )
=A0=A0=A0=A0=A0=A0 'append)
#+END_SRC=A0=A0

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-n= ote buffer."=A0 I admit I have used a wrench as a hammer at times, to = the chagrin of the true mechanic.=A0 I have found remember a useful tool.= =A0 I admit I haven't understood its mechanism: I have even been confus= ed by it.=A0 I use the templates, but am still a novice: I have written fai= rly complicated org-remember templates, but I still haven't gotten my h= ead entirely around what they can do.=A0 I have used it in whatever manner = seemed useful at the time.=A0 So it is actually helpful to see how org-reme= mber is intended to be used, that one should immediately file his notes.=A0= 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 unorthodo= x mode.=A0

All's the same, I hope=A0 a convincing argument to include this sol= ution.=A0 I would second the need to include a numbered backup mechanism to= cover recursive calls to org-remember.=A0

That being said, I have also started using "%!" in some templ= ates.=A0 It feels clumsy, but for the most part solves the problem, since I= seldom use the refiling options on the remember splash header.=A0 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 curs= or to a particular position.=A0

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.=A0

Something more transparent w= ould be ideal.=A0 I'm not sure how to organize that the *remember* buff= er would automatically be saved as a file transparently, with numbered back= ups for new *remember* buffers.

Remember rocks!

Alan



On Sun, Mar 22, 2009 at 5:28 AM, Sam= uel 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. =A0With 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. =A0Perhaps 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. =A0You might run
org-remember from org-remember and not undo. =A0My existing
proposal is to allow calling o-r from o-r. =A0I think that
solves it. =A0In 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. =A0This 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. =A0But it wouldn't be necessary to get that fancy. =A0Just
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. =A0http://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@gn= u.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode



--
Alan = Davis

"An inviscid theory of flow renders the screw useless, bu= t the need for one non-existent." =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ---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.
=A0 =A0 ---- Bertrand Russell
=

--000e0cd17488354d6f0465ab887a-- --===============0455988290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0455988290==--