From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions Date: Fri, 20 Dec 2013 18:44:52 +0100 Message-ID: <871u172z8r.fsf@rosalinde.fritz.box> References: <87ppsj3tvf.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387561519 11002 80.91.229.3 (20 Dec 2013 17:45:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2013 17:45:19 +0000 (UTC) Cc: 15225@debbugs.gnu.org To: Jambunathan K Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 20 18:45:21 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vu48W-00029j-Aq for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Dec 2013 18:45:20 +0100 Original-Received: from localhost ([::1]:50904 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu48V-0005iQ-R5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Dec 2013 12:45:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu48N-0005iK-QT for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 12:45:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vu48G-0004Rc-UA for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 12:45:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu48G-0004Qy-QF for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 12:45:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vu48F-0000zF-Cl for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 12:45:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Dec 2013 17:45:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15225 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15225-submit@debbugs.gnu.org id=B15225.13875615003769 (code B ref 15225); Fri, 20 Dec 2013 17:45:03 +0000 Original-Received: (at 15225) by debbugs.gnu.org; 20 Dec 2013 17:45:00 +0000 Original-Received: from localhost ([127.0.0.1]:60392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu48B-0000yj-CE for submit@debbugs.gnu.org; Fri, 20 Dec 2013 12:45:00 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:59602) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu487-0000yX-2W for 15225@debbugs.gnu.org; Fri, 20 Dec 2013 12:44:56 -0500 Original-Received: from rosalinde.fritz.box ([89.245.77.92]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LfSeH-1VA4Gy1lGb-00p2mP for <15225@debbugs.gnu.org>; Fri, 20 Dec 2013 18:44:53 +0100 In-Reply-To: <87ppsj3tvf.fsf@rosalinde.fritz.box> (Stephen Berman's message of "Sun, 08 Sep 2013 23:07:16 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V03:K0:iNnf7hPRebBZnostrPzOSSjYmD88/qJw8wY2hINQUmlfqWTj0Jr GxNk7uEdKwOHhY87hqostcQ3B0hZE+cs3jZ3+9CRM9BklxjwSQtkpZL4C4LeAgupUj9dR4G +NWH1cEfDhcCpcFQI/jKXv3j+cQrV9IfEkJ2X3IYN8z9SeKammVyojg0rA0Nr1xUJIYx3hE JAi2tRd8hshxpP5o4HWdA== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82293 Archived-At: On Sun, 08 Sep 2013 23:07:16 +0200 Stephen Berman wrote: > On Fri, 30 Aug 2013 23:48:28 +0530 Kanthimathi R wrote: >> --==-- todo-mode >> [Aug 29, 2013] `C m' MUST create new files on demand >> >> 1. Visit the odt category. >> 2. Type `C m' on the first entry >> 3. When prompted for a file-name, give a non-existing file name. >> 4. Note that completion insists on a MUST-MATCH. >> 5. I was expecting that the new file will be created and the entry >> moved to that category. > > I guess this is a reasonable expectation. My use-case for `C m' is that > I have a main todo file containing unrelated categories I add as the > need arises, and I have more specific todo files, and occasionally I > find that a category in the main file fits in better with one of the > more specific files, so I move it to that. So my assumption was that > users would only want to move categories between existing files. But I > guess it makes sense to be able to create the file on moving the > category and I'll make that change. I've now implemented this. But actually, I think you really meant the command todo-move-item (bound to `m') instead of todo-move-category (`C m'). That one is trickier, because it uses todo-category-completions, which a number of other commands also use. I'm not sure such a change is good for the other commands, and I think it's not such a straightforward change, so I've refrained from implementing it for the time being. But I'll give it more consideration. >> [Aug 28, 2013] `i i' should append or prepend items by default >> >> GTD says separate out collection and processing. >> >> Insertion of an item is a "collection" activity. Setting a >> priority is a "processing" activity. So I recommend that `i i' add >> an item to the top or the bottom of the file. Let the user move >> the raise or lower the items at a later point in time during the >> "processing" phase. > > I'm reluctant to eliminate prioritization from `i i' (and hence from > most of the other item insertion commands). This has always been a > feature of todo-mode.el, implicit in the command's name, as the manual > points out: insertion does not entail appending or prepending. But I > guess it's reasonable to have an option for prioritized item insertion > to make typing RET on being prompted for a priority default to first or > last item. I've implemented the default priority option. >> [Aug 30, 2013] When I `C m', most often I want to stay in the same category >> >> The current behaviour is to move to the new category. I >> essentially need a pop or a prefix binding. > > Making this possible with a prefix argument seems like a good idea. I've also put this on hold, because it also has implications for other commands and I need to think about it more. >> --==-- todo-mode/bugs >> [Aug 29, 2013] With desktop mode on and todo-mode leaves a stacktrace >> >> Strip your .emacs as below. >> >> (custom-set-variables >> ;; custom-set-variables was added by Custom. >> ;; If you edit it by hand, you could mess it up, so be careful. >> ;; Your init file should contain only one such instance. >> ;; If there is more than one, they won't work right. >> '(calendar-view-diary-initially-flag t) >> '(desktop-base-file-name ".emacs-desktop.junk") >> '(desktop-path (quote ("~"))) >> '(desktop-save-mode t) >> '(diary-file "~/.emacs.d/todo/emacs.todo") >> '(diary-number-of-entries 30) >> '(savehist-mode t) >> '(todo-wrap-lines t)) >> >> emacs >> M-x todo-show >> Make sure that todo buffer shows up fine >> C-x C-c and save the desktop file >> >> Re-load emacs >> M-x toggle-debug-on-error >> M-x todo-show >> >> See following stacktrace. >> >> Debugger entered--Lisp error: (error "Category nil is missing todo-category-done string") >> signal(error ("Category nil is missing todo-category-done string")) >> error("Category %s is missing todo-category-done string" nil) >> todo-category-select() >> todo-show(nil 1) >> call-interactively(todo-show record nil) >> command-execute(todo-show record) >> execute-extended-command(nil "todo-show") >> call-interactively(execute-extended-command nil nil) >> command-execute(execute-extended-command) > > This error actually has nothing to do with desktop: you also get it with > this recipe: > 1. emacs -Q > 2. C-x C-f ~/.emacs.d/todo/emacs.todo RET > 3. M-x todo-show > After step 2, the file emacs.todo is in fundamental mode (because, as > you note below, todo-mode is not yet loaded), but when todo-show finds > that a buffer is already visiting the file, it doesn't check the mode, > assuming it is already in todo-mode, and this leads to the error. This > can be avoided by making todo-show check the mode and call todo-mode if > the buffer isn't already in it; however, automatically putting files > whose names end in ".todo" into todo-mode, as you suggest below, would > also avoid the error and be a more general solution. > > There is, however, another problem that shows up with a saved desktop > containing a buffer visiting a todo file: namely, although the restored > buffer is in todo-mode (that is, after fixing the above error), it is > not properly displayed with narrowing to the current category. I think > I can fix this by writing a function to add to > desktop-buffer-mode-handlers I've now implemented this. >> [Aug 28, 2013] Highlighting reports an error >> >> F H on an item results in >> >> call-interactively: Symbol's value as variable is void: hl-line-mode > > Shortly before installing the package into trunk I had wrapped require > inside eval-when-compile to silence the byte compiler and must have > neglected to test it. I should have used eval-and-compile and will > change it accordingly. This is also done. >> [Aug 29, 2013] todo-mode not recognized with emacs -Q >> >> 1. emacs -Q >> 2. C-x C-f ~/.emacs.d/todo/emacs.todo >> 3. The file is not visited in todo mode and hence not fontified. >> >> I think `auto-mode-alist' should have an entry for todo-mode /even if/ >> todo-mode is not loaded apriori. > > It's a good idea to make todo files recognizable without previously > loading the package, but it's not necessary to add to the default value > of auto-mode-alist; I'll follow the practice of many other packages and > put an autoload cookie before each top-level add-to-list sexp in > todo-mode.el, and also before the corresponding mode functions (I should > have done this earlier but wasn't aware of the practice). This too is done. >> The section that talks about y k c d sequence seems to occur a bit >> too early in the manual. It should be placed a bit late in the >> manual. Mentioning the mnemonics upfront, y => diarY k => marK etc >> is *good* though. > > Since the item insertion key sequences are a central aspect of editing > in Todo mode, I think they belong in that chapter of the manual, and > that chapter shouldn't come too late, since editing (which includes > adding new items) is one of the most common functions of Todo mode. > (BTW, Stefan Monnier has proposed a different implementation of todo > item insertion key sequences that has a nice UI with direct feedback of > available completions; however, this relies on lexical binding, which > Todo mode currently can't use, since it makes essential use of some > dynamically scoped variables from the calendar package. But he's > working on transitioning the calendar code to lexically binding, so this > feature may soon be possible in Todo mode.) While waiting for Calendar to go lexical, I've implemented a dynamic binding version of Stefan's proposal, so this will facilitate using item insertion. I need to give some of your other recommendations and feature requests more thought, so they probably will have to wait till the feature freeze is over. But I will update the manual before the next release. In the mean time I'll leave this bug open. Steve Berman