X-Loop: help-debbugs@HIDDEN
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
Resent-From: Kanthimathi R <rkanthimathi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 30 Aug 2013 18:17:01 +0000
Resent-Message-ID: <handler.15225.B.13778866138241 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 15225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: 15225 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.13778866138241
(code B ref -1); Fri, 30 Aug 2013 18:17:01 +0000
Received: (at submit) by debbugs.gnu.org; 30 Aug 2013 18:16:53 +0000
Received: from localhost ([127.0.0.1]:59698 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VFTFd-00028r-2u
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 14:16:53 -0400
Received: from eggs.gnu.org ([208.118.235.92]:44550)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <rkanthimathi@HIDDEN>) id 1VFTFa-00028d-Oq
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 14:16:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <rkanthimathi@HIDDEN>) id 1VFTFN-0000Wc-MA
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 14:16:45 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: ***
X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
MSGID_FROM_MTA_HEADER,RECEIVED_FROM_WINDOWS_HOST autolearn=disabled
version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:35807)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <rkanthimathi@HIDDEN>) id 1VFTFN-0000WY-IU
for submit <at> debbugs.gnu.org; Fri, 30 Aug 2013 14:16:37 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46254)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <rkanthimathi@HIDDEN>) id 1VFTFG-0003tX-Jd
for bug-gnu-emacs@HIDDEN; Fri, 30 Aug 2013 14:16:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <rkanthimathi@HIDDEN>) id 1VFTF8-0000Uz-Ke
for bug-gnu-emacs@HIDDEN; Fri, 30 Aug 2013 14:16:30 -0400
Received: from blu0-omc1-s3.blu0.hotmail.com ([65.55.116.14]:5061)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <rkanthimathi@HIDDEN>) id 1VFTF8-0000Ur-GE
for bug-gnu-emacs@HIDDEN; Fri, 30 Aug 2013 14:16:22 -0400
Received: from BLU0-SMTP434 ([65.55.116.8]) by blu0-omc1-s3.blu0.hotmail.com
with Microsoft SMTPSVC(6.0.3790.4675);
Fri, 30 Aug 2013 11:16:21 -0700
X-TMN: [tLaSlTs/g9GbNt8zMukFrPIDNqXQJTXb]
X-Originating-Email: [rkanthimathi@HIDDEN]
Message-ID: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
Received: from porunai ([115.241.15.160]) by BLU0-SMTP434.phx.gbl over TLS
secured channel with Microsoft SMTPSVC(6.0.3790.4675);
Fri, 30 Aug 2013 11:16:19 -0700
From: Kanthimathi R <rkanthimathi@HIDDEN>
Date: Fri, 30 Aug 2013 23:48:28 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-OriginalArrivalTime: 30 Aug 2013 18:16:20.0269 (UTC)
FILETIME=[06D23DD0:01CEA5AD]
X-detected-operating-system: by eggs.gnu.org: Windows XP
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -2.4 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)
--=-=-=
Content-Type: text/plain
Quick feedback:
--------------
The interface for todo-mode looks good. Info documentation is good.
The starting few nodes are a bit too dense while the later nodes seem
like a lucid read.
Recommendation:
---------------
I would recommend it for simple todo-lists. Once the entries become
more, then categorization of entries looks like a rocket science. (Or I
should say, new users should be sufficiently trained.)
Verdict:
--------
Too many moving parts and the module needs to stabilize a bit. I
INVARIABLY run in to problems.
Giving up:
---------
1. For example, as I was exercising todo-mode for preparing this bug
report, the file ran in to an inconsistent state - A category with no
todo or done items was reporting 6 entries in `F c' table. I
wondered whether deleting the categories sexp and C-x C-q ing would
repair the todo file. Unfortunately, that doesn't help. So I am
attaching a "broken" todo file.
To add to the entries in the attached file,
1. Undo support while in todo-mode.
2. The following markers used in the todo file
--==--
==--==
are they consistent with the outline-mode. If not, some consideration
should be given so that they are compatible with outline-regexps.
Additional comment:
------------------
As some one who is familiar with (but doesn't use) Orgmode's data model,
I can share some opinions, if permitted.
With no further ado, here comes the attachment. Repairing the attached
file is reader's responsibility.
--=-=-=
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="emacs.todo"
Content-Transfer-Encoding: base64
Ci0tPT0tLSB0b2RvLW1vZGUKW0F1ZyAyOSwgMjAxM10gYEMgbScgTVVTVCBjcmVhdGUgbmV3IGZp
bGVzIG9uIGRlbWFuZAoJCgkxLiBWaXNpdCB0aGUgb2R0IGNhdGVnb3J5LgoJMi4gVHlwZSBgQyBt
JyBvbiB0aGUgZmlyc3QgZW50cnkKCTMuIFdoZW4gcHJvbXB0ZWQgZm9yIGEgZmlsZS1uYW1lLCBn
aXZlIGEgbm9uLWV4aXN0aW5nIGZpbGUgbmFtZS4KCTQuIE5vdGUgdGhhdCBjb21wbGV0aW9uIGlu
c2lzdHMgb24gYSBNVVNULU1BVENILgoJNS4gSSB3YXMgZXhwZWN0aW5nIHRoYXQgdGhlIG5ldyBm
aWxlIHdpbGwgYmUgY3JlYXRlZCBhbmQgdGhlIGVudHJ5IG1vdmVkIHRvIHRoYXQgY2F0ZWdvcnku
CgkKW0F1ZyAyOCwgMjAxM10gIGBpIGknIHNob3VsZCBhcHBlbmQgb3IgcHJlcGVuZCBpdGVtcyBi
eSBkZWZhdWx0CgkKCUdURCBzYXlzIHNlcGFyYXRlIG91dCBjb2xsZWN0aW9uIGFuZCBwcm9jZXNz
aW5nLgoJCglJbnNlcnRpb24gb2YgYW4gaXRlbSBpcyBhICJjb2xsZWN0aW9uIiBhY3Rpdml0eS4g
IFNldHRpbmcgYQoJcHJpb3JpdHkgaXMgYSAicHJvY2Vzc2luZyIgYWN0aXZpdHkuICBTbyBJIHJl
Y29tbWVuZCB0aGF0IGBpIGknIGFkZAoJYW4gaXRlbSB0byB0aGUgdG9wIG9yIHRoZSBib3R0b20g
b2YgdGhlIGZpbGUuICBMZXQgdGhlIHVzZXIgbW92ZQoJdGhlIHJhaXNlIG9yIGxvd2VyIHRoZSBp
dGVtcyBhdCBhIGxhdGVyIHBvaW50IGluIHRpbWUgZHVyaW5nIHRoZQoJInByb2Nlc3NpbmciIHBo
YXNlLgoJCltBdWcgMzAsIDIwMTNdIFdoZW4gSSBgQyBtJywgbW9zdCBvZnRlbiBJIHdhbnQgdG8g
c3RheSBpbiB0aGUgc2FtZSBjYXRlZ29yeQoJCglUaGUgY3VycmVudCBiZWhhdmlvdXIgaXMgdG8g
bW92ZSB0byB0aGUgbmV3IGNhdGVnb3J5LiAgSQoJZXNzZW50aWFsbHkgbmVlZCBhIHBvcCBvciBh
IHByZWZpeCBiaW5kaW5nLgoJCgkKW0F1ZyAzMCwgMjAxM10gQSBrZXkgYmluZGluZyBmb3IgZWRp
dGluZyBqdXN0IHRoZSBoZWFkZXIgbGluZSAoc2F5IGUgaCkKCj09LS09PSBET05FIAoKLS09PS0t
IHRvZG8tbW9kZS9idWdzCltBdWcgMjksIDIwMTNdIFdpdGggZGVza3RvcCBtb2RlIG9uIGFuZCB0
b2RvLW1vZGUgbGVhdmVzIGEgc3RhY2t0cmFjZQoJCglTdHJpcCB5b3VyIC5lbWFjcyBhcyBiZWxv
dy4KCQoJIChjdXN0b20tc2V0LXZhcmlhYmxlcwoJICA7OyBjdXN0b20tc2V0LXZhcmlhYmxlcyB3
YXMgYWRkZWQgYnkgQ3VzdG9tLgoJICA7OyBJZiB5b3UgZWRpdCBpdCBieSBoYW5kLCB5b3UgY291
bGQgbWVzcyBpdCB1cCwgc28gYmUgY2FyZWZ1bC4KCSAgOzsgWW91ciBpbml0IGZpbGUgc2hvdWxk
IGNvbnRhaW4gb25seSBvbmUgc3VjaCBpbnN0YW5jZS4KCSAgOzsgSWYgdGhlcmUgaXMgbW9yZSB0
aGFuIG9uZSwgdGhleSB3b24ndCB3b3JrIHJpZ2h0LgoJICAnKGNhbGVuZGFyLXZpZXctZGlhcnkt
aW5pdGlhbGx5LWZsYWcgdCkKCSAgJyhkZXNrdG9wLWJhc2UtZmlsZS1uYW1lICIuZW1hY3MtZGVz
a3RvcC5qdW5rIikKCSAgJyhkZXNrdG9wLXBhdGggKHF1b3RlICgifiIpKSkKCSAgJyhkZXNrdG9w
LXNhdmUtbW9kZSB0KQoJICAnKGRpYXJ5LWZpbGUgIn4vLmVtYWNzLmQvdG9kby9lbWFjcy50b2Rv
IikKCSAgJyhkaWFyeS1udW1iZXItb2YtZW50cmllcyAzMCkKCSAgJyhzYXZlaGlzdC1tb2RlIHQp
CgkgICcodG9kby13cmFwLWxpbmVzIHQpKQkKCQoJZW1hY3MKCU0teCB0b2RvLXNob3cKCU1ha2Ug
c3VyZSB0aGF0IHRvZG8gYnVmZmVyIHNob3dzIHVwIGZpbmUKCUMteCBDLWMgYW5kIHNhdmUgdGhl
IGRlc2t0b3AgZmlsZQoJCglSZS1sb2FkIGVtYWNzCglNLXggdG9nZ2xlLWRlYnVnLW9uLWVycm9y
CQoJTS14IHRvZG8tc2hvdwoJCglTZWUgZm9sbG93aW5nIHN0YWNrdHJhY2UuCQoJCglEZWJ1Z2dl
ciBlbnRlcmVkLS1MaXNwIGVycm9yOiAoZXJyb3IgIkNhdGVnb3J5IG5pbCBpcyBtaXNzaW5nIHRv
ZG8tY2F0ZWdvcnktZG9uZSBzdHJpbmciKQogIHNpZ25hbChlcnJvciAoIkNhdGVnb3J5IG5pbCBp
cyBtaXNzaW5nIHRvZG8tY2F0ZWdvcnktZG9uZSBzdHJpbmciKSkKICBlcnJvcigiQ2F0ZWdvcnkg
JXMgaXMgbWlzc2luZyB0b2RvLWNhdGVnb3J5LWRvbmUgc3RyaW5nIiBuaWwpCiAgdG9kby1jYXRl
Z29yeS1zZWxlY3QoKQogIHRvZG8tc2hvdyhuaWwgMSkKICBjYWxsLWludGVyYWN0aXZlbHkodG9k
by1zaG93IHJlY29yZCBuaWwpCiAgY29tbWFuZC1leGVjdXRlKHRvZG8tc2hvdyByZWNvcmQpCiAg
ZXhlY3V0ZS1leHRlbmRlZC1jb21tYW5kKG5pbCAidG9kby1zaG93IikKICBjYWxsLWludGVyYWN0
aXZlbHkoZXhlY3V0ZS1leHRlbmRlZC1jb21tYW5kIG5pbCBuaWwpCiAgY29tbWFuZC1leGVjdXRl
KGV4ZWN1dGUtZXh0ZW5kZWQtY29tbWFuZCkKCQpbQXVnIDI4LCAyMDEzXSBIaWdobGlnaHRpbmcg
cmVwb3J0cyBhbiBlcnJvcgoJCglGIEggb24gYW4gaXRlbSByZXN1bHRzIGluCgkKCSAgY2FsbC1p
bnRlcmFjdGl2ZWx5OiBTeW1ib2wncyB2YWx1ZSBhcyB2YXJpYWJsZSBpcyB2b2lkOiBobC1saW5l
LW1vZGUKCQpbQXVnIDI5LCAyMDEzXSB0b2RvLW1vZGUgbm90IHJlY29nbml6ZWQgd2l0aCBlbWFj
cyAtUQoJCgkxLiBlbWFjcyAtUQoJMi4gQy14IEMtZiB+Ly5lbWFjcy5kL3RvZG8vZW1hY3MudG9k
bwoJMy4gVGhlIGZpbGUgaXMgbm90IHZpc2l0ZWQgaW4gdG9kbyBtb2RlIGFuZCBoZW5jZSBub3Qg
Zm9udGlmaWVkLgoJCglJIHRoaW5rIGBhdXRvLW1vZGUtYWxpc3QnIHNob3VsZCBoYXZlIGFuIGVu
dHJ5IGZvciB0b2RvLW1vZGUgL2V2ZW4gaWYvIHRvZG8tbW9kZSBpcyBub3QgbG9hZGVkIGFwcmlv
cmkuCgkKCj09LS09PSBET05FIAotLT09LS0gdG9kby1tb2RlL2Rlc2lnbgpbQXVnIDI5LCAyMDEz
XSBDbGFyaWZ5IFtBdWcgMjksIDIwMTNdLCBBdWcgMjksMjAxMyBhbmQgJkF1ZyAyOSwgMjAxMyBl
bnRyaWVzCgkKCVRoZSBmb3JtZXIgaXMgbW9yZSBsaWtlIHdoZW4gdGhlIGVudHJ5IHdhcyBjcmVh
dGVkLiAgVGhlIHNlY29uZCBvbmUKCWlzIHdoYXQgdGhlIGRpYXJ5IGV4cGVjdHMgYXMgYW4gYWN0
aXZlIGVudHJ5LiAgVGhlIGxhc3Qgb25lIGlzCglkaXNhYmxlZCBmb3IgZGlhcnkgcHJvY2Vzc2lu
Zy4KCQoJRnJvbSBmdW5jdGlvbmFsIHN0YW5kcG9pbnQsIDEgYW5kIDMgc2VlbSBub3QgdmVyeSBk
aWZmZXJlbnQuICBJCgl0aGluayBbIF0gaXMgdGhlcmUgbW9zdGx5IGZvciBmaWxsaW5nIHVwIHBs
YWNlcyBhbmQgdG8gaW1wcm92ZQoJb3ZlcmFsbCBhZXN0aGV0aWNzLiAgV2Ugc2hvdWxkIHJlYWxs
eSBjb25zaWRlciBOT1QgaGF2aW5nIGEgZGF0ZQoJYXNzb2NpYXRlZCB3aXRoIGFuIGl0ZW0uCgkK
Cj09LS09PSBET05FIAotLT09LS0gdG9kby1tb2RlL2luZm8KW0F1ZyAyOCwgMjAxM10gTWVudGlv
biB0aGF0IGVudHJ5J3MgZGF0ZSBpcyBjb250cm9sbGVkIGJ5IGBjYWxlbmRhci1kYXRlLWRpc3Bs
YXktZm9ybScKCQpbQXVnIDI4LCAyMDEzXSBJbXByb3ZlIGRvY3VtZW50YXRpb24KCQoJRG9jdW1l
bnRhdGlvbiBpcyBnb29kIGFuZCB1c2VmdWwuICBQbGVhc2UgY29uc2lkZXIgZ2l2aW5nIHJlYWwt
bGlmZQoJZXhhbXBsZXMgb2YgaG93IFlPVSB1c2UgaXQuICBXaGF0IGRvZXMgYSB0b2RvIGZpbGUg
c3RhbmQgZm9yIGFuZAoJd2hhdCBjb3VsZCBiZSBwb3NzaWJsZSBjYXRlZ29yaWVzLCB3aGVuIGEg
bmVlZCBmb3Igc3BsaXR0aW5nIG9yCgltZXJnaW5nIGNhdGVnb3JpZXMgYXJpc2UgZXRjLgoJCglB
ZnRlciBleHBlcmltZW50aW5nIHdpdGggdG9kbyBtb2RlLCBJIGNvbnNpZGVyIHRvZG8tbW9kZSBh
cwoJZXNzZW50aWFsbHkgYSBmb250aWZpZWQgY29udmVudGlvbmFsIGRpYXJ5IGZpbGUgd2l0aCBz
b21lIGJlbGxzIGFuZAoJd2hpc3RsZXMuICBBbiBpbnRyb2R1Y3Rpb24gdGhhdCBzYXlzIHNvbWV0
aGluZyBpbiBzaW1pbGFyIHZlaW4gd2l0aAoJYSBpbmZvIGxpbmsgdG8gZGlhcnkgc3ludGF4IHdp
bGwgc2V0IHRoZSBtb29kIHJpZ2h0IGZvciBmdXJ0aGVyCglleHBsb3JhdGlvbi4KCQoJVGhlIHNl
Y3Rpb24gdGhhdCB0YWxrcyBhYm91dCB5IGsgYyBkIHNlcXVlbmNlIHNlZW1zIHRvIG9jY3VyIGEg
Yml0Cgl0b28gZWFybHkgaW4gdGhlIG1hbnVhbC4gIEl0IHNob3VsZCBiZSBwbGFjZWQgYSBiaXQg
bGF0ZSBpbiB0aGUKCW1hbnVhbC4gIE1lbnRpb25pbmcgdGhlIG1uZW1vbmljcyB1cGZyb250LCB5
ID0+IGRpYXJZIGsgPT4gbWFySyBldGMKCWlzICpnb29kKiB0aG91Z2guCgpbQXVnIDI4LCAyMDEz
XSBEb2VzIEMgc3RhbmQgZm9yICJ1cGNhc2VkIi1DIG9yIEN0cmwga2V5CgkKCUZvciBleGFtcGxl
LCBpbgoJICAoaW5mbyAiKHRvZG8tbW9kZSkgQ2F0ZWdvcnkgRWRpdGluZyIpCgkKCWFuZCBwb3Nz
aWJseSBvdGhlciBub2RlcywgaXQgaXMgZWFzeSB0byBiZSBjYXJyaWVkIGF3YXkgYnkKCW1pc3Rh
a2luZyBDIGFzIGNvbnRyb2wuICBUaGUgZG9jdW1lbnRhdGlvbiBtZW50aW9ucyB1cGZyb250IHRo
YXQgQwoJaXMgYWN0dWFsbHkgYWxwaGFiZXRpY2FsLUMgYnV0IGl0IGlzIGJ1cmllZCBkZWVwIHdp
dGhpbi4gIE1vcmUKCWltcG9ydGFudGx5IGEgcmVndWxhciBFbWFjcyB1c2VyIGNhbiBnZXQgY2Fy
cmllZCBhd2F5IGVhc2lseS4KCQoKPT0tLT09IERPTkUgCi0tPT0tLSB0b2RvLW1vZGUvbnVpc2Fu
Y2UKW0F1ZyAyOSwgMjAxM10gUmVwbGFjZSBDLXggQy1xIHdpdGggQy14IEMtcwoJCglTb21ldGlt
ZXMgSSBlbmQgdXAgZG9pbmcgQy14IEMtcSBhZnRlciBhbiBgRiBlJyBpbiB0aGUgdG9kby1tb2Rl
LgoJSXQgZW5kcyB1cCBlbmFibGluZy9kaXNhYmxpbmcgcmVhZC1vbmx5IG1vZGUgb24gdGhlIHRv
ZG8gZmlsZS4gIFNvCgl0aGUgY2hvaWNlIG9mIEMteCBDLXEgZm9yIHJlcGFpciBuZWVkcyBzb21l
IHJldmlldy4KCltBdWcgMzAsIDIwMTNdIEMteCBDLXEgc2hvdWxkIGVuc3VyZSBuZXdsaW5lIGF0
IHRoZSBlbmQgb2YgZW50cnkncyBkZXNjcmlwdGlvbgpbQXVnIDMwLCAyMDEzXSBSZXZpZXcgQy1h
IGluIGVkaXQgbW9kZQoJCglXaGVuIEkgcHJlc3MgUkVUIHRoZSBlbnR5IHdyYXBzIGF0IHRoZSB3
aW5kb3cncyBlZGdlLCB0aGUgY3Vyc29yCglyZXN0cyBhdCBjb2x1bW4gMy4gIEJ1dCBpZiBJIGRv
IEMtYSwgaXQgZ29lcyB0byB0aGUgc3RhcnQgb2YgdGhlCglsaW5lLiAgVGhlc2UgdHdvIGJlaGF2
aW91ciB0YWtlbiB0b2dldGhlciBpcyBjb25mdXNpbmcuCgoJSSBzZWUgdGhhdCBDLXggQy1xICJy
ZXBhaXJzIiB0aGUgZW50cnkgZGVzY3JpcHRpb24gYnkgYWRkaW5nIHRoZQoJbmVlZGVkIHByZWZp
eCBvbiB3cml0aW5nIHRvICoudG9kbyBmaWxlLCBJIGZlZWwgdGhpcyAzIChvcgoJd2hhdGV2ZXIp
LXNwYWNlIHJ1bGUgY291bGQgYmUgcmVsYXhlZC4gIEFzIEkgYW0gdHlwaW5nIHRoaXMgYnVnCgly
ZXBvcnQsIEkgcmVhbGl6ZSB0aGF0IEkgbmVlZCB0byBkbyBlIG0sIEMteCBDLXEgb25lIG1vcmUg
dGltZSB0bwoJZG8gdGhlIHByb3BlciByZXBhaXIuCgkKCUFmdGVyIGV4cGVyaW1lbnRpbmcgd2l0
aCAxMCBvZGQgZW50cmllcyBJIGZlZWwgdGhhdCBgZSBtJyBhbmQgYEMteAoJQy1xJyBzd2l0Y2gg
aXMgYSBiaXQgaGFyZCBvbiBteSB3cmlzdHMuICBUb28gbWFueSBjb250ZXh0IHN3aXRjaGVzLgoJ
SSB3b25kZXIgd2hldGhlciB0aGlzIGNvbnRleHQgc3dpdGNoIGNhbiBiZSBhdm9pZGVkLgoJCglJ
IHdvdWxkIG11Y2ggcHJlZmVyIE5PVCBzd2l0Y2hpbmcgYmV0d2VlbiB0b2RvIGFuZCBlZGl0IG1v
ZGVzIGFuZAoJcmF0aGVyIGhhdmUgYSBzaW5nbGUtc2hvdCByZXBhaXIgb2YgYWxsIGVkaXRlZCBp
dGVtcy4gIE1heSBiZQoJcmVwYWlyIG9uIHNhdmUgY291bGQgYmUgYSBnb29kIG9wdGlvbi4KCQpb
QXVnIDI5LCAyMDEzXSBBZGRpbmcgZW50cmllcyBkb2Vzbid0IHNjYWxlLiAgVG9vIG11Y2ggY29u
dGV4dCBzd2l0Y2ggd2l0aCBgZSBtJwoJCglDb25zaWRlciBpZGVhcyBmcm9tIGFsbC5lbCBvciBv
Y2N1ci1lZGl0IG1vZGUgZm9yIGVkaXRpbmcgImluIHBsYWNlIi4KCQoJRm9yIHJlcGFpciwgc2Vl
IGhvdyBzcmMgYmxvY2sgYXJlIGVkaXRlZCB3aXRoIEMtQyAnIGluIG9yZy1tb2RlLgoJCglCdHcs
IFJFVCBzZWVtcyBhIGdvb2QgcmVwbGFjZW1lbnQgZm9yIGBlIG0nLgoKPT0tLT09IERPTkUgCi0t
PT0tLSB0b2RvLW1vZGUvd2lzaApbQXVnIDI4LCAyMDEzXSBNZW51IGVudHJpZXMgZm9yIHRvZG8t
bW9kZQoJCgkJVGhpcyBpcyBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IGZvciBuZXcgdXNlcnMgbGlr
ZSBtZSB0byBtZW1vcml6ZSB0aGUga2V5IGJpbmRpbmdzLgoJCltBdWcgMjgsIDIwMTNdIERpc2Fi
bGUgYEYgZScKCQoJRG9uJ3QgcmVjb21tZW5kIGl0IGJ1dCBFTkZPUkNFIGl0LiAgRG8gdGhpcyBi
eSBwdXR0aW5nIGEgJ2Rpc2FibGVkIHByb3BlcnR5IHRvIHRoZSBjb21tYW5kLiAgU29tZXRoaW5n
IHZhcmlhdGlvbiBvZiAuLi4uCgkKCSAgKHB1dCAndG9kby1lZGl0LWZpbGUgJ2Rpc2FibGVkIHQp
CgkKW0F1ZyAyOCwgMjAxM10gRW5hYmxlIHNlbGVjdGl2ZSBkaXNwbGF5CgkKCShhZGQtaG9vayAn
dG9kby1tb2RlLWhvb2sgKGxhbWJkYSBuaWwgKHNldC1zZWxlY3RpdmUtZGlzcGxheSAxKSkpCgkK
CU1heSBiZSB0aGUgYWJvdmUgbGFtYmRhIGNhbiBnbyBhcyBwYXJ0IG9mIGBjdXN0b20tYWRkLWZy
ZXF1ZW50LXZhbHVlJy4KCQoJICAgICAoY3VzdG9tLWFkZC1mcmVxdWVudC12YWx1ZSAndG9kby1t
b2RlLWhvb2sgJ2JsYWgpCgkKCj09LS09PSBET05FIAotLT09LS0gdG9kby1tb2RlL21pbm9yCltB
dWcgMjksIDIwMTNdIEltcHJvdmUgYWVzdGhldGljcwoJCglBbGlnbm1lbnQgb2YgbnVtYmVycyBh
bmQgaGVhZGxpbmVzLiAgQWZ0ZXIgYWJvdXQgMTUgZW50cmllcyAodGhlCglmaWxlIHlvdSBhcmUg
cmVhZGluZyBpcyBhIGdvb2QgZXhhbXBsZSkgdGhlIGVudHJpZXMgbG9vayBzdGFnZ2VyZWQuCgkK
Cj09LS09PSBET05FIAo=
--=-=-=
Content-Type: text/plain
In GNU Emacs 24.3.50.2 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
of 2013-08-28 on porunai
Bzr revision: 114042 dmantipov@HIDDEN
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
Important settings:
value of $LANG: en_IN
locale-coding-system: iso-latin-1-unix
default enable-multibyte-characters: t
--=-=-=--
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Kanthimathi R <rkanthimathi@HIDDEN> Subject: bug#15225: Acknowledgement (24.3.50; todo-mode: Some bugs and suggestions) Message-ID: <handler.15225.B.13778866138241.ack <at> debbugs.gnu.org> References: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN> X-Gnu-PR-Message: ack 15225 X-Gnu-PR-Package: emacs Reply-To: 15225 <at> debbugs.gnu.org Date: Fri, 30 Aug 2013 18:17:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-gnu-emacs@HIDDEN If you wish to submit further information on this problem, please send it to 15225 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 15225: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15225 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
Resent-From: Jambunathan K <kjambunathan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 31 Aug 2013 04:06:01 +0000
Resent-Message-ID: <handler.15225.B15225.13779219371051 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: 15225 <at> debbugs.gnu.org
Received: via spool by 15225-submit <at> debbugs.gnu.org id=B15225.13779219371051
(code B ref 15225); Sat, 31 Aug 2013 04:06:01 +0000
Received: (at 15225) by debbugs.gnu.org; 31 Aug 2013 04:05:37 +0000
Received: from localhost ([127.0.0.1]:60536 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VFcRM-0000Gs-Pf
for submit <at> debbugs.gnu.org; Sat, 31 Aug 2013 00:05:37 -0400
Received: from mail-pa0-f47.google.com ([209.85.220.47]:37040)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <kjambunathan@HIDDEN>) id 1VFcRH-0000Gc-Ti
for 15225 <at> debbugs.gnu.org; Sat, 31 Aug 2013 00:05:32 -0400
Received: by mail-pa0-f47.google.com with SMTP id kl13so3082860pab.34
for <15225 <at> debbugs.gnu.org>; Fri, 30 Aug 2013 21:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-type;
bh=fGho1Vay08aM3MX3NkjuxpaEi6AUd5r9suy0DeDQ+iM=;
b=zu8CehTcVT2UTFwOir/FO/c/+TxW3JZapT/ceaU6it2YaPRC4oebV2NcehTbyRvND1
A5UOqTHiiFUwORzMEJeVhqJvzr+hJSWAHCsw537eQszFGuahcdhvEl7fEoVupnL+entM
4YqSMvbtFaVeTtWsv+YvBdSkLRoMWebU1jwJ9+Sb1xWpXCbv9Oes5kCa4hd01NHDKj5m
L602GW3OhEQM4GhuHjYliP8t1swOsuChFm6fxXOhwnAkAMBfrdkafg7HxasBztHjFp8S
JeoxbLgq4SZlPyyfNwabrTEDilD0DA1E+EYlo32x/f4/RFVwSiOMDhXtx5HjHb/HEC1k
UJwg==
X-Received: by 10.68.17.230 with SMTP id r6mr13495667pbd.112.1377921925964;
Fri, 30 Aug 2013 21:05:25 -0700 (PDT)
Received: from porunai ([101.63.191.18])
by mx.google.com with ESMTPSA id zi1sm1382771pbb.28.1969.12.31.16.00.00
(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
Fri, 30 Aug 2013 21:05:25 -0700 (PDT)
From: Jambunathan K <kjambunathan@HIDDEN>
References: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
Date: Sat, 31 Aug 2013 09:37:33 +0530
In-Reply-To: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN> (Kanthimathi R.'s
message of "Fri, 30 Aug 2013 23:48:28 +0530")
Message-ID: <87r4daa4fu.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
> To add to the entries in the attached file,
>
> 1. Undo support while in todo-mode.
>
> 2. The following markers used in the todo file
>
> --==--
> ==--==
>
> are they consistent with the outline-mode. If not, some consideration
> should be given so that they are compatible with outline-regexps.
Does the Info manual mention, that RET on a diary display takes you to
the todo file. If not it should.
AFAIK, in plain diary display, pressing RET doesn't take one to the
diary entry.
X-Loop: help-debbugs@HIDDEN
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
Resent-From: Jambunathan K <kjambunathan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 31 Aug 2013 12:38:03 +0000
Resent-Message-ID: <handler.15225.B15225.13779526454008 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: 15225 <at> debbugs.gnu.org
Received: via spool by 15225-submit <at> debbugs.gnu.org id=B15225.13779526454008
(code B ref 15225); Sat, 31 Aug 2013 12:38:03 +0000
Received: (at 15225) by debbugs.gnu.org; 31 Aug 2013 12:37:25 +0000
Received: from localhost ([127.0.0.1]:33091 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VFkQe-00012a-QD
for submit <at> debbugs.gnu.org; Sat, 31 Aug 2013 08:37:25 -0400
Received: from mail-pd0-f172.google.com ([209.85.192.172]:54292)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <kjambunathan@HIDDEN>) id 1VFkQc-00012G-Ll
for 15225 <at> debbugs.gnu.org; Sat, 31 Aug 2013 08:37:23 -0400
Received: by mail-pd0-f172.google.com with SMTP id z10so2935717pdj.3
for <15225 <at> debbugs.gnu.org>; Sat, 31 Aug 2013 05:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:to:subject:references:date:in-reply-to:message-id:user-agent
:mime-version:content-type;
bh=XM4fO0zSPbU1WMahxQGuAupucRMfWmd71xM9zK0HP+g=;
b=oYWlUoCb0Sn5j8K9DdeGgFWZEoWM1sy7Foo5HoZmnIFAYl8fLPvKzVmpm0idE0tgaP
lY4qR2eNhioIgeVpdf0J8cLq5FunqLrYXTz1a+nN0q0njDo1w/HJjD4726YSstw4LBVE
n9jqxBlnLpufSrhLFoZJcpKVlluQ2RcGRSN+ED4sVVbRKc5OrsRo3YnFzo1uA35Z9OCD
VhptPmkUfqTHh3r1W3iVdJaehCYuVFSvIwQDJc0QnKYoTfEmfcBp8uoAkHRQZno04aaR
9KzZMPnNXB42BxuPja4Z25pbE6Ga7NAmWDgZty7h50bu+MMsCSdFflFubkw2HKGKY3Wx
h9Mg==
X-Received: by 10.67.21.226 with SMTP id hn2mr16269880pad.69.1377952636564;
Sat, 31 Aug 2013 05:37:16 -0700 (PDT)
Received: from porunai ([101.63.196.46])
by mx.google.com with ESMTPSA id 7sm4382284paf.22.1969.12.31.16.00.00
(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
Sat, 31 Aug 2013 05:37:15 -0700 (PDT)
From: Jambunathan K <kjambunathan@HIDDEN>
References: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
<87r4daa4fu.fsf@HIDDEN>
Date: Sat, 31 Aug 2013 18:09:28 +0530
In-Reply-To: <87r4daa4fu.fsf@HIDDEN> (Jambunathan K.'s message of "Sat, 31
Aug 2013 09:37:33 +0530")
Message-ID: <878uzi3ugv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
1. `e m' on an item
2. C-x b
3. `e e' on an item
See the following:
todo-edit-multiline-item: Buffer name `*Todo Edit*' is in use [4
times]
I would expect that it switch to the buffer instead.
----------------------------------------------------------------
This is an error that occurs frequently and has made my todo file
practically unusable.
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
expand-file-name(nil)
find-file-noselect(nil nowarn)
todo-mode-external-set()
todo-edit-mode()
todo-edit-multiline-item()
call-interactively(todo-edit-multiline-item nil nil)
command-execute(todo-edit-multiline-item)
Once such a thing happens the todo file which was good to begin with
gets screwed and I really can do nothing more with it.
My STRONG RECOMMENDATION
To the users:
- Beware of todo-mode to create real life todo entries. It will make
you pay for it.
To the maintainer:
- PLEASE! Compute the sexp for categories on demand. Do you really
think that pre-computation is very much necessary speed up things on
large todo lists.
X-Loop: help-debbugs@HIDDEN
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
In-Reply-To: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
Resent-From: Stephen Berman <stephen.berman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 08 Sep 2013 21:08:02 +0000
Resent-Message-ID: <handler.15225.B15225.13786744524897 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Kanthimathi R <rkanthimathi@HIDDEN>
Cc: 15225 <at> debbugs.gnu.org, Jambunathan K <kjambunathan@HIDDEN>
Received: via spool by 15225-submit <at> debbugs.gnu.org id=B15225.13786744524897
(code B ref 15225); Sun, 08 Sep 2013 21:08:02 +0000
Received: (at 15225) by debbugs.gnu.org; 8 Sep 2013 21:07:32 +0000
Received: from localhost ([127.0.0.1]:49371 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VImCg-0001Gt-Ru
for submit <at> debbugs.gnu.org; Sun, 08 Sep 2013 17:07:32 -0400
Received: from mout.gmx.net ([212.227.17.22]:56205)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <stephen.berman@HIDDEN>) id 1VImCc-0001GZ-Dj
for 15225 <at> debbugs.gnu.org; Sun, 08 Sep 2013 17:07:28 -0400
Received: from rosalinde.fritz.box ([89.245.87.40]) by mail.gmx.com
(mrgmx001) with ESMTPSA (Nemesis) id 0Lw2Sj-1W1vgG1nkT-017loE for
<15225 <at> debbugs.gnu.org>; Sun, 08 Sep 2013 23:07:20 +0200
From: Stephen Berman <stephen.berman@HIDDEN>
References: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
Date: Sun, 08 Sep 2013 23:07:16 +0200
Message-ID: <87ppsj3tvf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K0:qu5IlzBrCdZcDqdi2WEYzsvidESQ6fFj2ooSdsAV0QVVdGR6/dO
keHrHy6usoIgRwwHK/g6BIJSskx0ouIGLum8FCzya+21VTVCeFJ/LRBSEIMeIfxKfTXeBSU
Ble+YThfG6Hmt92AVPRAIRK4qNh7J6V32k9q4JMydHHuDg4dOTHm6znJahePrRkARTrHTQl
kh/KxHq5A05ejFyVudg8A==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
On Fri, 30 Aug 2013 23:48:28 +0530 Kanthimathi R <rkanthimathi@HIDDEN> wrote:
> Quick feedback:
> --------------
>
> The interface for todo-mode looks good. Info documentation is good.
> The starting few nodes are a bit too dense while the later nodes seem
> like a lucid read.
Thanks for testing Todo mode and providing extensive feedback. Sorry
for not replying sooner; I was offline for a couple of weeks. I've
tried to respond to all your points below. In some cases I need more
details to be sure what you're suggesting, and it may be a while before
I can implement all suggestions I agree with. The clear bugs I'll try
to fix sooner.
> Recommendation:
> ---------------
>
> I would recommend it for simple todo-lists. Once the entries become
> more, then categorization of entries looks like a rocket science. (Or I
> should say, new users should be sufficiently trained.)
It's not clear to me what you're complaining about here. Can you be
more specific?
> Verdict:
> --------
>
> Too many moving parts and the module needs to stabilize a bit. I
> INVARIABLY run in to problems.
>
> Giving up:
> ---------
>
> 1. For example, as I was exercising todo-mode for preparing this bug
> report, the file ran in to an inconsistent state - A category with no
> todo or done items was reporting 6 entries in `F c' table.
This would certainly be a bug, but I can do nothing about it without a
reproducible recipe.
> I wondered whether deleting the categories sexp and C-x C-q ing would
> repair the todo file.
Before you did this you had typed `q' to exit Todo Categories mode and
return to Todo mode, where you typed `F e' to enter Todo Edit mode,
right? Note that the user manual urges caution when using `F e'. By
deleting the categories sexp you corrupted the internal file format,
which makes little or nothing work afterwards. I don't think
todo-mode.el should be required to recover from corruption due to user
manipulation of the internal format, but perhaps the user manual should
explicitly warn against doing that.
What I assume happened is that you deleted the categories sexp, but left
the first line empty. If you had deleted the entire first line, it
should have been possible to repair the sexp by typing `M-x
todo-repair-categories-sexp RET', but with an empty first line, you get
an "End of file during parsing" error when read is called on the empty
string. I could add code to prevent this particular error, but since it
arises as a result of user manipulation of the internal format, I think
the best advice is "Don't do that."
> Unfortunately, that doesn't help. So I am
> attaching a "broken" todo file.
To fix this file, first delete the empty first line. Then setq
todo-current-todo-file to the absolute file name of the file. (This
wouldn't be necessary if the file were already the current todo file,
but since we're now attempting to visit the file in Todo mode, it is not
yet current, and the corruption prevents it from becoming so.) Now
invoking todo-repair-categories-sexp will make the file recognizable by
Todo mode again.
> To add to the entries in the attached file,
>
> 1. Undo support while in todo-mode.
Please don't. Just fix the file as described and use the Todo mode
commands to add new items and otherwise manipulate the file.
> 2. The following markers used in the todo file
>
> --==--
> ==--==
>
> are they consistent with the outline-mode. If not, some consideration
> should be given so that they are compatible with outline-regexps.
These are part of the internal format and unless you use `F e', they are
not exposed, so as far as the user of Todo mode is concerned, they are
not available to manipulate, whether by Outline mode or any other way.
Why do you want to make them outline-aware?
> Additional comment:
> ------------------
>
> As some one who is familiar with (but doesn't use) Orgmode's data model,
> I can share some opinions, if permitted.
I'd be interested, since I know very little about Org (though your
"samurai sword" post to emacs-devel gave some hints).
> With no further ado, here comes the attachment. Repairing the attached
> file is reader's responsibility.
>
>
>
> --==-- 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.
> [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. Yet note there's also `i h', which inserts a new item with
the priority of the item at point, and since navigating to a category
always put point on the first item, subsequently calling `i h' amounts
to making the new item the first one (as does calling `i h' outside of
Todo mode or when point is in the done items section, as a special case
that in effect takes up your concern).
> [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.
> [Aug 30, 2013] A key binding for editing just the header line (say e h)
That functionality is bound to `e d t'. (I had at one point bound it to
`e h' but since the other commands with the prefix `e d' are for editing
parts of the date string, using it for the whole date/time header is
more consistent.)
> ==--== DONE
>
> --==-- 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
> [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.
> [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).
> ==--== DONE
> --==-- todo-mode/design
> [Aug 29, 2013] Clarify [Aug 29, 2013], Aug 29,2013 and &Aug 29, 2013 entries
>
> The former is more like when the entry was created.
This depends on the setting of the option `todo-include-in-diary'.
> The second one
> is what the diary expects as an active entry. The last one is
> disabled for diary processing.
>
> From functional standpoint, 1 and 3 seem not very different.
No, 3 prevents marking the date of the entry in the calendar (see
`diary-nonmarking-symbol'); the entry itself still appears in the diary.
In contrast, 1 prevents the todo item from appearing in the diary.
> I think [ ] is there mostly for filling up places and to improve
> overall aesthetics. We should really consider NOT having a date
> associated with an item.
That would be a rather large UI change; I'm not sure how easy it would
be to implement. I'm also not clear about what advantage it would
bring; do you have a use-case in mind? Note that you can toggle the
file-wide display of the date/time header with `F h'.
> ==--== DONE
> --==-- todo-mode/info
> [Aug 28, 2013] Mention that entry's date is controlled by `calendar-date-display-form'
I regard this as an implementation detail that isn't appropriate for the
Todo mode user manual. I think it's enough to know, as mentioned in
(info "(todo-mode) Todo Items as Diary Entries"), that todo items must
be recognized by the diary, if they are to be included in the diary.
The date format of todo item headers is not a Todo mode option, but is
automatically whatever the value of `calendar-date-display-form' is.
Users who know about this variable see that this is so, but those who
don't needn't be concerned with it.
> [Aug 28, 2013] Improve documentation
>
> Documentation is good and useful. Please consider giving real-life
> examples of how YOU use it. What does a todo file stand for and
> what could be possible categories, when a need for splitting or
> merging categories arise etc.
My intention and hope was that the manual's descriptions should indicate
or at least suggest potential uses, leaving specifics up to to users'
owns preferences or needs. Of course, my preferences and needs are
already reflected to an extent in the choice of commands and options and
how they work, and there are a few hints about possible workflows. I
may consider trying to expand on these somewhat, but I don't want to add
lengthy descriptions of how I use Todo mode, which might give the
impression that other uses are unsupported (and I hope the package is
flexible enough to support uses I haven't even thought of). However, if
the manual's descriptions are unclear anywhere, let me know and I'll try
to improve them.
> After experimenting with todo mode, I consider todo-mode as
> essentially a fontified conventional diary file with some bells and
> whistles. An introduction that says something in similar vein with
> a info link to diary syntax will set the mood right for further
> exploration.
This is certainly an important feature of Todo mode; isn't the node
mentioned above (which is part of the overview chapter of the manual)
sufficient? But I also think this aspect shouldn't outweigh other uses
for todo lists that Todo mode can facilitate.
> 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.)
> [Aug 28, 2013] Does C stand for "upcased"-C or Ctrl key
>
> For example, in
> (info "(todo-mode) Category Editing")
>
> and possibly other nodes, it is easy to be carried away by
> mistaking C as control. The documentation mentions upfront that C
> is actually alphabetical-C but it is buried deep within. More
> importantly a regular Emacs user can get carried away easily.
Well, it's mentioned in the short chapter Key Binding Conventions, so
that seems pretty easy to find; but I can perhaps emphasize that it's
not the control key.
> ==--== DONE
> --==-- todo-mode/nuisance
> [Aug 29, 2013] Replace C-x C-q with C-x C-s
>
> Sometimes I end up doing C-x C-q after an `F e' in the todo-mode.
> It ends up enabling/disabling read-only mode on the todo file. So
> the choice of C-x C-q for repair needs some review.
I assume you mean you sometimes type `C-x C-q' in Todo mode, after
having typed it to exit Todo Edit mode (which you enter with `F e'). I
don't think this should cause any problems, since the self-insertion
keys are disabled in Todo mode. My rationale for using `C-x C-q' to
exit Todo Edit mode is twofold: the mnemonic value of `q', and also
since exiting Todo Edit mode switches you from a writeable buffer to a
read-only one, it recalls the global value of that key sequence (which
is otherwise useless in Todo Edit mode). Binding `C-x C-s' to
todo-edit-quit, on the other hand, naturally leads to the expectation
that this also saves the buffer, which it doesn't. I could make it do
that, but I'm not convinced that the current behavior and key binding
are problematic.
> [Aug 30, 2013] C-x C-q should ensure newline at the end of entry's description
Why? New items are always added on a new line. Are you suggesting
items should be separated by an empty line? I'd prefer to let users
simply append a newline if they are so inclined.
> [Aug 30, 2013] Review C-a in edit mode
>
> When I press RET the enty wraps at the window's edge, the cursor
> rests at column 3. But if I do C-a, it goes to the start of the
> line. These two behaviour taken together is confusing.
I don't see this behavior; with the default setting of todo-wrap-lines,
C-a puts point on the beginning of the visually indented line. Can you
provide a recipe for what you describe?
> I see that C-x C-q "repairs" the entry description by adding the
> needed prefix on writing to *.todo file, I feel this 3 (or
> whatever)-space rule could be relaxed. As I am typing this bug
> report, I realize that I need to do e m, C-x C-q one more time to
> do the proper repair.
I'm not clear what you are referring to. The "repair" done by `C-x C-q'
on leaving Todo Edit mode is to ensure all lines of the todo item but
the first, which contains the date/time header, is indented. This is so
that if the item is included in the diary, it will be seen in its
entirety in the Fancy Diary display (see (info "(emacs) Format of Diary
File")). Are you saying you want to suppress this indentation? Is that
what you are calling "the proper repair"?
> After experimenting with 10 odd entries I feel that `e m' and `C-x
> C-q' switch is a bit hard on my wrists. Too many context switches.
> I wonder whether this context switch can be avoided.
>
> I would much prefer NOT switching between todo and edit modes and
> rather have a single-shot repair of all edited items. May be
> repair on save could be a good option.
Since you recommend below to disable `F e', which allows editing the
entire todo file, are you suggesting here to make it possible to
simultaneously edit all items in a category? While this would not
expose the entire internal file format, it would still pose a risk of
creating an inconsistant state and possible format corruption at the
item level (and also at the file level if you want to include the done
items section). I don't know how easy it would be to avoid such a risk,
which makes this alternative not much better than just using `F e' with
the necessary caution. But perhaps the packages you mention below have
relevant ideas I haven't thought of; I'll take a look, and thanks for
the pointers.
> [Aug 29, 2013] Adding entries doesn't scale. Too much context switch with `e m'
>
> Consider ideas from all.el or occur-edit mode for editing "in place".
>
> For repair, see how src block are edited with C-C ' in org-mode.
>
> Btw, RET seems a good replacement for `e m'.
I suppose RET could be an alternative binding, though it would be just
as plausible for `e e'. In fact, the latter is better, since
todo-edit-item (bound to `e e') calls todo-edit-multiline-item (bound to
`e m') if the item is longer than one visual line.
> ==--== DONE
> --==-- todo-mode/wish
> [Aug 28, 2013] Menu entries for todo-mode
>
> This is particularly important for new users like me to memorize the key bindings.
I wrote a menu for an earlier version, which extended the menu of the
original todo-mode.el, but as the number of commands increased, I felt
putting them all in would make the menu unwieldy, in particular all the
item insertion commands. But if the code for these can be reimplemented
as mentioned above, maybe a menu of the other commands would be
manageable. I'll try to look into it, but I'd welcome suggestions for
how to structure the menu.
> [Aug 28, 2013] Disable `F e'
>
> Don't recommend it but ENFORCE it. Do this by putting a 'disabled property to the command. Something variation of ....
>
> (put 'todo-edit-file 'disabled t)
This might be a good idea.
> [Aug 28, 2013] Enable selective display
>
> (add-hook 'todo-mode-hook (lambda nil (set-selective-display 1)))
>
> May be the above lambda can go as part of `custom-add-frequent-value'.
>
> (custom-add-frequent-value 'todo-mode-hook 'blah)
I'm not clear what you want selective display to be used for; is it to
"fold" longer todo items? Is that really so useful? Or do you have
something else in mind?
> ==--== DONE
> --==-- todo-mode/minor
> [Aug 29, 2013] Improve aesthetics
>
> Alignment of numbers and headlines. After about 15 entries (the
> file you are reading is a good example) the entries look staggered.
I'm not clear what you mean here (I don't see any staggering of items
when I visit this file in Todo mode); can you be more specific?
> ==--== DONE
Thanks again for your feedback. I'll reply to this thread when I check
in changes prompted by it.
Steve Berman
X-Loop: help-debbugs@HIDDEN
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
In-Reply-To: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
Resent-From: Stephen Berman <stephen.berman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 08 Sep 2013 21:09:02 +0000
Resent-Message-ID: <handler.15225.B15225.13786744934983 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Jambunathan K <kjambunathan@HIDDEN>
Cc: 15225 <at> debbugs.gnu.org
Received: via spool by 15225-submit <at> debbugs.gnu.org id=B15225.13786744934983
(code B ref 15225); Sun, 08 Sep 2013 21:09:02 +0000
Received: (at 15225) by debbugs.gnu.org; 8 Sep 2013 21:08:13 +0000
Received: from localhost ([127.0.0.1]:49375 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VImDM-0001IJ-IT
for submit <at> debbugs.gnu.org; Sun, 08 Sep 2013 17:08:12 -0400
Received: from mout.gmx.net ([212.227.17.21]:53132)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <stephen.berman@HIDDEN>) id 1VImDL-0001I5-Aq
for 15225 <at> debbugs.gnu.org; Sun, 08 Sep 2013 17:08:11 -0400
Received: from rosalinde.fritz.box ([89.245.87.40]) by mail.gmx.com
(mrgmx001) with ESMTPSA (Nemesis) id 0Lb5nF-1Vh5P349NJ-00kjED for
<15225 <at> debbugs.gnu.org>; Sun, 08 Sep 2013 23:08:05 +0200
From: Stephen Berman <stephen.berman@HIDDEN>
References: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
<87r4daa4fu.fsf@HIDDEN> <878uzi3ugv.fsf@HIDDEN>
Date: Sun, 08 Sep 2013 23:08:04 +0200
Message-ID: <87ob833tu3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K0:ZfMlzPwxXaQLS6xCjT+5R7a3jvmGtw6WwWynSrioSU4QDK2nktd
CJPbAojiLVanGW5Qqw9K1x4CAMujVSDPjgiJhTvNSZIBkpEpDv/gVPUE5OVHB6Q1ilFJQPc
h2ZKQX5f2VQJDbJmdCXqy/6IE0heub3TFPiyAdIh+FxB0KTdzqC7Lw7ZDtZ6+1UEmAGv+Gh
6YLUYwDt0PN0tBBS4jBBg==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
On Sat, 31 Aug 2013 18:09:28 +0530 Jambunathan K <kjambunathan@HIDDEN> wrote:
> 1. `e m' on an item
> 2. C-x b
> 3. `e e' on an item
>
> See the following:
>
> todo-edit-multiline-item: Buffer name `*Todo Edit*' is in use [4
> times]
This only happens with the above recipe if the item in step 1 is a
multiline item and in step 3 you type `e e' on the same item. It also
happens if in step 3 you type `e m' instead of `e e', and then it
doesn't matter whether the item is the same. The reason is because
todo-edit-multiline-item (bound to `e m') uses an indirect buffer (and
todo-edit-item (bound to `e e') calls todo-edit-multiline-item if the
item is multiline), and currently allows only a single instance, named
*Todo Edit*.
> I would expect that it switch to the buffer instead.
This is a reasonable expectation, but I think it's a bit involved to
implement correctly, because you have to keep track of which item from
the Todo mode buffer is associated with which indirect buffer, whose
content may have changed. I think I can make it work, but is it really
important to you to be able to have multiple item editing buffers? In
terms of key strokes, there's little difference between `C-x b'+`e m'
and `C-x C-q'+`e m'. (I understand from your other post that you'd
prefer to edit multiple items in a single buffer, but that's a different
functionality.)
> ----------------------------------------------------------------
>
> This is an error that occurs frequently and has made my todo file
> practically unusable.
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> expand-file-name(nil)
> find-file-noselect(nil nowarn)
> todo-mode-external-set()
> todo-edit-mode()
> todo-edit-multiline-item()
> call-interactively(todo-edit-multiline-item nil nil)
> command-execute(todo-edit-multiline-item)
>
> Once such a thing happens the todo file which was good to begin with
> gets screwed and I really can do nothing more with it.
The only thing I can say for sure here is that this happens because
find-file-noselect tries to find the current todo file but for some
reason there is none. This is certainly a bug, but to debug it I really
need a reproducible recipe.
> My STRONG RECOMMENDATION
>
> To the users:
>
> - Beware of todo-mode to create real life todo entries. It will make
> you pay for it.
I'll do my best to lower the cost where I can. Can you tell me
specifically what you consider overpriced?
> To the maintainer:
>
> - PLEASE! Compute the sexp for categories on demand. Do you really
> think that pre-computation is very much necessary speed up things on
> large todo lists.
I'm not sure it is, but I tried to use the stored value only where
on-the-fly computation wasn't necessary. Is there some place you think
I missed?
Steve Berman
X-Loop: help-debbugs@HIDDEN
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
In-Reply-To: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
Resent-From: Stephen Berman <stephen.berman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 08 Sep 2013 21:09:02 +0000
Resent-Message-ID: <handler.15225.B15225.13786745205027 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Jambunathan K <kjambunathan@HIDDEN>
Cc: 15225 <at> debbugs.gnu.org
Received: via spool by 15225-submit <at> debbugs.gnu.org id=B15225.13786745205027
(code B ref 15225); Sun, 08 Sep 2013 21:09:02 +0000
Received: (at 15225) by debbugs.gnu.org; 8 Sep 2013 21:08:40 +0000
Received: from localhost ([127.0.0.1]:49379 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VImDn-0001J1-Ec
for submit <at> debbugs.gnu.org; Sun, 08 Sep 2013 17:08:39 -0400
Received: from mout.gmx.net ([212.227.15.18]:54111)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <stephen.berman@HIDDEN>) id 1VImDl-0001Ij-NR
for 15225 <at> debbugs.gnu.org; Sun, 08 Sep 2013 17:08:38 -0400
Received: from rosalinde.fritz.box ([89.245.87.40]) by mail.gmx.com
(mrgmx001) with ESMTPSA (Nemesis) id 0LxPuE-1W3J6j3Eeg-016w5X for
<15225 <at> debbugs.gnu.org>; Sun, 08 Sep 2013 23:08:32 +0200
From: Stephen Berman <stephen.berman@HIDDEN>
References: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
<87r4daa4fu.fsf@HIDDEN>
Date: Sun, 08 Sep 2013 23:08:31 +0200
Message-ID: <87mwnn3ttc.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K0:fCfoPc+epn9nwanItxWBgOVvcrlq71RYuOKXriL4CRnua+rJPUH
2zrehmN5E3aeOE+NjqVlj3yJvii7hhbLCtGAlS0S9A2KN6QXuvNGgo9+xiKJjxjT1t7+rVR
HiK9R9tViQK9abdb26i7aJXBVGgQj1VALGIiIRbXp+ACFE41eQHxeFa2z+0Y7UpPXzSb9V7
XxBycDSDu62qmgT4bazIQ==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
On Sat, 31 Aug 2013 09:37:33 +0530 Jambunathan K <kjambunathan@HIDDEN> wrote:
>> To add to the entries in the attached file,
>>
>> 1. Undo support while in todo-mode.
>>
>> 2. The following markers used in the todo file
>>
>> --==--
>> ==--==
>>
>> are they consistent with the outline-mode. If not, some consideration
>> should be given so that they are compatible with outline-regexps.
>
> Does the Info manual mention, that RET on a diary display takes you to
> the todo file. If not it should.
This is mentioned in (info "(todo-mode) Todo Items as Diary Entries"):
The Fancy Diary display is also Todo mode aware: if it contains an
item from a Todo mode file, clicking or typing <RET> on this item will
switch to the buffer visiting that file and properly display the item's
category, with point on the item.
> AFAIK, in plain diary display, pressing RET doesn't take one to the
> diary entry.
Right, that's a feature of the Fancy Diary display only.
Steve Berman
X-Loop: help-debbugs@HIDDEN
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
Resent-From: Stephen Berman <stephen.berman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 20 Dec 2013 17:45:03 +0000
Resent-Message-ID: <handler.15225.B15225.13875615003769 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Jambunathan K <kjambunathan@HIDDEN>
Cc: 15225 <at> debbugs.gnu.org
Received: via spool by 15225-submit <at> debbugs.gnu.org id=B15225.13875615003769
(code B ref 15225); Fri, 20 Dec 2013 17:45:03 +0000
Received: (at 15225) by debbugs.gnu.org; 20 Dec 2013 17:45:00 +0000
Received: from localhost ([127.0.0.1]:60392 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Vu48B-0000yj-CE
for submit <at> debbugs.gnu.org; Fri, 20 Dec 2013 12:45:00 -0500
Received: from mout.gmx.net ([212.227.17.20]:59602)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <stephen.berman@HIDDEN>) id 1Vu487-0000yX-2W
for 15225 <at> debbugs.gnu.org; Fri, 20 Dec 2013 12:44:56 -0500
Received: from rosalinde.fritz.box ([89.245.77.92]) by mail.gmx.com (mrgmx002)
with ESMTPSA (Nemesis) id 0LfSeH-1VA4Gy1lGb-00p2mP for
<15225 <at> debbugs.gnu.org>; Fri, 20 Dec 2013 18:44:53 +0100
From: Stephen Berman <stephen.berman@HIDDEN>
References: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
<87ppsj3tvf.fsf@HIDDEN>
Date: Fri, 20 Dec 2013 18:44:52 +0100
In-Reply-To: <87ppsj3tvf.fsf@HIDDEN> (Stephen Berman's message of
"Sun, 08 Sep 2013 23:07:16 +0200")
Message-ID: <871u172z8r.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K0:iNnf7hPRebBZnostrPzOSSjYmD88/qJw8wY2hINQUmlfqWTj0Jr
GxNk7uEdKwOHhY87hqostcQ3B0hZE+cs3jZ3+9CRM9BklxjwSQtkpZL4C4LeAgupUj9dR4G
+NWH1cEfDhcCpcFQI/jKXv3j+cQrV9IfEkJ2X3IYN8z9SeKammVyojg0rA0Nr1xUJIYx3hE
JAi2tRd8hshxpP5o4HWdA==
X-Spam-Score: -0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)
On Sun, 08 Sep 2013 23:07:16 +0200 Stephen Berman <stephen.berman@HIDDEN> wrote:
> On Fri, 30 Aug 2013 23:48:28 +0530 Kanthimathi R <rkanthimathi@HIDDEN> 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
X-Loop: help-debbugs@HIDDEN
Subject: bug#15225: 24.3.50; todo-mode: Some bugs and suggestions
Resent-From: Jambunathan K <kjambunathan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 21 Dec 2013 07:21:03 +0000
Resent-Message-ID: <handler.15225.B15225.13876104479640 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15225
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stephen Berman <stephen.berman@HIDDEN>
Cc: 15225 <at> debbugs.gnu.org
Received: via spool by 15225-submit <at> debbugs.gnu.org id=B15225.13876104479640
(code B ref 15225); Sat, 21 Dec 2013 07:21:03 +0000
Received: (at 15225) by debbugs.gnu.org; 21 Dec 2013 07:20:47 +0000
Received: from localhost ([127.0.0.1]:60724 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VuGre-0002VJ-Vz
for submit <at> debbugs.gnu.org; Sat, 21 Dec 2013 02:20:47 -0500
Received: from mail-pa0-f52.google.com ([209.85.220.52]:37993)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <kjambunathan@HIDDEN>) id 1VuCf5-0001a3-Tm
for 15225 <at> debbugs.gnu.org; Fri, 20 Dec 2013 21:51:32 -0500
Received: by mail-pa0-f52.google.com with SMTP id ld10so3396092pab.11
for <15225 <at> debbugs.gnu.org>; Fri, 20 Dec 2013 18:51:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-type;
bh=+VKgfJEyTyt8ilFZDFsdqOYF+4nYoXbH/XqUzEw4E6Y=;
b=G9NkcOPNq00XItR67bSEX3kECYjP4g5BG2Z/HVD7jfhOIqbpFQa5UPDFLfRjuWHgTJ
t9qvlE1boYkcwax6wQnnK/UP+zvql8rTWX3CdJHRpt76ir3mePgshNAWesRxKQbmMHhS
ZDqy9kAL6mEkzvGyaFzFSkBK1Fu0zCo2qz5pdpk15UU+G3YBrCtkQCR7KSZneeT5LV8U
EmEkJHvzMyfNPCSb3p5wrtcBIRAPJQJ6B//fNDQMfTgMhjNVMetFoWPqK/CuK8Bw2ee6
2xMNAYdZq5Rl+eCXzy/IFBuaQoQXaVY28+LRxNZLd8U6BkJsWl/Ml5FmBXPBJdhNv3l0
qhgQ==
X-Received: by 10.67.22.67 with SMTP id hq3mr12406280pad.132.1387594289603;
Fri, 20 Dec 2013 18:51:29 -0800 (PST)
Received: from debian-6.05 ([115.242.163.220])
by mx.google.com with ESMTPSA id q7sm17601620pbc.20.2013.12.20.18.51.26
for <multiple recipients>
(version=TLSv1.1 cipher=RC4-SHA bits=128/128);
Fri, 20 Dec 2013 18:51:28 -0800 (PST)
From: Jambunathan K <kjambunathan@HIDDEN>
References: <BLU0-SMTP434CD292F2D127A65E9A0C691350@HIDDEN>
<87ppsj3tvf.fsf@HIDDEN>
<871u172z8r.fsf@HIDDEN>
Date: Sat, 21 Dec 2013 08:20:39 +0530
In-Reply-To: <871u172z8r.fsf@HIDDEN> (Stephen Berman's message of
"Fri, 20 Dec 2013 18:44:52 +0100")
Message-ID: <8738lmgbnk.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Mailman-Approved-At: Sat, 21 Dec 2013 02:20:43 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)
Stephen Berman <stephen.berman@HIDDEN> writes:
> In the mean time I'll leave this bug open.
Thanks for the fixes. Let me test run your new changes...
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.