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
Bug: ob-R.el breaks when :session is specified
Hi there, 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. When removing the :session argument it executes and returns as expected. When bisecting this issue, I found that this commit causes it: ac8c009e006197d2dad226dbe822d450aec23d23 lisp/ob-R.el: Fix session output with substrings matching prompts Reverting it fixes the issue for earlier release (9.5.3) as well as for the current main branch. The (with-current-buffer session ... ) somehow seems to break it for me, but I am unsure why no one else here seems to experience this as the commit is from 2020? Any suggestions? Thanks! Christian signature.asc Description: This is a digitally signed message part
a problem with lilypond babel fontification
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.
The error occurs on every ending lilypond block line, #+end_src.
How can I fix this?
Thanks in advance :),
Edgard
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: I can't set dabbrev to respect the writen case
Ypo writes: > Hi > > I find dabbrev and fancy-dabbrev very useful to typing fast. But there > is a problem I am not able to solve: When I apply an expansion while > writing, the case is always that of the expansion, I can't make it to > respect what I have written. An example: > > — (Typing) "Hel > > — (Offered expansion) "hello" > > — (What I get when accepting the expansion) "hello" > > — (What I wanted) "Hello" > > Best regards, > > Ypo > Take a look at these variables. I have them configured as non-nil: (setq dabbrev-case-replace t) (setq dabbrev-case-fold-search t) Best regards, Juan Manuel
I can't set dabbrev to respect the writen case
Hi I find dabbrev and fancy-dabbrev very useful to typing fast. But there is a problem I am not able to solve: When I apply an expansion while writing, the case is always that of the expansion, I can't make it to respect what I have written. An example: — (Typing) "Hel — (Offered expansion) "hello" — (What I get when accepting the expansion) "hello" — (What I wanted) "Hello" Best regards, Ypo
org-noter
Hi I am running GNU emacs master (2 month old) and have not been able to use successfully org-noter. When I open a pdf file with doc-view there seems no way to add a note to the file. The documentation says one should simple press «i», but either with (org-noter-notes-mode 'toggle) that binding is not defined with org-noter-doc-mode it is but nothing happens, only garbage collecting. Can anybody enlighten me please? Uwe Brauer -- 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.
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: [BUG] org-babel-load-file can not compile file
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) As to another patch 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 The following thread should be more suitable for discussion Greg Minshall to emacs-orgmode. tangle option to not write a file with same contents? Thu, 28 Oct 2021 07:04:58 +0300. https://list.orgmode.org/583051.1635393...@apollo2.minshall.org
Re: \minus entity and LaTeX export
On 14/05/2022 13:30, Ihor Radchenko wrote:
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.
Timothy tried texlive-2022, I had 2019 installed, users of old versions
may add \usepackage{textcomp}.
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.
I am a bit lazy to check what font and what codepoint is used in each case.
From my point of view, the correct way to type negative numbers is
\(-1\), not \(-\)1. TeX math mode sets proper spaces around the
character, e.g. \(1 - 1\) has larger spaces around. I considered \minus
as something special for cases when a user has reasons to avoid math,
e.g. to avoid MathJax or images when a document contains only a few of
simple expressions.
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: [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/)]
Thanks so much, Ihor. On Sat, 14 May 2022 at 06:08, Ihor Radchenko wrote: > > 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
