Re: [BUG] org-table-blank-field missing keybinding [9.5.2 (N/A @ /gnu/store/zkm1kxbk6p56ag6rscsl4k8ckxksp1bz-emacs-org-9.5.2/share/emacs/site-lisp/org-9.5.2/)]
André A. Gomes writes: > org-table-auto-blank-field used to be bound to C-c SPC and the manual > still refers to it. Was the keybinding removed by mistake? Thanks. The manual has been fixed in Org 9.5.3. It will be included in Emacs 28.2. See https://orgmode.org/manual/Built_002din-Table-Editor.html Or you can update your Org mode manually and not wait for the Emacs release. See https://orgmode.org/manual/Installation.html#Installation Best, Ihor
Re: [BUG] Let org-latex-compile fall back on org-latex-compiler as the default instead of "pdflatex" [9.6 (9.6-??-4f0f24447 @ /home/dan/.emacsen/doom-emacs/.local/straight/build-29.0.50/org/)]
daanturo writes: > On 5/22/22 10:42, Ihor Radchenko wrote: >> Can you provide more details on the problem? >> `org-latex-compile' relies on `org-latex--insert-compiler' that is >> called by `org-latex-template'. So, your org-latex-compiler >> customization should be obeyed. > > Sorry, I was a problem on my side, the file where I test has > `org-latex-compiler-file-string' set to nil as a local variable. Note that `org-latex-compiler-file-string' must not be set to nil. It is not considered a valid value and causes undefined behavior. > But IMO, falling back to the customized `org-latex-compiler' instead of > "pdflatex" should be intuitive. Not necessarily. If org-latex-compiler is not a member of org-latex-compilers, we need some sane fallback. Moreover, apart from org-latex-compiler variable, the compiler can be set locally in buffer or locally in the subtree. Either way, it is not necessarily clear which fallback is reasonable. I'd go as far as throwing an error instead of using "pdflatex", but alas, we already have the existing behavior and changing it without strong justification can break things for other users. Docstring of org-latex-compiler: >>> Must be an element in org-latex-compilers or the empty quote. >>> Can also be set in buffers via #+LATEX_COMPILER. See also >>> org-latex-compiler-file-string. Best, Ihor P.S. You dropped org mailing list from CC. Please, use "reply all" when replying to the Org mailing list messages in future.
[BUG] org-open-file immediately termininates when calling xdg-open that calls emacsclient [9.5.3 (release_9.5.3-508-ge268e4 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hi, I have a problem with the following commits: 869b7a21b org-open-file: Avoid make-process for Emacs 24 compatibility 5db61eb0f org.el: Avoid xdg-open silent failure They both set process-connection-type to nil/'pipe. Somehow, this change breaks org-open-file for me when org-open-file calls xdg-open and xdg is confugured to open the file with emacsclient. I only see a flicker and the file does not open. Sometimes, Emacs even crashes. If I change the process type back to default tty value, things work again as expected. While I understand that the original commits intended to solve a similar problem, they clearly caused the same problem with other apps. Best, Ihor Emacs : GNU Emacs 28.1.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2022-05-14 Package: Org mode version 9.5.3 (release_9.5.3-508-ge268e4 @ /home/yantar92/.emacs.d/straight/build/org/) --
[PATCH] Re: Bug in 9.5.3 org--file-default-apps
Max Nikulin writes: > On 21/05/2022 08:44, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>> It is the same with and without -Q and no, I have not customized >>> `mailcap-user-mime-data', its value is nil, easy customization interface >>> tells that it is the standard value. There is a chance that debian has >>> some patch, but most of debian specific is disabled when -Q option is used. >> >> Interesting. In any case, it confirms that mailcap behaviour depends on >> both Emacs settings and also system settings. > > You should be even more surprised, if I say that [[file:~/tstorg]] link > is opened in emacs buffer in shell-script mode (emacs-27.1, org main > HEAD) despite > > (mailcap-mime-info nil) > nil > > The source of the problem is that Emacs-27 was released with the > following bug: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40247 > mailcap-mime-data erased when parsing mime parts > > So `mailcap-parse-mailcaps' called from `mailcap-mime-info' erases > predefined associations in Emacs-27. If I understand correctly, this extra complication does not affect most of the systems. I am not sure if we need to work around it. Also, I am attaching a patch to address the original issue. We can just use file command when available. WDYT? Best, Ihor >From f69824559d62cb6963ff30f11ceb46303bf1b3d4 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sun, 22 May 2022 12:04:35 +0800 Subject: [PATCH] org-open-file: Use file command to determine mime type, when available * lisp/org.el (org-open-file): Prefer file command to determine file type instead of relying on `mailcap-extension-to-mime'. Only fallback to the latter when file command is not available on the system. Fixes https://list.orgmode.org/874k1n2hpv.fsf@localhost/T/#mcc10df4ea7937360671e6dea8061153dee518807 --- lisp/org.el | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index d7da8efc4..3102fe611 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7975,7 +7975,12 @@ (defun org-open-file (path in-emacs line search) (when (eq cmd 'mailcap) (require 'mailcap) (mailcap-parse-mailcaps) - (let* ((mime-type (mailcap-extension-to-mime (or ext ""))) + (let* ((mime-type (if (executable-find "file") +(shell-command-to-string + (format "%s --brief --mime-type %s" + (executable-find "file") + file)) + (mailcap-extension-to-mime (or ext "" (command (mailcap-mime-info mime-type))) (if (stringp command) (setq cmd command) -- 2.35.1
[PATCH] Avoid ignoring LaTeX export output errors when org-latex-pdf-process is a list
Hi, The attached patch is fixing a rather annoying problem when org-latex-pdf-process is set to a list. Currently, only output of the last command in the list is preserved in *Org PDF LaTeX output* buffer, which sometimes prevents ox-latex from detecting compilation warnings. ox-latex relies on *Org PDF LaTeX output* to contain the output of latex compiler. However, unless the last command in the org-latex-pdf-process is something like pdflatex, the compiler errors are erased by `shell-command' called by `org-compile-file'. Best, Ihor >From d4f15ed260f47195b01cb60061b57823428d2eef Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sun, 22 May 2022 11:44:56 +0800 Subject: [PATCH] Avoid ignoring LaTeX export output errors * lisp/org-macs.el (org-compile-file): When PROCESS is a list, keep output of all the listed commands, not just the last one. * lisp/ox-latex.el (org-latex-pdf-process): Clarify that the process output is parsed to detect compilation errors/warnings. --- lisp/org-macs.el | 9 +++-- lisp/ox-latex.el | 3 +++ 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/lisp/org-macs.el b/lisp/org-macs.el index 10eed2686..2a7131ded 100644 --- a/lisp/org-macs.el +++ b/lisp/org-macs.el @@ -323,8 +323,13 @@ (defun org-compile-file (source process ext err-msg log-buf spec) (?F . ,(shell-quote-argument full-name)) (?o . ,(shell-quote-argument out-dir)) (?O . ,(shell-quote-argument output)) - (dolist (command process) - (shell-command (format-spec command spec) log-buf)) + ;; Combine output of all commands in PROCESS. + (with-current-buffer log-buf + (let (buffer-read-only) + (erase-buffer))) + (let ((shell-command-dont-erase-buffer t)) + (dolist (command process) + (shell-command (format-spec command spec) log-buf))) (when log-buf (with-current-buffer log-buf (compilation-mode) (_ (error "No valid command to process %S%s" source err-msg ;; Check for process failure. Output file is expected to be diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 5a2de8afb..ed16ec46f 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -1426,6 +1426,9 @@ (defcustom org-latex-pdf-process "%latex -interaction nonstopmode -output-directory %o %f")) "Commands to process a LaTeX file to a PDF file. +The command output will be parsed to extract compilation errors and +warnings according to `org-latex-known-warnings'. + This is a list of strings, each of them will be given to the shell as a command. %f in the command will be replaced by the relative file name, %F by the absolute file name, %b by the file -- 2.35.1
Re: [BUG] Let org-latex-compile fall back on org-latex-compiler as the default instead of "pdflatex" [9.6 (9.6-??-4f0f24447 @ /home/dan/.emacsen/doom-emacs/.local/straight/build-29.0.50/org/)]
daanturo writes: > Having set `org-latex-compiler` to `lualatex`, when exporting with > `org-latex-export-to-pdf`, I expected that `lualatex` is the compiler to > be used but `org-latex-compile` falled back on `pdflatex` instead. Can you provide more details on the problem? `org-latex-compile' relies on `org-latex--insert-compiler' that is called by `org-latex-template'. So, your org-latex-compiler customization should be obeyed. Best, Ihor
Re: [BUG] HTML export of buffer with fringe indicators
Daniel Fleischer writes: > Ihor Radchenko [2022-05-20 Fri 16:36] wrote: > >> I am unable to reproduce your problem on my side using the following >> steps. > > Ok, thanks anyway. BTW, even the steps you took are useful for me for future > debugging. It is exactly the reason I listed the steps. So that you can also try on your side. If you cannot reproduce using my steps, there is a chance that the problem is also caused by some other part of your config. In which case, you can use https://github.com/Malabarba/elisp-bug-hunter to hunt down the cause. Also, see https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9 Best, Ihor
Re: Fwd: [BUG] when open a large org file, emacs get stuck and show a warning "org-element--cache: Unregistered buffer modifications detected"
imymorror wang writes: >>Now, it is confusing. I am unable to reproduce the warning on my side >>even with org-fragtog and valign installed. > > valign-mode causes the problem. Try these steps to reproduce the problem : > add-hook for valign and open a large org file, then try moving the mouse a > few times，quickly TAB and SHIFT-TAB a few times. Thanks! I have opened an issue in valign repo: https://github.com/casouri/valign/issues/30 This problem needs to be fixed on valign side. Best, Ihor
Re: Fwd: [BUG] when open a large org file, emacs get stuck and show a warning "org-element--cache: Unregistered buffer modifications detected"
imymorror wang writes: >> Can you share the values of change-major-mode-hook and org-mode-hook? > I uploaded all *emacs **current state* in recent e-mail . Sorry, I missed that. Unfortunately I do not see anything suspicious there. Now, it is confusing. I am unable to reproduce the warning on my side even with org-fragtog and valign installed. Can you try to reproduce the problem starting from clean Emacs state (emacs -Q)? See https://orgmode.org/manual/Feedback.html >> Also, do you deliberately drop the CC to emacs-orgmode@gnu.org and prefer > the conversation to be not public? > sorry. I'm not good at email communication. This is my first attempt to > submit a bug report to Emacs. Maybe I could add CC to emacs-orgmode@gnu.org > on > the recent email that shows all my emacs current state info. Just use "Reply All" in future. Best, Ihor
Re: Bug in 9.5.3 org--file-default-apps
Max Nikulin writes: > On 20/05/2022 15:22, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>>>> run-mailcap --norun ~/path/to/script >>>> >>>> Note that mailcap.el does _not_ use run-mailcap or anything external. It >>>> is written purely in elisp. >>>> >>>> So, can you please report the output of M-: (mailcap-mime-info nil)? >>> >>> view-mode >> >> Sorry, I did not consider that you customised mailcap-user-mime-data (I >> guess). No doubt your Emacs opens the script in other window. >> >> What about using emacs -Q? > > It is the same with and without -Q and no, I have not customized > `mailcap-user-mime-data', its value is nil, easy customization interface > tells that it is the standard value. There is a chance that debian has > some patch, but most of debian specific is disabled when -Q option is used. Interesting. In any case, it confirms that mailcap behaviour depends on both Emacs settings and also system settings. As I understand now: 1. (mailcap-mime-info nil) in Emacs 26 returns 'view-mode disregarding ~/.mailcap 2. (mailcap-mime-info nil) in Emacs 27 returns "less %s" on my system unless I have ~/.mailcap, in which case it takes text/plain handler from ~/.mailcap 3. (mailcap-mime-info nil) in Emacs 28/29 returns 'fundamental-mode unless I have ~/.mailcap, in which case it takes text/plain handler from there Dear Craig, your issue will kind of disappear if you upgrade Emacs or provide plain/text handler in ~/.mailcap. On Org side, the very reason we call (mailcap-mime-info nil) with _nil_ argument is because mailcap.el does not recognise file types without extension. I think that we can prefer the output of `file' utility if it is available on the system. However, I am not sure what to do on Windows/Mac. Best, Ihor
Re: Trouble producing nicely aligned org tables from emacs-jupyter code blocks using latest org version
"Richard H. Stanton" writes: > Here’s a simple init.el that shows the problem (most of it is just > boilerplate code to use straight.el to manage packages, and you may need to > edit the python executable path). > ... > —— > > Now execute the following source block and you’ll see the misaligned table. > > #+begin_src jupyter-python :async yes :session py > [['aaa', 'a'], None, ['b', 'b']] > #+end_src I am unable to reproduce the problem using Emacs 28.1 on Linux. I ran Emacs in a clean .emacs.d environment using https://github.com/alphapapa/with-emacs.sh: $ with-emacs.sh -e emacs -OPR -- -Q -l /tmp/bug.el /tmp/bug.org with bug.el containing your script with latest Org line uncommented and built-in Org line commented and bug.org containing the example source block. Best, Ihor
Re: [BUG] HTML export of buffer with fringe indicators
Daniel Fleischer writes: > Ihor Radchenko [2022-05-19 Thu 21:43] wrote: > >> What if you try to run M-: (htmlize-buffer) >> on your file? > > It works, creating an HTML buffer that can be opened and looks good. Then I have no more ideas. I am unable to reproduce your problem on my side using the following steps: 1. Install https://github.com/alphapapa/with-emacs.sh 2. Create /tmp/bug.org with the following contents #+begin_src python def hi(): pass #+end_src 3. cd /tmp/ 4. git clone git://git.sv.gnu.org/emacs/org-mode.git 5. cd org-mode 6. make clean; make autoloads; with-emacs.sh -e emacs -O -i elpy -- -Q -L ./lisp/ -l org -l org-inlinetask --eval "(setq elpy-folding-fringe-indicators t)" --eval "(elpy-enable)" /tmp/bug.org 7. C-c ' and install the dependencies 8. C-e h o to export html Best, Ihor
Re: Bug in 9.5.3 org--file-default-apps
Max Nikulin writes: >>> run-mailcap --norun ~/path/to/script >> >> Note that mailcap.el does _not_ use run-mailcap or anything external. It >> is written purely in elisp. >> >> So, can you please report the output of M-: (mailcap-mime-info nil)? > > view-mode Sorry, I did not consider that you customised mailcap-user-mime-data (I guess). No doubt your Emacs opens the script in other window. What about using emacs -Q? Best, Ihor
Re: [PATCH] Re: Concatenate properties
Ihor Radchenko writes: > I will leave this for another week to give other people a chance to > comment. Applied upstream onto main via e268e4797. Best, Ihor
Re: [BUG] when open a large org file, emacs get stuck and show a warning "org-element--cache: Unregistered buffer modifications detected"
imymorror wang writes: > - if keeping org-startup-folded defaul value（i.e "showeverything") , > enable org-indent-mode , open the large org file, get a warning, but not > get stuck: >#+begin_quote >Warning (org-element-cache): 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). >#+end_quote Is the no more warning text? The warning you are seeing should continue with The buffer is:... Current command:... Chars modified:... Buffer modified:... Backtrace:... ... Best, Ihor
Re: [BUG] HTML export of buffer with fringe indicators
Daniel Fleischer writes: > Ihor Radchenko [2022-05-18 Wed 20:54] wrote: > >> Can you set debug-on-error to t and share the full backtrace? > > Attached. > ... > htmlize-buffer-1() What if you try to run M-: (htmlize-buffer) on your file? Best, Ihor
Re: Bug in 9.5.3 org--file-default-apps
Max Nikulin writes: > On 18/05/2022 18:36, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>> Sounds reasonable. However I just have tried a [[file:~/path/to/script]] >>> link running Org main HEAD and the file is opened in emacs (26.3) other >>> window. >> >> The behaviour is dependent on the OS-level mailcap defaults. What does >> (mailcap-mime-info nil) return for you? > > view-mode > > run-mailcap --norun ~/path/to/script Note that mailcap.el does _not_ use run-mailcap or anything external. It is written purely in elisp. So, can you please report the output of M-: (mailcap-mime-info nil)? Best, Ihor
Re: Trouble producing nicely aligned org tables from emacs-jupyter code blocks using latest org version
Richard Stanton writes: > A bit more experimenting shows that asynchronous execution is actually a part > of my original problem. By default, I have jupyter-python blocks running > asynchronously. In that case, the tables don’t format quite right, as I > noted. But if I add the header ":async nil", the table comes out fine. Table > formatting is OK in python blocks with or without asynchronous execution. Can you also see the problem without using jupyter-python? A detailed recipe starting from emacs -Q would help (see https://orgmode.org/manual/Feedback.html) Best, Ihor
Re: [please check] Add RET to go from overlay to edit buffer
Marco Wahl writes: > Dear Orgers, > > Just pushed the little feature "RET to go from overlay to edit buffer". > > As always complaints and comments are welcome. Two comments: 1. It would make sense to mention the new key binding in NEWS 2. org-edit-src-goto binding is slightly confusing given the behaviour of C-c ' on a src-block being edited. C-c ' achieves the same, but queries a question to discard/not discard the edits. Best, Ihor
Re: [PATCH] New function org-speed-command-add for adding/modifying speed commands
Shankar Rao writes: > Using ``org-speed-command-add'', I don't have to be concerned with > whether or not a given key is already present in > ``org-speed-commands''. Sure. However, the same can be achieved with fairly simple Elisp, as you saw in the earlier messages. I do not clearly see how a significant number of users can really benefit from this command. Most people will simply not notice it. Beginners should better use customize interface. Power users can just write elisp. The only way I can see the proposed approach useful is creating a unified framework to set various non-trivial Org options programatically (like org-agenda-custom-commands). I would be in favour of merging such framework, but not individual commands. Having convenience setters for some customisations, but not other will be just confusing. Org already has a huge number of cusomisations. Alternatively, if many people jump in and say that your idea is very for them, the patch can be merged. > I agree that ``org-speed-command-add'' has undefined behavior when > provided with only a descriptive headline as its first element. Would > you be more amenable to this command if it either ignored or > explicitly disallowed descriptive headline entries? There is not much point discussing this part given the above issue I raised. Best, Ihor
Re: [BUG] HTML export of buffer with fringe indicators
Daniel Fleischer writes: > Have `elpy' installed with enabled fringe markers (have > `elpy-folding-fringe-indicators' non-nil). Then try to export, say to > HTML. I get the error > > cons: Args out of range: " ", 0, -3 Can you set debug-on-error to t and share the full backtrace? Best, Ihor
Re: Tips on using Org-mode to manage a reading list
Sébastien Gendre writes:
> I want to use Org-mode to manage a reading list and I'm looking for
> tips.
>
> My goals are to:
> * List books and articles I want to read
> * Track books I have to buy and which I already own
> * Track books and articles I have read
> * Take notes on books I have read
I think the ideas you proposed already covers most of your needs.
Note that apart from heading, you can set book status
(TO-READ/TO-BUY/etc) via todo-keywords. Owning a physical copy can be
marked by a tag. Completed books can be marked DONE.
I am personally using somewhat similar system, though geared to handle
my over 3k books and articles.
I am structuring books/articles by topic using
SOMEDAY/TODO/NEXT/DOING/CANCELLED/FAILED/DONE todo keywords.
I keep the digital copies in attachments and notes under the book headings.
I capture new books/articles automatically from websites using
https://github.com/yantar92/org-capture-ref
I query the books with various status using agenda and helm-org-ql.
Example:
* NEXT Getting things done (GTD) \ time management \ planning
:COMMON:AREA:NOREFILE:
:PROPERTIES:
:CATEGORY: GTD[T]
:ORG-TIME-BALANCE-MULTIPLIER: -0.5
:END:
** Bookmarks \ References :NOARCHIVE:REFILE:
*** DONE #spaced_repetition Sung Cho [getdnote] (2018) Learning More Vocabulary
Using My Own Open Source Software | Dnote :BOOKMARK:
:PROPERTIES:
:ID: getdnote_cho2018_learn_more_vocab_using_my
:CREATED: [2020-08-02 Sun 22:20]
:Source:
https://www.getdnote.com/blog/learning-vocabularies-using-my-open-source-software/
:SUMMARY: Check spaced repetition discussion
:END:
:LOGBOOK:
- Refiled on [2020-11-19 Thu 21:43]
- State "DONE" from "NEXT" [2020-11-19 Thu 21:43]
- Note taken on [2020-11-08 Sun 21:01] \\
Check spaced repetition discussion
CLOCK: [2020-08-13 Thu 21:22]--[2020-08-13 Thu 21:25] => 0:03
- Refiled on [2020-08-03 Mon 09:40]
:END:
:BIBTEX:
#+begin_src bibtex
@misc{getdnote_cho2018_learn_more_vocab_using_my,
author = {Sung Cho},
howpublished = {getdnote},
DATE_ADDED = {Sun Aug 2 22:20:19 2020},
note = {Online; accessed 02 August 2020},
title ={Learning More Vocabulary Using My Own Open Source
Software | Dnote},
url =
{https://www.getdnote.com/blog/learning-vocabularies-using-my-open-source-software/},
year = 2018,
}
#+end_src
:END:
Spaced repetition is not only useful for learning languages, but can be used to
remind some useful practices, which cannot be immediately used. For example,
some code snippet may only make sense next time some algorithm is being used,
but that time is not known a priori. Normally, it would be forgotten by the
time it could actually be used. However, spaced repetition can help to keep it
in mind.
*** DONE Newport [Penguin] Digital Minimalism: Choosing a Focused Life in a
Noisy World By Cal Newport :BOOKMARK:FLAGGED:book:ATTACH:
CLOSED: [2021-02-27 Sat 22:33]
:PROPERTIES:
:ID: goodreads_digit_minim_choos_focus_life
:CREATED: [2020-07-28 Tue 10:18]
:Source: https://www.goodreads.com/book/show/40672036-digital-minimalism
:Effort: 0:20
:SHOWFROMDATE: 2020-09-25
:END:
:LOGBOOK:
- State "DONE" from "NEXT" [2021-02-27 Sat 22:33]
:END:
:BIBTEX:
@book{newport2019digital,
title={Digital minimalism: Choosing a focused life in a noisy world},
author={Newport, Cal},
year={2019},
publisher={Penguin}
}
:END:
Related:
- [[id:d95ab75ad2c5819d36b05fc494ef513c0e5a][Subrisk [Habr] (2020) 4 часа
без смартфона. Дурацкий пост на серьёзную тему]]
- [[id:lesswrong_benkuhn2020_tools_keepin_focus][#attention_management
#mindless_browsing benkuhn [lesswrong] (2020) Tools for Keeping Focused]]
Many of the modern apps are over-utilising various techniques to keep out
attention.
The reason is simple - it is their way to get more revenue.
With many different apps we use every day, it transforms in several hours every
single day people spend checking their phone or scrolling social media pages on
average. *This is a huge chunk of a day*.
Two main driving forces used by mobile apps are: (1) immediate positive reward;
(2) social feedback [unpredictable reward is
[[id:7ab8e592-a045-4c04-9a02-3af765247aec][most desired]]]
The example of social feedback is posting on platform with many likes/upvotes.
Example of unpredictable reward is mindless browsing when you may (or may not)
stumble upon something funny.
Social feedback is even more dangerous than one may think. Because of instant
messaging and popup notifications, our urge to continuously communicate with
friends/relatives (social validation) goes overboard and we may check/reply
messages even when inappropriate (car). This may reach anecdotal levels when
people chat with others during date - the thing some cafes are even marketing
on by adding electromagnetic insulation around to cut-off the interned and
phone during dinner [I have read about such cafe in Great Britain, do not
remember the
Re: Bug in 9.5.3 org--file-default-apps
Craig STCR writes: > I know your time is valuable. No need for you to spend a lot of time on > this if I am the only one having this problem. It could be some random > artifact in my installation, maybe something in my ~/.emacs. My > ~/.emacs has a lot in it. And I have a work-around, since I can use #5. Using #5 may surprise you if you actually set something via mailcap. Can you instead try to put text/plain; emacs27 %s; test=test -n "$DISPLAY" into your mailcap file and report if it helps? Best, Ihor
Re: Bug in 9.5.3 org--file-default-apps
Max Nikulin writes: > On 16/05/2022 18:57, Ihor Radchenko wrote: >> Craig STCR writes: >>> But with the new form in 9.5.3, /home/user/myscript is opened by >>> /bin/less, not emacs. I assume mailcap is not consulted. Which does >>> not work well. These behaviors are only for org. Outside of org, emacs >>> behaves correctly. >> >> mailcap does get consulted. What you are seeing happens because >> mailcap.el (built-in Emacs library) is only able to recognise mime-types >> by extension. So, your file is likely recognised as "nil" mimetype thus >> making Org mode fallback to default mailcap handler, which is /bin/less >> in your case. > > Sounds reasonable. However I just have tried a [[file:~/path/to/script]] > link running Org main HEAD and the file is opened in emacs (26.3) other > window. The behaviour is dependent on the OS-level mailcap defaults. What does (mailcap-mime-info nil) return for you? Best, Ihor
Re: [BUG] when open a large org file, emacs get stuck and show a warning "org-element--cache: Unregistered buffer modifications detected"
imymorror wang writes: >> *Can you please share the exact output of M-x org-version?If you really >> see 9.5.1, then you likely have a "mixed" Org installationwith some code in >> your init file first loading built-in Org mode andthen loading the newer >> version. Such state can cause all kinds of bugs.* > > > You are right. When I Update Org to the latest version *Org mode version > 9.5.3 (9.5.3-g277897)* . The bug is gone。 Sharing this to the mailing list (it was not in CC). Best, Ihor
Re: [BUG] when open a large org file, emacs get stuck and show a warning "org-element--cache: Unregistered buffer modifications detected"
William Denton writes: > I'm also having problems like this with large files. I haven't been able to > narrow it down but I'll try what you say about org-startup-folded. > > Do you also have a problem where sometimes TAB or SHIFT-TAB on a heading has > no > effect? Some Org files seem to get broken after editing them for a while, > and > some folding no longer works (that is, some headings stay closed, while > others > can be cycled), and the only way to fix it is to reload. > > I'll turn on debugging and see what that says. Before you try anything weird, can you do the following: (1) Update Org to the latest version and make sure that M-x org-version reports Org 9.5.3 (2) Remove org-persist-directory (3) Try to see if the error persists Best, Ihor
Re: [BUG] when open a large org file, emacs get stuck and show a warning "org-element--cache: Unregistered buffer modifications detected"
imymorror wang writes: > - desktop environment > - GNU Emacs 29.0.50 (build 2, x86_64-apple-darwin20.4.0, NS > appkit-2022.44 Version 11.3.1 (Build 20E241)) of 2022-01-08 > - Org mode version 9.5.1 Thanks for reporting! Can you please share the exact output of M-x org-version? If you really see 9.5.1, then you likely have a "mixed" Org installation with some code in your init file first loading built-in Org mode and then loading the newer version. Such state can cause all kinds of bugs. The latest Org version is Org mode version 9.5.3 (release_9.5.3-1799-ge73d5b) The latest stable Org version (distributed via ELPA) is also 9.5.3 Best, Ihor
Re: org-noter
Uwe Brauer writes: > Ok, so it is my setting, sigh. > > BTW does this mode set any sort of marker in the pdf? FYI, org-pdftools package allows to set links to specific coordinates in pdf files by creating annotations. Best, Ihor
Re: Bug in 9.5.3 org--file-default-apps
Craig STCR writes: > OK, I'll take a look as you suggested as soon as I can. > > So the form in 9.5.2 was a bug? Yes, 9.5.2 version of that function was a bug. > The problem I encounter with the new form in 9.5.3 is that when opening > a shell script -- no file extension, e.g. /home/user/myscript -- 9.5.2 > would consult mailcap and open the script in Emacs. The mailcap entry is: > > application/x-shellscript; emacs27 %s; test=test -n "$DISPLAY" > > But with the new form in 9.5.3, /home/user/myscript is opened by > /bin/less, not emacs. I assume mailcap is not consulted. Which does > not work well. These behaviors are only for org. Outside of org, emacs > behaves correctly. mailcap does get consulted. What you are seeing happens because mailcap.el (built-in Emacs library) is only able to recognise mime-types by extension. So, your file is likely recognised as "nil" mimetype thus making Org mode fallback to default mailcap handler, which is /bin/less in your case. In Org 9.5.2 the error in org--file-default-apps made Org mode skip using mailcap and use the last possible fallback, which is opening in emacs. That fallback just happened to be the same with your setting in mailcap file. I guess that Org can also try to use `file' command (when available) to determine the mime type. Though ideally, it should be all handled by mailcap.el Would you mind writing to emacs-devel mailing list and asking to add the feature of using `file' command into mailcap.el? Best, Ihor
Re: [tip] Export and open a PDF in Android via Termux
Juan Manuel Macías writes:
> I have recently installed TeX live on Android inside Termux:
>
> $ pkg install texlive-installer
>
> (https://wiki.termux.com/wiki/TeX_Live)
>
> And I've managed to open a PDF exported from Org using an external
> android viewer (mupdf, downloaded from f-droid). The Termux command is
> termux-open. You need to add:
>
> (setq org-file-apps
> '((auto-mode . emacs)
> (directory . emacs)
> ("\\.mm\\'" . default)
> ("\\.x?html?\\'" . default)
> ("\\.pdf\\'" . "termux-open %s")))
Thanks for sharing! I am wondering if tips like this should be added to
worg.
Best,
Ihor
Re: Bug in 9.5.3 org--file-default-apps
Craig STCR writes:
> 9.5.3 does not return org-file-apps-gnu because org-file-apps-gnu is not
> quoted. Should be (and was in 9.5.2):
>
> 'org-file-apps-gnu
>
> but in 9.5.3 it is:
>
> _ org-file-apps-gnu
Please try to run the following form:
(pcase 'gnu/linux
(`darwin org-file-apps-macos)
(`windows-nt org-file-apps-windowsnt)
('org-file-apps-gnu)) ;; => nil
and then
(pcase 'gnu/linux
(`darwin org-file-apps-macos)
(`windows-nt org-file-apps-windowsnt)
(_ org-file-apps-gnu)) ;; => ((remote . emacs) (system . mailcap) (t .
mailcap))
The second case is returning a list, which org--file-default-apps
supposed to return. The previous behaviour was erroneous. You may refer
to M-x describe-function pcase to understand the code.
Please, provide more details on the actual error you ran into. The
change in the org--file-default-apps is not a bug.
Best,
Ihor
Re: Bug in 9.5.3 org--file-default-apps
Craig STCR writes: > I believe a change to the last line of org--file-default-apps introduced > in 9.5.3 is a bug. For example, the change prevents shell scripts from > being recognized correctly, since the mailcap logic in org-file-apps-gnu > is no longer included in org--file-default-apps. Can you elaborate? In the past version org--file-default-apps returned nil on Linux, while now it returns the value of org-file-apps-gnu, as intended. What else did you expect? Best, Ihor
Re: [PATCH] Re: No mathematics in Texinfo exports
Rudolf Adamkovič writes: > Ihor Radchenko writes: > >> Rudolf Adamkovič, feel free to ask questions if you find the copyright >> assignment instructions unclear. > > I think I need help with the copyright assignment. On April 23, I sent a > request to ass...@gnu.org, and I have yet to receive a reply as of May 15. Sorry for this delay. Then, can you send them a followup email reminder? If they do not reply within another week, we will contact FSF directly. Best, Ihor P.S. The precise procedure is the following as in https://www.gnu.org/prep/maintain/maintain.html >>> When the contributor emails the form to the FSF, the FSF sends per >>> an electronic (usually PDF) copy of the assignment. This, or >>> whatever response is required, should happen within five business >>> days of the initial request. If no reply from the FSF comes after >>> that time, please send a reminder. If there is still no response >>> after an additional week, please write to maintain...@gnu.org about >>> it. (the last thing is what I (or other Org maintainers) need to do).
Re: Bug: ob-R.el breaks when :session is specified
Christian Heinrich writes: > I got back to an org file after upgrading to the latest release of org-mode > and tried executing the > contained R source blocks. Unfortunately, emacs got stuck in the execution > and was blocked; I had to > exit using C-g. > > Here's a minimal example src block that causes emacs to get stuck: > > #+begin_src R :results output :session *R* :exports both > a <- 10 > a > #+end_src > > R itself does start and the code is also executed correctly. However, the > output from that session > is apparently not returned to emacs or the buffer. I tried you example using Emacs >=26 and it works just fine. Best, Ihor
Re: a problem with lilypond babel fontification
"" writes:
> I’m using emacs compiled from trunk as of today. This is my minimal file
> for testing:
>
>
> #+begin_src lilypond :file shalala.pdf
> \clef bass {c d e f g a b c' b a g f e d c}
> #+end_src
>
> #+begin_src lisp
> (setq tralala mimimi)
> #+end_src
>
>
> If I open it using `emacs -Q`, both blocks get fontified/highlighted
> correctly. If I load `ob-lilypond` with `(require 'ob-lilypond)` and
> reopen the file, I get a fontification error.
Could you elaborate? Maybe provide screenshots?
See https://orgmode.org/manual/Feedback.html
I was unable to see any issue with the code block you provided, except
that without ob-lilypond, you would have to use #+begin_src LilyPond
Best,
Ihor
Re: Dealing with growing backlog (was: next-error for agenda searches)
Tim Cross writes: > I've also learnt to be quite ruthless in making decisions about what to > archive and what to simply delete. This is possibly the hardest > behaviour to learn. In a digital age, it is way too easy to keep > everything. However, this has a hidden cost - the quality of material > degrades and results from searching etc become less productive because > there is too much 'noise' in your data. Data, like many other things, > degrades over time. It is important to learn how to recognise when > things have passed their 'use by date' and just get rid of them. > > I'm often stunned by people who boast about the fact they still have all > their emails boing back to 1990 and are somewhat proud about having an > email archive with over 50Gb of messages. Reality is, the vast majority > of those email messages will never be read again and are of little or no > actual value. > > Knowing when to just delete old data is almost as important as gathering > it, but a much harder skill to master. I disagree about this. Sometimes, you may find yourself in a situation when you remember some link/idea because it suddenly become relevant to what you are doing now, though it looked interesting but irrelevant in the past. Then, you may try to find that link and there will be nothing to find if you deleted it. So, I prefer to keep things that caught my attention in the past saved somewhere in searchable location. On the other hand, it is not very useful to keep every single saved link in "active" search location. In daily workflows, the things you search for usually belong to the currently active areas and search results must not be polluted by links you discarded years back. So, I maintain the main notes file with the important links I search relatively regularly; and an archive where the notes/links are not searchable by default, but can be searched any time I wish so (e.g. see org-agenda-archive-mode). The archive is just like having a backup. It is usually useless until you suddenly need it. Best, Ihor
Re: [PATCH] Re: Bug: org-deadline drops warning periods from TIME [9.4.6 (9.4.6-10-gee652a-elpaplus @ /home/fap/.emacs.d/elpa/org-plus-contrib-20210712/)]
Ihor Radchenko writes: > erim...@web.de writes: > >> * Reproduction >> >> Call ~org-deadline~ with a warning period like so: >> >> >> (org-deadline nil "<2021-07-20 Tue -1d>") >>;; => DEADLINE: <2021-07-20 Tue> >> >> * Expected >> >> Deadline gets added with the warning period provided. > > Can you try the attached patch? > > Also, note that warning period is still not supported when reading > deadline interactively. Not sure if we need it though. Applied onto main via cdbb1c963. I changed the patch adding support for timestamps with repeaters _and_ warning. Also, added the relevant tests. Best, Ihor
Re: [BUG] Plain capture template clocks into following headline instead of given olp [9.5.1 (release_9.5.1-15-gdb4805 @ /usr/share/emacs/29.0.50/lisp/org/)]
Ihor Radchenko writes: > Michael Eliachevitch writes: > >> I found a potential bug in org which I can reproduce with a >> minimal configuration. > > Can you try the attached patch? Since the patch fixes the problem on my side, I just applied it upstream. Fixed. Applied onto main via 5c14a1734. Best, Ihor
Re: [BUG] Org-cycle strange behaviour in Emacs 29.0.50 [9.5.3 (9.5.3-g0b07b3 @ /home/yaslam/.emacs.d/straight/build/org/)]
Yusef Aslam writes: > I've supplied a video to show you that it does indeed work properly now: Good to hear that the problem is resolved now. I am CCing this email to the Org ML, to indicate that the problem is solved. To List, the problem was caused by earlier Emacs master and resolved itself after an update. Best, Ihor
Re: [BUG] org-babel-load-file can not compile file
Max Nikulin writes: > On 13/05/2022 17:38, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>>>> It seems, it is a regression caused by the Org commit >>>>> 0193b543e9ef84bfefe76d55e330d5b1cb842cef >>>>> >>>>>> - (byte-compile-file tangled-file 'load) >>>>>> + (byte-compile-file tangled-file) >>>>>> + (load tangled-file) >>>> >>>> >>>> What if you substitute the load call with >>>> (load (byte-compile-dest-file tangled-file))? >>> >>> I do not mind (of course if there is no plan to deprecate the function). >> >> Fixed on bugfix via 4fe59b688 > > Ihor, I am sorry for confusion, it still does not work for me. Likely I > tried locally with `load-file' instead of `load'. The former > additionally has `expand-file-name'. (Emacs-26.3) Should work now. Best, Ihor
Re: Inline src org block element with containing inside item does not get exported when it contains a newline (was: Inline src block element not parsed correctly for export when in a list item)
Ihor Radchenko writes: > Confirmed. > > Interestingly, I cannot reproduce the bug using my personal branch at > https://github.com/yantar92/org. The fix should be lurking somewhere > close... I just tried again on the latest main and I cannot reproduce anymore. Though I do see the problem on bugfix. Can you please check again on your side? Best, Ihor
Re: [PATCH] Re: [Style] Shouldn’t the macros in org-fold-core have (indent 0)
Ihor Radchenko writes: >> I didn’t want to create a patch, since it would involve whitespace changes >> on quite a lot of places, but I thought it could be good to highlight now >> that org-fold just got merged. > > Still, it needs to be done. > Attaching the patch with fixed indent statements and reindented code. Applied onto main as d6bae908f. Best, Ihor
Re: \minus entity and LaTeX export
Max Nikulin writes:
>> "** Science et al."
>> - ("minus" "\\minus" t "" "-" "-" "−")
>> + ("minus" "-" t "" "-" "-" "−")
>
> Should it be "\textminus" instead? I never used it but my expectation
> that it was added for text mode outside of equations: \minus1. It
> required \usepackage{textcomp} in the past, but it seems it is not the
> issue any more, so the symbol is available out of the box. I was not
> following that changes in LaTeX so I may miss something.
\textminus appears to work without textcomp. However, I am not sure if it
should be used instead of math version.
Look at the attached screenshot where I tried to compare how \textminus
vs. $-$ would look inside a document. I find the math version to be more
visually appealing. Of course, we can always change to \textminus if
people more familiar with typography jump in and ask for the change.
Best,
Ihor
Re: [PATCH v4] org-encode-time compatibility and convenience helper
Max Nikulin writes: >>> I do not like repeating of `org-encode-time' but do not see another way >>> till Emacs-29 will become the lowest supported version. >> >> This is fine. AFAIK, other parts of time handling code is full of conds >> and pcases. > > I mean that before my patch there was single `encode-time' outside of > `pcase', I replace `list' by `org-encode-time' inside each pattern. I do not see it is a big deal. At least, readability of the code did not degrade, IMHO. + (org-encode-time + (apply #'list +(or (car time0) 0) +(+ (if (eq timestamp? 'minute) n 0) (nth 1 time0)) +(+ (if (eq timestamp? 'hour) n 0) (nth 2 time0)) +(+ (if (eq timestamp? 'day) n 0)(nth 3 time0)) +(+ (if (eq timestamp? 'month) n 0) (nth 4 time0)) +(+ (if (eq timestamp? 'year) n 0) (nth 5 time0)) +(nthcdr 6 time0 (when (and (memq timestamp? '(hour minute)) extra (string-match "-\\([012][0-9]\\):\\([0-5][0-9]\\)" extra)) > > From my point of view > >(cl-mapcar > (lambda (value part) > (if (and part (eq part timestamp?)) >(+ n value) > value)) > time0 '(second minute hour day month year nil nil nil)) > > is better than the original code, but... > > Nicolas Goaziou to emacs-orgmode. [Patch] to correctly sort the items > with emphasis marks in a list. Mon, 19 Apr 2021 18:08:17 +0200. > https://list.orgmode.org/87r1j6b6ku@nicolasgoaziou.fr > > >> I stay away from CL as much as possible, otherwise newcomers will have >> to learn two languages to start contributing, Elisp and CL (cl-loop, >> ewww). CL is still necessary however, as we cannot use `seq' yet. I think that Nicolas was mostly referring to things like cl-loop, which introduce a whole new piece of language concepts into Elisp. cl-mapcar is merely a convenience function. Just as any other Elisp function. It behaves without surprises within the general Elisp programming concepts. I do not see why we should not use it if it improves the code clarity. Best, Ihor
Re: [PATCH] org-element--current-element: Fix #+BEGIN$ parsed as special block
Nicolas Goaziou writes: > Hello, > > Ihor Radchenko writes: > >> Nicolas, >> Let me know if I miss something about special block parsing. > > LGTM! Thanks. Applied onto main as e5e7ae36c. I changed the patch as org-element-dynamic-block-open-re is matching from bol. Also, I fixed one broken test that assumed #+BEGIN: Paragraph to be a full paragraph, not a sequence of keyword + paragraph. Best, Ihor
Re: [PATCH] Re: [BUG] org-element-map doco should refer to org-element-parse-buffer [9.5.2 (9.5.2-gfbff08 @ /home/phil/.emacs.d/elpa/org-9.5.2/)]
Phil Hudson writes: > Thanks Ihor, that's great! > > One tiny nit-pick: I think "e.g." is deprecated in favor of the > explicit literal "for example". My source for this is (info "(elisp) > Documentation Tips"). Fair point, though searching across org-element.el reveals that e.g. is used in many places. I do not see it as too much of a big deal. Will just update the patch here. > Also, just spotted what I think is a pre-existing typo, "objects > types", which I think should probably be just "object types". Might as > well fix that while we're at it. Fixed. Applied the new version of the patch onto main as 3996ea99a. Best, Ihor
Re: [PATCH] Re: How to stop results being hidden when using ":results drawer"?
Eric S Fraga writes: > On Friday, 13 May 2022 at 21:35, Ihor Radchenko wrote: >> In fact, forcefully folding the drawers is relatively recent addition by >> Nicolas in 1027e0256903bc2. > > I wonder if this is related to my issue with ediff-ing org buffers and > having drawers hidden? I've not had time yet to investigate but > interesting coincidence maybe? If I recall correctly, you had some drawers folded and some not in ediff. That is a different issue and it should be fixed on the latest main. Best, Ihor
Re: Org-cite/Citar cannot recognize neither biblatex nor natbib
"Bruce D'Arcus" writes: >> Last thing: I heard that the citation part of the manual is still >> undocumented. Is this right? If so, do you think what we discovered >> (especially about manually requiring libraries) may be useful? May I >> help? > > It's not undocumented; it's poorly documented :-) > > https://orgmode.org/manual/Citation-handling.html#Citation-handling > > I don't know the process here on this, but definitely it needs improvements. The process is just as any other patch. That is https://orgmode.org/worg/org-contribute.html Best, Ihor
[PATCH] Re: How to stop results being hidden when using ":results drawer"?
John Kitchin writes: > This issue is specific to using a scimax function > `scimax-ob-execute-and-next-block` that executes the current block then > moves to the next or creates a new block if needed. This is a UI feature > from jupyter notebooks that I like to use. > > That function uses `(org-babel-next-src-block)`, which uses > org-next-block, which calls org-show-context, which uses > org-show-set-visibility, which calls org-show-entry, which hides the > drawers. > > It isn't an org-core issue perhaps, other than it is not obvious why > org-show-entry has a hard-coded line to hide drawers in it. I'd say that it is org-core issue. The current behaviour does not really follow what org-fold-show-entry docstring promises: >> Show the body directly following its heading. >> Show the heading too, if it is currently invisible. In fact, forcefully folding the drawers is relatively recent addition by Nicolas in 1027e0256903bc2. I am attaching the patch making drawer folding controllable via optional argument. WDYT? Best, Ihor >From bd3c7ac6162d64a19eff370b7b22ba233f8480ad Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Fri, 13 May 2022 21:30:46 +0800 Subject: [PATCH] org-fold-show-entry: Do not fold drawers unless requested * lisp/org-fold.el (org-fold-show-entry): Do not fold drawers in the unfolded entry unless the new optional argument is non-nil. Folding the drawers was introduced in 1027e0256903bc2, but does not follow the function docstring. Moreover, folding drawers creates unexpected behaviour in some cases. See https://orgmode.org/list/m2a6bl4mmr@andrew.cmu.edu * etc/ORG-NEWS (~org-fold-show-entry~ does not fold drawers by default anymore): Document the change. * lisp/org-agenda.el (org-agenda-show): (org-agenda-show-and-scroll-up): (org-agenda-show-1): * lisp/org-clock.el (org-clock-goto): * lisp/org-compat.el (outline-toggle-children): * lisp/org-timer.el (org-timer--get-timer-title): * lisp/org.el (org-move-subtree-down): (org-return): Explicitly request folding drawers inside the revealed entry in the places where it appears to make sense. --- etc/ORG-NEWS | 7 +++ lisp/org-agenda.el | 6 +++--- lisp/org-clock.el | 2 +- lisp/org-compat.el | 2 +- lisp/org-fold.el | 4 ++-- lisp/org-timer.el | 2 +- lisp/org.el| 4 ++-- 7 files changed, 17 insertions(+), 10 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 582816534..15986c935 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -190,6 +190,13 @@ installed. It uses Emacs' font-lock information, and so tends to produce results superior to Minted or Listings. ** New functions and changes in function arguments +*** ~org-fold-show-entry~ does not fold drawers by default anymore + +~org-fold-show-entry~ now accepts an optional argument HIDE-DRAWERS. +When the argument is non-nil, the function folds all the drawers +inside entry. This was the default previously. + +Now, ~org-fold-show-entry~ does not fold drawers by default. *** New function ~org-element-cache-map~ for quick mapping across Org elements diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 0479a0e1f..6fd0e4498 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -9701,7 +9701,7 @@ (defun org-agenda-show ( full-entry) (interactive "P") (let ((win (selected-window))) (org-agenda-goto t) -(when full-entry (org-fold-show-entry)) +(when full-entry (org-fold-show-entry 'hide-drawers)) (select-window win))) (defvar org-agenda-show-window nil) @@ -9720,7 +9720,7 @@ (defun org-agenda-show-and-scroll-up ( arg) (select-window org-agenda-show-window) (ignore-errors (scroll-up))) (org-agenda-goto t) - (org-fold-show-entry) + (org-fold-show-entry 'hide-drawers) (if arg (org-cycle-hide-drawers 'children) (org-with-wide-buffer (narrow-to-region (org-entry-beginning-position) @@ -9764,7 +9764,7 @@ (defun org-agenda-show-1 ( more) ((and (called-interactively-p 'any) (= more 1)) (message "Remote: show with default settings")) ((= more 2) - (org-fold-show-entry) + (org-fold-show-entry 'hide-drawers) (org-fold-show-children) (save-excursion (org-back-to-heading) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index ec87aaf8a..c04a8fdcf 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1849,7 +1849,7 @@ (defun org-clock-goto ( select) (pop-to-buffer-same-window (marker-buffer m)) (if (or (< m (point-min)) (> m (point-max))) (widen)) (goto-char m) -(org-fold-show-entry) +(org-fold-show-entry 'hide-drawers) (org-back-to-heading t) (recenter org-clock-goto-before-context) (org-fold-reveal) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 704197645..8553500d6 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -1400,7 +1400,7 @@ (defadvice outline-toggle-children (around out
Re: [PATCH] Re: Concatenate properties
Tyler Grinn writes: > Ihor Radchenko writes: > >> Note that your patch is >15LOC long and you need to sign the copyright >> agreement with FSF in order to contribute. See >> https://orgmode.org/worg/org-contribute.html#copyright > > I've already submitted a copyright assignment to the FSF in order to > publish on ELPA. Do I need one specific to org-mode? Nope. The ELPA one is good enough. Basically, Org has the same requirement as Emacs (Org is a part of Emacs). >>> +(defcustom org-property-separators nil >>> ... >>> + :group 'org-properties >>> + :type '(alist :key-type string :value-type sexp)) >> >> This defcustom type does not match what you described in the docstring. >> You need something like :type '(alist :key-type (choice string (repeat >> string)) :value-type string) > > Setting ':value-type string' is confusing, in my opinion, because the > default single space looks like: in the customization buffer, which is > indistinguishable from no space: . I just found out about the restricted-sexp > type, which I think makes the customization buffer more user-friendly. restricted-sexp is fine. Though you could also do something like (choice (const :tag "Single space" " ") (string :tag "Other string")) > From f474cb25840fdc6b24618b1452cb7fdd32545092 Mon Sep 17 00:00:00 2001 > From: Tyler Grinn > Date: Mon, 9 May 2022 15:52:58 -0400 > Subject: [PATCH] lisp/org.el: Add org-property-separators option LGTM! I will leave this for another week to give other people a chance to comment. For reference, this patch might be useful in https://orgmode.org/list/87o821dv7o.fsf@localhost Best, Ihor
Re: How to stop results being hidden when using ":results drawer"?
John Kitchin writes: > This does not change anything for me. > > The function that causes folding for me is `org-entry-show'. Presumably > because of this line: (org-cycle-hide-drawers 'children) > > My solution was an override advice that makes this function not run when > point is in a src-block > (https://github.com/jkitchin/scimax/blob/master/scimax-jupyter.el#L281). Could you elaborate? I am not sure how `org-entry-show' has anything to do with hiding results. I tried the following Org file with latest Org main (after (require 'ob-python)): * test heading #+begin_src python :results drawer output print(1+2) #+end_src #+RESULTS: :results: 3 :end: The drawer does not get hidden. Best, Ihor
Re: [BUG] org-babel-load-file can not compile file
Max Nikulin writes: >>> It seems, it is a regression caused by the Org commit >>> 0193b543e9ef84bfefe76d55e330d5b1cb842cef >>> -(byte-compile-file tangled-file 'load) +(byte-compile-file tangled-file) +(load tangled-file) >> >> >> What if you substitute the load call with >> (load (byte-compile-dest-file tangled-file))? > > I do not mind (of course if there is no plan to deprecate the function). Fixed on bugfix via 4fe59b688 Best, Ihor
Re: [BUG] org-babel-load-file can not compile file
Max Nikulin writes: >> What if you substitute the load call with >> (load (byte-compile-dest-file tangled-file))? > > I do not mind (of course if there is no plan to deprecate the function). > > In addition, from my point of view, `byte-recompile-file' with 0 as the > FORCE argument is more suitable than simple `byte-compile-file' since > the former does not rewrite the compiled file when it is up to date. What about simply using touch? >From 9746b9cd0a1accfc20b9d59c387bb05624154fe2 Mon Sep 17 00:00:00 2001 Message-Id: <9746b9cd0a1accfc20b9d59c387bb05624154fe2.1652438075.git.yanta...@gmail.com> From: Ihor Radchenko Date: Fri, 13 May 2022 18:21:36 +0800 Subject: [PATCH] org-babel-load-file: Do not rely on `org-babel-tangle-file' making changes * lisp/org.el (org-babel-load-file): Update modification time even when `org-babel-tangle-file' does not actually modify the tangled file. This makes sure that modify-time comparison logic does not make Org re-tangle Org file that had been changed but the changes did not affect the tangled code. See https://orgmode.org/list/t5j75h$dbo$1...@ciao.gmane.io --- lisp/org.el | 5 + 1 file changed, 5 insertions(+) diff --git a/lisp/org.el b/lisp/org.el index 47a16e94b..09a001414 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -256,6 +256,11 @@ (defun org-babel-load-file (file compile) tangled-file (file-attribute-modification-time (file-attributes (file-truename file + ;; Make sure that tangled file modification time is + ;; updated even when `org-babel-tangle-file' does not make changes. + ;; This avoids re-tangling changed FILE where the changes did + ;; not affect the tangled code. + (set-file-times tangled-file) (org-babel-tangle-file file tangled-file (rx string-start -- 2.35.1
Re: [BUG] C-u C-u C-u TAB regression on master
Allen Li writes: > There appears to be a regression in the behavior of C-u C-u C-u TAB on > master (at aea24b3feafb9c389dc5933005928462bb20c4f8). > > C-u C-u C-u TAB is supposed to show everything including drawers, but on > this test file it does not show property drawers: > > This bug does not manifest on small files, e.g. containing one copy of > the above. > > This is using (setq org-fold-core-style 'text-properties), the default. > The behavior does not happen with 'overlays. > > Can anyone else reproduce? Thanks for reporting! Fixed on main via 7dcd15105. Best, Ihor
Re: Regarding arbitrary Org blocks
Russell Adams writes: > I used to insert arbitrary blocks like: > > #+BEGIN_IMPORTANT > yadda yadda > #+END_IMPORTANT > > in my documents, and when I hit C-c ' to edit them it would give me a > basic buffer and I could edit the plain text within. > > Some recent change instead now says "No special environment to edit > here". How can I get back that behavior? I am unable to get the described behaviour even using Org 8.2.10. Could you elaborate what you mean by "used to"? Which Org version? > I'm really just editing text blocks for Latex export, and the source > block type triggers some latex formatting. It's not source code > language, just plain text. > > Could I add some minor mode to say text-mode with auto-fill-mode and > aspell somewhere when opening those blocks? Not currently, unless you advice org-edit-special. Though we might add something like org-edit-special-hook (similar to org-ctrl-c-ctrl-c-hook) if others are also interested in this functionality. Best, Ihor
Re: How to stop results being hidden when using ":results drawer"?
Richard Stanton writes: > I’m creating documents where I run Python code blocks that create LaTeX > mathematical output that I want to be able to export to either LaTeX/PDF or > HTML. > > Using :wrap in the header works fine, except that LaTeX complains about the > unknown environment “results” (it still compiles the file to PDF fine). > > Using :wrap export latex works fine for LaTeX export, but I can’t get HTML > that way. > > The recommended method seems to be to use :results drawer. This works fine > from an export perspective to both LaTeX/PDF and to HTML. However, it has one > significant drawback when I’m actually creating the document: the results > drawer starts out hidden and to see what’s there I have to click on it. This > makes debugging the code in the first place a lot less convenient. > > Is there a way to use :results drawer and have the results NOT hidden by > default? I think that you are experiencing the same issue with https://list.orgmode.org/80k0ar1lml@felesatra.moe/T/#u Does it help when you run M-: (setq org-fold-core-first-unfold-functionsp nil) before running the code block? Best, Ihor
Re: [oc] multiple cite_export keywords for multiple export processors?
"Bruce D'Arcus" writes: > OIC; that's the part I was missing. > > So something like this? > > #+bind: org-cite-export-processors ((latex biblatex "verbose")) > > It doesn't seem to work though. Is there something wrong with my syntax? Seems to be alright (except that "verbose" is ignored by oc-biblatex). Note that you need org-export-allow-bind-keywords to be set to t. Otherwise, #+bind keywords are ignored. I tried the following .org file: #+bind: org-cite-export-processors ((latex biblatex "verbose")) #+bibliography: /home/yantar92/Git/Books/References.bib [cite:@brovzek2009soldering] Best, Ihor
Re: [PATCH] Re: org-agenda-clock-report-header
Colin Baxter writes: > > Because your clock tables in Org _files_ have nothing to do with > > agenda. There is no "Agenda clock report mode" when you create an > > ordinary clock report in Org buffers. > > Well now you've really confused me because I wasn't in an agenda buffer, > I had constructed a clock table from a non-agenda org file. > > Could give me a concrete example of where the variable > org-agenda-clock-report-header might be used? When you are in agenda, you can press v R to toggle org-agenda-clockreport-mode: (11.5 Commands in the Agenda Buffer) >> Toggle Clockreport mode. In Clockreport mode, the daily/weekly >> agenda always shows a table with the clocked times for the time >> span and file scope covered by the current agenda view. The >> initial setting for this mode in new agenda buffers can be set with >> the variable ‘org-agenda-start-with-clockreport-mode’. By using a >> prefix argument when toggling this mode (i.e., ‘C-u R’), the clock >> table does not show contributions from entries that are hidden by >> agenda filtering(1). See also the variable >> ‘org-clock-report-include-clocking-task’. Best, Ihor
Re: [PATCH] Re: Concatenate properties
Tyler Grinn writes:
> OK, what I have now is that if the car of an alist item is a list, exact
> matching will be done for each list item, but if it is a string, it will
> be matched as a regular expression.
Sounds reasonable.
Note that your patch is >15LOC long and you need to sign the copyright
agreement with FSF in order to contribute. See
https://orgmode.org/worg/org-contribute.html#copyright
Some comments on the patch:
> * lisp/org.el (org-property-separators, org-property-get-separator):
> Created.
I'd make the function private: org--property-get-separator. It is not
intended as an API function.
> (org-entry-get, org-entry-get-with-inheritance): Use new
> org-property-get-separator function.
> org-property-separators is a customization option that allows for
Please quote the function name as `org-property-get-separator'.
> +If a property is specified multiple times with a =+=, like
> +=:EXPORT_FILE_NAME+:=, the old behavior was to always combine them
> +with a single space. For the new variable, the car of each item in
> the
Please, use double space " " to separate sentences. Also, see
doc/Documentation_Standards.org
> +For example, in order to combine =EXPORT_FILE_NAME= properties with a
> +forward slash =/=, one can use
> +
> +#+begin_src emacs-lisp
> +(setq org-use-property-inheritance '("EXPORT_FILE_NAME")
> + org-property-separators '((("EXPORT_FILE_NAME") . "/")))
> +#+end_src
This example is a bit confusing because it is unclear what you want to
achieve and why you also need to set inheritance.
> +(defcustom org-property-separators nil
> ...
> + :group 'org-properties
> + :type '(alist :key-type string :value-type sexp))
This defcustom type does not match what you described in the docstring.
You need something like :type '(alist :key-type (choice string (repeat string))
:value-type string)
Best,
Ihor
Re: [PATCH] lisp/org-table.el: Use booktabs on org-table-export
Pride Allman writes: > So basically, the export function is doing the overwrite for user options > but to reduce the number of inconsistency we can't use this patch for only > one such option. > > Now you explained it I can't think of a way to solve it without rewriting > the whole thing. Or maybe I need to read the source code more deeply. > Would it be too much to hope for it to be integrated on the basis that > things like this can be added for other options in other export backend > too? Or somehow introduce the global settings there. As an option, the override arguments can be factored out into defcustoms. Then, you would have an option to deal with the problem you encountered. Another possibility comes from the fact that the overrides are mostly copying the defaults or trying to transfer alternative option names into export options: (list :backend 'latex :latex-default-table-mode 'table ;; <- this is default :latex-tables-centered nil <- this is _not_ default. The current default is t :latex-tables-booktabs (plist-get params :booktabs) <- default is nil :latex-table-scientific-notation nil <- this is also default :latex-default-table-environment <- default is "tabular" but :environment is transferred (or (plist-get params :environment) "tabular")) Then, we can: 1. Remove options directly overriding the defaults 2. Do not assign :latex-tables-booktabs and :latex-default-table-environment unless :booktabs and :environment options are actually provided. Currently, when the latter options are not set by user (via #+attr_latex), they are treated as if the user force-set them to nil (because plist-get does not distinguish (:property nil) and complete absence of :property). I like the second possibility better because it will make table export consistent with the rest of export customisation. The downside is that we can break the existing workflows relying on current behaviour (which is not too much of a big deal though - we can always document this change in ORG-NEWS). The first possibility, on the other hand, will not break the current behaviour. However, it will only help people who manage to find this new customisation. We already have too many customisations. > And considering the answer is no for the previous question; is there a > workaround for this? Something people use? Because having to manually edit > the table everytime I export is a bit too much for me. Yes, there should be a workaround. org-table functions only override global export settings, not file-local and element-local. That is you should be able to set #+bind: org-latex-tables-booktabs org-latex-tables-booktabs. Or #+attr_latex: :booktabs t Of course, it is not very intuitive and relies on internal knowledge of the code. Best, Ihor
Re: [oc] multiple cite_export keywords for multiple export processors?
"Bruce D'Arcus" writes: >> Emm. org-cite-export-processors? > > So I recognize I don't fully understand the org export system, but > that sets global defaults. > > What if I want to set a different style on a specific document? There is also #+cite_export: keyword, but it only sets global processor. You cannot choose per-export backend options. So, you can use #+bind to set org-exportprocessors explicitly in buffer. Best, Ihor
Re: [BUG] Org-cycle strange behaviour in Emacs 29.0.50 [9.5.3 (9.5.3-g0b07b3 @ /home/yaslam/.emacs.d/straight/build/org/)]
Yusef Aslam writes: > Emacs : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version > 3.24.31, cairo version 1.16.0) > of 2022-05-09 > Package: Org mode version 9.5.3 (9.5.3-g0b07b3 @ > /home/yaslam/.emacs.d/straight/build/org/) > > I have strange behaviour in Emacs 29.0.50 and the org-cycle function inside > org-mode, my config is normal and I haven't changed the behaviour for the TAB > key inside org-mode. > > When I am in an org-mode document, pressing TAB doesn't show subtrees, I > bound org-cycle to double click on the mouse and it works everytime, just > when pressing TAB on a heading, it doesn't show the content of that heading > until I unfocus and then refocus the Emacs window. > > I switched back to Emacs 27.2 and went into one of my files that are in > org-mode, and org-cycle works perfectly when pressing TAB everytime. Thanks for the report! Are you able to reproduce the issue starting from emacs -Q? See https://orgmode.org/manual/Feedback.html Best, Ihor
Re: ivy-done and "Unregistered buffer modifications detected"
William Denton writes: > I was fiddling with my init file and something with pdf-tools blew up and > initialization went wrong and I lost my desktop history list of buffers I > always > have open. When I fixed the problem (by dropping pdf-tools, which I realized > I > never used), I had to load all the files I like to have open. I opened four, > and for each one I got the same warning, as you can see below. Further below > that is the full Org debug dump. > > I don't know if the ivy-done clue is enough to be helpful (maybe it just > means > there's something funny involving ivy), but if there's more I can do I'm glad > to > help. Thanks for the report! ivy-done does not appear to do anything with Org buffer. So, the warning looks rather strange. I am wondering if you can reproduce the problem using some minimal config starting from emacs -Q. See https://orgmode.org/manual/Feedback.html or https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9 Best, Ihor
Re: org-agenda todos list sorted by earliest deadline first
Sébastien Gendre writes: > The only option I have to set is: > ``` > (setq org-agenda-sorting-strategy '((agenda deadline-down time-up habit-up > priority-down timestamp-down category-keep) > (todo deadline-up priority-down > category-keep) > (tags priority-down category-keep) > (search category-keep))) > ``` > > Do the `deadline-up` option will apply to all todo lists in the agenda ? > Even the ones in custom views ? Yes. (setq org-agenda-sorting-strategy ...) is global setting. However, you can also set it locally inside custom agenda command if you wish. See the docstring of org-agenda-custom-commands: >> settings A list of option settings, similar to that in a let form, so like >> this: ((opt1 val1) (opt2 val2) ...). The values will be >> evaluated at the moment of execution, so quote them when needed. optN can be org-agenda-sort-strategy. Best, Ihor
Re: [oc] multiple cite_export keywords for multiple export processors?
"Bruce D'Arcus" writes: > I just saw a post on reddit that reminded me of this issue. > > User wants to use the oc-biblatex export processor for latex export, > but otherwise use oc-csl. > > They want to specify styles for each. > > This isn't possible currently; one has to modify the org source file > for each export target. > > Is there a relatively easy way to fix this? Emm. org-cite-export-processors? Best, Ihor
Re: [PATCH v4] org-encode-time compatibility and convenience helper
Max Nikulin writes: >> + (defmacro org-encode-time ( time) >> +(pcase (length time) ; Emacs-29 since d75e2c12eb >> + (1 `(encode-time ,@time)) >> + ((or 6 9) `(encode-time (list ,@time))) >> + (_ (error "`org-encode-time' may be called with 1, 6, or 9 >> arguments but %d given" >> +(length time) > > Should it be something like the following? > > (signal 'wrong-type-argument (list '(1 6 9) (length time))) > > or even > > (signal 'wrong-type-argument > (list '(lambda (n-args) (memq n-args) '(1 6 9)) (length time))) > > Usually "wrong type argument" errors give no clue even related to called > function til enabling enter debugger on error and realizing how to > reproduce the problem. The current error is fine. I'd rather propose Emacs to change the "wrong type argument" message to mention the function name. >> + ;; In Emacs-27 and Emacs-28 `encode-time' does not support 6 >> elements >> + ;; list argument so `org-encode-time' can not be outside of >> `pcase'. >> + (pcase-let >> + ((`(,_ ,_ ,_ ,d ,m ,y ,dow . ,_) (decode-time start))) >> +(pcase step >> + (`day (org-encode-time 0 0 org-extend-today-until (1+ d) >> m y)) >> + (`week >> + (let ((offset (if (= dow week-start) 7 >> + (mod (- week-start dow) 7 >> + (org-encode-time 0 0 org-extend-today-until (+ d >> offset) m y))) >> + (`semimonth (org-encode-time 0 0 0 >> + (if (< d 16) 16 1) >> + (if (< d 16) m (1+ m)) y)) >> + (`month (org-encode-time 0 0 0 month-start (1+ m) y)) >> + (`year (org-encode-time 0 0 org-extend-today-until 1 1 >> (1+ y)) > > I do not like repeating of `org-encode-time' but do not see another way > till Emacs-29 will become the lowest supported version. This is fine. AFAIK, other parts of time handling code is full of conds and pcases. >> +(org-encode-time >> + (apply #'list >> +(or (car time0) 0) >> +(+ (if (eq timestamp? 'minute) n 0) (nth 1 time0)) >> +(+ (if (eq timestamp? 'hour) n 0) (nth 2 time0)) >> +(+ (if (eq timestamp? 'day) n 0)(nth 3 time0)) >> +(+ (if (eq timestamp? 'month) n 0) (nth 4 time0)) >> +(+ (if (eq timestamp? 'year) n 0) (nth 5 time0)) >> +(nthcdr 6 time0 >>(when (and (memq timestamp? '(hour minute)) >> extra >> (string-match "-\\([012][0-9]\\):\\([0-5][0-9]\\)" extra)) > > I am tempting to write something like > >(let* ((ts (copy-sequence time0)) >(ord (memq timestamp? '(year month day hour minute))) >(field (and ord (nthcdr (length ord) ts > (when field >(setcar field (+ (car field) n))) > (org-encode-time ts)) > > but I am afraid it will make the code rather obscure. Yes, the second version is rather hard to understand. The proper solution would be writing (or using) some high-level time handling library and then using it in Org. Then, we would not need to deal with low-level time representations so frequently. >> + (org-encode-time >> + (append '(0) >> + (mapcar >> +(lambda (prop) (or (org-element-property prop timestamp) 0)) >> +(if end '(:minute-end :hour-end :day-end :month-end :year-end) >> + '(:minute-start :hour-start :day-start :month-start >> + :year-start))) >> + '(nil -1 nil >> >> (defun org-timestamp-has-time-p (timestamp) >>"Non-nil when TIMESTAMP has a time specified." > > Hardly may be considered as an example of elegant code. It is ok. You also could do it as `(0 ,@(mapcar (lambda (prop) ...) (if ...)) nil -1 nil) AFAIK, there is nothing much you can improve further without using function composition from dash.el. Best, Ihor
Re: [BUG] org-babel-load-file can not compile file
Max Nikulin writes: > Actual result: >> Compiling /home/ubuntu/examples/org/ex-ob-load-file.el...done >> Wrote /home/ubuntu/examples/org/ex-ob-load-file.elc >> progn: Cannot open load file: No such file or directory, ex-ob-load-file.el > > It seems, it is a regression caused by the Org commit > 0193b543e9ef84bfefe76d55e330d5b1cb842cef > >> - (byte-compile-file tangled-file 'load) >> + (byte-compile-file tangled-file) >> + (load tangled-file) What if you substitute the load call with (load (byte-compile-dest-file tangled-file))? Best, Ihor
Re: [PATCH] lisp/org-table.el: Use booktabs on org-table-export
Pride Allman writes: > This is my first patch so hopefully I followed the instructions correctly, Thanks for the patch! Patches are always welcome, though I do not fully agree with the approach you used in this particular one. > While using ~org-table-export~ on a table directly even with > ~org-latex-tables-booktabs~ set to ~t~, it exports a normal table instead > of booktabs table. But on the same situation, if you export the whole > buffer the table will be exported according to booktabs. I also find this discrepancy awkward. Normally, Org export options are chosen according to org-export-options-alist (see the docstring) and the equivalent variables in specific export backend (see org-export-define-backend 'latex in ox-latex.el). However, when you look into orgtbl-to-latex, orgtbl-to-html, orgtbl-to-texinfo, and orgtbl-to-unicode, they all overwrite certain export settings by force. Sometimes, even not leaving the user an option to choose. All those (list :option value ...) are force-overwriting the _global_ export defaults (see orgtbl-to-latex calling orgtbl-to-generic that calls org-export-get-environment with third argument) , including :latex-tables-booktabs. This is by design. While I do not like the current design, your patch will only create even more inconsistencies; The same problem will remain for other force-overwritten options. Best, Ihor
Re: Concatenate properties
Tyler Grinn writes:
> Ihor Radchenko writes:
>
>> Tyler Grinn writes:
>>
>>>
>>> Could you provide an example of what the value of that variable would be
>>> if, for instance, I wanted PROP_A and PROP_B to be joined with a single
>>> space and PROP_C and PROP_D to be concatenated? Or better yet, have the
>>> default be to join with a single space for any property and have only
>>> PROP_C and PROP_D concatenated?
>>
>> Say,
>>
>> '(("PROP_[CD]" . ""))
>>
>> or
>>
>> '(("PROP_[AB]" . "/") ("PROP_[CD]" . "") (".+" . "∿"))
>>
>> Best,
>> Ihor
>
> I'm not sure forcing regular expressions for all use cases is ideal. Is
> there a way to allow the option (I'm calling it org-property-separators)
> to allow either regular expressions or exact matches, like
> org-use-property-inheritance does?
It's up to you. I merely suggested that the new option should work
similarly to org-use-property-inheritance. It will not be the exact
match since we also need to provide the separator string.
> Other than that I'm mostly ready to send in my first patch. Should I
> attach it in this thread or start a new one?
Keeping the patch within this thread will be more reasonable for future
readers. Just remember to prefix the subject line with [PATCH].
Best,
Ihor
Re: [PATCH] Re: org-agenda-clock-report-header
Colin Baxter writes: > Unfortunately, I see no difference in my clock tables whether I have > org-agenda-clock-report-header set to t, nil or something like > "My-Heading", or if I put :Header: as a tag in the file headline that > contains the clock table, or if I write :Header t in the #+BEGIN: > clocktable line. You can see I'm ringing the changes in ignorant > desperation. I'm pretty stupid so I'm obviously missing something > fundamental here - but what? Because your clock tables in Org _files_ have nothing to do with agenda. There is no "Agenda clock report mode" when you create an ordinary clock report in Org buffers. Best, Ihor
Re: [BUG] Error when editing properties in column view [9.5.3 (release_9.5.3-452-g407104 @ /home/mbork/others-works/emacs/org-mode/lisp/)]
Marcin Borkowski writes: > When I try to edit a property in column view, I get the following error > message: > > Invalid column specification format: nil > > This only seems to happen if the point is not too close to the left > margin. I did a bit of digging and found out that the culprit is most > probably the `org-columns-update' function, which contains this: Thanks for the report! Confirmed. This (or similar) issue also appears when you run make test using Emacs master. AFAIK, it has been introduced in some of the Emacs master commits a few months ago where Emacs changed its behaviour. We probably need to bisect Emacs and figure out what exactly changed and whether the problem is on Emacs or Org side. Best, Ihor
Re: [BUG] void function incf in org-screenshot [9.5.3 (9.5.3-ga3dac4 @ /home/jds6696/.emacs.d/straight/build/org/)]
Justin Silverman writes: > I am getting an error > > > org-screenshot-generate-file-name: Symbol’s function definition is void: incf Thanks for the report! Note that org-screenshot is not a part of Org anymore. See the first item in https://orgmode.org/Changes.html. Nevertheless, this particular issue has been resolved in the new repository holding org-contrib (https://git.sr.ht/~bzg/org-contrib). Please, update your org-contrib to fix the error. Best, Ihor
Re: oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]
Kaushal Modi writes: > On Mon, May 9, 2022 at 5:44 PM Kaushal Modi wrote: >> >> I have now sent this to Emacs bug tracking: >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342 > > Thanks for the debug[1] Ihor! > > This issue was quickly fixed on Emacs master in > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d221c02fa1db17e1275687f0bbce4ff1499119a1. > > [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342#11 Thanks for reporting back! Note that apart from the problem on Emacs side, there appears to be a problem with org-cite-basic-export-bibliography. org-cite-basic-export-bibliography uses org-cite-basic--print-entry, which fails to print keys, which are not in .bib files. As a result, #+print_bibliography: appears to fail all the time when the document contains invalid cite keys. I consider this as a bug. At least org-cite-basic-export-bibliography could provide a more useful error message. Or maybe even skip the invalid keys. Or, similar to LaTeX, print ???. I am not sure which way will be more canonical according to general oc.el design. Best, Ihor
Re: [PATCH] (v2) New LaTeX code export option: engraved
Timothy writes: Thanks for the replies. I consider all but one as resolved. >> What will happen if there is no [LISTINGS-SETUP]? > > Captioned/Floating code blocks won’t work. Can you also add this to the documentation of the preamble variable? Otherwise, it may not be very clear what inclusion/removal of [LISTINGS-SETUP] does. Best, Ihor
Re: org-fold problems
Eric S Fraga writes: >> Note that I tried to run ediff-buffers on Org buffers and everything >> remains folded with stable Org 9.5 as well. > > That has not been my experience. I think... but cannot verify. I do > use drawers a lot and differences are often in them for the type of > document I was working on last week. > > With ediff, we need the documents being compared to be completely > expanded in general. I understand the issue. However, I do not fully understand why you get the documents fully unfolded. Can you create a reproducible example that shows how to compare to Org buffers/files and get them unfolded using an earlier Org version from emacs -Q? Best, Ihor
bug#55342: 29.0.50; org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil
Eli Zaretskii writes: >> From: Kaushal Modi >> Date: Mon, 9 May 2022 17:41:32 -0400 >> >> Exporting an Org file with citations on Emacs 29 now throws the error >> "Wrong value for ENTRY-OR-KEY: nil". This error can be reproduced with >> the Org version shipped with Emacs on the master branch. > > Shouldn't this be reported to Org developers first? It has been. However, part of the problem lies in the bibtex-map-entries: ;; If we have invalid entries, ensure that we have forward ;; progress so that we don't infloop. (if (= (point) prev) (forward-line 1) The code above always skips a bibtex entry starting at bob. Hence, the provided example bibliography is parsed as empty, which is not expected by Org. While handling empty bibfiles should be fixed on Org side, the current behaviour of bibtex-map-entries should indeed be fixed on Emacs side. Best, Ihor
Re: [BUG] orgtbl-toggle-comment hangs if table is in first line [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]
matteo writes: > If in an org buffer there is a table, commented or not, starting from > the first line of the buffer, the command orgtbl-toggle-comment hangs > and must be terminated with C-g. Thanks for reporting! Fixed on main via 0b07b30de. Best, Ihor
Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment
Eric S Fraga writes: > On Monday, 9 May 2022 at 20:47, Ihor Radchenko wrote: >> Moreover, it would be useful to be able to wrap the whole chunk into >> custom environment: >> #+attr_latex: :wrap [options]environmant > > This is already possible using special blocks? I.e. > > #+begin_environment > ... figure stuff > #+end_environment > > unless you mean something different. Nope. I meant exactly this. Time to re-read the manual again :) Best, Ihor
Re: [BUG] orgtbl-toggle-comment hangs if table is in first line [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]
matteo writes: > If in an org buffer there is a table, commented or not, starting from > the first line of the buffer, the command orgtbl-toggle-comment hangs > and must be terminated with C-g. Thanks for reporting! Fixed on main via 0b07b30de. Best, Ihor
Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment
Juan Manuel Macías writes: > If we want to introduce arbitrary LaTeX code at the very beginning of a > float environment, apart from the usual tricks of putting the code in > :caption or :placement, this solution I describe here is more from the > LaTeX side. I thik its advantages are more control and consistency from > the point of view of LaTeX, and the possibility of introducing code of a > certain complexity. I'd be happy to see a built-in solution for this. I feel that the ability to insert arbitrary LaTeX code near the begin/end of environment would be generally a useful feature to have in ox-latex. It could be done via #+attr_latex: :pre/:post Moreover, it would be useful to be able to wrap the whole chunk into custom environment: #+attr_latex: :wrap [options]environmant WDYT? Best, Ihor
[PATCH] Re: [ISSUE] Re: [PATCH] lisp/org-agenda.el: Add header to agenda clock report table
"Christopher M. Miles" writes: > I tested this commit, it should auto append a newline character after > ~org-agenda-clock-report-header~. Otherwise the header line will in same line > with table first line. Reasonable concern. The attached patch should fix it. Best, Ihor >From c918d5097af4ca82e381cc7a45efccebadf22e91 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Mon, 9 May 2022 20:35:18 +0800 Subject: [PATCH] org-agenda: Make sure that clock report header has trailing newline * lisp/org-agenda.el (org-agenda-list): Add trailing newline to `org-agenda-clock-report-header' if there is none. --- lisp/org-agenda.el | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9d38b889d..3a795ef74 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4486,8 +4486,10 @@ (defun org-agenda-list ( arg start-day span with-hour) (setq p (plist-put p :tend clocktable-end)) (setq p (plist-put p :scope 'agenda)) (setq tbl (apply #'org-clock-get-clocktable p)) -(when org-agenda-clock-report-header - (insert (propertize org-agenda-clock-report-header 'face 'org-agenda-structure))) + (when org-agenda-clock-report-header +(insert (propertize org-agenda-clock-report-header 'face 'org-agenda-structure)) +(unless (string-suffix-p "\n" org-agenda-clock-report-header) + (insert "\n"))) (insert tbl))) (goto-char (point-min)) (or org-agenda-multi (org-agenda-fit-window-to-buffer)) -- 2.35.1
[PATCH] Re: org-agenda-clock-report-header
Colin Baxter writes: > Could more information perhaps be added to the doc string of > "org-agenda-clock-report-header"? And an example would be very > useful. As it stands at present, I haven't a clue as to what the > variable does and why it might be useful. It's literally a string inserted right before the table. There is nothing much to show there. See https://orgmode.org/list/CAJAdVc06_tj58Je=tn42jqfutkjamqbqdcvobqxeegars_m...@mail.gmail.com Is version in the attached patch more clear? Best, Ihor >From 9b5f5844aedfab9f36ba89ed8beca36651370c0a Mon Sep 17 00:00:00 2001 Message-Id: <9b5f5844aedfab9f36ba89ed8beca36651370c0a.1652099870.git.yanta...@gmail.com> From: Ihor Radchenko Date: Mon, 9 May 2022 20:34:38 +0800 Subject: [PATCH] org-agenda-clock-report-header: Update docstring See https://orgmode.org/list/87o808j6si@yandex.com --- lisp/org-agenda.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 0479a0e1f..9d38b889d 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -1221,11 +1221,11 @@ (defcustom org-agenda-timegrid-use-ampm nil :type 'boolean) (defcustom org-agenda-clock-report-header nil - "Header for org agenda clock report mode" + "Header inserted before the table in Org agenda clock report mode." :group 'org-agenda :type '(choice -(string :tag "Header") -(const :tag "No header" nil)) + (string :tag "Header") + (const :tag "No header" nil)) :safe #'stringp :package-version '(Org . "9.6")) -- 2.35.1
Re: how to best correct exams (code matlab) using org mode (and tables)
Uwe Brauer writes: > I am now experimenting with org-remark putting the remarks and marks in the > property sections of headers and use than > What do others use? I haven't tried org-remark yet, but I am using something somewhat similar (but much simpler). Every time I add a note to a heading with C-c C-z, the last note contents is saved to SUMMARY heading property. See https://github.com/yantar92/emacs-config/blob/master/config.org#column-mode > I strongly condemn Putin's war of aggression against the Ukraine. > I support to deliver weapons to Ukraine's military. > I support the ban of Russia from SWIFT. > I support the EU membership of the Ukraine. Thanks! Best, Ihor
Re: [PATCH] (v2) New LaTeX code export option: engraved
Timothy writes:
> I have a new set of patches (attached), which make use of a major new feature
> in
> engrave-faces v0.3: engraved themes.
Thanks!
> Glad to hear you’ve been able to have a look over the patches. With the
> feedback
> I’ve received here so far, if no issues come up in the next few days I’m
> inclined to merge this, add documentation, and see what feedback pops
> up.
Before merging, could you also try to implement tests at least for
engraved feature? If I recall correctly, we do not currently have
backend-specific tests. But it would certainly help if we did. You might
as well write a small "nucleus" test for ox-latex.
Also, unless I miss something, there is no support for coderefs in the
patchset. Is it intentional?
> +(defun org-latex-src-block--verbatim
> ...
> + (let ((caption-str (org-latex--caption/label-string src-block info))
> +(defun org-latex-src-block--custom
> ...
> + (let ((caption-str (org-latex--caption/label-string src-block info))
> +(formatted-src (org-export-format-code-default src-block info)))
It appears that the code for caption-str is duplicated. It could be
also factored out.
> + (format-spec custom-env
> + `((?s . ,formatted-src)
> + (?c . ,caption)
> + (?f . ,float)
> + (?l . ,(org-latex--label src-block info))
> + (?o . ,(or (plist-get attributes :options) "")))
I do not see a definition of `format-spec' function. There is only
`spec' above in the code. Can you double check? Either I am missing
something or something fishy is going on.
> + (let ((code (org-element-property :value inline-src-block))
> +(lang (org-element-property :language inline-src-block)))
> +(pcase (plist-get info :latex-listings)
> + ('nil (org-latex--text-markup code 'code info))
> + ('minted (org-latex-inline-src-block--minted info code lang))
> + (_ (org-latex-inline-src-block--listings info code lang)
Please use `nil and `minted. Using ' may create issues in older Emacs.
> +% In case engrave-faces-latex-gen-preamble has not been run.
> +\\providecolor{EfD}{HTML}{f7f7f7}
> +\\providecolor{EFD}{HTML}{28292e}
What is the difference between EfD and EFD? EfD is also not documented.
> +FVEXTRA-SETUP sets fvextra's defaults according to
> +`org-latex-engraved-options', and LISTINGS-SETUP creates the
> +listings environment and defines \\listoflistings."
It is unclear what listings environment does given that we use engraved
package. Can you provide a bit more details in the docstring on what the
user will get if [LISTINGS-SETUP] is present.
It may catch users by surprise that deleting this will make captions
disappear.
> @@ -1756,6 +1929,17 @@ (defun org-latex-template (contents info)
> (let ((template (plist-get info :latex-hyperref-template)))
> (and (stringp template)
> (format-spec template spec)))
> + ;; engrave-faces-latex preamble
> + (when (eq org-latex-listings 'engraved)
> + (let ((src-p (org-element-map (plist-get info :parse-tree)
> +'(src-block inline-src-block) #'identity
> +info t))
> + (fixedw-p
> + (org-element-map (plist-get info :parse-tree)
> + '(example-block fixed-width) #'identity
> + info t)))
> + (when (or src-p fixedw-p)
> + (org-latex-generate-engraved-preamble info src-p
Why not just
(org-element-map (plist-get info :parse-tree)
'(src-block inline-src-block example-block fixed-width)
#'identity
info t)
?
> (pcase (plist-get info :latex-listings)
>('nil (org-latex--text-markup code 'code info))
>('minted (org-latex-inline-src-block--minted info code lang))
> + ('engraved (org-latex-inline-src-block--engraved info code lang))
>(_ (org-latex-inline-src-block--listings info code lang)
Same comment about ` in pcase.
> (defun org-latex-inline-src-block--listings (info code lang)
>"Transcode an inline src block's content from Org to LaTeX, using
> lstlistings.
> INFO, CODE, and LANG are provided by `org-latex-inline-src-block'."
> @@ -2323,6 +2513,7 @@ (defun org-latex-keyword (keyword _contents info)
> (cl-case (plist-get info :latex-listings)
> ((nil) "\\listoffigures")
> (minted "\\listoflistings")
> + (engraved "\\listoflistings")
> (otherwise "\\lstlistoflistings")
What will happen if there is no [LISTINGS-SETUP]?
> +(defcustom org-latex-engraved-theme nil
> + "The theme that should be used for engraved code, when non-nil.
> +This can be set to any theme defined in `engrave-faces-themes' or
> +loadable by Emacs. When set to t, the current Emacs theme is
> +used."
> + :group 'org-export-latex
> + :type 'symbol)
Docstring does not explain what happens when set to nil.
Also,
Re: Concatenate properties
Tyler Grinn writes:
>
> Could you provide an example of what the value of that variable would be
> if, for instance, I wanted PROP_A and PROP_B to be joined with a single
> space and PROP_C and PROP_D to be concatenated? Or better yet, have the
> default be to join with a single space for any property and have only
> PROP_C and PROP_D concatenated?
Say,
'(("PROP_[CD]" . ""))
or
'(("PROP_[AB]" . "/") ("PROP_[CD]" . "") (".+" . "∿"))
Best,
Ihor
Re: [PATCH] org-attach: Attach current Gnus article parts
Juan Manuel Macías writes: > What I don't quite understand is why it wouldn't be appropriate to add a > new entry with the new feature to the org-attach menu. Thinking about it more, new feature in org-attach menu should actually be ok. My initial logic was that we cannot easily select attach method for entries in the attach menu. However, anything other than 'cp method is meaningless when saving article attachments. > Well, as I said, I have chosen Gnus because it is part of GNU Emacs. In > any case, if anyone wants to write a patch with a more general solution, > I'd encourage them. I think that would be an interesting feature for > org-attach. I only use Gnus and unfortunately I'm not familiar with > other mail reader libraries (I could try to do something more "agnostic" > from message-mode, when I have some more time...). I think that a good example implementation is from notmuch.el. It does not use anything specific to notmuch, just built-in mm-*.el from gnus: (defun notmuch-save-attachments (mm-handle queryp) (notmuch-foreach-mime-part (lambda (p) (let ((disposition (mm-handle-disposition p))) (and (listp disposition) (or (equal (car disposition) "attachment") (and (equal (car disposition) "inline") (assq 'filename disposition))) (or (not queryp) (y-or-n-p (concat "Save '" (cdr (assq 'filename disposition)) "' "))) (mm-save-part p mm-handle)) (defun notmuch-foreach-mime-part (function mm-handle) (cond ((stringp (car mm-handle)) (dolist (part (cdr mm-handle)) (notmuch-foreach-mime-part function part))) ((bufferp (car mm-handle)) (funcall function mm-handle)) (t (dolist (part mm-handle) (notmuch-foreach-mime-part function part) Best, Ihor
Re: Problem with org-babel and geiser
Rudolf Adamkovič writes: > P.S. > > We should add 'testing/lisp/test-ob-scheme.el' or it will break again > sooner or later. Can we make the Org test suite depend on Geiser and > Guile? Given that Org uses Geiser out of the box, I think we should. > What do you think? Sounds reasonable. Patches are welcome! Best, Ihor
Re: org-agenda-filter-by-tag doco
Phil Hudson writes: > I'd like to expand the docstring of command `org-agenda-filter-by-tag` > to document the Elisp equivalent of interactive prefix arguments. By > trial and error and guesswork I determined that I could emulate `C-u > C-u` by passing `'(16)` as the second argument > (`strip-or-accumulate`). I'd like to add text explaining this, > generalized to all prefix combinations. I do not think that it is a good idea. There is not much point explaining basic Emacs concepts discussed in Emacs/Elisp manual in every docstring of functions making use of universal arguments. Note that C-u gets automatically highlighted when you view the function docstring. Clicking on it brings you to the docstring for universal argument, which, in turn, also contains a link to the manual page. I think it is good enough. Best, Ihor
Re: [PATCH] org-attach: Attach current Gnus article parts
Juan Manuel Macías writes: > In the attached patch I add a new command for org-attach: save *all* > attachments from the current Gnus article to the current org-attach-dir. > > (Sorry for repeating the word "attach" so much :-)) > > NB: > > 1. If no Gnus article is open, it returns an error message. > > 2. I've only tested it on Emacs 28. I don't know if it can cause any > problems on earlier Emacs/Gnus versions. > > 3. Although there are several alternatives to Gnus, I have chosen Gnus > specifically because it is part of GNU Emacs. > > 4. I think an option could be added to save only certain types of files > (pdf, png, jpg, docx, etc.). I think that supporting only Gnus is too specific. Not all the people use Gnus as mail reader. And the extra menu option you propose will only eat up space for people not using Gnus. I'd prefer a more generic approach working in any kind of email reader, be it rmail, gnus, mu4e, notmuch, or wunderlust. The approach can probably making use of message-mode or MML libraries from Emacs core. Also, I do not like adding yet another menu option even if it is working for other mail readers. Instead, it would be more consistent to follow what we do for dired. See interactive spec in org-attach-attach. Best, Ihor
Re: Concatenate properties
Tyler Grinn writes: > John Kitchin writes: > >> I like the variable idea. I would make it a concatenation string for >> joining. That way “” would concatenate the way Tyler wants, “ “ would >> preserve current behavior, and “,” could lead to a comma separated >> list for example. Other things like “\n” might lead to a column, etc. > > I'm not a huge fan of the variable idea because it would make it > impossible to include both behaviors in a single file, whereas extending > the syntax maintains any existing properties that used '+'. I think I need to elaborate what I meant by "similar to org-use-property-inheritance". org-use-property-inheritance docstring: >>> When nil, only the properties directly given in the current entry >>> count. When t, every property is inherited. The value may also be a >>> list of properties that should have inheritance, or a regular >>> expression matching properties that should be inherited. Similarly, concatenation of PROPERTY+ can be controlled on per-property basis. Best, Ihor
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Ignacio Casso writes: >> I have added TINYCHANGE cookie as you don't appear to have FSF copyright > > I should have it, I did the paperwork for commit 2b564f504b in > Emacs. Maybe I used a different email? Or maybe the problem is that now > that I see it I don't have my full name configured in git. It's Ignacio > Casso, and I appear in the commit author field as just Ignacio. I have > fixed it now for future commits. I see. The problem is that I do not have access to the up-to-date contributor list. And you are not listed in https://orgmode.org/worg/contributors.html Bastien, could you kindly check if Ignacio Casso has FSF assignment and update contributors page accordingly? Best, Ihor
Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Ignacio Casso writes: > Done. I attach the patch: Thanks! Applied onto main as a3dd2 with minor amendments. I have added TINYCHANGE cookie as you don't appear to have FSF copyright assignment and capitalised "match" in the commit summary. Best, Ihor > From 646f2a792dc5c6e6fa3933eb1d06420c86cd53c3 Mon Sep 17 00:00:00 2001 > From: Ignacio > Date: Fri, 6 May 2022 13:51:14 +0200 > Subject: [PATCH] lisp/org.el: match COMMENT in > `org-complex-heading-regexp-format' > > * lisp/org.el (org-set-regexps-and-options): Change > `org-complex-heading-regexp-format' initialization so that the regexp > it produces also matches a headline if it is commented. > --- > lisp/org.el | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/lisp/org.el b/lisp/org.el > index 1d5fc3903..cab59b87c 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -3846,7 +3846,8 @@ expected to be bound to nil when matching against this > regexp.") >"Printf format to make regexp to match an exact headline. > This regexp will match the headline of any node which has the > exact headline text that is put into the format, but may have any > -TODO state, priority and tags.") > +TODO state, priority, tags, statistics cookies (at the beginning > +or end of the headline title), or COMMENT keyword.") > > (defvar-local org-todo-line-tags-regexp nil >"Matches a headline and puts TODO state into group 2 if present. > @@ -4213,6 +4214,8 @@ related expressions." > "\\(?: +" org-todo-regexp "\\)?" > "\\(?: +\\(\\[#.\\]\\)\\)?" > "\\(?: +" > + ;; Headline might be commented > + "\\(?:" org-comment-string " +\\)?" > ;; Stats cookies can be stuck to body. > "\\(?:\\[[0-9%%/]+\\] *\\)*" > "\\(%s\\)" > -- > 2.25.1 > -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: [PATCH] update ob-scheme to latest changes in geiser package
Tim Van den Langenbergh writes: > I have updated the patch and enclosed it, feel free to drop a line if you > notice anything else obviously missing. Thanks! Applied onto main as 06d08e6f3. Best, Ihor
Re: Recent changes in org-fold regarding emphasize visibility
Daniel Fleischer writes: >> The question is what should be the logical behaviour of Org when editing >> text inside or at the border of these hidden text types? How should we >> interpret the values of org-catch-invisible-edits (nil error show >> show-and-error smart)? > > Not sure we need to reinterpret the settings; roughly they cover the > different options of what to do when you edit a hidden text: edit > anyways, throw an error, unfold but do nothing, unfold and do what you > wanted to do and the only thing I don't have an intuition about is the > smart option. > > BTW, there are no issues when the folding core style is "overlays". So > why not follow what happens in that case, even formalize it into tests? Reasonable. I have made changes in invisible edit handling. Now, when using 'text-properties style, org-fold-check-before-invisible-edits ignores folded links just like it does with overlays style. The commit is 2e4ed52b1. Let me know if you are getting the expected behaviour now. Best, Ihor
Re: org-fold problems
Eric S Fraga writes: > On a related matter, I typically use vc-ediff for comparing the current > working copy of a file and the last committed version. This used to > expand the file completely (assuming I'm remembering correctly) but now > (some?) drawers are not opened so if there are differences inside a > drawer, I cannot see them via ediff. Does this make sense? If so, is > there something I should customise to have *everything* opened when > using ediff? I suspect the same issue. If you try M-: (setq org-fold-core-first-unfold-functions nil) before doing ediff and it helps, then I will know the culprit. Note that I tried to run ediff-buffers on Org buffers and everything remains folded with stable Org 9.5 as well. Best, Ihor
Re: org-fold documentation
Max Nikulin writes: > Will it help to create files like org-fwd.el with function declarations > to allow other packages (even from org-mode) to use "(require > 'org-fwd.el)" instead of adding a lot of `declare-function' forms that > must be kept in sync with function definitions? It is an interesting idea, though I would not put a priority on such a change. Also, properly fixing circular dependencies will be even better. The current situation highlights the inconsistencies of our current code design. Best, Ihor
Re: [org-contrib] Take over maintaining of org-contacts.el
"Christopher M. Miles" writes: > Yes, please update to new place: https://repo.or.cz/org-contacts.git. > Thanks for checking this up, I have not realized missed migration of > org-contacts repo. Done in 15b03d5. Best, Ihor
Re: [PATCH] style/worg.css: Display TOC on top
Ihor Radchenko writes: > > The attached patch fixes the issue. Applied as 8d7d0c77
Re: [PATCH] Add unmaintained warnings for applicable blogging tools
thecashewtrader writes: > --- > org-blog-wiki.org | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) Thanks! Applied as ab6ab6d9. Best, Ihor
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
Max Nikulin writes: > To wrap up, I suggest (and I do not insist) to drop > "-Djava.awt.headless=true" since "-headless" is anyway added in jar > mode. Those who desperately need namely "-Djava.awt.headless=true" (for > some unknown to me reason) may customize :java header argument. I do not > see any real problem with the change, just a minor improvement. After further consideration, I decided to follow your suggestion. If we insist of -Djava.awt.headless=true in org-plantuml-exec-mode='jar but not in 'plantuml, we may run into inconsistency between users using the two alternatives. Applied onto main as b5f0efc04. Best, Ihor
