From: Ingo Lohmar <firstname.lastname@example.org> To: email@example.com Subject: Bug: org-agenda-buffer-name wrongly persists [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)] Date: Sat, 15 May 2021 11:40:35 +0000 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. ------------------------------------------------------------------------ The global variable org-agenda-buffer-name, once set, wrongly (IMO) affects all future agenda buffer names for composite commands. Minimal complete example (in emacs -q): ================================================================================ Evaluate (setq org-agenda-custom-commands '(("z" "Std Agenda" ((tags "select" ((org-agenda-overriding-header "*select*ed"))) (agenda "" ((org-agenda-span 2))))))) (("z" "Std Agenda" ((tags "select" ...) (agenda "" ...)))) (org-agenda nil "z") and get a custom agenda with the default buffer name "*Org Agenda*" (OK). Create a buffer "test.org" and switch it to `org-mode', insert a timestamp (C-c .). Now follow the timestamp link (C-c C-o), and get an agenda with buffer name "*Org Agenda(a:2021-05-15)" (OK). Now re-do (org-agenda nil "z") which has the same buffer name including the date (BUG). ================================================================================ I do not pretend to understand how the global variable org-agenda-buffer-name is supposed to work (not even mentioning the -sticky- functionality here). What I understand is the following: The org-agenda dispatcher let-binds o-a-buffer-name to the global value. "Simple" agenda commands (like a todo list) called from the dispatcher set this let-bound o-a-buffer-name, so they use the correct default value. "Composite" custom commands called via the dispatcher do not set the let-bound value, so they use the original let-bound value (the global value at the start of org-agenda). `org-follow-timestamp-link' calls the `org-agenda-list' command directly (not via the dispatcher), hence sets the global (not a local let-bound) value of o-a-buffer-name. I have little constructive advice to offer regarding a solution. It seems to me that the global variable o-a-buffer-name is only harmful and I would try to get rid of it, but I guess it is necessary for sticky agendas (not using them). Emacs : GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2021-05-01 Package: Org mode version 9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)
next reply other threads:[~2021-05-15 11:43 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-15 11:40 Ingo Lohmar [this message] 2021-06-19 15:22 ` [PATCH] " Ingo Lohmar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Bug: org-agenda-buffer-name wrongly persists [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this 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).