From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Dunsmore Subject: Re: Re: [PATCH] Stable key assignment for org-fast-tag-selection Date: Thu, 20 Jan 2011 20:27:38 -0600 Message-ID: <87ei876let.fsf@riotblast.dunsmor.com> References: <8739oxc143.fsf@riotblast.dunsmor.com> <87y66jghbi.fsf@altern.org> <87y66fxru5.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=37188 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pg6jI-0005I7-6S for emacs-orgmode@gnu.org; Thu, 20 Jan 2011 21:28:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pg6jG-0000s6-Qa for emacs-orgmode@gnu.org; Thu, 20 Jan 2011 21:28:00 -0500 Received: from deathroller.dunsmor.com ([98.129.169.48]:53507) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pg6jG-0000ry-Lc for emacs-orgmode@gnu.org; Thu, 20 Jan 2011 21:27:58 -0500 In-Reply-To: <87y66fxru5.fsf@fastmail.fm> (Matt Lundin's message of "Thu, 20 Jan 2011 15:06:42 -0500") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Matt Lundin Cc: emacs-orgmode@dunsmor.com, emacs-orgmode@gnu.org, Bastien Matt Lundin writes: > Bastien writes: > >> emacs-orgmode@dunsmor.com writes: >> >>> - Eval (setq org-use-fast-tag-selection t) >>> - Eval (setq org-fast-tag-selection-single-key "expert") >>> - Create a heading with tags :a1:a2: >>> - Create another heading with tags :a1:a2: >>> - Type "C-c a", "C-c a", "C-c a", "C-c a" >>> - Notice how it changes from a1 to a2 >> >> I reproduced this, well spotted. >> >>> Below is a patch to make the character assignment stable, given that all >>> of the same tags exist in the file each time it's run. >> >> Thanks for the patch! >> >> I was not able to apply it using the pw utility, so I made the change >> myself -- I forgot to do a "git commit --amend --author" tho, sorry! > > This patch breaks grouping in fast tag selection, since the sort > function ignores the grouping information provided in org-tag-alist. > > Here's a sample org-tag-alist: > > (setq org-tag-alist '((:startgroup . nil) > ("desk" . ?d) > ("email" . ?m) > ("hack" . ?k) > ("net" . ?n) > ("phone" . ?p) > (:endgroup . nil) > (:startgroup . nil) > ("home" . ?h) > ("yard" . ?y) > ("errands" . ?e) > (:endgroup . nil) > (:startgroup . nil) > ("read" . ?r) > ("script" .?s) > ("think" . ?t) > ("travel" . ?j) > (:endgroup . nil))) > > And here's the prompt for org-tag-alist: > > Inherited: inbox per prof > Current: > Next change exits > } > } > } > { { { [d] desk [m] email [e] errands [k] hack [h] home > [n] net [p] phone [r] read [s] script [t] think > [j] travel [y] yard Good catch. I see the problem. --8<---------------cut here---------------start------------->8--- (sort org-tag-alist (lambda (a b) (string< (car a) (car b)))) --8<---------------cut here---------------end--------------->8--- Yields: --8<---------------cut here---------------start------------->8--- ((:endgroup) (:endgroup) (:endgroup) (:startgroup) (:startgroup) (:startgroup) ("desk" . 100) ("email" . 109) ("errands" . 101) ("hack" . 107) ("home" . 104) ("net" . 110) ("phone" . 112) ("read" . 114) ("script" . 115) ("think" . 116) ("travel" . 106) ("yard" . 121)) --8<---------------cut here---------------end--------------->8--- And a bunch of code relies on the position of the :startgroup and :endgroup dummy tags. I wonder why this design was chosen instead of using a list of alists for grouping. For example: --8<---------------cut here---------------start------------->8--- (setq org-tag-alist '((("desk" . ?d) ("email" . ?m) ("hack" . ?k) ("net" . ?n) ("phone" . ?p)) (("home" . ?h) ("yard" . ?y) ("errands" . ?e)) (("read" . ?r) ("script" .?s) ("think" . ?t) ("travel" . ?j)))) --8<---------------cut here---------------end--------------->8--- Maybe org-tag-alist could either be an alist or a list of alists, and a simple (listp (caar org-tag-alist)) test could be used to see what form org-tag-alist is in and then handle accordingly. Does anybody see a problem with that approach? This doesn't seem like a trivial change, so my original patch should probably be reverted until this gets implemented properly. Regards, Jason