emacs-wiki-discuss
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]