a small remember suggestion

a small remember suggestion

[Samuel Wales]

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

Re: a small remember suggestion

[Alan E. Davis]

[-- 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.
#+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 <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

[-- 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.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: a small remember suggestion

[Carsten Dominik]

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 <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

Re: a small remember suggestion

[Richard Riley]

Carsten Dominik <dominik@science.uva.nl> writes:

>
> 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?

If anyone wants to do this deletion manually, I do this in a script
which backs up mysql databases (linux bash shell) to keep the directory
pruned:

,----
| find ./*.zip2 -mtime +10  -exec rm {} \;
`----

i.e delete all zip2 files older than ten days.

Re: a small remember suggestion

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 546 bytes --]

Carsten:

This is perfect!  Thank you again.

Alan Davis


   "Study and, in general the pursuit of truth and beauty is a sphere of
   activity in which we are permitted to remain children all of our
   lives."

   Albert Einstein

"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.





On Mon, Mar 23, 2009 at 1:16 AM, Carsten Dominik <dominik@science.uva.nl>wrote:

> org-remember-backup-directory'
>

[-- Attachment #1.2: Type: text/html, Size: 948 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: a small remember suggestion

[Samuel Wales]

On Sun, Mar 22, 2009 at 08:16, Carsten Dominik <dominik@science.uva.nl> wrote:
> 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 is perfect.  Thank you.

> 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?

As one possibility, how about removing the file once the contents are
successfully moved to their target locations?

After that,

(when (plusp number)
  (message "you have %s saved remember files" number))

-- 
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

Re: a small remember suggestion

[Samuel Wales]

If you set auto-save-visited-file-name buffer-local in that buffer,
you'll have the latest auto-saved contents in the file.

Re: a small remember suggestion

[Carsten Dominik]

[-- Attachment #1.1: Type: text/plain, Size: 228 bytes --]


On Mar 24, 2009, at 4:42 AM, Samuel Wales wrote:

> If you set auto-save-visited-file-name buffer-local in that buffer,
> you'll have the latest auto-saved contents in the file.

Good one, I am doing that.

Thanks.

- Carsten


[-- Attachment #1.2: Type: text/html, Size: 493 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: a small remember suggestion

[Carsten Dominik]

On Mar 24, 2009, at 4:29 AM, Samuel Wales wrote:

> On Sun, Mar 22, 2009 at 08:16, Carsten Dominik  
> <dominik@science.uva.nl> wrote:
>> 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 is perfect.  Thank you.
>
>> 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?
>
> As one possibility, how about removing the file once the contents are
> successfully moved to their target locations?

Of course!  I will do that.

>
> After that,
>
> (when (plusp number)
>  (message "you have %s saved remember files" number))

Hmmm.   When should this happen?  Not after a
successful remember process, I'd say.....

- Carsten

>
> -- 
> 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

Re: a small remember suggestion

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 2169 bytes --]

Wasn't going to say anything but at risk of sticking my foot in my mouth:

I learned that the convention for naming backups in Emacs is they end in ~.
Is it possible that if this is done, Emacs will automatically use the
mechanism that is available to keep a given number of old versions and a
given number of new versions?  For example, I have this in my .emacs:

(setq kept-old-versions 2)
(setq kept-new-versions 4)
(setq delete-old-versions t)

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




On Tue, Mar 24, 2009 at 9:29 PM, Carsten Dominik <dominik@science.uva.nl>wrote:

>
> On Mar 24, 2009, at 4:29 AM, Samuel Wales wrote:
>
>  On Sun, Mar 22, 2009 at 08:16, Carsten Dominik <dominik@science.uva.nl>
>> wrote:
>>
>>> 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 is perfect.  Thank you.
>>
>>  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?
>>>
>>
>> As one possibility, how about removing the file once the contents are
>> successfully moved to their target locations?
>>
>
> Of course!  I will do that.
>
>
>> After that,
>>
>> (when (plusp number)
>>  (message "you have %s saved remember files" number))
>>
>
> Hmmm.   When should this happen?  Not after a
> successful remember process, I'd say.....
>
> - Carsten
>
>
>
>> --
>> 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
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3602 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: a small remember suggestion

[Carsten Dominik]

I did look at this possibility, but then found it better to tag
the backup files with dates.

- Carsten

On Mar 24, 2009, at 3:22 PM, Alan E. Davis wrote:

> Wasn't going to say anything but at risk of sticking my foot in my  
> mouth:
>
> I learned that the convention for naming backups in Emacs is they  
> end in ~.  Is it possible that if this is done, Emacs will  
> automatically use the mechanism that is available to keep a given  
> number of old versions and a given number of new versions?  For  
> example, I have this in my .emacs:
>
> (setq kept-old-versions 2)
> (setq kept-new-versions 4)
> (setq delete-old-versions t)
>
> 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
>
>
>
>
> On Tue, Mar 24, 2009 at 9:29 PM, Carsten Dominik <dominik@science.uva.nl 
> > wrote:
>
> On Mar 24, 2009, at 4:29 AM, Samuel Wales wrote:
>
> On Sun, Mar 22, 2009 at 08:16, Carsten Dominik  
> <dominik@science.uva.nl> wrote:
> 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 is perfect.  Thank you.
>
> 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?
>
> As one possibility, how about removing the file once the contents are
> successfully moved to their target locations?
>
> Of course!  I will do that.
>
>
>
> After that,
>
> (when (plusp number)
>  (message "you have %s saved remember files" number))
>
> Hmmm.   When should this happen?  Not after a
> successful remember process, I'd say.....
>
> - Carsten
>
>
>
> -- 
> 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

Re: a small remember suggestion

[Samuel Wales]

On Tue, Mar 24, 2009 at 04:29, Carsten Dominik <dominik@science.uva.nl> wrote:
>> After that,
>>
>> (when (plusp number)
>>  (message "you have %s saved remember files" number))
>
> Hmmm.   When should this happen?  Not after a
> successful remember process, I'd say.....

The number will usually be zero, so that is when I would do it.  Of
course it should be combined with "successfully saved to ...".

I like it after rather than before saving because, in my view, we want
to limit the amount of attention required between "have an idea" and
"saved the idea".

Perhaps there are other times for it, but then would work for me.

-- 
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

Re: a small remember suggestion

[Alan E. Davis]

[-- Attachment #1.1: Type: text/plain, Size: 1466 bytes --]

What would happen then if one called remember from a previous remember
buffer, then saved it?

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




On Wed, Mar 25, 2009 at 2:46 PM, Samuel Wales <samologist@gmail.com> wrote:

> On Tue, Mar 24, 2009 at 04:29, Carsten Dominik <dominik@science.uva.nl>
> wrote:
> >> After that,
> >>
> >> (when (plusp number)
> >>  (message "you have %s saved remember files" number))
> >
> > Hmmm.   When should this happen?  Not after a
> > successful remember process, I'd say.....
>
> The number will usually be zero, so that is when I would do it.  Of
> course it should be combined with "successfully saved to ...".
>
> I like it after rather than before saving because, in my view, we want
> to limit the amount of attention required between "have an idea" and
> "saved the idea".
>
> Perhaps there are other times for it, but then would work for me.
>
> --
> 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
>

[-- Attachment #1.2: Type: text/html, Size: 2140 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: a small remember suggestion

[Carsten Dominik]

On Mar 25, 2009, at 7:24 AM, Alan E. Davis wrote:

> What would happen then if one called remember from a previous  
> remember buffer, then saved it?

I believe this will create a new backup.

- Carsten

>
> 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
>
>
>
>
> On Wed, Mar 25, 2009 at 2:46 PM, Samuel Wales <samologist@gmail.com>  
> wrote:
> On Tue, Mar 24, 2009 at 04:29, Carsten Dominik  
> <dominik@science.uva.nl> wrote:
> >> After that,
> >>
> >> (when (plusp number)
> >>  (message "you have %s saved remember files" number))
> >
> > Hmmm.   When should this happen?  Not after a
> > successful remember process, I'd say.....
>
> The number will usually be zero, so that is when I would do it.  Of
> course it should be combined with "successfully saved to ...".
>
> I like it after rather than before saving because, in my view, we want
> to limit the amount of attention required between "have an idea" and
> "saved the idea".
>
> Perhaps there are other times for it, but then would work for me.
>
> --
> 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