From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Re: Trouble setting variables in custom agenda command Date: Thu, 4 Jun 2009 09:49:19 +0200 Message-ID: <08FF8C08-A8CA-4DC9-B5C4-86240CA36B11@gmail.com> References: <20090527020507.GA5071@owl.prv.maya.com> <87my8puoa7.fsf@gollum.intra.norang.ca> <11098.1244067981@alphaville.usa.hp.com> <11277.1244069970@alphaville.usa.hp.com> Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MC7ha-00075G-IC for emacs-orgmode@gnu.org; Thu, 04 Jun 2009 03:49:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MC7hV-00073Z-B3 for emacs-orgmode@gnu.org; Thu, 04 Jun 2009 03:49:30 -0400 Received: from [199.232.76.173] (port=47339 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MC7hU-00073T-SK for emacs-orgmode@gnu.org; Thu, 04 Jun 2009 03:49:24 -0400 Received: from mx20.gnu.org ([199.232.41.8]:62775) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MC7hU-000080-7B for emacs-orgmode@gnu.org; Thu, 04 Jun 2009 03:49:24 -0400 Received: from mail-ew0-f210.google.com ([209.85.219.210]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MC7hS-00028C-TF for emacs-orgmode@gnu.org; Thu, 04 Jun 2009 03:49:23 -0400 Received: by mail-ew0-f210.google.com with SMTP id 6so841341ewy.42 for ; Thu, 04 Jun 2009 00:49:22 -0700 (PDT) In-Reply-To: <11277.1244069970@alphaville.usa.hp.com> 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: nicholas.dokos@hp.com Cc: Bernt Hansen , Matthew Lundin , emacs org-mode mailing list , Christopher DeMarco Hi, wow, what a fantastic response to my request, thank you all very much for contributing pieces to this puzzle. There are several issues here. 1. Christopher did define his agenda command incorrectly (I know this variable is very complex... ). You defined the command as a block agenda where in principle several agenda lists can be combined in a single view. You can see this by setting org-agenda-custom-commands just to the single entry like Bernt did in his setup, and then try to customize this variable. A block agenda has *two* places where options can be stored. One set of options for just the individual command, and one set for for the block as a whole. Things like org-agenda-start-with-column-view need to be set there, because they are only used in that final cleanup that happens in the second call to org-finalize-agenda, as Nick has described. 2. I had a bug for agenda series: As Nick has pointed out, the agenda buffer is created and things like log-mode are set up before the options are scoped with let. I have now fixed this, the buffer creation gets the *global* agenda series variables scoped as well. Note: NOT the local ones. Christopher, after getting the latest release with my fix, there are now two possibilities how you can write your command, to achieve what you wanted. 1. As this is only a single block, you can reformulate this as a single agenda command, not a series: (setq org-agenda-custom-commands '(("c" agenda nil ( (org-agenda-overriding-columns-format "%75ITEM %7Effort{:} %7CLOCKSUM{Total} %15TAGS %SCHEDULED") (org-agenda-view-columns-initially t) (org-agenda-start-with-log-mode t) (org-agenda-ndays 1) (org-agenda-skip-function '(org-agenda-skip-entry-if 'notregexp "\\* TODO")))))) 2. Keep it as a block in an agenda series, but then move the variables that are not specific for the block out: (setq org-agenda-custom-commands '(("c" "The Cycle" ((agenda "" ((org-agenda-ndays 1) (org-agenda-skip-function '(org-agenda-skip-entry-if 'notregexp "\\* TODO"))))) ((org-agenda-overriding-columns-format "%75ITEM %7Effort{:} %7CLOCKSUM{Total} %15TAGS %SCHEDULED") (org-agenda-view-columns-initially t) (org-agenda-start-with-log-mode t))))) You may also move all the settings into the global options block in this case. I do realize only now that the reason why you chose a block agenda may have been so that you could give the command a name, which is not possible in single commands. I also realize now that it was a mistake to not allow for a name also here. But I am not sure if there is an easy way to fix this without breaking legacy setups out there. Thanks again to everyone. If anyone has good proposals as to where to amend the documentation in order to avoid this issue, please let me know. - Carsten On Jun 4, 2009, at 12:59 AM, Nick Dokos wrote: > Nick Dokos wrote: > >> [Bernt, thanks very much for taking the time to do the set-up: it >> makes >> things so much easier!] >> >> I've made a little progress debugging this in the case of the >> org-agenda-start-with-log-mode variable: the doc for it says >> >> ,---- >> | org-agenda-start-with-log-mode is a variable defined in `org- >> agenda.el'. >> | Its value is nil >> | >> | Documentation: >> | The initial value of log-mode in a newly created agenda window. >> | >> | You can customize this variable. >> `---- >> >> Note that *initial*: it is only used once, in org-agenda-mode, to >> initialize org-agenda-show-log. So setting it in the definition of >> an >> agenda custom command (effectively in a (let ...) form) will not >> work: >> org-agenda-mode has been called already by the time the custom >> command >> is executed, and the global value of org-agenda-start-with-log-mode >> has >> been used to set org-agenda-show-log. Any local binding later on >> has no >> effect at all. >> >> So the workaround for this variable is to set org-agenda-show-log >> in the >> definition of the custom command. The following works as far as the >> log >> goes: >> >> (setq org-agenda-custom-commands >> '(("c" "The Cycle" >> ((agenda "" >> ( >> (org-agenda-overriding-columns-format "%75ITEM >> %7Effort{:} %7CLOCKSUM{Total} %15TAGS %SCHEDULED") ;; no >> (org-agenda-view-columns-initially t) ;; no >> (org-agenda-show-log t) ;;yes >> (org-agenda-ndays 1) ;; yes >> (org-agenda-skip-function ;; yes >> '(org-agenda-skip-entry-if 'notregexp "\\* >> TODO"))))) >> nil nil))) >> >> I presume that a similar problem afflicts the column view variables, >> but I have not gone there yet. >> > > The problem with the column variables is similar but not quite the > same: > column view is set in org-finalize, and org-finalize is called > *twice*: > > The custom commands are executed by org-run-agenda-series, which first > calls org-agenda-list with the (let ...) settings from the > definition of > the custom command and which eventually calls org-finalize with the > proper values of the column view variables. But once org-agenda-list > returns to org-run-agenda-series, the latter continues on and calls > org-finalize again with no (let ...) bindings. The last call wins and > column view loses. > > Thanks, > Nick > >