Re: Bug: org-no-popups disregards display-buffer-fallback-action 9.4.6
Hello!
On 13.11.21 14:15, Max Nikulin wrote:
Some users prefers multiple frames, others multiple windows in a full-screen
frame. Could you, please, briefly describe what kind of behavior you are truing
to achieve?
My thought is that I have a perfectly good window manager that allows me to
manage Emacs frames. This removes the need for things to improve window
switching (such as winner, which I used previously). Popping up frames to show
multiple things at the same time integrates well with my WM, and doesn't force
me to remap things like `C-x o`, which I find cumbersome to use. There are
packages that make window switching easier, but I've already configured my
window manager. Thus, I prefer to have my window manager manage Emacs frames,
instead of adding yet another way to switch between multiple things being
displayed at the same time, which I would have to do using Emacs windows.
My current configuration is as follows:
(setq display-buffer-base-action '((display-buffer-reuse-window
display-buffer-pop-up-frame)
(reusable-frames . 0)))
(setq display-buffer-alist
`(("\\*Packages\\*" display-buffer-pop-up-frame)
("\\*stdin.*\\*" display-buffer-same-window)
("\\*Help\\*" display-buffer-pop-up-frame)
("\\*.*\\*" display-buffer-pop-up-window)))
This allows me to pop up normal frames for regular buffers, and have special buffers pop
up in windows to fix the "focus stealing" behavior mentioned above.
The central problem with popping up frames is focus stealing: Things such as
undo-tree or embark don't deal well with having the focus stolen from the
current buffer by a new frame, which is why I needed to configure
`display-buffer-alist`.
Some Org buffers, in my opinion, should behave similarly to completion list. On
the other hand `minibuffer-completion-help' does not use
`display-buffer-overrining-action'. I do not like that this variable has higher
priority than `display-buffer-alist'. Action argument of `display-buffer' is
more appropriate since it keeps ability to customize placement of buffers with
particular names through `display-buffer-alist'.
I don't fully understand the `display-buffer-alist` definition, and copied
mostly from the documentation examples.
I hope this helps.
Best regards,
Jan
PS: Sorry for the empty mail I sent previously.
Re: Bug: org-no-popups disregards display-buffer-fallback-action 9.4.6
On 13.11.21 14:15, Max Nikulin wrote: On 10/11/2021 14:50, Jan Seeger wrote: I'm trying to make multi-frame emacsing nicer, and I encountered what I consider a bug with the `org-no-popups` macro in `org-macs.el`. `org-no-popups` tries to surpress the creation of new frames via setting `pop-up-frames` and `display-buffer-alist` to nil temporarily. This does not take `display-buffer-fallback-action` into account, which is the preferred way of making Emacs pop up new frames (or not, as the case may be). When the fallback variable is set, code run inside `org-no-popups` still creates new popups, which causes functions such as `org-insert-link` to fail, or at least act *very* confusingly. The preferred way of overriding the behavior of `display-buffer` for localized Emacs code seems to be the variable `display-buffer-overriding-action`. Changing the definition of `org-no-popups` to ``` (defmacro org-no-popups (&rest body) "Suppress popup windows and evaluate BODY." `(let ((display-buffer-overriding-action '(display-buffer-pop-up-window))) ,@body)) ``` correctly makes org pop up windows instead of frames. There were enough threads concerning displaying of buffers in Org, e.g. https://list.orgmode.org/87mtnovv7f@alphapapa.net https://list.orgmode.org/87zgrgke4b@ucl.ac.uk Some users prefers multiple frames, others multiple windows in a full-screen frame. Could you, please, briefly describe what kind of behavior you are truing to achieve? Overriding `display-buffer-alist' was certainly a mistake, users should be able to customize window creation. My impression is that `org-no-popups' is used in different scenarios that should have different default behavior. Some Org buffers, in my opinion, should behave similarly to completion list. On the other hand `minibuffer-completion-help' does not use `display-buffer-overrining-action'. I do not like that this variable has higher priority than `display-buffer-alist'. Action argument of `display-buffer' is more appropriate since it keeps ability to customize placement of buffers with particular names through `display-buffer-alist'. Thank you for suggesting `display-buffer-pop-up-window', current way of suppressing pop-up frames is unreliable. I am considering another option: '(nil (inhibit-switch-frame . t)) and I am unsure which variant is better. Actually I can not say that I really understand supposed ways to use `display-buffer' and related functions. My original expectation was that emacs should have a high level function for buffers similar to "*Completions*".
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/)]
On 10.11.21 11:20, Ihor Radchenko wrote: Jan Seeger via "General discussions about Org-mode." writes: Hello! I'm trying to make multi-frame emacsing nicer, and I encountered what I consider a bug with the `org-no-popups` macro in `org-macs.el`. This problem has been fixed in Org 9.5. Feel free to update. See https://orgmode.org/org.html#Installation for installation instructions. Best, Ihor Hello! Thanks for your help, turns out the org-mode package changed its name from what I was using, which is why it didn't update automatically. An upgrade did indeed solve the problem. Best regards, Jan
Re: Weird gap in agenda mode-line
Hi Ihor (sorry I have been calling you Igor for a while now :p), > (list "Org-Agenda" > (if (get 'org-agenda-files 'org-restrict) " []" "") > " " ;; <- this is the extra space > [...] > This part of code has not been changed from 2010. Ok then, nevermind the highlight issue which is probably related to my setup, what is reproducible is the "space issue" and the reason is obvious now. That said, what is the point of the list? What is the reason not to concatenate the parts into one single string? It looks and feels weird as if each section had its own menu while it's all the same thing. Best regards, Carlos
org-metashiftleft/right should honor org-support-shift-select
Hi all, on macOS option-shift-left / right extend the selection by one word. Emacs by default binds meta-shift-left / right in a way that is compatible with the system shortcuts. But org-mode interferes with these bindings even when org-support-shift-select is t. OTOH, an effort has been done to support shift selection in org-shiftcontrolleft / right. The problem is that macOS uses option instead of control to achieve selection by word. Best regards, Carlos
bug#51815: 27.2; Strange interaction between Org and Diary
Stephen Berman writes: > On Sat, 13 Nov 2021 21:29:03 +0200 Eli Zaretskii wrote: > >>> From: Robert Thorpe >>> Date: Sat, 13 Nov 2021 19:16:16 + >>> >>> I use Org mode but I also use the normal calendar and diary. >>> >>> This has an unwanted effect if I open an org file. After org has been >>> started the calendar no longer functions as expected. If I press "i d" >>> then it fails to insert an entry in the diary file. A warning in >>> *Messages* says: >>> >>> "command-execute: Wrong type argument: commandp, org-agenda-diary-entry" >>> >>> I don't use org-agenda, BTW. >>> >>> To clarify there are two conditions that are needed to see this >>> behaviour. >>> >>> 1) Org-mode has been started in the Emacs session. >>> >>> It does not happen if org-mode hasn't been started (e.g. by opening an >>> org file in another buffer). >>> >>> 2) Org-mode must be started first before calendar. >>> >>> If calendar is started first and org-mode is started second then the >>> calendar works. >> >> Which version of Org are you using? the one that came with Emacs 27.2 >> or something else? > > This is bug#48199, which was fixed in Org bundled with Emacs 28, so the > version of Org in GNU ELPA should have the fix. > > Steve Berman I'm using Org 9.4.4 which came with Emacs 27.2. I'll upgrade. Thank you all for the info. Rob
c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’
This commit may cause random failures when org-emphasis-regexp-components is changed by user. org-emph-re is calculated according to org-emphasis-regexp-components. Changing org-emphasis-regexp-components can make "(when (looking-at org-emph-re)" in parsers return nil. The emphasised text will still be fontified, but not available in the parsed buffer. Maybe we need to move the logic for org-emph-re from org.el to org-element.el? Also, there is org-emphasis-alist. It is even defcustom, but ignored by org-element.el. Best, Ihor
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 &optional 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 &rest 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] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
On Sun, Nov 14, 2021 at 3:00 AM Ihor Radchenko wrote: > > Aaron Jensen writes: > > > Another one: > > https://gist.github.com/aaronjensen/5114997373008e18a6473f513f5d5da8 > > > > I don't have the details of what I was doing in the time, sorry. > > > > I'm on: ded97b767 * main origin/main org-element.el: Fix regression > > from d3836c1a1 > > I have done some related fixes recently. An update might help. Also, do > you happen to use polymode? If so, the warning may be related to > https://github.com/polymode/poly-org/issues/33 I've updated. I do not use polymode. Thanks, Aaron
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/)]
On Sunday, 14 Nov 2021 at 20:40, Ihor Radchenko wrote: > I thought that display-buffer-alist should be sufficient to control the > window placement in Org. Isn't it (on main)? I would have thought so but my experience has been that it isn't. Capture buffers, in particular, did not seem to obey my settings. I'll play some more later this week and will report back because I possibly didn't try hard enough... > We still need to have reasonable defaults. They can always be > overwritten by display-buffer-alist. Yes (if the latter is true). The defaults generally are fine (in my experience) for normal sized monitors. -- : Eric S Fraga, with org release_9.5-223-g876e81 in Emacs 29.0.50 : Latest paper written in org: https://arxiv.org/abs/2106.05096
[downgrading to matlab 2019a and using 3.5 NOW does not work neither] (was: after installing python3.6 on Ubuntu 16.04, org files open with errors)
>>> "UB" == Uwe Brauer writes:
> Hi
> I am running Ubuntu 16.04 and I installed python3.6 (which is not
> officially supported for that Ubuntu version via
> https://askubuntu.com/questions/865554/how-do-i-install-python-3-6-using-apt-get
> I also installed
> sudo -H python3.6 -m pip install jupyter
> sudo -H python3.6 -m pip install pexpect
> sudo -H python3.6 -m pip install matlab_kernel
I finally gave up that approach: I uninstalled 2019b and installed 2019a
(the latest version that is compatible with 3.5). I uninstalled 3.6 and
all the packages I installed with pip
I installed the mathwork python engine.
But now ob-ipython gives me an serious error, so that org mode is basically not
usable. I have to comment out
(require 'ob-ipython)
BTW since I installed it via the emacs package system that require
shouldn't be necessary?
In any case I obtain the following serious error when opening an
org-file
Debugger entered--Lisp error: (json-readtable-error 84)
signal(json-readtable-error (84))
json-read()
json-read-array()
json-read()
json-read-from-string("[TerminalIPythonApp] WARNING | Subcommand `ipython...")
ob-ipython--get-kernels()
ob-ipython-auto-configure-kernels()
run-hooks(change-major-mode-after-body-hook text-mode-hook outline-mode-hook
org-mode-hook)
apply(run-hooks (change-major-mode-after-body-hook text-mode-hook
outline-mode-hook org-mode-hook))
Etc
I have set
(setq ob-ipython-command "ipython")
The default is jupyter, but it gives the same error.
I am now puzzled. Is there anybody still using this package?
Regards
Uwe Brauer
smime.p7s
Description: S/MIME cryptographic signature
Re: after installing python3.6 on Ubuntu 16.04, org files open with errors
>>> "MN" == Max Nikulin writes: > On 14/11/2021 01:39, Tim Cross wrote: >> Uwe Brauer writes: >>> Well in that case I'd rather would prefer 20.04 a LTS release. From >>> experience I know it will take me days till everything is working again, >>> but maybe it is time to do that step. >> I would check what the status was with Python in 20.04. I'm not sure >> they had completed the migration to v3 at that point and it was still a >> mixed v2/v3 setup. Pretty sure by 21.04 it was all v3. I need still 2.7 to compile mercurial, since I rely on some extensions for mercurial that do not work under 3.X smime.p7s Description: S/MIME cryptographic signature
Re: after installing python3.6 on Ubuntu 16.04, org files open with errors
On 14/11/2021 01:39, Tim Cross wrote: Uwe Brauer writes: Well in that case I'd rather would prefer 20.04 a LTS release. From experience I know it will take me days till everything is working again, but maybe it is time to do that step. I would check what the status was with Python in 20.04. I'm not sure they had completed the migration to v3 at that point and it was still a mixed v2/v3 setup. Pretty sure by 21.04 it was all v3. Ubuntu-20.04: Python-3.8 is default, python-3.9 is available. Inkscape depends on python2:any. dpkg -S /usr/bin/python python-is-python2: /usr/bin/python I have not noticed any problem with python3. If some packages are considered as too old, e.g. Emacs-26.3 then Ubuntu-21.10 should be considered. At least it will be possible to upgrade it to Ubuntu-22.04 LTS in a single hop. Another option for rare upgrades is Debian stable. One thing I do find useful is to upgrade a virtual first. I use virt-manager to create a virtual machine running my current version and then upgrade that to see how the upgrade goes. I tried Ubuntu-20.10 and Ubuntu-21.10 in qemu. With the former I faced a really weird bug with depressed shift in gdm3 password field (you have no chance to notice that only first letter typed with shift is capitalized), with the latter firefox does not always redraw tabs after switching them using Ctrl+PgUp or Ctrl+PgDown. Booting live image directly works better and allows to test hardware support, e.g. sound. I have not tried 21.10 in this way, with 20.10 default wayland session cursor on the external monitor was too huge to make point where it points to rather uncertain. Problems with upgrade are usually caused by rarely used packages. So unless precise configuration is tried (dpkg --get-selections, dpkg --set-selections, third-party packages), the problem will not be noticed in VM. On the other hand installing all packages makes image size noticeably large. That issue I could solve meanwhile but only to receive another error ipython3 from my Ubuntu distribution but that corresponds to python 3.5 not 3.6 hm, ☹️ ipython may be installed to python 3.6 as well.
Should be possible to export list items emphasized by default?
Is it intended to not be able to emphasize the whole item of a list? Example: /1. Introduction/ It doesn't work as a list item 1. //Introduction// It works as a list item but, when exporting, it doesn't export the whole item emphasized. Best regards, Ypo
Re: table and Cyrillic characters: org-element--cache: Unregistered buffer modifications detected. Resetting
On 14/11/2021 14:56, Ihor Radchenko wrote: Ihor Radchenko writes: Confirmed Ihor, sorry, I removed "[BUG]" from the subject, so the magic did not work. Fixed Unintentionally I pressed some keys and it appeared again Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). The buffer is: cyr.org Current command: quail-self-insert-command Backtrace: nil LANG=en_US.UTF-8 emacs -Q -L ~/src/org-mode/lisp/ cyr.org C-\ russian-computer RET || By "|" I mean Shift+\ that inserts "/" with russian-computer input method.
Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend
Hi! Max Nikulin writes: > On 14/11/2021 22:28, Daniel Kraus wrote: >> +(defun ob-clojure-escape-quotes (str-val) >> + "Escape quotes for STR-VAL." >> + (replace-regexp-in-string "\"" "\\\"" str-val 'FIXEDCASE 'LITERAL)) >> + >> +(defun ob-clojure-eval-with-babashka (bb expanded) >> + "Evaluate EXPANDED code block using BB (babashka or nbb)." >> + (let ((escaped (ob-clojure-escape-quotes expanded))) >> +(shell-command-to-string >> + (concat bb " -e \"" escaped "\"" > > Does not it an open door for security vulnerabilities? Consider a string > somewhere in the code: "`echo arbitrary code execution`". Only outer quotes > are > escaped. The escaping is not done for security reasons. When I have a babel block like #+BEGIN_SRC clojure (str "foo" "bar") #+END_SRC babashka has to be called with bb -e "(str \"foo\" \"bar\")" etc. Security wise someone should always be careful what he evaluates in an org-babel block. Nobody prevents you from evaluating #+BEGIN_SRC shell sudo rm -rf / #+END_SRC Cheers, Daniel
Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend
On 14/11/2021 22:28, Daniel Kraus wrote: * lisp/ob-clojure.el: Add support for babashka and nbb backend. --- +(defun ob-clojure-escape-quotes (str-val) + "Escape quotes for STR-VAL." + (replace-regexp-in-string "\"" "\\\"" str-val 'FIXEDCASE 'LITERAL)) + +(defun ob-clojure-eval-with-babashka (bb expanded) + "Evaluate EXPANDED code block using BB (babashka or nbb)." + (let ((escaped (ob-clojure-escape-quotes expanded))) +(shell-command-to-string + (concat bb " -e \"" escaped "\"" Does not it an open door for security vulnerabilities? Consider a string somewhere in the code: "`echo arbitrary code execution`". Only outer quotes are escaped.
[PATCH] ob-clojure.el: Add support for babashka and nbb backend
* lisp/ob-clojure.el: Add support for babashka and nbb backend. --- This adds support to ob-clojure for babashka (https://github.com/babashka/babashka) and nbb (node version of babashka). It doesn't use `params` as I'm not really sure what they're used for and if they're important for evaluation. I'm also new to org development and the git email workflow so any feedback to the code or the email patch etc is appreciated. lisp/ob-clojure.el | 28 1 file changed, 28 insertions(+) diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el index 3b995d94c..dc42daa5c 100644 --- a/lisp/ob-clojure.el +++ b/lisp/ob-clojure.el @@ -36,6 +36,8 @@ ;; For clojure-mode, see https://github.com/clojure-emacs/clojure-mode ;; For cider, see https://github.com/clojure-emacs/cider ;; For inf-clojure, see https://github.com/clojure-emacs/cider +;; For babashka, see https://github.com/babashka/babashka +;; For nbb, see https://github.com/babashka/nbb ;; For SLIME, the best way to install these components is by following ;; the directions as set out by Phil Hagelberg (Technomancy) on the @@ -73,6 +75,8 @@ (const :tag "inf-clojure" inf-clojure) (const :tag "cider" cider) (const :tag "slime" slime) + (const :tag "babashka" babashka) + (const :tag "nbb" nbb) (const :tag "Not configured yet" nil))) (defcustom org-babel-clojure-default-ns "user" @@ -80,6 +84,16 @@ :type 'string :group 'org-babel) +(defcustom ob-clojure-babashka-command (executable-find "bb") + "Path to the babashka executable." + :type 'file + :group 'org-babel) + +(defcustom ob-clojure-nbb-command (executable-find "nbb") + "Path to the nbb executable." + :type 'file + :group 'org-babel) + (defun org-babel-expand-body:clojure (body params) "Expand BODY according to PARAMS, return the expanded body." (let* ((vars (org-babel--get-vars params)) @@ -225,6 +239,16 @@ ,(buffer-substring-no-properties (point-min) (point-max))) (cdr (assq :package params) +(defun ob-clojure-escape-quotes (str-val) + "Escape quotes for STR-VAL." + (replace-regexp-in-string "\"" "\\\"" str-val 'FIXEDCASE 'LITERAL)) + +(defun ob-clojure-eval-with-babashka (bb expanded) + "Evaluate EXPANDED code block using BB (babashka or nbb)." + (let ((escaped (ob-clojure-escape-quotes expanded))) +(shell-command-to-string + (concat bb " -e \"" escaped "\"" + (defun org-babel-execute:clojure (body params) "Execute a block of Clojure code with Babel." (unless org-babel-clojure-backend @@ -236,6 +260,10 @@ (cond ((eq org-babel-clojure-backend 'inf-clojure) (ob-clojure-eval-with-inf-clojure expanded params)) + ((eq org-babel-clojure-backend 'babashka) + (ob-clojure-eval-with-babashka ob-clojure-babashka-command expanded)) + ((eq org-babel-clojure-backend 'nbb) + (ob-clojure-eval-with-babashka ob-clojure-nbb-command expanded)) ((eq org-babel-clojure-backend 'cider) (ob-clojure-eval-with-cider expanded params)) ((eq org-babel-clojure-backend 'slime) -- 2.33.1
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/)]
Eric S Fraga writes: > On Sunday, 14 Nov 2021 at 14:08, Ihor Radchenko wrote: >> Can you elaborate? We are looking forward for ideas how to improve Org >> in this area. More concrete suggestions are welcome. > > I posted about this some weeks ago. It would be desirable to have org > manage window placement much less, if at all. Emacs has sufficient > customizations possible for window management, display-buffer-alist > being the default variable to customize. I am constantly fighting org > and find that it just does not allow me to configure window placement to > my satisfaction, especially on *ultra-wide* monitors. I thought that display-buffer-alist should be sufficient to control the window placement in Org. Isn't it (on main)? I recall you posted a message about "window management for logging and capturing notes", but you can easily change the capture window location with display-buffer-alist. > My suggestion would be to remove all/most window management from org > itself and simply suggest possible settings for display-buffer-alist, > say. We still need to have reasonable defaults. They can always be overwritten by display-buffer-alist. Best, Ihor
Re: Weird gap in agenda mode-line
I don't see this in my agenda view. Image attached. -- : Eric S Fraga, with org release_9.5-228-g577b98 in Emacs 29.0.50 : Latest paper written in org: https://arxiv.org/abs/2106.05096
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/)]
On Sunday, 14 Nov 2021 at 14:08, Ihor Radchenko wrote: > Can you elaborate? We are looking forward for ideas how to improve Org > in this area. More concrete suggestions are welcome. I posted about this some weeks ago. It would be desirable to have org manage window placement much less, if at all. Emacs has sufficient customizations possible for window management, display-buffer-alist being the default variable to customize. I am constantly fighting org and find that it just does not allow me to configure window placement to my satisfaction, especially on *ultra-wide* monitors. My suggestion would be to remove all/most window management from org itself and simply suggest possible settings for display-buffer-alist, say. To some degree, gnus suffers from the same control issues but Lars has, as one would expect, provided an amazingly extensive fully customizable window management configuration for gnus... I don't think org should go to that extreme, however. Thank you, eric -- : Eric S Fraga, with org release_9.5-228-g577b98 in Emacs 29.0.50 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: Introducing Org-transclusion
Ihor Radchenko writes: >> 4. This file does not seem realistic for me as a user who use Emacs for >> writing -- but I see this sort of testing can be useful for avoiding >> potential issues. How important do you think it is to tackle this type >> of "hypothetical" issues as a package developer? It's a question of >> priority for me. I do not feel that I have sufficient knowledge and >> skill set to tackle it right now; if the priority is not so high, I think >> I would leave it (for now, but this "for now" would be for a long time). >> If priority is high, I would need to ask for some help with even framing >> the problem so that we can somehow tackle it. > > It is not very important. I did not think about recursive issue when > created the file. Mostly wanted to create a random large file. I tried to create a more realistic large file. AFAIU, there should be no recursion issue this time. M-x org-transclusion-add-all is very slow in the attached file. Same for saving file after edits (even if edits are outside the transcluded parts). For reference, overlays generally start to be an issue from >10k overlays. This file just have a few hundreds. Best, Ihor huge.org Description: Lotus Organizer
Re: Introducing Org-transclusion
Noboru Ota writes: > Ihor Radchenko writes: > >> Try to open the attached file and run M-x org-transclusion-add-all > > Thank you. I see. Not even org-transclusion-add-all but a single add > function takes a bit of time. > 1. I see it as an issue rather of recursive transclusions (transclusions > inside a transclusion) than of overlay. Do you agree? Do you mean that the #+tranclusion keyword is located inside the transcluded headline? I agree (though I did not really think about it when creating the file). > 2. If it is a recursion, I would like to somehow avoid it altogether by > "skipping it" before going into a loop. I thought I had done part of > it; apparently, it's not enough. Do you have some suggestions how other > programs might deal with this type of issues? I feel that many pieces > of software have done so... I am not very sure if I understand you correctly. AFAIU, the main problem here is that #+translude lines may expand into Org elements that change the element structure (e.g. when #+transclude is a low-level headline, it breaks current headline section). You may probably need to handle "headline inside headline" or "element inside non-greater element" transclusions specially. > 3. If it is an overlay issue, do you have suggestions what sort of > methods are available within Emacs? My example is certainly not an overlay issue. I did some performance debugging. Most of CPU time was spend on org-element-parse-buffer. For overlay issues, the alternative is text properties. > 4. This file does not seem realistic for me as a user who use Emacs for > writing -- but I see this sort of testing can be useful for avoiding > potential issues. How important do you think it is to tackle this type > of "hypothetical" issues as a package developer? It's a question of > priority for me. I do not feel that I have sufficient knowledge and > skill set to tackle it right now; if the priority is not so high, I think > I would leave it (for now, but this "for now" would be for a long time). > If priority is high, I would need to ask for some help with even framing > the problem so that we can somehow tackle it. It is not very important. I did not think about recursive issue when created the file. Mostly wanted to create a random large file. You may find https://www.gnu.org/prep/maintain/maintain.html#Replying-to-Mail helpful. Best, Ihor
Re: [BUG] Unregistered buffer modifications detected [9.5 (9.5-g49e2f6 @ /Users/myuser/.emacs.d/straight/29/straight/build/org/)]
Aaron Jensen writes: > Another one: > https://gist.github.com/aaronjensen/5114997373008e18a6473f513f5d5da8 > > I don't have the details of what I was doing in the time, sorry. > > I'm on: ded97b767 * main origin/main org-element.el: Fix regression > from d3836c1a1 I have done some related fixes recently. An update might help. Also, do you happen to use polymode? If so, the warning may be related to https://github.com/polymode/poly-org/issues/33 Best, Ihor
