emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: James TD Smith <ahktenzero@mohorovi.cc>
To: emacs-orgmode list <emacs-orgmode@gnu.org>
Subject: Re: Suggestion with bad patch for org-remember-templates
Date: Tue, 6 Jan 2009 23:06:39 +0000	[thread overview]
Message-ID: <20090106230639.GB2267@yog-sothoth.mohorovi.cc> (raw)
In-Reply-To: <94C56E04-418A-4121-AC31-9F2FCD6D8EB4@uva.nl>

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... :-)


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

  parent reply	other threads:[~2009-01-06 23:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-31 15:39 Suggestion with bad patch for org-remember-templates Wes Hardaker
2009-01-03 17:26 ` Carsten Dominik
2009-01-03 18:45   ` James TD Smith
2009-01-04  7:23     ` Carsten Dominik
2009-01-05 16:31       ` Wes Hardaker
2009-01-05 18:41         ` Carsten Dominik
2009-01-06 14:32           ` Wes Hardaker
2009-01-06 15:17             ` Carsten Dominik
2009-01-06 23:06           ` James TD Smith [this message]
2009-01-05 16:30     ` Wes Hardaker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090106230639.GB2267@yog-sothoth.mohorovi.cc \
    --to=ahktenzero@mohorovi.cc \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).