Re: Bug: org-link-descriptive needs to be buffer-local [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Ingo Lohmar writes: > On Mon, Apr 05 2021 22:36 (-0400), Kyle Meyer wrote: >> Hmm, I think a problem with `:local t' (or, equivalently, >> make-variable-buffer-local for backward compatibility reasons) is that >> then you'd interfere with user customization that directly sets this >> after ol.el is loaded. You could also still get into a mismatched state >> like you described above if you load an Org buffer, set the value >> through the customization interface, and then call >> org-toggle-link-display in that buffer. [...] > I am not sure that I understand the problem you're describing.. Maybe > it's because I don't use the customize interface myself, but I think any > such customization would only set the default value, wouldn't it? Yes. Here are expanded descriptions for the two problems I'm referring to above. This is based on testing with the `:local t' diff below (on top of bcfe6f985, before the commit I mentioned in my last message). * Breaks customization of direct setq callers if ol.el is already loaded. If (setq org-link-descriptive nil) is executed after ol.el is loaded, links in a visited Org buffer will be displayed according to the default org-link-descriptive value of t. * Setting org-link-descriptive via the customization interface can get into a mismatched state. - Visit an Org file with a link and description. org-link-descriptive is at its global value of t. - Set org-link-descriptive to nil via the customization interface, changing the global value to nil. This value is in effect in the Org buffer because org-link-descriptive isn't yet buffer-local. The description is still hidden because buffer-invisibility-spec hasn't been changed. - Calling org-toggle-link-display sets org-link-descriptive to t, making org-link-descriptive a buffer-local variable. The appearance of the description doesn't change due to the mismatch (like described in your original report). Calling it again aligns the buffer-local value and buffer-invisibility-spec. diff --git a/lisp/ol.el b/lisp/ol.el index d1db1683b..0e225ce4e 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -193,6 +193,7 @@ (defcustom org-link-descriptive t `org-toggle-link-display' or from the \"Org > Hyperlinks\" menu." :group 'org-link :type 'boolean + :local t :safe #'booleanp) (defcustom org-link-make-description-function nil
Re: Bug: Display Inline Images from Subdirectory [9.4.4 (9.4.4-33-g5450d6-elpaplus @ /home/ded/.emacs.d/elpa/org-plus-contrib-20210322/)]
"Daniel E. Doherty" writes:
> I have a hook function (cribbed from Emacs Stack Exchange) to re-display
> inline images in the current subtree after execution of a source block
> if the header argument contains, ':results graphics'. As its last
> action, it calls:
>
> (org-display-inline-images nil nil beg end)
>
> where beg and end have been set to the bounds of the current subtree.
>
> This works perfectly if the image file is in the current directory. For
> example, here is a block that displays as expected:
>
> #+begin_SRC dot :file lehman.svg :cmdline -Kdot -Tsvg :results graphics
> digraph lehman {
> Thomas [shape=circle];
> TideWater [shape = box, label="Tide Water\nSecurities\n(Issuer)"];
> Lehman [shape = box];
> Thomas -> TideWater [label="Director"];
> Lehman -> TideWater [label="Shareholder"];
> Thomas -> Lehman [label="Partner"];
> }
> #+end_SRC
>
>
> However, if I add a :dir header, it ceases to work:
>
> #+begin_SRC dot :dir dot :file lehman.svg :cmdline -Kdot -Tsvg :results
> graphics
> digraph lehman {
> Thomas [shape=circle];
> TideWater [shape = box, label="Tide Water\nSecurities\n(Issuer)"];
> Lehman [shape = box];
> Thomas -> TideWater [label="Director"];
> Lehman -> TideWater [label="Shareholder"];
> Thomas -> Lehman [label="Partner"];
> }
> #+end_SRC
>
>
> #+RESULTS:
> [[file:dot/lehman.svg]]
>
> I have run edebug on the function, and the only difference I can detect
> is the location of the image file in a subdirectory called 'dot'.
>
> Here is my hook function, just for the record:
>
> #+begin_SRC emacs-lisp
> (setq org-startup-with-inline-images t)
> (require 'subr-x)
> (defun ded:org-babel-display-subtree ()
> "Redisplay inline images in subtree if cursor in source block with
> :result graphics."
>
> (when (org-in-src-block-p)
> (let (beg end)
> (save-excursion
> (org-mark-subtree)
> (setq beg (point))
> (setq end (mark)))
> (when-let ((info (org-babel-get-src-block-info t))
>(params (org-babel-process-params (nth 2 info)))
>(result-params (cdr (assq :result-params params)))
>((member "graphics" result-params)))
> (org-display-inline-images nil nil beg end)
>
> (add-hook 'org-babel-after-execute-hook
> #'ded:org-babel-display-subtree)
> #+end_SRC
>
FWIW, this works fine for me: Org mode version 9.4.4 (release_9.4.4-231-gf46925
@ /home/nick/elisp/org-mode/lisp/)
The only things I had to do was 1) to make the above into a tree by
adding a headline (otherwise, I guess org-mark-subtree would complain:
Not in a subtree) and 2) create the dot subdirectory.
--
Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: "#+STARTUP: hideblocks" has no effect?
autofrettage writes: > I recently read about the #+STARTUP parameter "hideblocks", but it > doesn't seem to have any effect in my set-up. All the blocks kept > laughing straight in my face. :-( > > Any ideas about what could have gone wrong? > > I use Org Mode 9.4.5 with Emacs 26.3, and I also tried closing the > file and Emacs before I tried. > > > p.s. Setting org-hide-block-startup with local variables is a > solution, but not as nice as doing it with #+STARTUP, I'd say. It interacts with org-startup-folded (whose default was changed recently to 'showeverything'): you need to set the latter to something other than 'showeverything' in order for hideblocks to be effective. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Bug: Display Inline Images from Subdirectory [9.4.4 (9.4.4-33-g5450d6-elpaplus @ /home/ded/.emacs.d/elpa/org-plus-contrib-20210322/)]
I have a hook function (cribbed from Emacs Stack Exchange) to re-display
inline images in the current subtree after execution of a source block
if the header argument contains, ':results graphics'. As its last
action, it calls:
(org-display-inline-images nil nil beg end)
where beg and end have been set to the bounds of the current subtree.
This works perfectly if the image file is in the current directory. For
example, here is a block that displays as expected:
#+begin_SRC dot :file lehman.svg :cmdline -Kdot -Tsvg :results graphics
digraph lehman {
Thomas [shape=circle];
TideWater [shape = box, label="Tide Water\nSecurities\n(Issuer)"];
Lehman [shape = box];
Thomas -> TideWater [label="Director"];
Lehman -> TideWater [label="Shareholder"];
Thomas -> Lehman [label="Partner"];
}
#+end_SRC
However, if I add a :dir header, it ceases to work:
#+begin_SRC dot :dir dot :file lehman.svg :cmdline -Kdot -Tsvg :results
graphics
digraph lehman {
Thomas [shape=circle];
TideWater [shape = box, label="Tide Water\nSecurities\n(Issuer)"];
Lehman [shape = box];
Thomas -> TideWater [label="Director"];
Lehman -> TideWater [label="Shareholder"];
Thomas -> Lehman [label="Partner"];
}
#+end_SRC
#+RESULTS:
[[file:dot/lehman.svg]]
I have run edebug on the function, and the only difference I can detect
is the location of the image file in a subdirectory called 'dot'.
Here is my hook function, just for the record:
#+begin_SRC emacs-lisp
(setq org-startup-with-inline-images t)
(require 'subr-x)
(defun ded:org-babel-display-subtree ()
"Redisplay inline images in subtree if cursor in source block with
:result graphics."
(when (org-in-src-block-p)
(let (beg end)
(save-excursion
(org-mark-subtree)
(setq beg (point))
(setq end (mark)))
(when-let ((info (org-babel-get-src-block-info t))
(params (org-babel-process-params (nth 2 info)))
(result-params (cdr (assq :result-params params)))
((member "graphics" result-params)))
(org-display-inline-images nil nil beg end)
(add-hook 'org-babel-after-execute-hook
#'ded:org-babel-display-subtree)
#+end_SRC
Emacs : GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2021-02-09
Package: Org mode version 9.4.4 (9.4.4-33-g5450d6-elpaplus @
/home/ded/.emacs.d/elpa/org-plus-contrib-20210322/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-shiftdown-final-hook '(windmove-down)
org-directory "/home/ded/work/Projects/"
org-noter-notes-window-location 'other-frame
org-caldav-backup-file
"/home/ded/.emacs.d/ded/data/org-caldav-backup.org"
org-crypt-key "C0A9F2F0"
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-log-done 'time
org-log-into-drawer t
org-startup-folded 'overview
org-babel-after-execute-hook '(ded:org-babel-display-subtree)
org-link-abbrev-alist '(("bugzilla"
. "http://10.1.2.9/bugzilla/show_bug.cgi?id=;)
("google" . "http://www.google.com/search?q=;)
("gmap" . "http://maps.google.com/maps?q=%s;)
("omap" .
"http://nominatim.openstreetmap.org/search?q=%s=1;)
("ads" .
"http://adsabs.harvard.edu/cgi-bin/nph-abs_connect?author=%s_key=AST;)
)
org-agenda-files "/home/ded/work/Projects/agenda-files"
org-capture-templates '(("t" "Todo Item" entry (file+headline
"Office.org" "Tasks")
"* TODO %? \n %a")
("a" "Appointment" entry (file+headline
"Office.org" "Appointments")
"* %? \n %a")
("p" "Phone Call Log" entry (file+headline
"Office.org" "Phone calls")
"* %U Phone call with %^{Name|%:name} \n\n
%?")
("l" "Link" entry (file+headline "Links.org"
"Links")
"* %a %^g\n %?\n %T\n %i")
("i" "Invoice" entry (file+headline
"Office.org" "Invoices")
"* %^T %^G\n %?")
("j" "Journal Entry" entry (file+olp+datetree
"Journal.org")
"* Entered on %U\n %i%?\n%a")
)
org-format-latex-options '(:foreground default :background default
:scale 1.6 :html-foreground
"Black" :html-background "Transparent"
:html-scale 1.0 :matchers
("begin" "$1" "$" "$$" "\\(" "\\["))
org-babel-noweb-wrap-end "»"
org-refile-targets '((nil :maxlevel . 3) (org-agenda-files
Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
Thanks, Juan Manuel, if LuaTeX just solved the "symbols problem" it would be a great feature. But.., why nothing in TeX seems to be easy?! ;D lualatex: security risk: running with elevated privileges This is LuaHBTeX, Version 1.12.0 (MiKTeX 20.11) system commands enabled. lualatex: file not writable for security reasons: .log ! I can't write on file `.log'. Please type another transcript file name ! Emergency stop ! ==> Fatal error occurred, no output PDF file produced! Probably a Windowz problem, don't care. Just moaning ;D But I take your advise and save it. Best regards *From*: Juan Manuel Macías *Subject*: Choosing a LaTeX Compiler (my predilection for LuaTeX) *Date*: Mon, 05 Apr 2021 22:48:48 +0200 *User-agent*: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
captioned named table in org-babel R is dangling link in latex export
I have a goal: make a table in R using org-babel and have it appear in
the latex export. I also want to be able to refer to the table by name in
the org file and have that become a hypertext link in the latex export.
Using Org mode version 9.4.4 I build this document:
<>
#+NAME: t1
#+begin_src R :exports both
library(tidyverse)
x <- tribble(~a, ~b, 1, 3)
x
#+end_src
#+CAPTION: Org Table
#+RESULTS: t1
| 1 | 3 |
I want to refer to Table [[t1]].
<>
What I expect: the latex export will include the table and link to it.
What happens instead: the code and table appear, numbered and captioned.
However, the link is broken ("I want to refer to Table ??"). Looking in
the latex, this line reads
> I want to refer to Table \ref{org993764c}.
but that label org993764c appears nowhere else in the file.
Org-lint doesn't complain about the file at all. I searched the archives
and the intertubes, I don't see any discussion of this.
Any help would be greatly appreciated.
- JP
--
James E. Powell, MS
Pronouns: he/him/his
Applied Physics PhD Candidate
Department of Physics
Portland State University
Home page: http://web.pdx.edu/~powellj
Office: SRTC 409B Phone: +1-503-725-8515
Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
Hi Tomas, to...@tuxteam.de writes: > AFAIK Lua(La)Tex can output dvi (and Juan Manuel's answer implies > thati, too). Either via the option --output-format=dvi or invoking > it as "dviluatex". > > But perhaps I missed something. Yes, the first option I have commented in my previous mail (setq luamagick etc ...) converts from pdf to png via 'convert' (imagemagick); in the second option (setq luasvg etc ...) compiles with the option `-output-format dvi' and then the converter is dvisvgm. Best regards, Juan Manuel https://juanmanuelmacias.com/
org-refile using the ID of the target
I take a lot of notes using MobileOrg in my phone, and after syncing, they
go into in.org (my gtd "in basket"). From there, I do the capturing process.
Thing is, sometimes there's a *lot* of notes that I just want to refile to
the "Notes" subtree from the corresponding project/context. A quick way to
do that would be nice.
My idea was to use the org-speed-commands-user to have a single key to
press for each category of note. I'd add entries like
("Q" (my/org-refile-to-id "TODO")
("W" (my/org-refile-to-id "DONE")
("E" (my/org-refile-to-id "")
At first, I tried using org-refile, but couldn't find a way to tell it to
refile to a specific subtree (eg, using its id).
Then I started hackstumbling around. So far, what I could come up with was:
(defun my/org-refile-to-id (id todo)
"Refile current subtree to subtree with ID."
(interactive
(list (read-string "ID: ")))
(when todo (org-todo todo))
(org-cut-subtree)
(let ((anchor (ignore-errors (org-id-get-create
(org-id-goto id)
(org-insert-heading-respect-content)
(org-demote-subtree)
(org-yank)
(exchange-point-and-mark)
(zap-to-char 1 (string-to-char " "))
(move-beginning-of-line nil)
(if anchor
(org-id-goto anchor)
(message "This was the last one."
It feels kinda messy, though.
Any advice would be more than welcome!
Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
On Tue, Apr 06, 2021 at 09:03:27PM +0200, physiculus wrote: > Hello, > i use LuaTex / LuaLatex successfully after some configs and readings. > The result (quality and speed) for me is better then with the old latex > engine. > I'm satisfied. > BUT one thing isn't working and as far as i read here, there is no > solution yet :-( > The latex-preview inside org-mode is not possible, because it seems, > that org-mode needs the dvi subprocess for running the neccessary tools. > With LuaLatex there is no dvi file, because it produces a pdf right > away. > Any solution will be wellcome. AFAIK Lua(La)Tex can output dvi (and Juan Manuel's answer implies thati, too). Either via the option --output-format=dvi or invoking it as "dviluatex". But perhaps I missed something. Cheers - t signature.asc Description: Digital signature
Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
Hi physiculus,
physiculus writes:
> Hello,
> i use LuaTex / LuaLatex successfully after some configs and readings.
> The result (quality and speed) for me is better then with the old latex
> engine.
> I'm satisfied.
> BUT one thing isn't working and as far as i read here, there is no
> solution yet :-(
> The latex-preview inside org-mode is not possible, because it seems,
> that org-mode needs the dvi subprocess for running the neccessary tools.
> With LuaLatex there is no dvi file, because it produces a pdf right
> away.
> Any solution will be wellcome.
I have this in my ~/.emacs:
#+begin_src emacs-lisp
(setq luamagick
'(luamagick
:programs ("lualatex" "convert")
:description "pdf > png"
:message "you need to install lualatex and imagemagick."
:use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("lualatex -interaction nonstopmode -output-directory
%o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100
%O")))
(add-to-list 'org-preview-latex-process-alist luamagick)
(setq luasvg
'(luasvg
:programs ("lualatex" "dvisvgm")
:description "dvi > svg"
:message "you need to install lualatex and dvisvgm."
:use-xcolor t
:image-input-type "dvi"
:image-output-type "svg"
:image-size-adjust (1.7 . 1.5)
:latex-compiler ("lualatex -interaction nonstopmode -output-format dvi
-output-directory %o %f")
:image-converter ("dvisvgm %f -n -b min -c %S -o %O")))
(add-to-list 'org-preview-latex-process-alist luasvg)
(setq org-preview-latex-default-process 'luasvg)
#+end_src
You can set 'org-preview-latex-default-process' to luasvg or luamagick
Best regards,
Juan Manuel
--
--
--
https://juanmanuelmacias.com/
Re: Choosing a LaTeX Compiler (my predilection for LuaTeX)
Hello, i use LuaTex / LuaLatex successfully after some configs and readings. The result (quality and speed) for me is better then with the old latex engine. I'm satisfied. BUT one thing isn't working and as far as i read here, there is no solution yet :-( The latex-preview inside org-mode is not possible, because it seems, that org-mode needs the dvi subprocess for running the neccessary tools. With LuaLatex there is no dvi file, because it produces a pdf right away. Any solution will be wellcome. Regards Poul
Re: Bug: org-link-descriptive needs to be buffer-local [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
On Mon, Apr 05 2021 22:36 (-0400), Kyle Meyer wrote: >> I suggest a simple fix that I just tested: make `org-link-descriptive' >> automatically buffer-local, by adding ":local t" to the defcustom. > > Hmm, I think a problem with `:local t' (or, equivalently, > make-variable-buffer-local for backward compatibility reasons) is that > then you'd interfere with user customization that directly sets this > after ol.el is loaded. You could also still get into a mismatched state > like you described above if you load an Org buffer, set the value > through the customization interface, and then call > org-toggle-link-display in that buffer. > > Instead I've updated the body of `org-mode' to make org-link-descriptive > buffer-local (702e782cb). I am not sure that I understand the problem you're describing.. Maybe it's because I don't use the customize interface myself, but I think any such customization would only set the default value, wouldn't it? But in any case, I am (of course) perfectly fine with your fix, thanks a lot for the quick response!
Re: Using backticks for the inline code delimeter?
On 05/04/2021 06:06, Nicolas Goaziou wrote: Joost Kremers writes: I tend to agree that allowing local modifications of Org's syntax is pretty much pointless, but then why is `org-emphasis-alist` a user option? In practice, the faces, i.e., the values, are meant to be customizable, not the keys. It would be great to have more clear statement in the doc string. Even in the manual it could be stressed stronger. Unsure if the current phrase really forbids extension, I would rather tend to interpret it as invitation to customize the list: "To narrow down the list of available markup syntax, you can customize ~org-emphasis-alist~." Maybe the code interpreting this variable could spit a warning on attempt to add new emphasizing characters.
[PATCH] org-protocol: decode "+" in query part as space
Hi,
Some time ago, when I tried org-protocol, I was quite surprised that
query parameters generated using URLSearchParams JavaScript class are
decoded incorrectly. "+" characters representing space are passed as is.
I hope, I have found a proper place in the code to handle such case.
It does not affect previously recommended bookmarklets with abundant
calls of encodeURIComponent that escapes spaces as "%20". I believe, new
option is more readable:
javascript:location.href='org-protocol://capture?' +
new URLSearchParams({
template: 'x',
url: location.href,
title: document.title,
body: window.getSelection()});
I guess, with old org-protocol syntax only pure percent encoding was
necessary due to each parameter was represented as path component. "+"
is allowed only in query part. Such variant was just missed when new
query-like syntax was introduced.
>From bf14953cba974ef2199c8d551a47d58c819b9a33 Mon Sep 17 00:00:00 2001
From: Max Nikulin
Date: Tue, 6 Apr 2021 21:30:06 +0700
Subject: [PATCH] org-protocol.el: decode "+" in query part as space
* lisp/org-protocol.el (org-protocol-convert-query-to-plist):
Replace "+" chars by spaces before passing parameter string
to decoder. Allow making org-protocol URIs with help of URLSearchParams
JavaScript class.
* lisp/org-protocol.el doc/org-manual.org etc/ORG-NEWS: Add examples
demonstrating new opportunity for browser bookmarklets.
Make parsing of URI parameters a bit closer to URL standard
https://url.spec.whatwg.org/#urlencoded-parsing
---
doc/org-manual.org | 22
etc/ORG-NEWS | 11 ++
lisp/org-protocol.el | 48 ++--
3 files changed, 75 insertions(+), 6 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index efe956877..122da066d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -19625,11 +19625,20 @@ slashes, and probably quote those for the shell.
To use this feature from a browser, add a bookmark with an arbitrary
name, e.g., =Org: store-link= and enter this as /Location/:
+#+begin_example
+javascript:location.href='org-protocol://store-link?' +
+ new URLSearchParams({url:location.href, title:document.title});
+#+end_example
+
+Title is an optional parameter. Another expression was recommended earlier:
+
#+begin_example
javascript:location.href='org-protocol://store-link?url='+
encodeURIComponent(location.href);
#+end_example
+The latter form is compatible with older Org versions from 9.0 to 9.4.
+
*** The ~capture~ protocol
:PROPERTIES:
:DESCRIPTION: Fill a buffer with external information.
@@ -19645,6 +19654,15 @@ using acapture template.
To use this feature, add a bookmark with an arbitrary name, e.g.,
=Org: capture=, and enter this as =Location=:
+#+begin_example
+javascript:location.href='org-protocol://capture?' +
+ new URLSearchParams({
+template: 'x', url: window.location.href,
+title: document.title, body: window.getSelection()});
+#+end_example
+
+You might have seen another expression:
+
#+begin_example
javascript:location.href='org-protocol://capture?template=x'+
'='+encodeURIComponent(window.location.href)+
@@ -19652,6 +19670,10 @@ javascript:location.href='org-protocol://capture?template=x'+
'='+encodeURIComponent(window.getSelection());
#+end_example
+It is a bit more cluttered than the former one, but it is compatible with
+previous Org versions 9.0-9.4. In these versions encoding of space as "+"
+character was not supported by URI decoder.
+
#+vindex: org-protocol-default-template-key
The capture template to be used can be specified in the bookmark (like
=X= above). If unspecified, the template key is set in the variable
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8bf3a7d29..78c563e01 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -228,6 +228,17 @@ Storing links to files using ~org-store-link~ (==) when
description of the link, if available. If no title exists it falls
back to the filename as before.
+*** org-protocol compatibility with =URLSearchParams= JavaScript class
+
+Decoder of query part of org-protocol URI recognizes "+" as an encoded
+space characters now, so it is possible to avoid call to =encodeURIComponent=
+for each parameter and use more readable expression in bookmarklet:
+
+#+begin_example
+'org-protocol://store-link?' + new URLSearchParams({
+ url: location.href, title: document.title})
+#+end_example
+
* Version 9.4
** Incompatible changes
*** Possibly broken internal file links: please check and fix
diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el
index 731f51e19..ebfd3887b 100644
--- a/lisp/org-protocol.el
+++ b/lisp/org-protocol.el
@@ -94,6 +94,15 @@
;; You may use the same bookmark URL for all those standard handlers and just
;; adjust the sub-protocol used:
;;
+;; javascript:location.href='org-protocol://sub-protocol?'+
+;;
Re: "#+STARTUP: hideblocks" has no effect?
Kyle> Are you leaving org-startup-folded at showeverything Yes I do. Kyle> That will prevent org-startup-folded and "#+startup: Kyle> hideblocks" from having an effect: I must admit I was pig ignorant of that. Kyle> For example, try this: Specifying "#+startup: nofold" together with "#+startup: hideblocks", as suggested, worked like a charm! Case closed, and I will try to RTFM the next time. Cheers Rasmus
Re: life on the eading bledge
Nicolas, thanks, your fix also seem to solve the problem i was having. cheers, Greg
Re: Can no longer org-set-link-parameters with "fuzzy" link types
Thank you both for the replies!
Nicholas - can you recommend how to best implement this with
font-lock-add-keywords?
Best regards,
-Adam
> On 6 Apr 2021, at 13:06, Nicolas Goaziou wrote:
>
> Hello,
>
> Kyle Meyer writes:
>
>> [ Sorry for the slow response. ]
>>
>> Adam Sneller writes:
>>
>>> I have a function that searches for broken fuzzy links in org-mode and
>>> applies org-warning face to anything it finds:
>>>
>>> (org-link-set-parameters
>>> "fuzzy"
>>> :face (lambda (path)
>>> (let ((org-link-search-inhibit-query t))
>>> (if (condition-case nil
>>> (save-excursion
>>> (save-match-data
>>> (org-link-search path (point) t)))
>>> (error nil))
>>> 'org-link 'org-warning
>>>
>>> In 9.4.4 this patch breaks this:
>>>
>>> https://code.orgmode.org/bzg/org-mode/commit/8c4e270df280a08b7e61295712c86246088146ba
>>>
>>> Is there some other recommended way to get this done as of 9.4.4?
>>
>> I don't know enough about the change to say whether this is recommended,
>> but it looks like you could get the behavior you're after with something
>> like
>>
>> (add-to-list 'org-link-parameters
>> '("fuzzy" :face (lambda (path) ...)))
>
> Link parameters are meant to be used with "scheme:path" links. However,
> we forbid internal link types, as writing [[fuzzy:whatever]] would be
> confusing for Org. As a consequence, link parameters are not meant to
> control internal links.
>
> We might need a different variable specific to internal links, but in
> the current case, using `font-lock-add-keywords' should be sufficient.
>
> Regards,
> --
> Nicolas Goaziou
Re: Can no longer org-set-link-parameters with "fuzzy" link types
Hello,
Kyle Meyer writes:
> [ Sorry for the slow response. ]
>
> Adam Sneller writes:
>
>> I have a function that searches for broken fuzzy links in org-mode and
>> applies org-warning face to anything it finds:
>>
>> (org-link-set-parameters
>> "fuzzy"
>> :face (lambda (path)
>> (let ((org-link-search-inhibit-query t))
>> (if (condition-case nil
>> (save-excursion
>> (save-match-data
>> (org-link-search path (point) t)))
>> (error nil))
>> 'org-link 'org-warning
>>
>> In 9.4.4 this patch breaks this:
>>
>> https://code.orgmode.org/bzg/org-mode/commit/8c4e270df280a08b7e61295712c86246088146ba
>>
>> Is there some other recommended way to get this done as of 9.4.4?
>
> I don't know enough about the change to say whether this is recommended,
> but it looks like you could get the behavior you're after with something
> like
>
> (add-to-list 'org-link-parameters
>'("fuzzy" :face (lambda (path) ...)))
Link parameters are meant to be used with "scheme:path" links. However,
we forbid internal link types, as writing [[fuzzy:whatever]] would be
confusing for Org. As a consequence, link parameters are not meant to
control internal links.
We might need a different variable specific to internal links, but in
the current case, using `font-lock-add-keywords' should be sufficient.
Regards,
--
Nicolas Goaziou
Re: life on the eading bledge
Hello, Kyle Meyer writes: > Greg Minshall writes: > >> hi. running c881b60593b3beeed7b8c7a2bada64157cd9940a, the following >> >> >> *** this =equals= that >> >> and, so on >> >> >> exporting [C-e l o], gives >> : replace-regexp-in-string: Wrong type argument: arrayp, nil > > Thanks for reporting. The failure was introduced by bcfe6f985 > (ox-latex: convert verbatim text in headings to texttt, 2021-04-04). > The below change seems to fix the issue, though Nicolas may be able to > suggest a more appropriate change. Indeed. I pushed a fix. I forgot verbatim objects have no contents since they are leaf objects. Regards, -- Nicolas Goaziou
Re: Bug: Incompatible return type in org-babel C when using a table of doubles with a header as a variable [9.4.4 (release_9.4.4-272-ga9f38b @ /home/richard/.emacs.d/straight/build/org/)]
Richard, yourbug submission uncovered 3 problems. From minor to major:
1. Missing delimitersin your example
change :includes stdio.h
to :includes
2. The function strcmp() is undefined
A patch has already been committed to fix that, in early January.
3. A mess between char* and double in automatically generated code.
This is a regression. I am investigating it.
Stay connected for an update.
Thanks for reporting!
Cheers
Thierry
Le 02/04/2021 à 19:40, Richard Sent via General discussions about
Org-mode. a écrit :
> When a table of floating pointer numbers that contains a header row is
> set as a variable to a C source block, the generated header file
> contains an invalid return type, causing the program to not compile.
>
> For example, if I have a table that looks like
>
> #+NAME: tbl-doubles-org-bug-report
> #+begin_src C :includes :results table :colnames '("i" "val")
> for (int i = 0; i < 5; i++) {
> printf("%f %f\n", (double)i, i * 2.0);
> }
> #+end_src
>
> #+RESULTS: tbl-doubles-org-bug-report
> | i | val |
> |-+-|
> | 0.0 | 0.0 |
> | 1.0 | 2.0 |
> | 2.0 | 4.0 |
> | 3.0 | 6.0 |
> | 4.0 | 8.0 |
>
> And then attempt to include that table as a variable called data
>
> #+begin_src C :includes stdio.h :var data=tbl-doubles-org-bug-report
> printf("No errors!");
> #+end_src
>
> Nothing is printed, and *Org-Babel Error Output* will display
>
> /tmp/babel-NQHi51/C-src-lsA892.c: In function ‘data_h’:
> /tmp/babel-NQHi51/C-src-lsA892.c:24:65: error: incompatible types when
> returning type ‘double’ but ‘const char *’ was expected
> 24 | const char* data_h (int row, const char* col) { return
> data[row][get_column_num(2,data_header,col)]; }
> |
> ~^~~
> /bin/bash: line 1: /tmp/babel-NQHi51/C-bin-90Zk27: Permission denied
>
> If we look in the /tmp file mentioned, it's easy to see the
> inconsistency.
>
> double data[5][2] = {
> {0.00,0.00},
> {1.00,2.00},
> {2.00,4.00},
> {3.00,6.00},
> {4.00,8.00}
> };
> const int data_rows = 5;
> const int data_cols = 2;
> int get_column_num (int nbcols, const char** header, const char* column)
> {
> int c;
> for (c=0; c if (strcmp(header[c],column)==0)
> return c;
> return -1;
> }
> const char* data_header[2] = {"i","val"};
> const char* data_h (int row, const char* col) { return
> data[row][get_column_num(2,data_header,col)]; }
> int main() {
> printf("No errors!");
> return 0;
> }
>
> data_h() should not return a const char*, but a double.
>
> I've also tested this with $ emacs -Q and the issue is still present. It
> does not occur if the table contains integer values instead of floats
> or if a header row is omitted. Seeing as how the header row is processed
> differently from the data, I don't think the presence of a header row is
> meant to cause this error.
>
>
>
> 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.4.4 (release_9.4.4-272-ga9f38b @
> /home/richard/.emacs.d/straight/build/org/)
>
> current state:
> ==
> (setq
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer doom-modeline-set-org-src-modeline)
> org-link-shell-confirm-function 'yes-or-no-p
> org-blank-before-new-entry '((heading . t) (plain-list-item . t))
> 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-odt-format-headline-function 'org-odt-format-headline-default-function
> org-agenda-files '("~/org")
> org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
> org-startup-folded t
> org-mode-hook '(#[0 "\301\211\207" [imenu-create-index-function
> org-imenu-get-tree] 2]
> #[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 turn-on-auto-fill
> mixed-pitch-mode org-superstar-mode
> highlight-parentheses-mode)
> 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-adapt-indentation nil
> org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
> org-babel-pre-tangle-hook '(save-buffer)
> org-file-apps '(("\\.pdf\\'" . emacs) (auto-mode . emacs) (directory .
> emacs) ("\\.mm\\'" . default) ("\\.x?html?\\'" . default)
> ("\\.pdf\\'" .
Re: Bug: org-attach-follow with wrong-number-of-arguments [ ( @ /home/sbrass/.emacs.d/elpa/org-9.4.4/)]
Thanks for an answer, in any place first :).
Am Di., 6. Apr. 2021 um 05:46 Uhr schrieb Kyle Meyer :
> [ Sorry for the slow reply. ]
>
> Simon Braß writes:
>
> > Hi all,
> >
> > I've tried to open an attached file (added with org-attach-attach),
> however,
> > when I try to open it with C-c C-o I got the following backtrace:
> >
> > #+begin_example
> > Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1)
> > org-attach-follow("1805.00020.pdf")
> > org-link-open((link (:type "attachment" :path "1805.00020.pdf" :format
> > bracket :raw-link "attachment:1805.00020.pdf" :application nil
> > :search-option nil :begin 717 :end 818 :contents-begin 746 :contents-end
> > 816 :post-blank 0 :parent (paragraph (:begin 717 :end 819 :contents-begin
> > 717 :contents-end 819 :post-blank 0 :post-affiliated 717 :parent (item
> > (:bullet "- " :begin 708 :end 819 :contents-begin 717 :contents-end 819
> > :checkbox off :counter nil :structure (... ... ... ... ...) :pre-blank 0
> > :post-blank 0 :post-affiliated 708 :tag nil :parent (plain-list
> ...)))
> > nil)
> > org-open-at-point(nil)
> > funcall-interactively(org-open-at-point nil)
> > call-interactively(org-open-at-point nil nil)
> > command-execute(org-open-at-point)
> > #+end_example
>
> Hmm, this looks like an inaccessible state for Org 9.4.4. Here's how
> org-link-open would handle an attachment type:
>
> (let ((f (org-link-get-parameter type :follow)))
> (when (functionp f)
> ;; Function defined in `:follow' parameter may use a single
> ;; argument, as it was mandatory before Org 9.4. This is
> ;; deprecated, but support it for now.
> (condition-case nil
> (funcall (org-link-get-parameter type :follow) path arg)
> (wrong-number-of-arguments
> (funcall (org-link-get-parameter type :follow) path)
>
> So it first calls with the expected 2 arguments and then falls back to
> the single one.
>
Thanks, good to know. I'm clearly not a Lisp expert...
Follow attachment links works okay on my end, and, aside from a mixed
> installation, I can't think of a way to get into that state.
>
> https://orgmode.org/worg/org-faq.html#mixed-install
>
> > After adding == to the definition of =org-attach-follow=, and
> > reloading org-mode (uncompiled) I could get through org-attach-follow.
> > But, then I hit another issue:
> >
> > #+begin_example
> > Debugger entered--Lisp error: (void-function org-link-open-as-file)
> > (org-link-open-as-file (org-attach-expand file) arg)
> > org-attach-follow("0906.4487.pdf")
> > …
> > #+end_example
>
> That function was added in 9.4 and is in the same file as the caller,
> org-link-open. The fact that it's not defined also points to a mixed
> install, with an older ol.el taking precedence.
>
It seems to work with the recent Emacs version: GNU Emacs 27.2 (build 1,
x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.17.4) of
2021-03-26.
So, it actually points to a mixed installation on my side.
Next time I will follow the instructions in
https://orgmode.org/manual/Feedback.html more carefully, and remind myself
of a possible mixed installation.
Thanks, again, Kyle for your answer.
Cheers,
Simon
