Re: Unintended consequences of removing org-speed-commands-user
Hi,
If you want to insert a new element in the list after a particular
element, you could do :
#+begin_src emacs-lisp
(let ((bk (cdr (member '("Agenda Views etc") org-speed-commands
(setf (cdr (member '("Agenda Views etc") org-speed-commands))
(cons '("@" . my-foobarized-speed-command) bk)))
#+end_src
Use append to insert a list of new elements instead of one.
Also simply add a new list at the end, use append :
#+begin_src emacs-lisp :results code
(setq org-speed-commands
(append org-speed-commands '(("my foo commands!")
("@" . my-foobarized-speed-command)
("&" . my-barfooized-speed-command
#+end_src
However if you define many new commands, simply redefining the whole
list is simpler ;)
Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]
Ihor Radchenko writes:
>> As others I am currently advising a lot of org display functions to make
>> them obey to my 'display-buffer-alist'. I hope for a better cooperation
>> from org to window.el.
>
> Can you elaborate? We are looking forward for ideas how to improve Org
> in this area. More concrete suggestions are welcome.
>
The last time I looked into org-todo I seen that somewhere a call to
split-window was make, so wathever I was trying to configure with
display-buffer-alist would not conclude.
Then I translated that from Doom's Emacs.
#+begin_src emacs-lisp
;; Ensure todo, agenda, and other minor popups are delegated to the popup
system.
;; needed for at least org-noter / org-insert-structure-template
(with-eval-after-load 'org
(advice-add #'org-switch-to-buffer-other-window :override
(defun +popup--org-pop-to-buffer-a (buf norecord)
"Use `pop-to-buffer' instead of `switch-to-buffer' to open
buffer.'"
(pop-to-buffer buf nil norecord)))
(defun +popup--suppress-delete-other-windows-a (fn args)
(cl-letf (((symbol-function #'delete-other-windows) #'ignore)
((symbol-function #'delete-window) #'ignore))
(apply fn args)))
(dolist (fn '(org-add-log-note
org-capture-place-template
org-export--dispatch-ui
org-agenda-get-restriction-and-command
org-goto-location
org-fast-tag-selection
org-fast-todo-selection))
(advice-add fn :around #'+popup--suppress-delete-other-windows-a))
(advice-add #'org-fit-window-to-buffer :override #'fit-window-to-buffer))
#+end_src
You can see that it is not only the org-no-popup macro that is in
question but more generally the liberal usage of _split/switch/delete
windows_.
So if we want to make org cooperate with window.el we must ban theses
functions and instead delegate the window management with calls to
proper display functions.
Concretly if you look at org-fast-todo-selection you can see :
(if expert
(set-buffer (get-buffer-create " *Org todo*"))
(delete-other-windows)
(set-window-buffer (split-window-vertically) (get-buffer-create "
*Org todo*"))
(org-switch-to-buffer-other-window " *Org todo*"))
Now consider in place :
(set-buffer (get-buffer-create " *Org todo*"))
(unless expert
(display-buffer " *Org todo*"
'((display-buffer-below-selected)
(window-height . fit-window-to-buffer
It will display this buffer below the currently selected window and fit
him.
Let's imagine the user wants in place to use :
(add-to-list 'display-buffer-alist
'(" *Org todo*"
(display-buffer-in-side-window)
(side . top)))
Now the buffer display in a side window at top.
Re: Bug: org-no-popups disregards display-buffer-fallback-action [9.4.6 (9.4.6-13-g4be129-elpaplus @ /home/jeeger/.emacs.d/elpa/org-plus-contrib-20210920/)]
I just inspected the git version. Is the macro 'org-no-popups' setting _'pop-up-windows' to nil_ and is only used by 'org-switch-to-buffer-other-window' that call 'switch-to-buffer-other-window' which in turn, set _'pop-up-windows' to t_ ? Also 'pop-up-windows', 'pop-up-frame' are announced to be « provided mainly for backward compatibility and should not be used in new code ». As others I am currently advising a lot of org display functions to make them obey to my 'display-buffer-alist'. I hope for a better cooperation from org to window.el. Best regards, Dal.
