Re: org-capture at point
Since org-plus-contrib 20200920, I'm no longer able to get org-capture to insert a template at the point. Instead, it seems to place the entry at the appropriate heading level, above the current heading. Looking at the help page, perhaps it's this behavior: This happens with both a custom interactive function that calls (org-capture 0), and by using a zero prefix. I'm not able to get this functionality to work: "When called with a ‘C-0’ (zero) prefix, insert a template at point." I can confirm this behavior. Looks like it was introduced with: f5573e6a0 org-capture.el: Fix heading's level when inserting a template "here" I tested by running the following: #+begin_src emacs-lisp :lexical t (dotimes (n 3) (let ((org-capture-templates `(( "e" "test" entry (file "/temp/null.org") ,(format "* %d" n) :immediate-finish t :no-save t (goto-char (point-max)) (org-capture 0 "e"))) #+end_src with Org built from f5573e6a0 output is: * 1 * 2 * 0 prior to f5573e6a0 (tested on b79fef1da) output is: * 0 * 1 * 2
Re: opening a 0.5 MB org file is slow
> There's a thread about improving this, see: > https://orgmode.org/list/87h7x9e5jo.fsf@localhost/ > > Just in case that's of interest :) If anyone is interested, any feedback and/or testing will be appreciated. The relevant patch is complete in terms of functionality now. Best, Ihor TEC writes: > Samuel Wales writes: > >> a long time ago i discovered that drawers were the bottleneck. >> i >> removed a lot of them and got much faster loading speeds. idk >> if that >> is still true. > > There's a thread about improving this, see: > https://orgmode.org/list/87h7x9e5jo.fsf@localhost/ > > Just in case that's of interest :) > > Timothy.
Re: opening a 0.5 MB org file is slow
Samuel Wales writes: a long time ago i discovered that drawers were the bottleneck. i removed a lot of them and got much faster loading speeds. idk if that is still true. There's a thread about improving this, see: https://orgmode.org/list/87h7x9e5jo.fsf@localhost/ Just in case that's of interest :) Timothy.
Re: PATCH: Display point of code block point when confirming evaluation
Kyle Meyer writes: That sounds reasonable to me, and the change looks fine to me. My only thought is that perhaps the line number would be friendlier to report, but I don't feel strongly about that. +1 for line numbers Assuming the current format is something like: "Do you want to eval block at y/n:" I'd be in favour of: "Do you want to eval block at (line ) y/n:" or similar. All the best, Timothy.
Re: opening a 0.5 MB org file is slow
a long time ago i discovered that drawers were the bottleneck. i removed a lot of them and got much faster loading speeds. idk if that is still true. i think there is an effort to speed logbook and properties up by changing from overlays to text properties or so. recent maint is perhaps twice as fast at loading for me as the previous release was. On 9/29/20, Ihor Radchenko wrote: >> I'm afraid I don't know how to profile the opening of a file. Does >> anybody know a function that would do the profiling like >> elp-instrument-function for functions? > > There is elp-instrument-package. Also, I did successful profiling with > simple profiler-start/profiler-report before and after opening the file. > > In general, time for opening org files depends on many factors [1]. > Profiling is the way to go if one wants to find the bottlenecks. > > > [1] > https://www.reddit.com/r/orgmode/comments/ivifjv/a_question_about_orgagenda_performance_and_org/g5rxzf6/ > > Best, > Ihor > > > > Jeremie Juste writes: > >> Hello Uwe, >> >> Can you test with emacs -Q ? >> >> A 1.6M org file took a little under 7 sec on my computer. >> It probably depends on the number of minor modes are being loaded, >> font-lock, >> auto-completion, etc. >> >> I'm afraid I don't know how to profile the opening of a file. Does >> anybody know a function that would do the profiling like >> elp-instrument-function for functions? >> >> -- >> HTH >> Jeremie Juste >> >> >> >> On Tuesday, 29 Sep 2020 at 21:11, Uwe Brauer wrote: >>> Hi >>> >>> maybe I am just to impatient but on my 8 GB Thinkpad X1 (4gen) to open a >>> 0.5MB org file takes around 15 sec. >>> >>> Any change to speed this up? >>> >>> Thanks and regards >>> >>> Uwe Brauer >>> > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: opening a 0.5 MB org file is slow
> I'm afraid I don't know how to profile the opening of a file. Does > anybody know a function that would do the profiling like > elp-instrument-function for functions? There is elp-instrument-package. Also, I did successful profiling with simple profiler-start/profiler-report before and after opening the file. In general, time for opening org files depends on many factors [1]. Profiling is the way to go if one wants to find the bottlenecks. [1] https://www.reddit.com/r/orgmode/comments/ivifjv/a_question_about_orgagenda_performance_and_org/g5rxzf6/ Best, Ihor Jeremie Juste writes: > Hello Uwe, > > Can you test with emacs -Q ? > > A 1.6M org file took a little under 7 sec on my computer. > It probably depends on the number of minor modes are being loaded, font-lock, > auto-completion, etc. > > I'm afraid I don't know how to profile the opening of a file. Does > anybody know a function that would do the profiling like > elp-instrument-function for functions? > > -- > HTH > Jeremie Juste > > > > On Tuesday, 29 Sep 2020 at 21:11, Uwe Brauer wrote: >> Hi >> >> maybe I am just to impatient but on my 8 GB Thinkpad X1 (4gen) to open a >> 0.5MB org file takes around 15 sec. >> >> Any change to speed this up? >> >> Thanks and regards >> >> Uwe Brauer >>
Re: PATCH: Display point of code block point when confirming evaluation
Thanks for the patch, and sorry for the very delayed response. Jarmo Hurri writes: > Greetings. > > Please find attached a patch that adds the point of the source code > block to the message shown to user when confirming the evaluation of the > block. > > In large org-files, I have often trouble figuring out which code block > Org is confirming me to evaluate when exporting. This is especially true > when I have set 'cache: yes'. When something changes in code, these > blocks need to be re-evaluated during export, but the '#results:' of > these blocks are not changed. Therefore, on the next export I will be > asked again, unless I find the block and evaluate it by hand myself. > > This patch adds the 'start' element of source block info at the end of > the confirmation message. That sounds reasonable to me, and the change looks fine to me. My only thought is that perhaps the line number would be friendlier to report, but I don't feel strongly about that. I'll wait a few days for any babel users to chime in and then apply (unless you reply that you'd like to reroll it to use line numbers).
Re: Proposal: do not align tags in Agenda
Michaël Cadilhac writes: > Hello all, > > I have a wide screen, which makes right edge alignment of tags in the > agenda inconvenient (they're hard to match with the main entry). > Setting org-agenda-tags-column to a specific column overwrites part of > the entry, which is not optimal. I'd simply want the tag to be put > _after_ the entry. Hmm, I don't think it's supposed to overwrite part of the entry. I haven't been able to trigger that on my end. Here's the setup I tried with an otherwise vanilla configuration: (setq org-agenda-files (list "/tmp/scratch.org")) (setq org-agenda-tags-column 25) where /tmp/scratch.org looks like this * TODO foo bar baz :one: * TODO b :two: When I run org-todo-list, the longer top entry isn't overwritten: Global list of TODO items of type: ALL Press ‘N r’ (e.g. ‘0 r’) to search again: (0)[ALL] (1)TODO (2)DONE scratch:TODO foo bar baz :one: scratch:TODO b :two: What am I missing?
Framing images?
I'd like to have a frame around images in my exported documents. I'm primarily interested in LaTeX export, but html is a secondary concern. Is there any easy way to do this that I'm failing to find? Kind regards, Mike
Re: Bug: Math mode doesn't work if followed by a dash [9.4 (nil @ /home/gutin/.emacs.d/.local/straight/build/org-mode/)]
See below.
> On Sep 29, 2020, at 11:53 AM, Richard Lawrence wrote:
>
> "Berry, Charles" writes:
>
>> The case Gutin describes conforms to the documentation, viz. `$x\beta$-`
>> should produce math mode LaTeX as I read the next paragraph.
>>
>> From (info "(org) LaTeX fragments"):
>>
>> • Text within the usual LaTeX math delimiters. To avoid conflicts
>> with currency specifications, single ‘$’ characters are only
>> recognized as math delimiters if the enclosed text contains at most
>> two line breaks, is directly attached to the ‘$’ characters with no
>> whitespace in between, and if the closing ‘$’ is followed by
>> whitespace, punctuation or a dash.
>
> Hmm, good point.
>
> It looks to me like the relevant function is
> org-element-latex-fragment-parser, and the code for that hasn't changed
> much in several years (last change was 2017). (Also, I was wrong,
> parsing latex fragments is not done with just a regexp.) I can confirm
> that this function parses "$foo" in "$foo$ bar" as a latex fragment, but
> not in "$foo$-bar"
>
> Not sure if the problem here is the code or the documentation. Perhaps
> the documentation should be updated to reflect the current behavior?
>
Using
"\\(-\\|\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)"
as the regexp for the `looking-at-p` seems to resolve this. To save you some
eyestrain, there is "-\\|" added near the beginning right after "\\(" to match
the trailing dash.
Per (info (elisp) "Syntax Class Table"), neither \\s. nor \\s- include the
dash. \\s_ includes dash, but also $, so that seems like trouble.
Caveat: I've not run `make test`, so am unsure if there is a subtle gotcha
hidden here.
HTH,
Chuck
Re: opening a 0.5 MB org file is slow
On Tue, Sep 29, 2020 at 11:06:39PM +0200, Jeremie Juste wrote: > Can you test with emacs -Q ? Another good question is are you starting Emacs and opening the file, or just opening the file with Emacs already loaded? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: [PATCH] Omit file description when :file-desc has nil value
Kyle Meyer writes:
> I'd be happy for you to take what I sent and work it into a proper
> patch. Here are some other loose ends in addition to the manual update
> you mentioned:
>
> * a NEWS entry for 9.5
>
> * decide whether (:file-desc . []) should be handled explicitly rather
> than the current "any value that org-babel-read doesn't map to nil
> or a string"
>
> * check that there's a test case for each :file-desc scenario
Let me know if I missed anything, or any other issues. I've decided to
handle the empty vector case explicitly. I think this behavior is
clearer.
Thanks,
Matt
>From 749fd5ade6b65f9d07e87b4af44ebb1afef2bee6 Mon Sep 17 00:00:00 2001
From: Matt Huszagh
Date: Tue, 29 Sep 2020 14:11:59 -0700
Subject: [PATCH] list/ob-core.el: Allow passing empty vector to :file-desc to
omit description
* doc/org-manual.org (Type): Document empty vector argument for
file-desc.
* etc/ORG-NEWS (New argument for ~file-desc~ babel header): Add entry
to NEWS.
* lisp/ob-core.el (org-babel--file-desc): Add new function to evaluate
file description value.
(org-babel-execute-src-block): Correctly evaluate file description
when executing src block.
(org-babel-insert-result): Correctly evaluate file description value
when inserting the result of src block execution into the buffer.
* testing/lisp/test-ob.el (test-ob/file-desc-header-argument): Add
test case for new behavior.
---
doc/org-manual.org | 8 +---
etc/ORG-NEWS| 13 -
lisp/ob-core.el | 16 +++-
testing/lisp/test-ob.el | 20 +++-
4 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index e7d25b90e..a790f3225 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17482,10 +17482,12 @@ default behavior is to automatically determine the result type.
#+end_example
#+cindex: @samp{file-desc}, header argument
- The =file-desc= header argument defines the description (see
- [[*Link Format]]) for the link. If =file-desc= is present but has no value,
+ The =file-desc= header argument defines the description (see [[*Link
+ Format]]) for the link. If =file-desc= is present but has no value,
the =file= value is used as the link description. When this
- argument is not present, the description is omitted.
+ argument is not present, the description is omitted. If you want to
+ provide the =file-disc= argument but omit the description, you can
+ provide it with an empty vector (i.e., :file-desc []).
#+cindex: @samp{sep}, header argument
By default, Org assumes that a table written to a file has
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5dc68cba4..19f6af288 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -24,8 +24,19 @@ Earlier, IDs generated using =ts= method had a hard-coded format (i.e. =20200923
The new option allows user to customise the format.
Defaults are unchanged.
+*** New argument for ~file-desc~ babel header
+
+It is now possible to provide the =file-desc= header argument for a
+babel source block but omit the description by passing an empty vector
+as an argument (i.e., :file-desc []). This can be useful because
+providing =file-desc= without an argument results in the result of
+=file= being used in the description. Previously, the only way to
+omit a file description was to omit the header argument entirely,
+which made it difficult/impossible to provide a default value for
+=file-desc=.
+
** New features
-*** =ob-python= improvements to =:return= header argument
+*** =ob-python= improvements to =:return= header argument
The =:return= header argument in =ob-python= now works for session
blocks as well as non-session blocks. Also, it now works with the
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 7300f239e..075e3f928 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -646,6 +646,14 @@ a list with the following pattern:
(replace-regexp-in-string
(org-src-coderef-regexp coderef) "" expand nil nil 1
+(defun org-babel--file-desc (params result)
+ "Retrieve file description."
+ (pcase (assq :file-desc params)
+(`nil nil)
+(`(:file-desc) result)
+(`(:file-desc . ,(and (pred stringp) val)) val)
+(`(:file-desc . []) nil)))
+
;;;###autoload
(defun org-babel-execute-src-block ( arg info params)
"Execute the current source code block.
@@ -749,8 +757,7 @@ block."
(let ((*this* (if (not file) result
(org-babel-result-to-file
file
- (let ((desc (assq :file-desc params)))
- (and desc (or (cdr desc) result)))
+ (org-babel--file-desc params result)
(setq result (org-babel-ref-resolve post))
(when file
(setq result-params (remove "file" result-params))
@@ -2257,9 +2264,8 @@ INFO may provide the values of these header arguments (in the
(setq result (org-no-properties result))
(when (member "file" result-params)
(setq result
Re: opening a 0.5 MB org file is slow
Hello Uwe, Can you test with emacs -Q ? A 1.6M org file took a little under 7 sec on my computer. It probably depends on the number of minor modes are being loaded, font-lock, auto-completion, etc. I'm afraid I don't know how to profile the opening of a file. Does anybody know a function that would do the profiling like elp-instrument-function for functions? -- HTH Jeremie Juste On Tuesday, 29 Sep 2020 at 21:11, Uwe Brauer wrote: > Hi > > maybe I am just to impatient but on my 8 GB Thinkpad X1 (4gen) to open a > 0.5MB org file takes around 15 sec. > > Any change to speed this up? > > Thanks and regards > > Uwe Brauer >
opening a 0.5 MB org file is slow
Hi maybe I am just to impatient but on my 8 GB Thinkpad X1 (4gen) to open a 0.5MB org file takes around 15 sec. Any change to speed this up? Thanks and regards Uwe Brauer
Re: ob-java compile only
ian martins writes:
> Thanks for explaining. That makes sense.
>
> I'm hesitant to add the compile-only header for a couple reasons. Generally
> C-c C-c on a source block means "run this" but with compile-only it'll mean
> "run this but don't run it." It's semantically inconsistent. Also I want to
> bring more feature parity to ob-java, so that there's more consistency
> across babel. I'm reluctant to add headers not found elsewhere.
Thank you for the feedback, I am all with you on that and I think
consistency is very important!
>
> Consider some alternatives:
> 1. one option is to add a dummy main to every class. it could do nothing or
> run unit tests. it's not a bad place to kick off unit tests, but I don't
> think you should have to.
> 2. you could use org-babel-tangle to write out the source files, and
> compile from an emacs compile buffer. this might be more convenient than
> compiling from babel since recompiles are a single keystroke.
> 3. a future version of ob-java will know if a class has a "public static
> void main." at that point it'll be easy to automatically skip execution of
> the class if it doesn't define a main, without the need for a new
> header.
The alternatives are nice and I will manage fine!
Looking forward to see what will happen to ob-java!
:)
>
> On Mon, Sep 28, 2020 at 4:11 AM John Herrlin wrote:
>
>>
>> Hey Ian,
>>
>> Thank you for the quick feedback!
>>
>> That workflow seems to work perfectly if it's Java all the way. Then it
>> compiles all the related files. I am mostly working with the classes
>> from Clojure.
>>
>> Here is an example:
>>
>>#+HEADER: :classname se/my_test_package/Hey
>>#+HEADER: :compile-only t
>>#+HEADER: :results none
>>#+HEADER: :dir src
>>#+BEGIN_SRC java
>> package se.my_test_package;
>>
>> public class Hey {
>> public static String hey(String name) {
>> return "Hey " + name;
>> }
>> }
>>#+END_SRC
>>
>>#+BEGIN_SRC clojure :results output code
>> (import [se.my_test_package Hey])
>>
>> (Hey/hey "John")
>>#+END_SRC
>>
>>
>> Best regards
>>
>>
>>
>> ian martins writes:
>>
>> > Hi John,
>> >
>> > Thanks for the suggestion and patch. Is the reason for this so that you
>> can
>> > have classes without needing dummy "main" methods?
>> >
>> > Did you consider using org-babel-tangle to generate the source files?
>> This
>> > works for me:
>> >
>> > Steps:
>> > 1. put javatangle.org (below) on your local.
>> > 2. create "pkg" directory where javatangle.org is
>> > 3. run org-babel-tangle on javatangle.org (this writes two source files
>> to
>> > the pkg dir)
>> > 4. run C-c C-c on the top source block (this compiles both source files
>> and
>> > runs main)
>> >
>> > - javatangle.org -
>> >
>> > #+begin_src java :results output :classname pkg/Main :tangle
>> pkg/Main.java
>> > package pkg;
>> >
>> > public class Main {
>> > public static void main(String[] args) {
>> > System.out.println(Hey.hey());
>> > }
>> > }
>> > #+end_src
>> >
>> > #+begin_src java :results output :classname pkg/Hey :tangle pkg/Hey.java
>> > package pkg;
>> >
>> > public class Hey {
>> > public static String hey() {
>> > return "hey";
>> > }
>> > }
>> > #+end_src
>> >
>> >
>> >
>> > On Sun, Sep 27, 2020 at 5:19 PM John Herrlin wrote:
>> >
>> >>
>> >> Hey Ian!
>> >>
>> >> Happy to see you as the maintainer of the ob-java!
>> >>
>> >> I would like to propose a feature to ob-java. The feature allows a
>> >> source code block to write and compile only, without executing.
>> >>
>> >> Here is a common use case for me.
>> >>
>> >> Class without a entry point have an :compile-only header.
>> >>
>> >>#+HEADER: :classname se/my_test_package/Hey
>> >>#+HEADER: :dir src
>> >>#+HEADER: :compile-only t
>> >>#+HEADER: :results none
>> >>#+BEGIN_SRC java
>> >> package se.my_test_package;
>> >>
>> >> public class Hey {
>> >> public static String hey(String name) {
>> >> return "Hey " + name;
>> >> }
>> >> }
>> >>#+END_SRC
>> >>
>> >> The provided diff works for my small use case. What do you think?
>> >>
>> >> --
>> >> Best regards
>> >> John
>> >>
>> >>
>>
>>
>> --
>> Mvh John
>>
--
Mvh John
Re: Bug: Math mode doesn't work if followed by a dash [9.4 (nil @ /home/gutin/.emacs.d/.local/straight/build/org-mode/)]
"Berry, Charles" writes: > The case Gutin describes conforms to the documentation, viz. `$x\beta$-` > should produce math mode LaTeX as I read the next paragraph. > > From (info "(org) LaTeX fragments"): > >• Text within the usual LaTeX math delimiters. To avoid conflicts > with currency specifications, single ‘$’ characters are only > recognized as math delimiters if the enclosed text contains at most > two line breaks, is directly attached to the ‘$’ characters with no > whitespace in between, and if the closing ‘$’ is followed by > whitespace, punctuation or a dash. Hmm, good point. It looks to me like the relevant function is org-element-latex-fragment-parser, and the code for that hasn't changed much in several years (last change was 2017). (Also, I was wrong, parsing latex fragments is not done with just a regexp.) I can confirm that this function parses "$foo" in "$foo$ bar" as a latex fragment, but not in "$foo$-bar" Not sure if the problem here is the code or the documentation. Perhaps the documentation should be updated to reflect the current behavior? -- Best, Richard
[PATCH] Persistently save downloaded inline remote images
Currently remote images are downloaded upon each display.
As most of the time the images do not change in between redisplays, we can
instead buffer the images locally and only update the local copy when the
remote image is updated.
Attached is a proposed patch.
Best,
>From aa34ad1176f4599c5a3c2678806644f16a3d22a2 Mon Sep 17 00:00:00 2001
From: fpi
Date: Tue, 23 Jun 2020 15:59:28 +0200
Subject: [PATCH] org.el: Persistently save downloaded inline remote images
* lisp/org.el (org--create-inline-image): Save downloaded inline
remote images to temporary directory to persist them for future
`org-display-inline-images' calls.
---
lisp/org.el | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 4d46b4173..7b649d6d0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16277,10 +16277,22 @@ according to the value of `org-display-remote-inline-images'."
(file-or-data
(pcase org-display-remote-inline-images
((guard (not remote?)) file)
- (`download (with-temp-buffer
- (set-buffer-multibyte nil)
- (insert-file-contents-literally file)
- (buffer-string)))
+ (`download (let ((new (concat temporary-file-directory
+ "tramp/"
+ (file-remote-p file 'host)
+ (file-local-name file
+ ;; dont download file if local copy exists & is newer than remote
+ (if (and (file-exists-p new)
+ (file-newer-than-file-p new file))
+ (with-temp-buffer
+ (set-buffer-multibyte nil)
+ (insert-file-contents-literally new)
+ (buffer-string))
+ (with-temp-file new
+ (make-directory (file-name-directory new) t)
+ (set-buffer-multibyte nil)
+ (insert-file-contents-literally file)
+ (buffer-string)
(`cache (let ((revert-without-query '(".")))
(with-current-buffer (find-file-noselect file)
(buffer-string
--
2.20.1
[PATCH] ob-gnuplot: handle remote input files
When passing a remote file like "/ssh:myserver:/myfile.txt" to a gnuplot block as variable the gnuplot process can not access the remote data. An example: --8<---cut here---start->8--- #+begin_src gnuplot :var data="/ssh:myserver:/myfile.txt" plot data u 1:2 #+end_src --8<---cut here---end--->8--- Attached is a patch, which instead downloads remote files to a unique path and passes this new path to gnuplot. Please let me know if there's something to improve regarding the commit message or patch formatting. Best, >From 4f9f98ed8f48754eeff09b8de51734bc8521bb6a Mon Sep 17 00:00:00 2001 From: fpi Date: Tue, 29 Sep 2020 18:43:07 +0200 Subject: [PATCH] ob-gnuplot: Download remote input files * lisp/ob-gnuplot.el (org-babel-gnuplot-process-vars): When variables point to remote files download them and use a local copy instead. --- lisp/ob-gnuplot.el | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/lisp/ob-gnuplot.el b/lisp/ob-gnuplot.el index 62ab04d94..820929c84 100644 --- a/lisp/ob-gnuplot.el +++ b/lisp/ob-gnuplot.el @@ -92,7 +92,21 @@ code." (tablep (or (listp first) (symbolp first (if tablep val (mapcar 'list val))) (org-babel-temp-file "gnuplot-") params) - val + (if (and (file-remote-p val) ;; check if val is a remote file + (file-exists-p val)) ;; call to file-exists-p is slow, maybe remove it + (let* ((local-name (concat ;; create a unique filename to avoid multiple downloads +org-babel-temporary-directory +"/gnuplot/" +(file-remote-p val 'host) +(file-local-name val + (if (and (file-exists-p local-name) ;; only download file if remote is newer + (file-newer-than-file-p local-name val)) + local-name + (make-directory (file-name-directory local-name) t) + (copy-file val local-name t) + )) + val + ) (org-babel--get-vars params (defun org-babel-expand-body:gnuplot (body params) -- 2.20.1
Re: Bug: Math mode doesn't work if followed by a dash [9.4 (nil @ /home/gutin/.emacs.d/.local/straight/build/org-mode/)]
See below. > On Sep 28, 2020, at 11:42 AM, Richard Lawrence wrote: > > Hi Gutin, > > gutin writes: > >> What I meant is that if you type >> >> $*$-algebra >> >> and hit C-c C-x C-l, then the "$*$" doesn't get replaced with a >> mathematical image. A similar problem happens when you export to Latex: >> The dollar signs get escaped. > > I believe this is intentional. There are too many other uses of dollar > signs that people might want to use in Org documents that might be > broken if Org treated them as math mode delimiters; so the regexp that > matches math mode delimiters is deliberately limited in scope. [rest deleted] The case Gutin describes conforms to the documentation, viz. `$x\beta$-` should produce math mode LaTeX as I read the next paragraph. From (info "(org) LaTeX fragments"): • Text within the usual LaTeX math delimiters. To avoid conflicts with currency specifications, single ‘$’ characters are only recognized as math delimiters if the enclosed text contains at most two line breaks, is directly attached to the ‘$’ characters with no whitespace in between, and if the closing ‘$’ is followed by whitespace, punctuation or a dash. But the $...$ and $$...$$ seem fragile. I recall advice to avoid them in favor of \(...\) and \[...\]. FWIW, my sanity has been aided by using yf/org-electric-dollar[1], which inserts `\(\)` when I type `$` and leaves point where you need it to enter math mode LaTex. A dash after the closing parenthesis is no problem. HTH, Chuck [1] https://orgmode.org/list/87vc913oh5@yahoo.fr/ ;; from Nicolas Richard ;; Date: Fri, 8 Mar 2013 16:23:02 +0100 ;; Message-ID: <87vc913oh5@yahoo.fr>
org-capture at point
I use org-plus-contrib 2020928 with Emacs 27.1. Since org-plus-contrib 20200920, I'm no longer able to get org-capture to insert a template at the point. Instead, it seems to place the entry at the appropriate heading level, above the current heading. Looking at the help page, perhaps it's this behavior: "With a ‘C-u C-u’ prefix argument, go to the last note stored." This happens with both a custom interactive function that calls (org-capture 0), and by using a zero prefix. I'm not able to get this functionality to work: "When called with a ‘C-0’ (zero) prefix, insert a template at point." I'm not sure this is a bug -- I've had to make a handful of changes to my config since the 9.4 release. Any insights either way? Thank you, David -- dwrz|朱为文
Re: Bug: org-priority face has extra space at the end starting from version 9.4 [9.4 (9.4-elpaplus @ /home/rrudakov/.emacs.d/elpa/org-plus-contrib-20200914/)]
"Protesilaos Stavrou" writes: > Roman Rudakov [2020-09-15, 18:50 +]: > >> I use theme which draw boxes around priority cookie. Before updating to >> version 9.4 box was rendered just around square brackets, but since >> version 9.4 it has additional space at the end. >> >> I think it's related to the fact that org-priority face definition used >> to use separate regex which didn't include space, and now it uses >> variable org-priority-regexp which does include additional space >> character. >> >> [...] > > This issue is noticeable with any face properties for 'org-priority' > such as box, background, underline, overline. > > Just to add a reproducible recipe for this case. > > On 'emacs -Q' running Org 9.4: > > + C-x C-f /tmp/test.org > + Insert a heading, like: > > * TODO [#A] This is a test > > …see attached screenshot with "default" state. > > * Now evaluate the following expression: > > (set-face-attribute 'org-priority nil :underline t) > > …see attached screenshot with "edited" state. > > -- > Protesilaos Stavrou > protesilaos.com Hello, I think proper value for `org-priority-regex` should be ".*?\\(\\[#\\([A-Z0-9]+\\)\\]\\) ?", extra space should be moved out of the brackets, It won't break anything and face definition will be correct. Best regards.
