Suggestion with bad patch for org-remember-templates

Suggestion with bad patch for org-remember-templates

[Wes Hardaker]

My templates for remind are numerous.  So much that they don't fit in a
single mini-buffer line (and I stopped using auto-expanding minibuffers
years ago when I had issues with it; I suspect it's safer now and I just
haven't tried again).

But anyway, I started thinking: you know...  that *Remember* buffer is
sitting there open and blank when selecting a template.  Can't we put
the list of templates there?  So I hacked together a quick patch to put
the contents in the *Remember* buffer and it works just fine.  I'm not
an expert elisp hacker as I dabble in it only every few years, hence the
reason "bad" is in the subject line.  It's also left as an exercise to
the reader to make the inserted contents prettier (like a table, rather
than one item per line).

--- org-remember.el.~1~ 2008-10-25 03:57:02.000000000 -0700
+++ org-remember.el     2008-12-26 06:32:51.000000000 -0800
@@ -286,7 +286,23 @@
                           (string-to-char org-force-remember-template-char)
                         org-force-remember-template-char))
                      (t
-                      (message "Select template: %s"
+                      (let ((currbuf (current-buffer)))
+                        (switch-to-buffer remember-buffer t)
+                        (erase-buffer)
+                        (insert "Select template:\n"
+                         (mapconcat
+                          (lambda (x)
+                            (cond
+                             ((not (string-match "\\S-" (nth 1 x)))
+                              (format "  [%c]" (car x)))
+                             ((equal (downcase (car x))
+                                     (downcase (aref (nth 1 x) 0)))
+                              (format "  [%c]%s" (car x)
+                                      (substring (nth 1 x) 1)))
+                             (t (format "  [%c]%s" (car x) (nth 1 x)))))
+                          templates "  \n"))
+                        (switch-to-buffer currbuf t))
+                        (message "Select template: %s"
                                (mapconcat
                                 (lambda (x)
                                   (cond

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Suggestion with bad patch for org-remember-templates

[Carsten Dominik]

Hi Wes,

yes, a better display of the remember template options would be useful.
However, right now the remember interface, because I believe that
James is working on a rewrite of the remember integration.  Maybe he
wants to put this on his list?

- Carsten

On Dec 31, 2008, at 4:39 PM, Wes Hardaker wrote:

>
> My templates for remind are numerous.  So much that they don't fit  
> in a
> single mini-buffer line (and I stopped using auto-expanding  
> minibuffers
> years ago when I had issues with it; I suspect it's safer now and I  
> just
> haven't tried again).
>
> But anyway, I started thinking: you know...  that *Remember* buffer is
> sitting there open and blank when selecting a template.  Can't we put
> the list of templates there?  So I hacked together a quick patch to  
> put
> the contents in the *Remember* buffer and it works just fine.  I'm not
> an expert elisp hacker as I dabble in it only every few years, hence  
> the
> reason "bad" is in the subject line.  It's also left as an exercise to
> the reader to make the inserted contents prettier (like a table,  
> rather
> than one item per line).
>
> --- org-remember.el.~1~ 2008-10-25 03:57:02.000000000 -0700
> +++ org-remember.el     2008-12-26 06:32:51.000000000 -0800
> @@ -286,7 +286,23 @@
>                           (string-to-char org-force-remember- 
> template-char)
>                         org-force-remember-template-char))
>                      (t
> -                      (message "Select template: %s"
> +                      (let ((currbuf (current-buffer)))
> +                        (switch-to-buffer remember-buffer t)
> +                        (erase-buffer)
> +                        (insert "Select template:\n"
> +                         (mapconcat
> +                          (lambda (x)
> +                            (cond
> +                             ((not (string-match "\\S-" (nth 1 x)))
> +                              (format "  [%c]" (car x)))
> +                             ((equal (downcase (car x))
> +                                     (downcase (aref (nth 1 x) 0)))
> +                              (format "  [%c]%s" (car x)
> +                                      (substring (nth 1 x) 1)))
> +                             (t (format "  [%c]%s" (car x) (nth 1  
> x)))))
> +                          templates "  \n"))
> +                        (switch-to-buffer currbuf t))
> +                        (message "Select template: %s"
>                                (mapconcat
>                                 (lambda (x)
>                                   (cond
>
> -- 
> "In the bathtub of history the truth is harder to hold than the soap,
> and much more difficult to find."  -- Terry Pratchett
>
>
> _______________________________________________
> 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: Suggestion with bad patch for org-remember-templates

[James TD Smith]

Hi Carsten and Wes,

On 2009-01-03 18:26:16(+0100), Carsten Dominik wrote:
> Hi Wes,
>
> yes, a better display of the remember template options would be useful.
> However, right now the remember interface, because I believe that
> James is working on a rewrite of the remember integration.  Maybe he
> wants to put this on his list?
>
> - Carsten

The selection interface will need to be redesigned anyway to cope with
multi-stage selection. Using the remember buffer to display the available
templates makes sense, I also like the idea of using a tabular layout.

I am still working on the remember rewrite. Unfortunately I haven't been able to
devote as much time to it as I had wanted, so it's still not ready for wider
testing. I think I'm about 2/3rds of the way through the refactoring and adding
plist templates.

I have auto-expanding minibuffers turned on (Emacs 22.2) and haven't noticed any
problems with them, so I'd suggest Wes give them another try.

> On Dec 31, 2008, at 4:39 PM, Wes Hardaker wrote:
>
> > My templates for remind are numerous. So much that they don't fit in a
> > single mini-buffer line (and I stopped using auto-expanding minibuffers
> > years ago when I had issues with it; I suspect it's safer now and I just
> > haven't tried again).
> >
> > But anyway, I started thinking: you know... that *Remember* buffer is
> > sitting there open and blank when selecting a template. Can't we put the
> > list of templates there? So I hacked together a quick patch to put the
> > contents in the *Remember* buffer and it works just fine. I'm not an expert
> > elisp hacker as I dabble in it only every few years, hence the reason "bad"
> > is in the subject line. It's also left as an exercise to the reader to make
> > the inserted contents prettier (like a table, rather than one item per
> > line).
> >
> > --- org-remember.el.~1~ 2008-10-25 03:57:02.000000000 -0700
> > +++ org-remember.el     2008-12-26 06:32:51.000000000 -0800
> > @@ -286,7 +286,23 @@
> >                           (string-to-char org-force-remember-
> > template-char)
> >                         org-force-remember-template-char))
> >                      (t
> > -                      (message "Select template: %s"
> > +                      (let ((currbuf (current-buffer)))
> > +                        (switch-to-buffer remember-buffer t)
> > +                        (erase-buffer)
> > +                        (insert "Select template:\n"
> > +                         (mapconcat
> > +                          (lambda (x)
> > +                            (cond
> > +                             ((not (string-match "\\S-" (nth 1 x)))
> > +                              (format "  [%c]" (car x)))
> > +                             ((equal (downcase (car x))
> > +                                     (downcase (aref (nth 1 x) 0)))
> > +                              (format "  [%c]%s" (car x)
> > +                                      (substring (nth 1 x) 1)))
> > +                             (t (format "  [%c]%s" (car x) (nth 1
> > x)))))
> > +                          templates "  \n"))
> > +                        (switch-to-buffer currbuf t))
> > +                        (message "Select template: %s"
> >                                (mapconcat
> >                                 (lambda (x)
> >                                   (cond

--
|-<James TD Smith>-<email/ahktenzero@mohorovi.cc>-|

Re: Suggestion with bad patch for org-remember-templates

[Carsten Dominik]

On Jan 3, 2009, at 7:45 PM, James TD Smith wrote:

> Hi Carsten and Wes,
>
> On 2009-01-03 18:26:16(+0100), Carsten Dominik wrote:
>> Hi Wes,
>>
>> yes, a better display of the remember template options would be  
>> useful.
>> However, right now the remember interface, because I believe that
>> James is working on a rewrite of the remember integration.  Maybe he
>> wants to put this on his list?
>>
>> - Carsten
>
> The selection interface will need to be redesigned anyway to cope with
> multi-stage selection. Using the remember buffer to display the  
> available
> templates makes sense, I also like the idea of using a tabular layout.

I think it would be better not to use the remember buffer for this,
but another, dedicated, temporary buffer.

- Carsten

>
>
> I am still working on the remember rewrite. Unfortunately I haven't  
> been able to
> devote as much time to it as I had wanted, so it's still not ready  
> for wider
> testing. I think I'm about 2/3rds of the way through the refactoring  
> and adding
> plist templates.
>
> I have auto-expanding minibuffers turned on (Emacs 22.2) and haven't  
> noticed any
> problems with them, so I'd suggest Wes give them another try.
>
>> On Dec 31, 2008, at 4:39 PM, Wes Hardaker wrote:
>>
>>> My templates for remind are numerous. So much that they don't fit  
>>> in a
>>> single mini-buffer line (and I stopped using auto-expanding  
>>> minibuffers
>>> years ago when I had issues with it; I suspect it's safer now and  
>>> I just
>>> haven't tried again).
>>>
>>> But anyway, I started thinking: you know... that *Remember* buffer  
>>> is
>>> sitting there open and blank when selecting a template. Can't we  
>>> put the
>>> list of templates there? So I hacked together a quick patch to put  
>>> the
>>> contents in the *Remember* buffer and it works just fine. I'm not  
>>> an expert
>>> elisp hacker as I dabble in it only every few years, hence the  
>>> reason "bad"
>>> is in the subject line. It's also left as an exercise to the  
>>> reader to make
>>> the inserted contents prettier (like a table, rather than one item  
>>> per
>>> line).
>>>
>>> --- org-remember.el.~1~ 2008-10-25 03:57:02.000000000 -0700
>>> +++ org-remember.el     2008-12-26 06:32:51.000000000 -0800
>>> @@ -286,7 +286,23 @@
>>>                          (string-to-char org-force-remember-
>>> template-char)
>>>                        org-force-remember-template-char))
>>>                     (t
>>> -                      (message "Select template: %s"
>>> +                      (let ((currbuf (current-buffer)))
>>> +                        (switch-to-buffer remember-buffer t)
>>> +                        (erase-buffer)
>>> +                        (insert "Select template:\n"
>>> +                         (mapconcat
>>> +                          (lambda (x)
>>> +                            (cond
>>> +                             ((not (string-match "\\S-" (nth 1 x)))
>>> +                              (format "  [%c]" (car x)))
>>> +                             ((equal (downcase (car x))
>>> +                                     (downcase (aref (nth 1 x) 0)))
>>> +                              (format "  [%c]%s" (car x)
>>> +                                      (substring (nth 1 x) 1)))
>>> +                             (t (format "  [%c]%s" (car x) (nth 1
>>> x)))))
>>> +                          templates "  \n"))
>>> +                        (switch-to-buffer currbuf t))
>>> +                        (message "Select template: %s"
>>>                               (mapconcat
>>>                                (lambda (x)
>>>                                  (cond
>
> --
> |-<James TD Smith>-<email/ahktenzero@mohorovi.cc>-|
>
>
> _______________________________________________
> 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: Suggestion with bad patch for org-remember-templates

[Wes Hardaker]

>>>>> On Sun, 4 Jan 2009 08:23:04 +0100, Carsten Dominik <dominik@science.uva.nl> said:

CD> I think it would be better not to use the remember buffer for this,
CD> but another, dedicated, temporary buffer.

Why would it matter though?  You're already opening and displaying
it...  Granted, you could stop doing that.

The only benefit to using another buffer is if the person canceled the
request (ctrl-g) in mid-selection then the original contents of the
remember buffer would be unaltered.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Suggestion with bad patch for org-remember-templates

[Carsten Dominik]

On Jan 5, 2009, at 5:31 PM, Wes Hardaker wrote:

>>>>>> On Sun, 4 Jan 2009 08:23:04 +0100, Carsten Dominik <dominik@science.uva.nl 
>>>>>> > said:
>
> CD> I think it would be better not to use the remember buffer for  
> this,
> CD> but another, dedicated, temporary buffer.
>
> Why would it matter though?  You're already opening and displaying
> it...  Granted, you could stop doing that.
>
> The only benefit to using another buffer is if the person canceled the
> request (ctrl-g) in mid-selection then the original contents of the
> remember buffer would be unaltered.


There are more reasons why it matters.

It is possible to make setup that will pop up the remember
buffer in a different/new frame, but you might still want to
have the template selection in your current frame.  Also, it
is allowed to call org-remember again in an existing remember
buffer, to apply a new template to the existing context.

Most of all, it is much cleaner this way.  A dispatcher splash
screen is by definition a one-off temporary buffer.  Creating
and displaying temporary buffer is very cheap and easily done,
and it is the standard way to do this kind of stuff.

I have reasonably strong feelings about this, because at the
beginning of my career, I did work with legacy computer codes
which where done in the old days when dynamic allocation was
not possible and computer memory was small, so people would
write programs where the same vector was used for different
purposes, in different locations of the program... :-)


> -- 
> "In the bathtub of history the truth is harder to hold than the soap,
> and much more difficult to find."  -- Terry Pratchett


I do love this citation in your signature......

- Carsten

Re: Suggestion with bad patch for org-remember-templates

[Wes Hardaker]

>>>>> On Mon, 5 Jan 2009 19:41:09 +0100, Carsten Dominik <dominik@science.uva.nl> said:

>> The only benefit to using another buffer is if the person canceled the
>> request (ctrl-g) in mid-selection then the original contents of the
>> remember buffer would be unaltered.

CD> There are more reasons why it matters.

Ok, I could certainly argue further but it doesn't matter to me which
way it goes.  I'm fine with either way :-)

>> --
>> "In the bathtub of history the truth is harder to hold than the soap,
>> and much more difficult to find."  -- Terry Pratchett

CD> I do love this citation in your signature......

If you haven't read any of his books, then I strongly suggest you do.
He's a fantastic author full of quips like that.  I have a very hard
time choosing between quotes of his.  I'll change it for this message
for you :-)

Suggested key sequence for you:

ctrl-c r Buy _The Color of Magic_ by /Terry Pratchett/ and read it ctrl-c ctrl-c

-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett

Re: Suggestion with bad patch for org-remember-templates

[Carsten Dominik]

On Jan 6, 2009, at 3:32 PM, Wes Hardaker wrote:

>>>>>> On Mon, 5 Jan 2009 19:41:09 +0100, Carsten Dominik <dominik@science.uva.nl 
>>>>>> > said:
>
>>> The only benefit to using another buffer is if the person canceled  
>>> the
>>> request (ctrl-g) in mid-selection then the original contents of the
>>> remember buffer would be unaltered.
>
> CD> There are more reasons why it matters.
>
> Ok, I could certainly argue further but it doesn't matter to me which
> way it goes.  I'm fine with either way :-)
>
>>> --
>>> "In the bathtub of history the truth is harder to hold than the  
>>> soap,
>>> and much more difficult to find."  -- Terry Pratchett
>
> CD> I do love this citation in your signature......
>
> If you haven't read any of his books, then I strongly suggest you do.
> He's a fantastic author full of quips like that.  I have a very hard
> time choosing between quotes of his.  I'll change it for this message
> for you :-)
>
> Suggested key sequence for you:
>
> ctrl-c r Buy _The Color of Magic_ by /Terry Pratchett/ and read it  
> ctrl-c ctrl-c

I do have that one, and about 8 others....... :-)

- Carsten

Re: Suggestion with bad patch for org-remember-templates

[James TD Smith]

On 2009-01-05 19:41:09(+0100), Carsten Dominik wrote:
>
> On Jan 5, 2009, at 5:31 PM, Wes Hardaker wrote:
>
> >>>>>> On Sun, 4 Jan 2009 08:23:04 +0100, Carsten Dominik <dominik@science.uva.nl
> >>>>>> > said:
> >
> > CD> I think it would be better not to use the remember buffer for this,
> > CD> but another, dedicated, temporary buffer.
> >
> > Why would it matter though? You're already opening and displaying it...
> > Granted, you could stop doing that.
> >
> > The only benefit to using another buffer is if the person canceled the
> > request (ctrl-g) in mid-selection then the original contents of the remember
> > buffer would be unaltered.
>
> There are more reasons why it matters.
>
> It is possible to make setup that will pop up the remember buffer in a
> different/new frame, but you might still want to have the template selection
> in your current frame. Also, it is allowed to call org-remember again in an
> existing remember buffer, to apply a new template to the existing context.

Also, the template selection interface needs to be usable when there is no
remember buffer, as it is also used to select a template to jump to the last
note stored using that template.

> Most of all, it is much cleaner this way. A dispatcher splash screen is by
> definition a one-off temporary buffer. Creating and displaying temporary
> buffer is very cheap and easily done, and it is the standard way to do this
> kind of stuff.
>
> I have reasonably strong feelings about this, because at the beginning of my
> career, I did work with legacy computer codes which where done in the old days
> when dynamic allocation was not possible and computer memory was small, so
> people would write programs where the same vector was used for different
> purposes, in different locations of the program... :-)

Agreed.

--
|-<James TD Smith>-<email/ahktenzero@mohorovi.cc>-|

Re: Suggestion with bad patch for org-remember-templates

[Wes Hardaker]

>>>>> On Sat, 3 Jan 2009 18:45:36 +0000, James TD Smith <ahktenzero@mohorovi.cc> said:

JTS> I think I'm about 2/3rds of the way through the refactoring and
JTS> adding plist templates.

Thanks for the updates to both of you and I'm very much looking forward
to the new code!

One of the reasons that I have so many remember templates is I almost
always have 2 per subject: one that includes a link to the current spot
in the current buffer and one that doesn't.  Having a multi-stage
selection would certainly fix that aspect of the problem.

JTS> I have auto-expanding minibuffers turned on (Emacs 22.2) and
JTS> haven't noticed any problems with them, so I'd suggest Wes give
JTS> them another try.

FYI, this was under XEmacs and it was a number of years ago (10+
probably) where if you had too long of a potential buffer it would crash
XEmacs (probably when the mini buffer needed to be larger than the
original window size or something).

I'll try again...
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett