From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tim O'Callaghan" Subject: Re: A simpler remember architecture (was: Re: Re: is there a hook to save a remember buffer?) Date: Wed, 30 Sep 2009 16:45:17 +0200 Message-ID: <3d6808890909300745i4213a0ddo9e12be00c4bb4023@mail.gmail.com> References: <20524da70909291348m6e1a6611ve01d6dac2faca93c@mail.gmail.com> <2647742D-5A30-4F33-8FDF-E5203B2E0246@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mt0R7-0003Tk-PW for emacs-orgmode@gnu.org; Wed, 30 Sep 2009 10:45:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mt0R3-0003Ry-6T for emacs-orgmode@gnu.org; Wed, 30 Sep 2009 10:45:45 -0400 Received: from [199.232.76.173] (port=44852 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mt0R3-0003Rn-1z for emacs-orgmode@gnu.org; Wed, 30 Sep 2009 10:45:41 -0400 Received: from mail-bw0-f220.google.com ([209.85.218.220]:38477) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mt0R2-0006Z8-3J for emacs-orgmode@gnu.org; Wed, 30 Sep 2009 10:45:40 -0400 Received: by bwz20 with SMTP id 20so5270794bwz.42 for ; Wed, 30 Sep 2009 07:45:37 -0700 (PDT) In-Reply-To: <2647742D-5A30-4F33-8FDF-E5203B2E0246@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 To: Carsten Dominik Cc: org-mode +1, can we keep/have: - the templates, - possibility to 'pick file/topic first then remember' - 'throw it into the bucket for later'. - org - remember keymap - local fontification? - remove need to have remember package installed? Tim. 2009/9/30 Carsten Dominik : > I don't know what the others think.... > > ... but I think this is a brilliant idea. > > - Carsten > > On Sep 29, 2009, at 10:48 PM, Samuel Wales wrote: > >> Hi Carsten, >> >> Here is an idea for a much simpler remember architecture that >> simultaneously solves Alan's problem. >> >> =A01) To me also, a more complicated way to deal with >> =A0 =A0remember buffers feels wrong. >> =A02) If there is more than one thing you are working on, the >> =A0 =A0power of the org hierarchy feels like the best way to >> =A0 =A0keep track. >> >> =A03) The current remember probably does not do what Alan >> =A0 =A0wants, even with a better workflow. >> =A0 =A0- What if you want to remember from remember? >> =A0 =A0- It feels complicated to finalize the old idea and go >> =A0 =A0 =A0there, then remember the new one, then finish the old >> =A0 =A0 =A0one, then go back to where you were. =A0Maybe we can >> =A0 =A0 =A0simplify. >> =A0 =A0- When you've finished the old one, you want to restore >> =A0 =A0 =A0context to before the old idea. =A0This is probably >> =A0 =A0 =A0impossible. =A0The stack is blown. >> =A04) Other issues: >> =A0 =A0- If you forget to finalize, you lose data. >> =A0 =A0- It is easy to reflexively call remember from remember, >> =A0 =A0 =A0making you surprised that the old idea disappeared. >> =A0 =A0- You might forget that you had the old idea. >> =A0 =A0 =A0Especially if you are having short-term memory issues >> =A0 =A0 =A0or are distracted. >> >> =A05) Here is my idea: discard the concept of remember >> =A0 =A0buffers entirely. >> =A0 =A0- Create the entry at the target location when you call >> =A0 =A0 =A0org-remember. >> =A0 =A0- Employ a virtual buffer to narrow to the created >> =A0 =A0 =A0entry. >> >> =A06) Some benefits: >> =A0 =A01) Alan can remember, then remember again, then >> =A0 =A0 =A0 remember a third time without having to save >> =A0 =A0 =A0 remember buffers or name them (which he would need). >> =A0 =A02) Your idea is where it should be. =A0If you want >> =A0 =A0 =A0 context, you simply remove the narrowing. >> =A0 =A03) org has access to the target buffer's buffer-local >> =A0 =A0 =A0 variables, org variables, encoding and multilingual >> =A0 =A0 =A0 settings of the target, etc. >> =A0 =A04) Auto-save saves to a place where Emacs will pick it >> =A0 =A0 =A0 up again if Emacs crashes. >> =A0 =A05) A backup directory is no longer necessary to restore >> =A0 =A0 =A0 data from a killed (remember) buffer. >> =A0 =A06) Finalizing is no longer a matter of losing your data >> =A0 =A0 =A0 if you forget. =A0It merely pops windows. >> >> =A07) If you still want the concept of "I am not done >> =A0 =A0remembering this remember," add a tag (:REMEMBERING:) >> =A0 =A0at creation time and have org-remember-finalize remove >> =A0 =A0that tag. =A0To see in-progress remembers, call the >> =A0 =A0agenda on that tag. >> >> =A08) This eases yak shaving. >> =A0 =A0- http://www.catb.org/~esr/jargon/html/Y/yak-shaving.html >> =A0 =A0- This is a simple way to keep track of what you were >> =A0 =A0 =A0doing when you remember from remember. >> =A0 =A0- I recommend making org-remember-finalize use a >> =A0 =A0 =A0/stack/, so that successive invocations recreate the >> =A0 =A0 =A0previous window/buffer context until they get to the >> =A0 =A0 =A0original context. >> =A0 =A0- I think that we intuitively work in stacks. =A0This >> =A0 =A0 =A0lets us avoid overloading our own memory. >> =A0 =A0- If Emacs crashes, the worst thing that will happen is >> =A0 =A0 =A0that you end up with a bunch of :REMEMBERING: tasks >> =A0 =A0 =A0around your org files. =A0Not lost data. >> >> To summarize, the current remember naturally leads to the >> need for increasing workarounds, and therefore requests for >> features, which leads to more complexity. =A0By leveraging the >> power of the org hierarchy, we can simplify, and get yak >> shaving support as a nice surprise benefit. >> >> Let me know what you think. >> >> >> On Tue, Sep 29, 2009 at 02:37, Carsten Dominik >> wrote: >>> >>> Hi Allen, >>> >>> saving remember buffers is hackish and complex as it is, so I am not >>> going >>> to add this option. >>> >>> I think the workflow has to be this: >>> >>> Create a remember buffer and more-or-less immediately file it. >>> >>> If you need to work on the content for a longer time, work on it at the >>> target location: =A0Simply exit remember with C-u C-c C-c. =A0The buffe= r will >>> be >>> filed and the target location will be visited immediately. =A0So now yo= u >>> can >>> work there as long as you want, and start another remember process when >>> you >>> need one. >>> >>> HTH >>> >>> - Carsten >>> >>> On Sep 9, 2009, at 10:17 PM, Alan E. Davis wrote: >>> >>>> I've looked briefly into the org-remember.el. =A0A hook exists: >>>> remember-mode-hook. =A0Im not sure it can be successfully applied to t= he >>>> case >>>> I envision. >>>> >>>> THere are tradeoffs to immediately saving a remember buffer to a file, >>>> and >>>> editing a note in the remember buffer, then saving with >>>> =A0remember-finalize. >>>> =A0I don't remember what they are, as they led me away from immediatel= y >>>> saving >>>> quite a while ago. I was strongly encouraged by the establishment of a >>>> procedure to automatically save to a directory, any remember buffer th= at >>>> was >>>> not finallized. =A0I had some issues with it, including how clunky it = was >>>> to >>>> recover, and it was broken at some point, when I was too busy to fix i= t. >>>> >>>> One problem with editing in the Remember buffer, then saving later, is >>>> forgetting where I am. =A0I can rely on several remember templates, an= d >>>> too >>>> often have lost the remember buffer's contents, when I ran remember >>>> again. >>>> >>>> What I propose is the make it possible---optionally---to invoke a hook >>>> to >>>> save existing remember buffers when C-c C-r (X) is used to file a >>>> remember >>>> note while in the remember buffer already. >>>> >>>> I found a test "bufferp". =A0It does not seem to recognize the buffer = name >>>> "Remember", nor "*Remember*". >>>> >>>> Is it possible to do this, or is remember going to defeat this? >>>> >>>> >>>> Alan Davis >>>> >>>> You can know the name of a bird in all the languages of the world, =A0= but >>>> when you're finished, you'll know absolutely nothing whatever about th= e >>>> bird... So let's look at the bird and see what it's doing---that's wha= t >>>> counts. >>>> >>>> =A0----Richard Feynman >>>> >>>> >>>> >>>> On Wed, Sep 9, 2009 at 3:42 PM, Alan E. Davis wrot= e: >>>> Is there a hook to save the remember buffer when I type C-c C-r when I= 'm >>>> in an unsaved remember buffer? =A0That would be almost as good, perhap= s >>>> better, than saving the remember buffer to a special file or directory= . >>>> >>>> >>>> Alan >>>> >>>> You can know the name of a bird in all the languages of the world, =A0= but >>>> when you're finished, you'll know absolutely nothing whatever about th= e >>>> bird... So let's look at the bird and see what it's doing---that's wha= t >>>> counts. >>>> >>>> =A0----Richard Feynman >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Myalgic encephalomyelitis causes death (Jason et al. 2006) >> and severe suffering. =A0Conflicts of interest are destroying >> research. =A0What people "know" is wrong. =A0Silence =3D death. >> 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 >