Re: C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."
Ihor Radchenko writes: > Confirmed > However, I can only trigger the warning up to Emacs 27. Emacs 28 and > later has no issue. > > Need to investigate further. Fixed via c3f457375. This is another case when Emacs internals (replace-match) increase buffer-chars-modified-tick. Eventually, this warning should be disabled and we need to make a patch for Emacs to trigger cache updates regardless of inhibit-modification-hooks. See https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-11/msg01069.html Best, Ihor
Re: table and Cyrillic characters: org-element--cache: Unregistered buffer modifications detected. Resetting
Ihor Radchenko writes: > Confirmed Fixed I tried to change buffer-chars-modified-tick to buffer-hash, but it is too slow. After discussion with Emacs devs [1], we found some heuristics that can filter away this particular case. Fixed on main via d8606c316. [1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-11/msg00894.html Best, Ihor
Re: Weird gap in agenda mode-line
Carlos Pita writes: > Hi Igor, > > Have you checked that there is no extra space (I mean with the default > bg face) as in the attached image? > > I've checked this now again with org main branch and emacs master > branch and the gap is still there. The extra space was there. However, it should have the same font. The relevant code in org-agenda.el is: (list "Org-Agenda" (if (get 'org-agenda-files 'org-restrict) " []" "") " " ;; <- this is the extra space '(:eval (org-agenda-span-name org-agenda-current-span)) (if org-agenda-follow-mode " Follow" "") (if org-agenda-entry-text-mode " ETxt" "") (if org-agenda-include-diary " Diary" "") (if org-agenda-include-deadlines " Ddl" "") (if org-agenda-use-time-grid " Grid" "") This part of code has not been changed from 2010. Best, Ihor
Re: Weird gap in agenda mode-line
Hi Igor, Have you checked that there is no extra space (I mean with the default bg face) as in the attached image? I've checked this now again with org main branch and emacs master branch and the gap is still there. Best regards, Carlos
Re: Weird gap in agenda mode-line
Carlos Pita writes: > Hi all, > > in the *Org Agenda* buffer mode-line I'm seeing a weird gap that I > can't remember whether it was before or not. > ... > org-mode version: 9.5, release_9.5-68-g77e2ec (emacs-28 branch) I am unable to reproduce 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/)]
dal-bla...@onenetbeyond.org writes: > 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 ». You are right. org-no-popups was more widely used in the past. It is probably time to obsolete it and eventually remove it. AFAIU, org-no-popups is a legacy function introduced very long time ago. Is it left there mostly to keep the working code working. > 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. Best, Ihor
Re: [BUG] org-agenda-get-scheduled in 2e99997 ignores org-todo-keywords [9.5 (release_9.5 @ /home/ning/.emacs.d/.local/straight/build-27.1/org-mode/)]
Ning Yuan writes: > A few days ago I updated org-mode to the latest available commit, > "9.6-??-2e7". > After this update, tasks which were closed by my custom "CANCELLED" > keyword, defined in org-todo-keywords, appeared in my org-agenda as if > they were still open. > I believe org-agenda-get-scheduled may be the culprit, but I am not too > sure. > ... > Here's how my org-todo-keywords is set: > (setq org-todo-keywords > '((sequence "TODO(t)" "|" "CANCELLED(c)" "DONE(d)"))) > Thanks for reporting! Can you reproduce the problem with some small example Org file that you can share? Best, Ihor
[BUG] org-agenda-get-scheduled in 2e99997 ignores org-todo-keywords [9.5 (release_9.5 @ /home/ning/.emacs.d/.local/straight/build-27.1/org-mode/)]
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. A few days ago I updated org-mode to the latest available commit, "9.6-??-2e7". After this update, tasks which were closed by my custom "CANCELLED" keyword, defined in org-todo-keywords, appeared in my org-agenda as if they were still open. I believe org-agenda-get-scheduled may be the culprit, but I am not too sure. Reverting my org-mode version to 9.5 (stable) without any change in configuration fixed this bug for me. Here's how my org-todo-keywords is set: (setq org-todo-keywords '((sequence "TODO(t)" "|" "CANCELLED(c)" "DONE(d)"))) Sorry if this description is too vague or unhelpful --- I know very little emacs-lisp. Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2020-09-02 Package: Org mode version 9.5 (release_9.5 @ /home/ning/.emacs.d/.local/straight/build-27.1/org-mode/) Notice: This email is generated from the account of an NUS alumnus. Contents, views, and opinions therein are solely those of the sender.
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.
[Feature Request] Support org-link-abbrev-alist for clickable image links
Org mode supports clickable images in the following form: [[https://orgmode.org][file:/tmp/org-mode-logo.png]] This is also displayed by =org-display-inline-images= as the second case: #+begin_quote An inline image is a link which follows either of these conventions: 1. Its path is a file with an extension matching return value from image-file-name-regexp and it has no contents. 2. Its description consists in a single link of the previous type. In this case, that link must be a well-formed plain or angle link, i.e., it must have an explicit "file" type. #+end_quote However, this docstring isn't quite true. - The image link is parsed as a plain link, and thus if it contains spaces, it must be wrapped in angle brackets. This should be mentioned in the docstring. - More crucially, it does not support =org-link-abbrev-alist=, which works in case 1. Yes: [[file:/tmp/org-mode-logo.png]] Yes: [[my-abbrev:org-mode-logo.png]] Yes: [[https://example.com][file:/tmp/org-mode-logo.png]] Yes: [[https://example.com][]] No: [[https://example.com][file:/tmp/with a space.png]] (docstring should mention this and suggest angle links) No: [[https://example.com][my-abbrev:org-mode-logo.png]] (this should work)
Re: after installing python3.6 on Ubuntu 16.04, org files open with errors
Uwe Brauer writes: > [[S/MIME Signed Part:Undecided]] > >> Uwe Brauer writes: > > >> The whole transition from v2.x to v3.x for python has been a terrible >> mess. Version issues are the most frustrating aspect of Python and one >> reason I've never embraced the language. > >> Given that Ubuntu 16.04 was end of life in April 2021, my recommendation >> would be to upgrade to ubuntu 21.04. That version seems to have a more >> consistent Python environment (based on v3). It also has newer ciaro, >> hafbuzz and other libs used by Emacs which will likely work better and >> once Emacs 28.0 is released, will have the gccjit libs necessary for >> native comp etc. > > 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. While I do find upgrades to a new version can be very disruptive if it is left for a few versions, updates to the next version has been minimally disruptive for me. I guess a lot depends on how much 'extra' stuff you install and what tweaks you do, but for the last few years, I've found the upgrades quite painless. A lot depends on what changes - for example, I expect the update to 22.04 or maybe 22.10 will be more disruptive due to the move to pipewire for sound. 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. In fact, I tend to maintain a VM which is the same as my current version and whenever I need to make some potentially disruptive upgrades or configuration changes - such as updating org to a new version or try out the latest Emacs, I do that on the virtual machine first. This way, I don't interfere with my core system and configuration and have time to investigate any issues before doing the same on my core system.
Re: after installing python3.6 on Ubuntu 16.04, org files open with errors
>>> "MN" == Max Nikulin writes: > On 13/11/2021 09:22, Tim Cross wrote: >> Uwe Brauer writes: >> Given that Ubuntu 16.04 was end of life in April 2021, my >> recommendation >> would be to upgrade to ubuntu 21.04. > I would not recommend a release with end of support in January 2022 to > a person who is trying to avoid upgrading despite 18.04 and 20.04 long > time support releases are available. I think 20.04 is the best choice for me > From mails to this list my impression is that 5-years old OS generates > enough compatibility problems to seriously consider newer LTS version. > Support of python-2.7 and early 3.x version has been seized as well. >>> File "/usr/lib/python3/dist-packages/dateutil/parser.py", line 25, in >>> >>> from six import text_type, binary_type, integer_types >>> ModuleNotFoundError: No module named 'six' > ^ 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, ☹️ I think I rather upgrade Ubuntu or downgrade Matlab to make it work again with python3.5 smime.p7s Description: S/MIME cryptographic signature
Re: after installing python3.6 on Ubuntu 16.04, org files open with errors
>>> "MS" == Martin Schöön writes: > I learned the hard way not to mix distro installed Python with pip > installed Python. I now always use "pip install --user > " to keep things sane. Right, I installed python3.6 from a ppa, and that increased the mess. I uninstalled python3.6, also had to uninstall and then reinstall ob-ipython before I got rid of that error. smime.p7s Description: S/MIME cryptographic signature
Re: after installing python3.6 on Ubuntu 16.04, org files open with errors
> Uwe Brauer writes: > The whole transition from v2.x to v3.x for python has been a terrible > mess. Version issues are the most frustrating aspect of Python and one > reason I've never embraced the language. > Given that Ubuntu 16.04 was end of life in April 2021, my recommendation > would be to upgrade to ubuntu 21.04. That version seems to have a more > consistent Python environment (based on v3). It also has newer ciaro, > hafbuzz and other libs used by Emacs which will likely work better and > once Emacs 28.0 is released, will have the gccjit libs necessary for > native comp etc. 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. smime.p7s Description: S/MIME cryptographic signature
Re: [BUG] Tables with square brackets do not compile in PDF (latex) export [9.5 (release_9.5-59-g52e6f1 @ /home/sjt015/repo/emacs/lisp/org/)]
On 10/11/2021 23:16, Stewart Thomas wrote:
A table in which a first column begins with square brackets is not
compiling. The square bracket is interpreted by latex as an argument
to the preceding line break.
Confirmed
Thank you for reporting the issue. Example of a workaround
>8
#+macro: tr @@latex:\relax @@
| one |
| {{{tr}}}[2] |
Ref \\
{{{tr}}} [2]
8< -
To fix the bug newline (in tables and paragraphs) should be exported as
"\\\relax" or "\\{}". I do not suggest curly brackets in the beginning
of line to avoid issues with spurious spaces. Percent character
(comment) at the end of line should be considered for a fix since it is
usually used in the opposite way: to suppress newline character and
spaces at the beginning of next source line.
Re: after installing python3.6 on Ubuntu 16.04, org files open with errors
On 13/11/2021 09:22, Tim Cross wrote: Uwe Brauer writes: Given that Ubuntu 16.04 was end of life in April 2021, my recommendation would be to upgrade to ubuntu 21.04. I would not recommend a release with end of support in January 2022 to a person who is trying to avoid upgrading despite 18.04 and 20.04 long time support releases are available. From mails to this list my impression is that 5-years old OS generates enough compatibility problems to seriously consider newer LTS version. Support of python-2.7 and early 3.x version has been seized as well. File "/usr/lib/python3/dist-packages/dateutil/parser.py", line 25, in from six import text_type, binary_type, integer_types ModuleNotFoundError: No module named 'six' ^ Another question: does ipython babel backend in Org uses the same python interpreter as python or it should be configured separately? Since you are using ipython, do you have it installed for python versions you are trying?
Re: Bug: org-no-popups disregards display-buffer-fallback-action 9.4.6
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 ( 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: whitespace in org source files
Hi, excalamus--- via "General discussions about Org-mode." writes: > I've not used the email contribution style before and have had > whitespace issues in the past with GitHub PRs. I typically run > whitespace-cleanup with the before-save-hook which changes tabs to > spaces. I agree with Tim that running whitespace-cleanup is usually a bad idea within a Git repository. I also have, like you, whitespace-cleanup hooked to before-save-hook, like a relic of my first Emacs setups. In case it helps, I have added to my init this function: (defun my-whitespace-cleanup-no-git () (let ((buf (buffer-file-name))) (when (not (vc-git-responsible-p buf)) (whitespace-cleanup and then: (add-hook 'before-save-hook 'my-whitespace-cleanup-no-git) Best regards, Juan Manuel
Re: execute src block during export (Re: Worg HTML export problem?)
On 12/11/2021 23:55, Thomas S. Dye wrote: Max Nikulin writes: On 12/11/2021 00:24, Thomas S. Dye wrote: The original problem is likely due to the default header arguments in ob-org.el, which are unusual. It is great that the problem is solved. I do not think however that something inside ob-org.el may affect processing of a file before this package is loaded. If I export both, then all is well. #+begin_src emacs-lisp :results value none :exports both (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src I feel that I have missed something. I do not see the purpose to include this source block in user docs. I expect that for accidental usage it is more convenient to type (require 'ob-org), while as a permanent settings it is possible to do customize-variable org-babel-load-languages or to use `add-to-list'. The source block is included to show the user how to modify their .emacs. My ~/.emacs.d/init.el has (among other variables) (custom-set-variables '(org-babel-load-languages (quote ((emacs-lisp . t) (C . t) (python . t ;; ... ) I consider it better since it does not force immediate loading of Org if emacs is launched for a file of different type. Before sending the previous message I forgot to check Org manual. It recommends `org-babel-do-load-language' and it looks more prominent than customizing of the variable, however a more concise example is given a bit below (require 'ob-closure) Additional feature of `org-babel-do-load-language' is that the function can "unload" some languages, however it is not the case for initialization. That is why I disputed recommending more complicated example with `org-babel-do-load-language'. It is matter of taste however even if current example has no less obvious advantages. I was surprised that changing its :results header argument had an effect on export. Do you have an explanation why the header argument makes this difference on Worg? Worg build procedure is more close to defaults. Earlier I wrote that the issue can be reproduced locally using "emacs -Q". Actually it is reasonable that without explicit request, source blocks are not executed during export. `org-babel-default-header-args' has (:exports . "code"), so it is necessary to override default value to execute the source block loading ob-org. I was confused that build log contains a message related to evaluating of some code ob-doc-sql.org without explicit overriding of :exports. Likely it is caused by noweb option.
Re: [BUG] Citations: Locator treated as prefix [9.5 (release_9.5-225-g494c20 @ /home/quintus/.emacs.d/org-mode/lisp/)]
Am Freitag, dem 12. November 2021 schrieb Nicolas Goaziou: > Indeed. I forgot to say you also need to re-evaluate > ‘org-cite-csl--label-regexp’ definition (in "oc-csl.el"), in order to > refresh the locator regexp matched against. Ah, I see. Indeed, re-evaluating that definition after amending `org-cite-csl--label-alist' results in the desired result on export. Thanks! -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kont...@guelker.eu| O<
Re: after installing python3.6 on Ubuntu 16.04, org files open with errors
I learned the hard way not to mix distro installed Python with pip installed Python. I now always use "pip install --user " to keep things sane. /Martin On Sat, 13 Nov 2021 at 03:29, Tim Cross wrote: > > 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 > > > > > > Now however I cannot open even simple org files, I obtain errors I attach > > and most of my keybinding and other things do not work. > > > > Any help is strongly appreciated. > > > > Regards > > > > The whole transition from v2.x to v3.x for python has been a terrible > mess. Version issues are the most frustrating aspect of Python and one > reason I've never embraced the language. > > Given that Ubuntu 16.04 was end of life in April 2021, my recommendation > would be to upgrade to ubuntu 21.04. That version seems to have a more > consistent Python environment (based on v3). It also has newer ciaro, > hafbuzz and other libs used by Emacs which will likely work better and > once Emacs 28.0 is released, will have the gccjit libs necessary for > native comp etc.
Re: [BUG] Keep getting warning when saving org file org-element--cache: (save-buffer) Cached element is incorrect
Yu Shen writes: > Subject: [BUG] Keep getting warning when saving org file > org-element--cache: (save-buffer) Cached element is incorrect in > 2021095727-cs61a_scheme_interpreter_beyond_calculator.org. (Cache tic > up to date: "yes") Resetting. [9.6 (9.6-??-2e783 @ > /home/yshen/.emacs.d/.local/straight/build-27.1/org/)] You are just one commit behind the fix :) Try to update Org. Best, Ihor
