emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Fix for bug in org-capture
@ 2013-04-15 22:14 Robert Goldman
  2013-04-16  7:29 ` Bastien
  0 siblings, 1 reply; 4+ messages in thread
From: Robert Goldman @ 2013-04-15 22:14 UTC (permalink / raw)
  To: Org Mode

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

I tried to make two submenus to my org-capture templates: a prefix key
"t" (for TODO) and a prefix key "T" (for today's TODO).

When I tried to use them, the "T" key did not appear and was not accepted.

Looking more deeply, it appears that it was filtered out by a mistakenly
case-folding (or at least potentially case-folding) search in org-capture.

I am attaching a diff which has the two line fix for this bug.

[-- Attachment #2: org-capture.patch --]
[-- Type: text/plain, Size: 616 bytes --]

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index d8e62a1..861d640 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1431,7 +1431,8 @@ only the bare key is returned."
 	      (insert prefix "[" dkey "]" "..." "  " ddesc "..." "\n")
 	      ;; Skip keys which are below this prefix
 	      (setq re (concat "\\`" (regexp-quote dkey)))
-	      (while (and tbl (string-match re (caar tbl))) (pop tbl)))
+	      (let ((case-fold-search nil))
+		(while (and tbl (string-match re (caar tbl))) (pop tbl))))
 	     ((= 2 (length (car tbl)))
 	      ;; Not yet a usable description, skip it
 	      )

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: Fix for bug in org-capture
  2013-04-15 22:14 Fix for bug in org-capture Robert Goldman
@ 2013-04-16  7:29 ` Bastien
  2013-04-16 16:06   ` Robert Goldman
  0 siblings, 1 reply; 4+ messages in thread
From: Bastien @ 2013-04-16  7:29 UTC (permalink / raw)
  To: Robert Goldman; +Cc: Org Mode

Hi Robert,

Robert Goldman <rpgoldman@sift.info> writes:

> I tried to make two submenus to my org-capture templates: a prefix key
> "t" (for TODO) and a prefix key "T" (for today's TODO).
>
> When I tried to use them, the "T" key did not appear and was not accepted.
>
> Looking more deeply, it appears that it was filtered out by a mistakenly
> case-folding (or at least potentially case-folding) search in org-capture.

I cannot reproduce this.

I have these two captures templates:

(setq org-capture-templates
      '(
	("Ir" "Information read" entry (file+headline "~/org/garden.org" "Infos")
	 "* TODO %?%a :Read:\n  :PROPERTIES:\n  :CAPTURED: %U\n  :END:\n\n%i" :prepend t)

	("IR" "Information read (!)" entry (file+headline "~/org/garden.org" "Infos")
	 "* TODO %?%a :Read:\n  :PROPERTIES:\n  :CAPTURED: %U\n  :END:\n\n%i" :prepend t :immediate-finish t)
       ))

They are both recognized well.

Maybe you can try with this minimal example and tell if you can
still reproduce the problem?  Also let us know what version of Org
you are using.

> I am attaching a diff which has the two line fix for this bug.

I'll apply it if we can reproduce and narrow down the problem.

Thanks,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Fix for bug in org-capture
  2013-04-16  7:29 ` Bastien
@ 2013-04-16 16:06   ` Robert Goldman
  2013-04-16 16:27     ` Bastien
  0 siblings, 1 reply; 4+ messages in thread
From: Robert Goldman @ 2013-04-16 16:06 UTC (permalink / raw)
  To: Bastien; +Cc: Org Mode

Bastien wrote:
> Hi Robert,
> 
> Robert Goldman <rpgoldman@sift.info> writes:
> 
>> I tried to make two submenus to my org-capture templates: a prefix key
>> "t" (for TODO) and a prefix key "T" (for today's TODO).
>>
>> When I tried to use them, the "T" key did not appear and was not accepted.
>>
>> Looking more deeply, it appears that it was filtered out by a mistakenly
>> case-folding (or at least potentially case-folding) search in org-capture.
> 
> I cannot reproduce this.
> 
> I have these two captures templates:
> 
> (setq org-capture-templates
>       '(
> 	("Ir" "Information read" entry (file+headline "~/org/garden.org" "Infos")
> 	 "* TODO %?%a :Read:\n  :PROPERTIES:\n  :CAPTURED: %U\n  :END:\n\n%i" :prepend t)
> 
> 	("IR" "Information read (!)" entry (file+headline "~/org/garden.org" "Infos")
> 	 "* TODO %?%a :Read:\n  :PROPERTIES:\n  :CAPTURED: %U\n  :END:\n\n%i" :prepend t :immediate-finish t)
>        ))
> 
> They are both recognized well.

This isn't actually the same as my bug (which I didn't explain
adequately).  A closer equivalent to mine would have been to have both
"i" and "I", not both "r" and "R".

Here's the bit of my config:

(defvar rpg-org-remember-todo-template
    "* TODO %^{todo title}\n   %?")

(setq org-capture-templates
      `(
        ("t" "Templates for TODO items.")
	("tw" "Work Todo" entry (file+headline "~/org/todo.org" "Tasks")
,rpg-org-remember-todo-template)
	("tp" "Personal Todo" entry (file+headline "~/personal/org/todo.org"
"Tasks") ,rpg-org-remember-todo-template)
        ("T" "Templates for today TODO items.")
        ("Tw" "Today work todo" entry (file+headline "~/org/todo.org"
"Tasks")
                  "* TODO %^{todo title}\n   SCHEDULED: %t\n   %?")
        ("Tp" "Today personal todo" entry (file+headline
"~/personal/org/todo.org" "Tasks")
                  "* TODO %^{todo title}\n   SCHEDULED: %t\n   %?"))

You will see above that it's the prefix keys, not the suffix keys that
causes the problem.

Also, note that if I delete the lines defining the prefix keys:

        ("t" "Templates for TODO items.")
        ("T" "Templates for today TODO items.")

the problem goes away.  You don't seem to have such definitions in your
code.

> 
> Maybe you can try with this minimal example and tell if you can
> still reproduce the problem?  Also let us know what version of Org
> you are using.

I can replicate this with head pulled within the past hour.
> 
>> I am attaching a diff which has the two line fix for this bug.
> 
> I'll apply it if we can reproduce and narrow down the problem.

BTW, I would actually argue that my fix is right, even if you could not
replicate down the problem.  This use of the string matching function
incorrectly allows global state to bleed into the functioning of the
calling function.  If you *know* (as here) that case-fold-search should
be nil (because the org manual dictates that these keys are case
sensitive), then you should never allow a surrounding binding of
case-fold-search to bleed into the function.

The use of dynamic binding complicates replication, because global state
(binding of case-fold-search) dictates whether this function as written
behaves correctly or not.

Hope that clarifies,
cheers,
r

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Fix for bug in org-capture
  2013-04-16 16:06   ` Robert Goldman
@ 2013-04-16 16:27     ` Bastien
  0 siblings, 0 replies; 4+ messages in thread
From: Bastien @ 2013-04-16 16:27 UTC (permalink / raw)
  To: Robert Goldman; +Cc: Org Mode

Hi Robert,

Robert Goldman <rpgoldman@sift.info> writes:

> Hope that clarifies,

It does, fixed, thanks.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-04-16 16:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-15 22:14 Fix for bug in org-capture Robert Goldman
2013-04-16  7:29 ` Bastien
2013-04-16 16:06   ` Robert Goldman
2013-04-16 16:27     ` Bastien

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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