Re: Re: Trouble setting variables in custom agenda command

[Carsten Dominik <carsten.dominik@gmail.com>]

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 <nicholas.dokos@hp.com> 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
>
>