Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Sébastien Miquel writes: > at least as long as you're tangling to a programming language, that > can read lisp strings. >> Consider the following example: >> >> #+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no :noweb-trans >> prin1-to-string >> <> >> (setq latex-header <>) >> #+END_SRC >> >> There are two noweb references here. Setting source block-wide >> :noweb-trans is not helpful because the first reference will be >> incorrectly filtered through prin1-to-string. > Indeed. Originally I had thought of adding a new syntax <<"nw">> to > insert a string representation. I've attached a new patch, that does > this instead of introducing :noweb-trans. Now that I think of the > universality of prin1-to-string, I actually like it slightly better > than :noweb-trans. It would break existing "nw"-like noweb references. This is too specific, as for me. Thinking about the whole idea of :noweb-trans more, I see little benefit compared to something like: #+name: documentation This is a sample function documentation. Because there are "quotes", it must be escaped and cannot be directly used as noweb-reference. #+name: doc-escape #+begin_src emacs-lisp :var str="" :tangle no (prin1-to-string (string-trim-right str)) #+end_src #+begin_src emacs-lisp :tangle yes (defun test () <> t) #+end_src Maybe we can instead distribute a library ob babel file containing useful functions together with Org. >>> [...] >> This sounds a bit confusing. I would also add an example where it is >> useful to set :noweb-prefix to no. > > I've added such an example in the revised patch attached. Other than :noweb-trans, the patch looks good for me. Best, Ihor
Re: asterisk allowed for list items
c.bu...@posteo.jp writes: > Am 29.04.2022 15:49 schrieb Ihor Radchenko: >> Exactly because you are actively trying to understand the syntax, you >> are in unique situation where you can easily see all the "opaque" >> places >> in the syntax description. > > I still don't know if I misunderstand the syntax description document or > if there is really and "error" in it. Ideally, our document should be reasonably easy to understand for native or non-native English speakers. So, please keep posting if you find some parts difficult. >> That's why I ask you to propose modifications >> to the document that would make it easier to read for you. > > First of all I have to understand everything and then write that down > for my self (especially as Python code and unittests). > > My english is awful and it wouldn't help you. I even do not understand > all words and sentences (from a language perspective) of the syntax > description document. I am not into it enough to propose a patch. I can > only offer you "my understanding" of the document and "testing" a new > version of it. Well. The document has been written by native speaker of (AFAIK) Australian English. I myself (non-native speaker) had hard time understanding some parts given my experience with American English. If you observe some particularly tricky sentences, feel free to complain here :) The goal of that document is to make things easier, not harder for the reader. Best, Ihor
Re: [BUG] Scheme code block evaluation doesn't show any result [9.5.\ 2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
Pascal Grossé writes: > I managed to track the bug to *ob-scheme.el*: > > in (defun org-babel-scheme-execute-with-geiser, on line 179, simply > replace geiser-eval-region with geiser-eval-region/wait so that the > temporary result buffer doesn't close too soon. It then works as > expected. Duplicate of https://orgmode.org/list/874k2k0vtw@terra.tmtvl.info Best, Ihor
Re: [PATCH] Show drawers in text entries in Org Agenda
Rodrigo Morales writes: >> For this reason, I am wondering whether there is a way to make >> =org-agenda-entry-text-mode= to show the drawers without much >> tinkering. >> > > After inspecting the source code of Org Mode, I managed to do what I was > searching by deleting the relevant part of the function > =org-agenda-get-some-entry-text=. This function unconditionally removes > drawers from subtrees in order for the remaining content be shown in > text entries. > > I've created the following patch which adds a defcustom that would allow > the user to decide whether drawers must be hidden or shown in text > entries. Hope this helps. Thanks! The patch looks useful. > +(defcustom org-agenda-entry-text-hide-drawers t > + "Non-nil means hide drawers in entry text in agenda buffers." > + :group 'org-agenda > + :type 'boolean) > + (when org-agenda-entry-text-hide-drawers > + (while (re-search-forward drawer-re nil t) > + (delete-region > + (match-beginning 0) > + (progn (re-search-forward > + "^[ \t]*:END:.*\n?" nil 'move) > + (point) >(unless (member 'planning keep) I'd prefer if you reuse the KEEP argument to org-agenda-get-some-entry-text. It is already designed for such things. Best, Ihor
[BUG] <2022-04-11 Mon 17:1-19:10> is wrongly parsed as a valid timestamp [9.5.3 (release_9.5.3-461-ga3dac4 @ /home/yantar92/.emacs.d/straight/build/org/)]
Hi, Consider the following timestamp with a typo in starting minute: <2022-04-11 Mon 17:1-19:10> Running org-element-context yields a timestamp object with unexpected properties: (timestamp (:type active :raw-value "<2022-04-11 Mon 17:1-19:10>" :year-start 2022 :month-start 4 :day-start 11 :hour-start nil :minute-start nil :year-end 2022 :month-end 4 :day-end 11 :hour-end nil :minute-end nil :begin 1916 :end 1943 :post-blank 0)) Note that hour/minute values are nil. Expected: The example timestamp is not parsed as a valid timestamp, but rather considered a paragraph. Best, Ihor Emacs : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2022-04-24 Package: Org mode version 9.5.3 (release_9.5.3-461-ga3dac4 @ /home/yantar92/.emacs.d/straight/build/org/)
Re: org-depend: bug fix
Damien Couroussé writes: > Please find attached a small patch for org-depend, which fixes a bug > (function 'remove-if' is unknown). > - (setq items (remove-if > + (setq items (org-remove-if org-remove-if is itself obsolete :) I applied a slightly different change remove-if -> cl-remove-if. Best, Ihor
Re: [PATCH] Remove XEmacs and ancient Emacs compat code
Stefan Kangas writes: > The attached patch removes some compat code for XEmacs, and Emacs 21/22. Thanks! And sorry for the late reply. The patch does not apply onto current main anymore. Would you mind updating the patch? Best, Ihor
bug#45915: 28.0.90; deletechar distorts org-table
Tak Kunihiro writes: > Thank you for the patch. I applied the patch to org-table.el on Emacs > 28.0.90. > > And I still see the problem there. Is the problem solved by the patch > on your environment? The problem was solved on my side, but _not_ using your reproducer explicitly. If I save the buffer from your reproducer as a file and later open in, the patch does solve the problem. However, when I run the reproducer as is, a similar-looking problem emerges. Using your reproducer, something very strange is going on. With the patch, is correctly mapped to org-delete-char, which calls (delete-char 1) at some point. However, this (delete-char 1) somehow deletes 2!! chars instead of 1. This should be some tricky Emacs issue (bug?). In any case, I am not ready to dig into what is going on in Emacs. I do not think that such problem is going to appear during normal Emacs usage. At least, I was unable to reproduce it by other means than your reproducer function. To illustrate the issue, one can use the following version of the reproducer. Feel free to report this to Emacs upstream. (defun emacs-bug-reproduce-45915 () "Reproduce bug#45915." ;; (gnus-read-ephemeral-emacs-bug-group 45915) (interactive) (with-current-buffer (get-buffer-create "*temp buffer*") (erase-buffer) (require 'org) (orgtbl-mode 1) (insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version)) (insert "| | rownames | | / | | |---+--| | | a|")) (switch-to-buffer-other-window "*temp buffer*") (execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f")) (message "I will hit S-.") (sit-for 2) (execute-kbd-macro (kbd "S-")) (message "I will hit .") (sit-for 2) ;; (execute-kbd-macro (kbd "")) (delete-char 1) (message "I will call previous-line.") (sit-for 2) (call-interactively 'previous-line)) Best, Ihor
bug#45915: 28.0.90; deletechar distorts org-table
Tak Kunihiro writes: > Thank you for the patch. I applied the patch to org-table.el on Emacs > 28.0.90. > > And I still see the problem there. Is the problem solved by the patch > on your environment? The problem was solved on my side, but _not_ using your reproducer explicitly. If I save the buffer from your reproducer as a file and later open in, the patch does solve the problem. However, when I run the reproducer as is, a similar-looking problem emerges. Using your reproducer, something very strange is going on. With the patch, is correctly mapped to org-delete-char, which calls (delete-char 1) at some point. However, this (delete-char 1) somehow deletes 2!! chars instead of 1. This should be some tricky Emacs issue (bug?). In any case, I am not ready to dig into what is going on in Emacs. I do not think that such problem is going to appear during normal Emacs usage. At least, I was unable to reproduce it by other means than your reproducer function. To illustrate the issue, one can use the following version of the reproducer. Feel free to report this to Emacs upstream. (defun emacs-bug-reproduce-45915 () "Reproduce bug#45915." ;; (gnus-read-ephemeral-emacs-bug-group 45915) (interactive) (with-current-buffer (get-buffer-create "*temp buffer*") (erase-buffer) (require 'org) (orgtbl-mode 1) (insert (format "emacs-version: %s, org-version: %s\n" emacs-version org-version)) (insert "| | rownames | | / | | |---+--| | | a|")) (switch-to-buffer-other-window "*temp buffer*") (execute-kbd-macro (kbd "M-< C-n C-n C-n C-n C-f C-f")) (message "I will hit S-.") (sit-for 2) (execute-kbd-macro (kbd "S-")) (message "I will hit .") (sit-for 2) ;; (execute-kbd-macro (kbd "")) (delete-char 1) (message "I will call previous-line.") (sit-for 2) (call-interactively 'previous-line)) Best, Ihor
Re: [PATCH] "Cache corruption detected" when editing CLOCK timestamp by hand
Ihor Radchenko writes: > Should we consider the above CLOCK line as a valid running clock or > maybe it should be parsed as a paragraph? Nicolas, do you have any comment on this? I am inclined to treat CLOCK: [2021-10-22 Fri 10:41]--[2021] as a paragraph, not a clock line. Best, Ihor
Re: [PATCH] org-attach-attach: fix symlinks
Matt Price writes: > I'm having trouble with org-attach-attach if my current buffer is visiting > a filepath starting with "~/". This trivial patch fixes the problem for me > by running (expand-file-name) on the file before attaching. I always use > the 'lns method, so I don't know whether it might be better to > expand-file-name before running any of the methods. > > Alternatively, it might actually be better to use a *relative* file path > where possible (e.g. to ensure that project directories are fully > portable), but I'm not sure how best to do that. I do not like explicit expansion of the FILE path. It may break relative vs. absolute path handling. Attaching an alternative patch. It makes use of make-symbolic-link arguments. Best, Ihor >From ff9ccae51ce1b02fc5d95cbc60de7a44c42f28a1 Mon Sep 17 00:00:00 2001 Message-Id: From: Ihor Radchenko Date: Sat, 30 Apr 2022 11:27:30 +0800 Subject: [PATCH] org-attach-attach: Avoid linking to path starting with ~ * lisp/org-attach.el (org-attach-attach): Auto-expand ~ in the file patch when using symlink (`lns') attach method. Fixes https://orgmode.org/list/can_dec_lytkgsn_kiftee9gulm7fper5frqfant3n_2c3cw...@mail.gmail.com --- lisp/org-attach.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-attach.el b/lisp/org-attach.el index 5ee2b84b2..760592507 100644 --- a/lisp/org-attach.el +++ b/lisp/org-attach.el @@ -524,7 +524,8 @@ (defun org-attach-attach (file &optional visit-dir method) ((eq method 'mv) (rename-file file attach-file)) ((eq method 'cp) (copy-file file attach-file)) ((eq method 'ln) (add-name-to-file file attach-file)) - ((eq method 'lns) (make-symbolic-link file attach-file)) + ;; We pass integer third argument to auto-expand "~" in FILE. + ((eq method 'lns) (make-symbolic-link file attach-file 1)) ((eq method 'url) (url-copy-file file attach-file))) (run-hook-with-args 'org-attach-after-change-hook attach-dir) (org-attach-tag) -- 2.35.1
Re: Org as a workspace (an impromptu reflection)
On Fri, 29 Apr 2022 11:03:55 -0400 Juan Manuel Macías wrote > I don't know if anyone has had a similar experience... I tell people that Emacs changed my life. I feel it's that profound. My story is different from yours, yet similar in that it started with Org. I love that it has this affect on people. It brings a smile to my face. This really is a great community. Thanks for sharing your experience. :)
[BUG] Scheme code block evaluation doesn't show any result [9.5.\ 2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
I configured a fresh emacs 28 installation to include the package
geiser-guile.
I tried to evaluate this simple org block (after activating scheme with
babel of course):
#+begin_src scheme :session test
(define x 42)
x
#+end_src
I get:
#+RESULTS:
The *Geiser Messages* buffer shows this:
ERROR: <5>: continuation failed ",geiser-eval #f (begin ;; -*- geiser-sch\
eme-implementation: guile -*-
(define x 42)
x
) ()"
(error Selecting deleted buffer)
I managed to track the bug to *ob-scheme.el*:
in (defun org-babel-scheme-execute-with-geiser, on line 179, simply
replace geiser-eval-region with geiser-eval-region/wait so that the
temporary result buffer doesn't close too soon. It then works as
expected.
Pascal Grossé
From cdc2c10f48585fb6328486d9821526f2bd994400 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pascal=20Gross=C3=A9?=
Date: Fri, 29 Apr 2022 10:33:05 +0200
Subject: [PATCH] Bug fix for scheme code block evaluation showing no result
---
lisp/ob-scheme.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/ob-scheme.el b/lisp/ob-scheme.el
index 72d2e029e..80a5b76ee 100644
--- a/lisp/ob-scheme.el
+++ b/lisp/ob-scheme.el
@@ -176,7 +176,7 @@ is true; otherwise returns the last value."
(setq geiser-impl--implementation nil)
(let ((geiser-debug-jump-to-debug-p nil)
(geiser-debug-show-debug-p nil))
- (let ((ret (geiser-eval-region (point-min) (point-max
+ (let ((ret (geiser-eval-region/wait (point-min) (point-max
(setq result (if output
(or (geiser-eval--retort-output ret)
"Geiser Interpreter produced no output")
--
2.36.0
Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc.
On 4/29/22 07:22, Max Nikulin wrote: It was still working in most real-life cases. Yes, the current code breaks only in fine-grained cases. Most of the time it'll work fine since people rarely compile the same file twice in the same second. From my point of view, it is better to rewrite `org-compile-time' to treat the case when there were no file prior to the call as that the file has been updated without comparison of timestamps Yes, that sounds simpler and better. How about the attached patch?From fbd6561952acf359236afcf7957a197376a18c66 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 29 Apr 2022 11:06:00 -0700 Subject: [PATCH] Improve org-compile-file timestamp handling MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org/org-macs.el (org-file-newer-than-p): Don’t lose timestamp information in an attempt to work around problems on filesystems with coarse-grained timestamps. (org-compile-file): Use only filesystem timestamps; don’t try to compare them to the current time, as the filesystem clock may be different from our clock. --- lisp/org/org-macs.el | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/lisp/org/org-macs.el b/lisp/org/org-macs.el index bb0562dde0..907043580a 100644 --- a/lisp/org/org-macs.el +++ b/lisp/org/org-macs.el @@ -260,14 +260,8 @@ org-file-newer-than-p "Non-nil if FILE is newer than TIME. FILE is a filename, as a string, TIME is a Lisp time value, as returned by, e.g., `current-time'." - (and (file-exists-p file) - ;; Only compare times up to whole seconds as some file-systems - ;; (e.g. HFS+) do not retain any finer granularity. As - ;; a consequence, make sure we return non-nil when the two - ;; times are equal. - (not (time-less-p (org-time-convert-to-integer - (nth 5 (file-attributes file))) - (org-time-convert-to-integer time) + (when-let ((mtime (file-attribute-modification-time (file-attributes file +(time-less-p time mtime))) (defun org-compile-file (source process ext &optional err-msg log-buf spec) "Compile a SOURCE file using PROCESS. @@ -301,7 +295,7 @@ org-compile-file (full-name (file-truename source)) (out-dir (or (file-name-directory source) "./")) (output (expand-file-name (concat base-name "." ext) out-dir)) - (time (current-time)) + (time (file-attribute-modification-time (file-attributes output))) (err-msg (if (stringp err-msg) (concat ". " err-msg) ""))) (save-window-excursion (pcase process @@ -320,7 +314,7 @@ org-compile-file (_ (error "No valid command to process %S%s" source err-msg ;; Check for process failure. Output file is expected to be ;; located in the same directory as SOURCE. -(unless (org-file-newer-than-p output time) +(unless (or (not time) (org-file-newer-than-p output time)) (error (format "File %S wasn't produced%s" output err-msg))) output)) -- 2.34.1
RE: [BUG] org-mode #+SETUPFILE not working with properties [9.5.2 (release_9.5.2-378-g98588e @ /home/eros/src/org-mode/lisp/)]
I agree. There is no reason to think this should not work. I have been down
this road myself in wished it did.
From: Emacs-orgmode On Behalf
Of Ihor Radchenko
Sent: Thursday, April 28, 2022 9:41 AM
To: Eros Zaupa
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] org-mode #+SETUPFILE not working with properties [9.5.2
(release_9.5.2-378-g98588e @ /home/eros/src/org-mode/lisp/)]
CAUTION: This email is from an External Source. Please use proper judgment and
caution when opening attachments, clicking links, or responding to this email.
Eros Zaupa mailto:erosza...@gmail.com>> writes:
> I would like to move the properties drawer to a separate file and import it
> into the main one. To do so I'm using the `#SETUPFILE` property suggested
> [here][1], but this doesn't seem to work.
Confirmed.
Though I am not 100% sure.
Org is indeed ignoring top-level property drawer when parsing
#+SETUPFILE.
Dear All,
I think that parsing top-level property drawer is simply an omission
from the time we introduced top-level property drawers into syntax.
We may either implement this support or leave things as is and document
the current behaviour.
I would be in favour of implementing top-level drawer support in
SETUPFILE, but there might be alternative opinions. WDYT?
Dear Eros Zaupa,
> ***main.org***
>
> #+SETUPFILE: test.org
>
> #+begin_src sh
> echo ${A}
> #+end_src
>
> #+RESULTS:
>
> ***test.org***
>
> :PROPERTIES:
> :header-args:sh: :var A="this is a"
> :END:
To work around your issue, you can use keyword property syntax:
***test.org***
#+PROPERTY: header-args:sh :var A="this is a"
Best,
Ihor
Org as a workspace (an impromptu reflection)
Hi all, Since I use Org Mode I have been noticing a gradual change in the way I work with a computer (as a simple user). It is not something consciously sought, but I have to say that I see it as a positive evolution. I've always been used to (or rather resigned to) the typical Unix directory/file scheme: everything must be a file and everything must be stored in a directory. When one has many and varied interests and tasks, and manages a wide variety of files and folders, it is certainly hard to maintain order and 'digital hygiene' within that scheme. Before using Gnu Emacs as a shell and as a desktop environment, I used KDE and Gnome for quite a while. The indexers and file search tools in these environments (especially the GnomeShell one, tracker) were somewhat helpful in keeping things tidy and close at hand. But, at the end of the day, the directory/file scheme was always present. With Org something curious has happened. I've gotten used to working around nodes (regardless of what documents those nodes are in), rather than around folders or files. Little by little, a kind of virtual world of ideas, objects, etc., all intertwined with each other, is being built. What amazes me about Org is that all of this is tremendously transparent and simple. I'm not saying that the detachment of the directory/file schema is complete: directories and files are there, actually, but at least they don't show up when working. It is somewhat akin to being in a play, where there is a suspension of disbelief. Of course, there are tools that I find indispensable. Helm-org-ql, for example, is what I use to nimbly navigate that virtual world of nodes. I also make heavy and obsessive use of org-attach and org-capture (I barely use the classic 'Documents', 'Images', 'Videos', 'Music', etc. style directories, but everything is stored in folders associated with nodes). And since I've started using org-transclusion, a new dimension has been opened to that virtuality that I mentioned before. Sometimes I wonder if this isn't a working style similar to that of the old Lisp machines, a subject I find exciting but know little about, so I apologize if that statement sounds too ignorant ;-). I don't know if anyone has had a similar experience... Best regards, Juan Manuel
Re: [PATCH] Add :noweb-prefix and :noweb-trans babel header arguments
Hi,
Ihor Radchenko writes:
prin1-to-string is too specific and only solves a single use-case.
prin1-to-string is actually universal in a way, since any other
manipulation can then be achieved with
: (setq var (do-something <>))
at least as long as you're tangling to a programming language, that
can read lisp strings.
Consider the following example:
#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no :noweb-trans
prin1-to-string
<>
(setq latex-header <>)
#+END_SRC
There are two noweb references here. Setting source block-wide
:noweb-trans is not helpful because the first reference will be
incorrectly filtered through prin1-to-string.
Indeed. Originally I had thought of adding a new syntax <<"nw">> to
insert a string representation. I've attached a new patch, that does
this instead of introducing :noweb-trans. Now that I think of the
universality of prin1-to-string, I actually like it slightly better
than :noweb-trans. It would break existing "nw"-like noweb references.
Of course, one can work around this easily enough by using two blocks.
I'd rather introduce a new syntax to transform the noweb reference
inline. Something like
#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes :noweb-prefix no
<>
(setq latex-header <<(prin1-to-string nw)>>)
#+END_SRC
You'd need to only allow a single function call with only one
argument, or use something like <<(prin1-to-string <>)>>. The
change would be much more complex than what I propose, for maybe
little benefit.
[...]
This sounds a bit confusing. I would also add an example where it is
useful to set :noweb-prefix to no.
I've added such an example in the revised patch attached.
Thanks for the feedback.
Regards,
--
Sébastien Miquel
From 99d043b9d837a2658e60fb4b4913454d9566519b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?=
Date: Mon, 6 Sep 2021 18:45:42 +0200
Subject: [PATCH] ob-core.el: Add `:noweb-prefix`, `:noweb-trans` babel header
arguments
* lisp/ob-core.el (org-babel-expand-noweb-references): Add support for
`noweb-prefix' header argument, to not repeat the prefix characters
when expanding a noweb reference. Add support for `noweb-trans' header
argument, to apply a function to the noweb content upon
expansion.
(org-babel-common-header-args-w-values):
(org-babel-safe-header-args): Add `noweb-prefix' and `noweb-trans' values.
* doc/org-manual.org: Document `noweb-prefix' and `noweb-trans' babel header
arguments.
* etc/ORG-NEWS: Document `:noweb-prefix' and `:noweb-trans'.
---
doc/org-manual.org | 42 ++
etc/ORG-NEWS | 10 +-
lisp/ob-core.el| 26 --
3 files changed, 71 insertions(+), 7 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 6768ca98d..5ef8e2f8b 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18760,6 +18760,48 @@ else:
print('do things when false')
#+end_example
+This prefix behavior can be turned off in a block by setting the
+=noweb-prefix= header argument to =no=, as in:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb-prefix no
+ (setq example-data "<>")
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+which expands to:
+
+#+begin_example
+(setq example-data "this is the
+multi-line body of example")
+#+end_example
+
+The header argument =noweb-trans= can be set to =prin1-to-string= to
+insert a lisp string representing the content of the referenced src
+block. With:
+
+#+begin_example
+,#+NAME: latex-header
+,#+BEGIN_SRC latex
+ \usepackage{amsmath}
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+this code block:
+
+#+begin_example
+,#+BEGIN_SRC elisp :noweb yes :noweb-trans prin1-to-string
+ (setq header <>)
+,#+END_SRC
+#+end_example
+
+#+texinfo: @noindent
+expands to:
+
+: (setq header "\\usepackage{amsmath}")
+
When in doubt about the outcome of a source code block expansion, you
can preview the results with the following command:
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 2b539d305..70f7606db 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -150,7 +150,7 @@ The entry points are ~org-persist-register~, ~org-persist-unregister~,
~org-persist-read~, and ~org-persist-read-all~. Storing circular
structures is supported. Storing references between different
variables is also supported (see =:inherit= key in
-~org-persist-register~).
+~org-persist-register~).
The library permits storing buffer-local variables. Such variables
are linked to the buffer text, file =inode=, and file path.
@@ -175,6 +175,14 @@ the =compact-itemx= export option, or globally using the
Items in a description list that begin with =Function:=, =Variable:=
or certain related prefixes are converted using Texinfo definition
commands.
+*** New =:noweb-prefix= and =:noweb-trans= babel header arguments
+
+=:noweb-prefix= can be set to =no= to prevent the prefix characters
+from being repeated when expanding a multiline noweb reference.
+
+=:noweb-trans= can be set to =prin1-to-strin
Re: asterisk allowed for list items
Dear Ihor, thanks for your reply. Am 29.04.2022 15:49 schrieb Ihor Radchenko: Exactly because you are actively trying to understand the syntax, you are in unique situation where you can easily see all the "opaque" places in the syntax description. I still don't know if I misunderstand the syntax description document or if there is really and "error" in it. That's why I ask you to propose modifications to the document that would make it easier to read for you. First of all I have to understand everything and then write that down for my self (especially as Python code and unittests). My english is awful and it wouldn't help you. I even do not understand all words and sentences (from a language perspective) of the syntax description document. I am not into it enough to propose a patch. I can only offer you "my understanding" of the document and "testing" a new version of it.
Re: master 4a1f69ebca 2/2: Use (TICKS . HZ) for current-time etc.
On 29/04/2022 05:27, Paul Eggert wrote: On 4/27/22 09:55, Stefan Monnier wrote: Instead of rounding the times to whole seconds, wouldn't it make more sense to check that the difference is larger than 1s? org-file-newer-than-p is intended to work on filesystems like HFS+ that store just the seconds part of the last-modified time. I have found just 2 calls of `org-file-newer-than-p' in the Org code and in both cases the intention is to check whether particular file has been updated. I have not checked Org extensions for usage of this function. I would rather assume that the code was written without any considerations concerning filesystem timestamps precision and its difference from `current-time' representation. It was still working in most real-life cases. From my point of view, it is better to rewrite `org-compile-time' to treat the case when there were no file prior to the call as that the file has been updated without comparison of timestamps, so `current-time' can be dropped to eliminate comparison of timestamp from different sources. With such modification it is better to compare file timestamps without truncation to whole seconds, however I have not tried to create an example where fractional seconds may change behavior.
Re: Ordered list items and the point
c.bu...@posteo.jp writes:
> This is about https://orgmode.org/worg/dev/org-syntax.html#Plain_Lists
>
> Comparing the syntax description and the real world behaviour of my
> Emacs 27 with org from yesterday it seems to me that the syntax
> description is not correct.
>
> I cite "Plain Lists" section:
> "If first item in a plain list has a COUNTER in its BULLET, the plain
> list will be an “ordered plain-list”."
> This is not true in many ways because in the section "Items" a COUNTER
> is described as
> "Either a number or a single letter (a-z)."
To be on the same page, I will also quote what is BULLET:
>> One of the two forms below, followed by either a whitespace character
>> or line ending.
>> - An asterisk, hyphen, or plus sign character (i.e., *, -, or +).
>> - Either the pattern COUNTER. or COUNTER).
>> + COUNTER :: Either a number or a single letter (a-z).
> An ordered list item need to have a point after its digit. Correct is
> "1. item"; incorrect is "1 item". As an alternative to the "." an ")" is
> allowed also.
>
> A letter is not a COUNTER no matter if there is an "." or ")" after it.
> An org-buffer and org-html-export-as-html does not recognize this as a
> list item.
> Do I miss something? Are there any other characters that need to
> considered?
The latter ("1 item") is not an item because it does not have BULLET
even though it contains COUNTER.
Again, if you can think about better way to explain ordered plain lists,
feel free to propose a patch. The fact that you were confused already
shows that the current description is not ideal.
I am also CCing Timothy as he may be interested.
Best,
Ihor
Re: asterisk allowed for list items
c.bu...@posteo.jp writes: > Am 29.04.2022 15:04 schrieb Detlef Steuer: >> But *first* it should be easily read- and writable by humans and only >> then easily parseble by parsers! At least imho. > > I agree and understand that this is one of the design principals of Org. > > But even for humans the current situation is IMHO not "easy". When I > want to have asterix bullet for my list items I always have to think > about the trailing whitespace to prevent Org from interpreting this as a > heading. If you want to avoid this confusion, just don't use asterisks in lists. Yet, Org still provides this option if you suddenly need to use asterisks in some weird scenario :) Generally, fontification is a guide. Best, Ihor
Re: asterisk allowed for list items
c.bu...@posteo.jp writes: > Sidenote: As someone who writes software that parse org-content I would > suggest to make the whitespace in front of a list item mandatory even > for "-" and "+". It would reduce code complexity. It might probably simplify things for third-party parsers. Not for org-element. The "^* " vs "^ * " is distinguished without much efforts on Org side because of hierarchical matching (headlines have higher priority over lists). Moreover Org is trying to be as back-compatible as possible, so minor simplification is not sufficient to advocate changing Org syntax. Best, Ihor
Re: asterisk allowed for list items
c.bu...@posteo.jp writes: > Am 29.04.2022 14:15 schrieb Ihor Radchenko: >> Would you be interested to contribute an example to >> https://orgmode.org/worg/dev/org-syntax.html#Items ? > > Not sure what you mean. Currently I just try to understand the syntax > and get the hard rules for my own parser. ;) Exactly because you are actively trying to understand the syntax, you are in unique situation where you can easily see all the "opaque" places in the syntax description. That's why I ask you to propose modifications to the document that would make it easier to read for you. Ideally, the modifications should be the form of a patch :) > btw: There is a "problem" with the mailinglist. Follow-Up and Reply-To > is ignored. I always get copy to my own adress instead of the > mailinglist. I do not need copies. This is noise. I do not think that it is a problem of the mailing list software. Rather we are used to Reply-All to make sure that people who are not subscribed are kept in the look. Getting a copy to your own address is a side effect. Best, Ihor
Re: asterisk allowed for list items
Dear Detlef Am 29.04.2022 15:04 schrieb Detlef Steuer: But *first* it should be easily read- and writable by humans and only then easily parseble by parsers! At least imho. I agree and understand that this is one of the design principals of Org. But even for humans the current situation is IMHO not "easy". When I want to have asterix bullet for my list items I always have to think about the trailing whitespace to prevent Org from interpreting this as a heading.
Re: asterisk allowed for list items
Am Fri, 29 Apr 2022 12:17:24 + schrieb c.bu...@posteo.jp: > Sidenote: As someone who writes software that parse org-content I > would suggest to make the whitespace in front of a list item > mandatory even for "-" and "+". It would reduce code complexity. But *first* it should be easily read- and writable by humans and only then easily parseble by parsers! At least imho. Detlef
Re: asterisk allowed for list items
Am 29.04.2022 14:15 schrieb Ihor Radchenko: Would you be interested to contribute an example to https://orgmode.org/worg/dev/org-syntax.html#Items ? Not sure what you mean. Currently I just try to understand the syntax and get the hard rules for my own parser. ;) - List item with whitespace before and after bullet + List item with whitespace before and after bullet * List item with whitespace before and after bullet - List item with whitespace only after bullet + List item with whitespace only after bullet * A heading because there is no whitespace before the bullet btw: There is a "problem" with the mailinglist. Follow-Up and Reply-To is ignored. I always get copy to my own adress instead of the mailinglist. I do not need copies. This is noise.
Re: asterisk allowed for list items
I need to add something here and think the syntax description should be updated about that. A "*" is allowed or recognized as a list item instead as a head only if there is one (or maybe more) whitespace space in front of it. But "-" and "+" also recognized as starts for list items without any trailing whitespace in front of them. Sidenote: As someone who writes software that parse org-content I would suggest to make the whitespace in front of a list item mandatory even for "-" and "+". It would reduce code complexity. Am 29.04.2022 13:53 schrieb c.bu...@posteo.jp: I was looking into https://orgmode.org/worg/dev/org-syntax.html#Items to find out which characters are allowed as "bullets" for unorderd lists. I cite from there "An asterisk, hyphen, or plus sign character (i.e., *, -, or +)." I wonder why * is allowed because * also starts a heading. So how does a piece of software/parser decide if a line starting with an * is a heading or a list item?
Re: asterisk allowed for list items
c.bu...@posteo.jp writes: > I cite from there > "An asterisk, hyphen, or plus sign character (i.e., *, -, or +)." > > I wonder why * is allowed because * also starts a heading. So how does a > piece of software/parser decide if a line starting with an * is a > heading or a list item? Headlines always start at beginning of line and have stars followed by space: * this is a heading ** this is also a heading **but this is not (no space after stars) * this is a list item (star not at bol) Would you be interested to contribute an example to https://orgmode.org/worg/dev/org-syntax.html#Items ? Best, Ihor
Ordered list items and the point
This is about https://orgmode.org/worg/dev/org-syntax.html#Plain_Lists Comparing the syntax description and the real world behaviour of my Emacs 27 with org from yesterday it seems to me that the syntax description is not correct. I cite "Plain Lists" section: "If first item in a plain list has a COUNTER in its BULLET, the plain list will be an “ordered plain-list”." This is not true in many ways because in the section "Items" a COUNTER is described as "Either a number or a single letter (a-z)." An ordered list item need to have a point after its digit. Correct is "1. item"; incorrect is "1 item". As an alternative to the "." an ")" is allowed also. A letter is not a COUNTER no matter if there is an "." or ")" after it. An org-buffer and org-html-export-as-html does not recognize this as a list item. Do I miss something? Are there any other characters that need to considered?
asterisk allowed for list items
I was looking into https://orgmode.org/worg/dev/org-syntax.html#Items to find out which characters are allowed as "bullets" for unorderd lists. I cite from there "An asterisk, hyphen, or plus sign character (i.e., *, -, or +)." I wonder why * is allowed because * also starts a heading. So how does a piece of software/parser decide if a line starting with an * is a heading or a list item?
Re: [BUG] org-fold-core-style 'text-properties interprets Org link syntax in code blocks too
Kaushal Modi writes: > It's not time-critical, but it would be good to fix this bug. It's not > just the Org link syntax.. any Org markup is fontified inside the src > blocks. Here's a screenshot (attached) that shows the bold > fortification happen in the src block as well. Emphasis should not be affected by the latest change. Are you sure that what you are seeing appeared _after_ org-fold merge? For me, it looks like known problem with partial fontification of large source blocks. It should disappear if you scroll up to the block begin line. >> This and other fontification issues will be solved by new parser-based >> fontification engine I am working on now. > > If it is planned to be fixed before the next major release of Org, > it's OK. Thanks for working on this! I hope so. Feel free to bump this thread few months later if there is no progress on fontification. Best, Ihor
Re: Link display not working for orgroam links as items in enumeration
>> Link display not working for orgroam links as items in enumeration Could you elaborate what about what you did, what you expected, and what you actually observed? It is very hard for us to guess what "not working" means. Please refer to https://orgmode.org/manual/Feedback.html for more instructions on bug reporting. Best, Ihor
Re: ob-lisp determining package
Alan Ruttenberg writes: > I propose that the package determination be changed to > > (or (cdr (assq :package params)) (funcall org-babel-lisp-package-fn)) > > with org-babel-lisp-package-fn being bound analogous to how > org-babel-lisp-eval-function is: > > (require (pcase org-babel-lisp-package-fn > (`slime-current-package 'slime) > (`sly-current-pacakge 'sly))) > > This (approximately) seems to work fine in my emacs. However, I am using an > older version of emacs/org-mode and so am not submitted a patch, which > would be against slightly different code. Did you have a chance to test your changes against the latest Org? If everything works fine, could you prepare a patch? best, Ihor
