Re: noweb expansion when eval and not tangle?
George Mauer writes: > I would like noweb to expand during eval but *not* tangle. Is this possible? > > I realize I can achieve the same effect with multiple code blocks but it > seems an odd asymmetry to not be able to do this directly. > > Is it possible and just not documented? It is indeed, and it's documented in https://orgmode.org/manual/Noweb-Reference-Syntax.html. ‘eval’ Expansion of noweb syntax references in the body of the code block only before evaluating. -- Timothy.
Re: [feature request] The :pre header argument
I've provided more relevant information on this feature request [[
https://codeberg.org/rdrg109/gists/src/branch/main/feature-request-pre-header-argument.org][here]].
Please consider reading that instead of the first message on this thread.
On Fri, 19 Feb 2021 at 08:33, Rodrigo Morales
wrote:
> You can read this message with proper formatting here (
> https://codeberg.org/rdrg109/gists/src/branch/main/the-pre-header-argument.org
> ).
>
> On Thu, 18 Feb 2021 at 16:52, Rodrigo Morales <
> moralesrodrigo1...@gmail.com> wrote:
>
>>
>> This message contains my thoughts on a feature request which I think
>> would be useful: The =:pre= header argument, it would be used to
>> execute a code block before the code block at point is executed. It
>> would be similar to the behavior of the =:post= header argument.
>>
>> Here's a simple example that shows how =:pre= could be used
>>
>> #+NAME: clean-path-experiments
>> #+begin_src dash
>> if [ ! -z "$my__experiments" ] && [ -d "$my__experiments" ]; then
>> find ~/e -mindepth 1 -maxdepth 1 -exec rm -rf {} +
>> fi
>> #+end_src
>>
>> #+NAME: tree-command
>> #+begin_src dash
>> tree -a --noreport
>> #+end_src
>>
>> #+NAME: create-dir-for-minimal-reproducible-example
>> #+HEADER: :pre clean-path-experiments()
>> #+HEADER: :post tree-command()
>> #+begin_src python
>> import os
>>
>> [os.makedirs(_) for _ in ["a/foo", "a/bar", "b"]]
>> [os.mknod(_) for _ in ["a/1.txt", "a/2.txt", "a/foo/b.txt",
>> "a/bar/b.txt", "b/b.txt"]]
>> #+end_src
>>
>> #+RESULTS: create-dir-for-minimal-reproducible-example
>> #+begin_example
>> .
>> ├── a
>> │ ├── 1.txt
>> │ ├── 2.txt
>> │ ├── bar
>> │ │ └── b.txt
>> │ └── foo
>> │ └── b.txt
>> └── b
>> └── b.txt
>> #+end_example
>>
>> I think that such header argument would be useful because of two
>> main reasons:
>>
>> * It would improve readability of code blocks by explicitly expressing
>> dependency
>>
>> By having a header argument for the sole purpose of expressing
>> dependencies between code blocks, the readability of header arguments
>> would be improved. Recall that it is currently possible to express
>> such dependency by calling a code block through a =:var <>=
>> header argument but I think that =:var= header argument must only be
>> used for defining variables (be it from results obtained from
>> different code blocks or literals).
>>
>> The first code block shown below show the differences between using
>> =:var= and =:pre= for the same scenario. =first-code-block= uses the
>> =:var= header argument while the =second-code-block= uses the =:pre=
>> header argument.
>>
>> #+NAME: first-code-block
>> #+begin_src org
>> For our experimentation, let's start with an empty directory and let's
>> execute the first step.
>>
>> ,#+NAME: first-step
>> ,#+HEADER: :results silent
>> ,#+HEADER: :var e=clean-path-experiments
>> ,#+begin_src dash
>> touch first-step.txt
>> ,#+end_src
>>
>> We know execute the second step.
>>
>> ,#+NAME: second-step
>> ,#+HEADER: :results silent
>> ,#+HEADER: :var e=first-step
>> ,#+begin_src dash
>> touch second-step.txt
>> ,#+end_src
>>
>> Finally, we execute the third step.
>>
>> ,#+NAME: third-step
>> ,#+HEADER: :results silent
>> ,#+HEADER: :var e=second-step
>> ,#+begin_src dash
>> touch third-step.txt
>> ,#+end_src
>> #+end_src
>>
>> #+NAME: second-code-block
>> #+begin_src org
>> For our experimentation, let's start with an empty directory and let's
>> execute the first step.
>>
>> ,#+NAME: first-step
>> ,#+HEADER: :results silent
>> ,#+HEADER: :pre clean-path-experiments()
>> ,#+begin_src dash
>> touch first-step.txt
>> ,#+end_src
>>
>> We know execute the second step.
>>
>> ,#+NAME: second-step
>> ,#+HEADER: :results silent
>> ,#+HEADER: :pre first-step()
>> ,#+begin_src dash
>> touch second-step.txt
>> ,#+end_src
>>
>> Finally, we execute the third step.
>>
>> ,#+NAME: third-step
>> ,#+HEADER: :results silent
>> ,#+HEADER: :pre second-step()
>> ,#+begin_src dash
>> touch third-step.txt
>> ,#+end_src
>> #+end_src
>>
>> In my opinion, the second code block looks more readable than the
>> first one.
>>
>> * it would add importance to the =:post= header argument
>>
>> The =:post= header argument can be used in Org Mode 9.3 to execute a
>> given code block after the code block at point is executed; having a
>> header argument that does the opposite of the =:post= header argument
>> would give relevance to the =:post= header argument.
>>
>> --
>> Greetings,
>> Rodrigo Morales.
>>
>> IRC: rdrg109 (freenode)
>>
>
Bug: exporting a subtree to icalendar omits body of subtree [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hi,
With a simple test file /tmp/o.ics:
** test
<2021-03-18 Thu 15:00-16:00>
body of text
If I first do C-c C-e c f I get a correct .ics file:
Version 1
BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:o
PRODID:-//Stephen Eglen//Emacs with Org mode//EN
X-WR-TIMEZONE:GMT
X-WR-CALDESC:
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20210220T002714Z
UID:TS1-9618d322-4761-4706-9432-dce5c80e2113
DTSTART:20210318T15Z
DTEND:20210318T16Z
SUMMARY:test
DESCRIPTION:<2021-03-18 Thu 15:00>–<2021-03-18 Thu 16:00> body of text
CATEGORIES:o
END:VEVENT
END:VCALENDAR
If however when I export, I leave the point on line 1, and then do C-c
C-e C-s c f I get the following calendar, with no events.
Version 2
BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:o
PRODID:-//Stephen Eglen//Emacs with Org mode//EN
X-WR-TIMEZONE:GMT
X-WR-CALDESC:test
CALSCALE:GREGORIAN
END:VCALENDAR
Am I missing something? I tried exporting to HTML which seems to work
when using C-s to turn on the subtree export.
Many thanks, Stephen
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
cairo version 1.17.3)
of 2020-08-28
Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-export-use-babel nil
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-agenda-files "~/txt/org/agenda-list.txt"
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-tag-alist '(("@damtp" . 100) ("julia" . 106) ("@magd" . 109) ("@home" .
104)
("laptop" . 108))
org-mode-hook '(#[0 "\301\211\207"
[imenu-create-index-function org-imenu-get-tree] 2]
org-mode-auto-revert-for-googlecal
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append
local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-babel-load-languages '((R . t) (shell . t) (dot . t) (ditaa . t)
(emacs-lisp . t) (latex . t))
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-agenda-insert-diary-extract-time t
org-icalendar-date-time-format ":%Y%m%dT%H%M%SZ"
org-occur-hook '(org-first-headline-recenter)
outline-minor-mode-hook '((lambda nil
(define-key outline-minor-mode-map [(control tab)]
'org-cycle)
(define-key outline-minor-mode-map [(shift tab)]
'org-global-cycle)
)
)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO" "WAIT" "DONE"))
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-babel-tangle-lang-exts '(("latex" . "tex") ("emacs-lisp" . "el")
("elisp" . "el"))
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link :export
org-attach-export-link :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow eww :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
filling quoted email in org does not infer a fill prefix
i'd like to fill things like this > asdfka sdfnl akjs dnflkajs ndfkjasdn kfj ansdkj nfaksjdfn > sadj nflakjs ndfklaj ndsfkjans dkfjna skdjfn aklsjd nfkajdnsf in org. i always had no problem with it, and when i did, i could use filladapt, with a little alist change from long ago. but recently, at least in maint with my .emacs on emacs 25, it all gets bunched up into a single paragraph with "> " not a prefix. i know emacs has developed filladapt-like features to infer a fill prefix, but my cognition is just not figuring any of this out. any ideas? thank you. -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
noweb expansion when eval and not tangle?
I would like noweb to expand during eval but *not* tangle. Is this possible? I realize I can achieve the same effect with multiple code blocks but it seems an odd asymmetry to not be able to do this directly. Is it possible and just not documented?
Re: bug#44824: [PATCH] org.el: Avoid xdg-open silent failure
On 19/02/2021 21:54, Eli Zaretskii wrote: From: Maxim Nikulin Date: Fri, 19 Feb 2021 19:29:49 +0700 On Windows Emacs always uses pipes, because we don't have PTYs there. And there's no xdg-open on MS-Windows anyway, so it's a moot point. Should I consider your response as a suggestion to remove the `if' related to `system-type'? Yes, that 'if' isn't necessary. Let's wait for comments comments from org developers. I do not mind to remove the `if' but they could ask for other changes. If I remember correctly, on windows it is possible to communicate with a process through stdin and stdout only if the application is compiled as a *console* one. That's true. But in this case we don't really want to communicate with the sub-process, do we? We just want to invoke it and let it run. So the fact that there's no way of communicating with the sub-process is not important here, as the pipes will not be used. We just need to specify pipes because that works around the problem with xdg-open. The reason to switch to pipe process here is to avoid side effects of *terminal session*. PTY is redundant here. Pipe process is the only alternative available in emacs. Currently there is no data exchange with subprocess. Reading of stderr and stdout from the handler and its descendants could be useful to realize a cause of a problem when it happens. At least on linux it is enough to specify some buffer instead of `nil' or add a :filter function. The reason why I did not make such change is that Gtk applications tends to report significant number of failed asserts. I do not like to pollute the "*Messages*" buffer. I am in doubts if a dedicated buffer should be created for such purpose. Reading of stdout could be useful in mailcap handlers e.g. to display text from PDF file when only text terminal is available (no X11 or wayland). Currently emacs ignores "needsterminal" and "copiousoutput" flags in mailcap. Example of an entry for PDF: application/pdf; pdftotext -layout %s -; test=test -z "$DISPLAY"; copiousoutput Likely only a small part of users could benefit from such feature. "start file.pdf" executed in cmd.exe launches an application that does not block command prompt. In this sense it similar to background processes launched by kde-open5 or "gio open". However I am unaware if there is something similar to process groups on windows that leads to termination of all group members when leader process finishes. Things are fairly similar on Windows. But is this really relevant to the issue at hand? There's no xdg-open on Windows, so whatever problems you had with xdg-open will never happen on Windows. the proposed patch fixes the problem only on systems where org.el invokes the PDF viewer via xdg-open. Right? 1. It is not a problem of namely xdg-open. It is (mostly reasonable but with some caveats however) specific of DE-specific handlers as "gio open" and kde-open5. They exit just after spawning of a process with actual handler. (Just like "start file.pdf" on windows.) I am afraid that I could break something on windows, so I would prefer that somebody will test the changes on non-linux systems. 2. It is not specific to PDF files, the problem could happen with any format if wrapper handler such as "gio open" is invoked instead of e.g. direct execution of eog.
Re: wrong-type-argument stringp nil
Dear Eric, > Eric S Fraga writes: > On Friday, 19 Feb 2021 at 14:11, Colin Baxter wrote: >> I getting the Lisp error: (wrong-type-argument stringp nil) when >> I 'C-c C-c' the babel gnuplot source code "poynting", even though >> the pdf graph is produced correctly. Any help at debugging would >> be much appreciated. > Works fine for me. No error. I initially I thought maybe you > needed a horizontal line dividing the headings from the numbers > but works fine without. > What version of org are you using? > You could "M-x toggle-debug-on-error RET" to see where the error > happens? Found the error! In my ~/.emacs, I have a defun #+begin_src elisp (defun cb/display-inline-images () (condition-cl-case nil (org-display-inline-images) (error nil))) #+end_src Changing the 'condition-cl-case' to 'condition-case' removed the error. Interestingly, debug on error using emacs-27.1 configured for the lucid pointed explicitly to the defun, whereas emacs-27.1 configured for gtk3 didn't! Any idea why that should be? Best wishes, Colin.
Re: wrong-type-argument stringp nil
On Friday, 19 Feb 2021 at 14:11, Colin Baxter wrote: > I getting the Lisp error: (wrong-type-argument stringp nil) when I 'C-c > C-c' the babel gnuplot source code "poynting", even though the pdf graph > is produced correctly. Any help at debugging would be much appreciated. Works fine for me. No error. I initially I thought maybe you needed a horizontal line dividing the headings from the numbers but works fine without. What version of org are you using? You could "M-x toggle-debug-on-error RET" to see where the error happens? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-231-gf46925
bug#44824: [PATCH] org.el: Avoid xdg-open silent failure
> From: Maxim Nikulin > Date: Fri, 19 Feb 2021 19:29:49 +0700 > Cc: 44...@debbugs.gnu.org > > > On Windows Emacs always uses pipes, because we don't have PTYs there. > > And there's no xdg-open on MS-Windows anyway, so it's a moot point. > > Should I consider your response as a suggestion to remove the `if' > related to `system-type'? Yes, that 'if' isn't necessary. > If I remember correctly, on windows it is possible to communicate with a > process through stdin and stdout only if the application is compiled as > a *console* one. That's true. But in this case we don't really want to communicate with the sub-process, do we? We just want to invoke it and let it run. So the fact that there's no way of communicating with the sub-process is not important here, as the pipes will not be used. We just need to specify pipes because that works around the problem with xdg-open. > "start file.pdf" executed in cmd.exe launches an application that does > not block command prompt. In this sense it similar to background > processes launched by kde-open5 or "gio open". However I am unaware if > there is something similar to process groups on windows that leads to > termination of all group members when leader process finishes. Things are fairly similar on Windows. But is this really relevant to the issue at hand? There's no xdg-open on Windows, so whatever problems you had with xdg-open will never happen on Windows. the proposed patch fixes the problem only on systems where org.el invokes the PDF viewer via xdg-open. Right?
wrong-type-argument stringp nil
Hello, I getting the Lisp error: (wrong-type-argument stringp nil) when I 'C-c C-c' the babel gnuplot source code "poynting", even though the pdf graph is produced correctly. Any help at debugging would be much appreciated. #+name: poynting | i | R |P/M | | 0 | 0.0400 | 0.4000 | | 20 | 0.0402 | 0.4240 | | 40 | 0.0458 | 0.4925 | | 50 | 0.0572 | 0.5310 | | 60 | 0.0893 | 0.5720 | | 65 | 0.1205 | 0.5771 | | 70 | 0.1710 | 0.5683 | | 75 | 0.2531 | 0.5329 | | 80 | 0.3878 | 0.4521 | | 89 | 0.9044 | 0.0738 | | 90 | 1. | 0. | #+begin_src gnuplot :var data=poynting :file poynting.pdf :results file set title 'Plot of Data from Table 1' show title set key at 30,0.8 unset key set xlabel 'Angle' set ylabel '' set style datapoints set style line 1 lc rgb '#0060ad' # --- blue set style line 2 lc rgb '#dd181f' # --- red set label 'P/M' at 10,0.3700 set label 'R' at 35,0.0855 plot data using 1:2 with points ls 1, \ data using 1:2 smooth csplines with lines, \ data using 1:3 with points ls 2, \ data using 1:3 smooth csplines with lines #+end_src Best wishes, Colin Baxter.
Re: [feature request] The :pre header argument
You can read this message with proper formatting here (
https://codeberg.org/rdrg109/gists/src/branch/main/the-pre-header-argument.org
).
On Thu, 18 Feb 2021 at 16:52, Rodrigo Morales
wrote:
>
> This message contains my thoughts on a feature request which I think
> would be useful: The =:pre= header argument, it would be used to
> execute a code block before the code block at point is executed. It
> would be similar to the behavior of the =:post= header argument.
>
> Here's a simple example that shows how =:pre= could be used
>
> #+NAME: clean-path-experiments
> #+begin_src dash
> if [ ! -z "$my__experiments" ] && [ -d "$my__experiments" ]; then
> find ~/e -mindepth 1 -maxdepth 1 -exec rm -rf {} +
> fi
> #+end_src
>
> #+NAME: tree-command
> #+begin_src dash
> tree -a --noreport
> #+end_src
>
> #+NAME: create-dir-for-minimal-reproducible-example
> #+HEADER: :pre clean-path-experiments()
> #+HEADER: :post tree-command()
> #+begin_src python
> import os
>
> [os.makedirs(_) for _ in ["a/foo", "a/bar", "b"]]
> [os.mknod(_) for _ in ["a/1.txt", "a/2.txt", "a/foo/b.txt", "a/bar/b.txt",
> "b/b.txt"]]
> #+end_src
>
> #+RESULTS: create-dir-for-minimal-reproducible-example
> #+begin_example
> .
> ├── a
> │ ├── 1.txt
> │ ├── 2.txt
> │ ├── bar
> │ │ └── b.txt
> │ └── foo
> │ └── b.txt
> └── b
> └── b.txt
> #+end_example
>
> I think that such header argument would be useful because of two
> main reasons:
>
> * It would improve readability of code blocks by explicitly expressing
> dependency
>
> By having a header argument for the sole purpose of expressing
> dependencies between code blocks, the readability of header arguments
> would be improved. Recall that it is currently possible to express
> such dependency by calling a code block through a =:var <>=
> header argument but I think that =:var= header argument must only be
> used for defining variables (be it from results obtained from
> different code blocks or literals).
>
> The first code block shown below show the differences between using
> =:var= and =:pre= for the same scenario. =first-code-block= uses the
> =:var= header argument while the =second-code-block= uses the =:pre=
> header argument.
>
> #+NAME: first-code-block
> #+begin_src org
> For our experimentation, let's start with an empty directory and let's
> execute the first step.
>
> ,#+NAME: first-step
> ,#+HEADER: :results silent
> ,#+HEADER: :var e=clean-path-experiments
> ,#+begin_src dash
> touch first-step.txt
> ,#+end_src
>
> We know execute the second step.
>
> ,#+NAME: second-step
> ,#+HEADER: :results silent
> ,#+HEADER: :var e=first-step
> ,#+begin_src dash
> touch second-step.txt
> ,#+end_src
>
> Finally, we execute the third step.
>
> ,#+NAME: third-step
> ,#+HEADER: :results silent
> ,#+HEADER: :var e=second-step
> ,#+begin_src dash
> touch third-step.txt
> ,#+end_src
> #+end_src
>
> #+NAME: second-code-block
> #+begin_src org
> For our experimentation, let's start with an empty directory and let's
> execute the first step.
>
> ,#+NAME: first-step
> ,#+HEADER: :results silent
> ,#+HEADER: :pre clean-path-experiments()
> ,#+begin_src dash
> touch first-step.txt
> ,#+end_src
>
> We know execute the second step.
>
> ,#+NAME: second-step
> ,#+HEADER: :results silent
> ,#+HEADER: :pre first-step()
> ,#+begin_src dash
> touch second-step.txt
> ,#+end_src
>
> Finally, we execute the third step.
>
> ,#+NAME: third-step
> ,#+HEADER: :results silent
> ,#+HEADER: :pre second-step()
> ,#+begin_src dash
> touch third-step.txt
> ,#+end_src
> #+end_src
>
> In my opinion, the second code block looks more readable than the
> first one.
>
> * it would add importance to the =:post= header argument
>
> The =:post= header argument can be used in Org Mode 9.3 to execute a
> given code block after the code block at point is executed; having a
> header argument that does the opposite of the =:post= header argument
> would give relevance to the =:post= header argument.
>
> --
> Greetings,
> Rodrigo Morales.
>
> IRC: rdrg109 (freenode)
>
Re: bug#44824: [PATCH] org.el: Avoid xdg-open silent failure
On 18/02/2021 21:48, Eli Zaretskii wrote: From: Maxim Nikulin Date: Thu, 18 Feb 2021 19:56:03 +0700 I could not estimate effect of such change on windows, so pipe process is used only on linux. I am unsure concerning mac however. On Windows Emacs always uses pipes, because we don't have PTYs there. And there's no xdg-open on MS-Windows anyway, so it's a moot point. Should I consider your response as a suggestion to remove the `if' related to `system-type'? If I remember correctly, on windows it is possible to communicate with a process through stdin and stdout only if the application is compiled as a *console* one. That is why it is unclear for me, which component handles console or GUI distinction when process is specified as pipe in lisp code, and whether all arguments of `make-process', that I have used, are suitable on windows. "start file.pdf" executed in cmd.exe launches an application that does not block command prompt. In this sense it similar to background processes launched by kde-open5 or "gio open". However I am unaware if there is something similar to process groups on windows that leads to termination of all group members when leader process finishes.
