[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[emacs-wiki-discuss] Re: New: planner-tasks-file-behavior
From: |
Sacha Chua |
Subject: |
[emacs-wiki-discuss] Re: New: planner-tasks-file-behavior |
Date: |
Thu, 23 Sep 2004 01:00:18 +0900 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) |
address@hidden writes:
> The patch as I submitted it was actually too slow when many files
> had to be opened (mainly due to font-locking). I'm not using it
> anymore, but Sacha's suggestion to collect the open files first,
Hmm. My current implementation behaves reasonably well, although I
find myself wondering if I should defadvice
planner-sort-tasks-automatically and
planner-renumber-tasks-automatically to nil to prevent my tasks from
moving around whenever I update or reschedule a task. Is this a
reasonable default? I tend to expect that C-c C-c on a task will leave
my cursor on the same task, and if planner-update-task saves buffers,
it makes everything jump around.
> then update them (without saving & closing after every task update),
> and then restore them, seems a better and more viable alternative.
> My patch was just a fast way to get a "prototype" working.
I love the way Emacs lets us make quick hacks to see if an idea works.
=)
> Perhaps it an even simpler technique is to keep track of the
> files that have to be opened for saving/updating, and then to
> save and kill these buffers once done. The advantage: the names
I'm a little nervous about using get-buffer for this, as I could run
into problems with buffers with duplicate names. What's the canonical
way to check if a file is already open?
> [Something else: The duplication of recording the live buffers
> (both in planner-copy-or-move-region and
> planner-copy-or-move-task, where the former calls the latter),
> makes me uneasy.]
Duplicated because the functions can be called independently, and
should have reasonable behavior in both cases. The current code
processes buffers at the end of a planner-copy-or-move-region if
called that way, and at the end of a planner-copy-or-move-task
only if it's called by itself. =)
> [1] A (possible) example of this going astray: suppose that a
> hook/function is called during the update that changes the
> major mode of an open buffer B to planner-mode. The
True. This could be a problem. As you suggested, the more reasonable
way to implement this is to check which files were opened. I'm
sure there's a canonical way to do this...
--
Sacha Chua <address@hidden> - open source geekette
interests: emacs, gnu/linux, making computer science education fun
wearable computing, personal information management
http://sacha.free.net.ph/ - PGP Key ID: 0xE7FDF77C