Re: ox-html: Bug or feature for export of title and meta information?
On 2020-02-14, at 20:31, Nicolas Goaziou wrote: > Hello, > > Jens Lechtenboerger writes: > >> 1. Export to HTML when the title contains markup, say this one: >> >> #+TITLE: This does *not* work > > What does not work? > >> The HTML title element contains a nested b element, which is >> invalid as only text is allowed. > > Who said that? The above is perfectly valid. Good morning (over here), the W3C Markup Validator [1] disagrees with this output from ox-html (which I reduced to the essential parts): #+begin_src html http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;> http://www.w3.org/1999/xhtml; lang="en" xml:lang="en"> This does not work #+end_src Best wishes Jens [1] https://validator.w3.org/#validate_by_input
Load Org Babel Languages on Demand
In Doom Emacs (https://github.com/hlissner/doom-emacs), Org's babel packages aren't loaded all at once with org-babel-do-load-languages, but on demand when their src blocks are encountered (fontified) or executed. Same with its export backends. Dooms maintainer, Henrik Lissner, has kindly extracted his code into a gist (https://gist.github.com/hlissner/14b42de71c65945f55a31b393af0391b) following a GitHub issue ( https://github.com/hlissner/doom-emacs/issues/2536#issuecomment-586088410) and the interest expressed in a Reddit thread ( https://www.reddit.com/r/emacs/comments/f3ed3r/how_is_doom_emacs_so_damn_fast/fhixxjx/ ). I think this would make the org-mode literate programming experience significantly smoother. Any thoughts on including this in org-mode?
Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface
I wonder if it would make sense to use shadow-cljs rather than cider as a back end for evaluating clojurescript? More generally, I wonder if there would be any benefit in considering a Clojure CLI Tools back end integration and bypassing CIDER altogether? While I love CIDER, I'm not sure it is the right tool for a org-babel type environment. I've recently been moving my projects from being lein based to Clojure CLI tools based and while I still use CIDER for larger development work, find the CLI great for basic execution of code. For me, CIDER has a lot of additional overhead and complexity which is often of little benefit to what I want via babel and I've found it to be a very fragile environment. Sean Corfield has a great example deps.edn file at https://github.com/seancorfield/doc-clojure and it shows how you can hook in various different REPLs - for example, a basic socket based REPL, which might provide a cleaner and more stable back end interface for evaluating Clojure (and potentially clojurescript) for babel. My rough and immature idea would be to have a back end that allowed you to specify CLI aliases in the block header. These aliases can do a lot, including select whatever execution environment you want the code to run in. The back end could have default aliases for basic evaluation and it could all be based around a socket REPL, which should make sending/reading from the REPL fairly straight-forward. As I said, this is an initial and immature idea, but I think it could provide a back end which was a little more like other babel back ends and may be less fragile than one based on CIDER (plus I suspect it would be faster). What do people think? Is this something worth investigating further? Bastien writes: > stardiviner writes: > >> I use CIDER (sesman) keybinding =[C-c C-s d]= on ob-clojure src >> block to link current buffer directory to CIDER REPL session. > > I simply start Cider with C-c M-j and then execute the Clojure source > block with C-c C-c, it works fine. > >> I guess this should work for ClojureScript src block too. > > IMHO it works differently for ClojureScript, as C-c M-J doesn't know > how to start a ClojureScript session unless you're in a directory with > the proper cljs configuration (be it figwheel-main.edn, dev.cljs.edn, > whatever.) At least this is how I made it work. -- Tim Cross
Re: Bug: refiling gobbles a newline and absorbs the next heading [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
I have no compelling reason to delete those lines, it just sometimes happens that I do delete when I do a quick capture, and then they wreak havoc in my main org buffer. No longer, thanks to you! Miguel On Tue, 11 Feb 2020 at 11:38 WET, Bastien wrote: > Hi Miguel, > > Miguel Morin writes: > >> delete newlines from the end of the org-capture buffer > > I can reproduce your problem when I do delete newlines > from the end of the capture buffer, but I don't see why > I would delete newlines. > > Is this just some casual cleanup on your side or do you > have a compelling reason for deleting those lines?
Re: Possible to exclude/include tags for agenda custom commands?
Stig Brautaset writes:
> Hi Bastien,
>
> Bastien writes:
>>> I can easily do this in the list of TODOs, with a tag search. However, I
>>> haven't figured out how to do this for the agenda. Is it possible? If
>>> so, how?
>>
>> From what I understand, check `org-agenda-tag-filter' to see how to
>> use it within an agenda custom command.
>
> Thank you! That did indeed do it.
>
> FWIW my stanza looks like this now:
>
> (setq org-agenda-custom-commands
> '(("w" "Work Agenda"
> ((agenda "" ((org-agenda-span 'day)))
> (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@home" "-MAYBE"
>("h" "Home Agenda"
> ((agenda "")
> (todo "TODO"
>((org-agenda-max-entries 5)
> (org-agenda-todo-ignore-scheduled 'all)
> (org-agenda-todo-ignore-deadlines 'all)
> (org-agenda-todo-ignore-timestamp 'all
> ((org-agenda-tag-filter '("-@work" "-MAYBE"
>("m" "Maybe"
> ((todo "PROJ")
> (tags-todo "-PROJ/TODO"))
> ((org-agenda-tag-filter '("MAYBE"
>("P" "Projects" tags-todo "-MAYBE/PROJ"
>
> Stig
Hi Stig,
Thanks for sharing that. I think this is a fairly common question among
Org users, yet not always easy to find the answer to, so I've added your
example here along with a couple of other solutions:
https://alphapapa.github.io/org-almanac/#Exclude%20and%20include%20tags%20in%20custom%20Agenda%20commands
Step by step tutorial on Worg on how to create a new export backend
We have a good reference documentation for creating export backends: https://orgmode.org/worg/dev/org-export-reference.html But we *badly* need a step by step tutorial on Worg. Anyone would like to volunteer for writing such a tutorial? -- Bastien
Re: ox-html: Bug or feature for export of title and meta information?
Hi Nicolas, Nicolas Goaziou writes: > This doesn't mean the manual cannot be improved, of course. Improvements > are welcome in that area. I see org-export-options-alist is not mentioned in the manual - would it be worth mentioning it in the "Adding Export Back-ends" section? -- Bastien
Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface
stardiviner writes: > I use CIDER (sesman) keybinding =[C-c C-s d]= on ob-clojure src > block to link current buffer directory to CIDER REPL session. I simply start Cider with C-c M-j and then execute the Clojure source block with C-c C-c, it works fine. > I guess this should work for ClojureScript src block too. IMHO it works differently for ClojureScript, as C-c M-J doesn't know how to start a ClojureScript session unless you're in a directory with the proper cljs configuration (be it figwheel-main.edn, dev.cljs.edn, whatever.) At least this is how I made it work. -- Bastien
Re: ox-html: add option to restore old src block behaviour?
Hi Jens, Jens Lechtenboerger writes: > that issue has been resolved: > https://lists.gnu.org/archive/html/emacs-orgmode/2019-10/msg00099.html great, thanks for confirming. -- Bastien
Re: attachment: link type export to HTML invalid attach dir
Nicolas Goaziou writes: >> Now, I'm not sure who wants to try implementing Nicolas suggestion to >> let ox.el expand attachments into file links: since you both know the >> issue better than I do, I suggest one of you can try? > > I will try to propose a patch by tomorrow evening. Thanks! If things are okay, I'll then have some time on sunday to prepare for the release on monday. -- Bastien
Re: Custom image link types in LaTeX
Also, it would be nice to get access to the "info" variable for custom links; that way, custom image links could handle attributes like "#+WIDTH". But straight up giving the ":export" function (registered through "org-link-set-parameters") another argument would break all existing custom links, so I'm not sure whats the way to go about this. Regards, -- Solomon
Re: ox-html: Bug or feature for export of title and meta information?
Completing myself, Nicolas Goaziou writes: > General export rules are described in ox.el (org-export-options-alist), > then each export back-end define its own specificities (look at the > back-end definition). This doesn't mean the manual cannot be improved, of course. Improvements are welcome in that area.
Re: ox-html: Bug or feature for export of title and meta information?
Hello, Jens Lechtenboerger writes: > 1. Export to HTML when the title contains markup, say this one: > > #+TITLE: This does *not* work What does not work? > The HTML title element contains a nested b element, which is > invalid as only text is allowed. Who said that? The above is perfectly valid. > 2. The documentation does not explain which headers are exported how > to HTML. Some keywords have are more important than others, since they have a special meaning during export, e.g., TITLE vs. RANDOM_FOO. General export rules are described in ox.el (org-export-options-alist), then each export back-end define its own specificities (look at the back-end definition). Regards, -- Nicolas Goaziou
Re: Custom image link types in LaTeX
Alright, I'll wait. Meanwhile I have a few crude advises in my config that allow some functionality, so no hurry :) On Fri, Feb 14, 2020 at 7:17 PM Nicolas Goaziou wrote: > Hello, > > Bastien writes: > > > solomon theNinja writes: > > > >> I'll be happy to implement exporting custom image links myself, given > >> time, if that's the issue. > > > > Sure, please go ahead! If your change is more than 15 lines or so, > > you might need to sign the FSF copyright assignment: > > > > https://orgmode.org/request-assign-future.txt > > > >> - If it was not clear, in "custom links" I'm referring to links > >> defined with `org-link-set-parameters` that have a special export > >> behavior. > > > > Yes, that's what they are for. > > Note that I need to slightly improve the tooling in "ol.el", so > I suggest to wait for these changes, as it might make this feature > trivial. > > Regards, > > -- > Nicolas Goaziou >
Re: ox-html: add option to restore old src block behaviour?
On 2020-02-11, at 16:40, Bastien wrote: > Matt Price writes: > >> However, at least one very common syntax highlighter, https:// >> highlinghtjs.org, expects just a single tag, as do other >> common CSS frameworks. These often leave odd borders or background >> color disruptions which somewhat distort the view of the code. >> There's also a funny conflict with `org-re-reveal`, which expects the >> old behaviour (see https://gitlab.com/oer/org-re-reveal/issues/27). >> It would in principal be possible to fix these issues directly in >> CSS, but it might be much more practical to have an option -- a >> defvar or a file/headline-settable property -- that restores the old >> behaviour when desired. If this would be welcome, I could do it. I >> know org already has a bewildering number of options,though,and the >> code change would be oddly a number of times as large as the >> substantive change of that commit, os thought I'd check first. > > Yes, an option makes sense here -- can you provide one that allows to > restore the old behavior (and avoid all those ... lines)? Hi Bastien, that issue has been resolved: https://lists.gnu.org/archive/html/emacs-orgmode/2019-10/msg00099.html Best wishes Jens
Re: ox-html: Bug or feature for export of title and meta information?
On 2020-02-11, at 09:16, Bastien wrote: > Hi Jens, > > it is difficult to justify existing code, it is easier to answer to > bug reports. If you think there is a bug in this aread, can you tell > what it is? Hi Bastien, many thanks for following up on this! I see two or more bugs: 1. Export to HTML when the title contains markup, say this one: #+TITLE: This does *not* work The HTML title element contains a nested b element, which is invalid as only text is allowed. 2. The documentation does not explain which headers are exported how to HTML. I described different variants in my previous e-mail. I’m not sure whether there was a reason to treat them differently. So, this is at least a bug in the documentation (with potentially more bugs in the code if the current treatment was not desirable). Best wishes Jens
Re: Custom image link types in LaTeX
Hello, Bastien writes: > solomon theNinja writes: > >> I'll be happy to implement exporting custom image links myself, given >> time, if that's the issue. > > Sure, please go ahead! If your change is more than 15 lines or so, > you might need to sign the FSF copyright assignment: > > https://orgmode.org/request-assign-future.txt > >> - If it was not clear, in "custom links" I'm referring to links >> defined with `org-link-set-parameters` that have a special export >> behavior. > > Yes, that's what they are for. Note that I need to slightly improve the tooling in "ol.el", so I suggest to wait for these changes, as it might make this feature trivial. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Bastien writes: > Now, I'm not sure who wants to try implementing Nicolas suggestion to > let ox.el expand attachments into file links: since you both know the > issue better than I do, I suggest one of you can try? I will try to propose a patch by tomorrow evening. Regards, -- Nicolas Goaziou
How to occasionally store link as file.org+headline
Hello, For most of my links, I want to use the ID generated by orgmode i.e., (setq org-id-link-to-org-use-id t) But occasionally, for targets that are not part of my agenda files, I want to store a link of the type file:path.org::*headline I wrote the following function to accomplish that: (defun org-store-file+headline () "Store link as file + headline" (interactive) (let ((org-id-link-to-org-use-id nil)) (org-store-link nil t))) This function works (lightly tested). But is there a built-in way, such as using prefixes or arguments to org-store-link? I browsed the code for it, but that function is several hundred lines long, and I gave up. Thank you, Mirko
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, On Fri, Feb 14 2020, Bastien wrote: I hope you can fix this somehow, maybe upstream. Unfortunately, I'm afraid I don't understand this enough, and what 'ivy-completing-read' was supposed to do, to be able to provide a pertinent report there. I personally don't have a problem locally. I had a workaround thus far, and with your fix, I won't even need that. As previously reported, the issue initially raised is indeed fixed, and things work as expected. I don't claim a problem persists in Org, and I was just trying to be thorough in the testing you requested. And did so with pleasure. So... From what I understand, this is not a bug in Org. ... if you are satisfied, I'm happy with that too. Thank you very very much! Best, Gustavo.
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, On Fri, Feb 14 2020, Bastien wrote: I've revisited org-refile-get-location given your new information on ivy-completing-read but I'm not able to see something wrong in the current implementation of org-refile-get-location. At the same time, I don't see why ivy-completing-read would handle arguments differently than completing-read-default, so _perhaps_ org-refile-get-location still does something wrong. If you - or other ivy users - have time to investigate and report, please do so. As I said before, there is much that eludes me in 'org-refile-get-location', but I'm trying to pin this down further by getting some inspection points and trying at least to grasp where it happens. In particular, I set one inspection point exactly after the completing-read function is called to store the value of local variable "answ" which is the return value of the completing-read function. That is, right after: #+begin_src emacs-lisp (setq answ (funcall cfunc prompt tbl nil (not new-nodes) nil 'org-refile-history (or cdef (concat (car org-refile-history) extra #+end_src The value of "answ" right after this step is then: - with 'ivy-mode' off, that is with 'completing-read-default' as 'completing-read-function': "test.org/Top heading 1//" (that is with a *double trailing slash*). - with 'ivy-mode' on, that is with 'ivy-completing-read' as 'completing-read-function': "test.org/Top heading 2/" In both cases the last trailing slash seems (as far as I understand it) to be then trimmed off by 'org-refile--get-location' with: #+begin_src emacs-lisp (replace-regexp-in-string "/$" "" refloc) #+end_src Why 'ivy-completing-read' does not return the end double slash while 'completing-read-default' does, I have no idea. But the fact that 'completing-read-default' returns the refile location with a double trailing slash makes me think there is still something to be fixed in 'org-refile-get-location'. Best, Gustavo.
Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bastien writes: > Hi Stardiviner, > > stardiviner writes: > >> About this patch, last night, I try to test ob-clojurescript eval with CIDER >> connection. But no luck, the ClojureScript REPL connection always failed to >> start. I have problem on CIDER. So I have a request that can you take a test. >> Because on my side, ~(cider-current-connection "cljs")~ returns ~nil~ unable >> to >> test. > > I was able to execute #+begin_src clojurescript source blocks only > when the containing Org file is itself within a project where cider > knows how to launch a clojurescript nrepl. This is what I tried to > convey in the ORG-NEWS entry: > > You can now use =#+begin_src clojurescript= and execute > ClojureScript code from Org files. You will need to put the file in > an directory from where ClojureScript knows how to start a nrepl > connection: e.g. you can put your Org file at the root of a > figwheel-main directory. I use CIDER (sesman) keybinding =[C-c C-s d]= on ob-clojure src block to link current buffer directory to CIDER REPL session. I guess this should work for ClojureScript src block too. > > There was no patch attached to your email, can you resend it? > You already applied patches. I already checked latest master of Org Mode source code. - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5GuZEUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsNd9wf7BNRVjn52wjYJtO+FEZXXfoWFuhZg qCYqd6LhWL8tC3/aLEYmomWD0nLyz4QzOsxD9hliRRl1KNc+JYTRU9b5Si901l23 FPQQdGWxX6LqdRPx9TUg4IToo1AM1qNfRnZXq4lDvpDgO/NxWldeF14681RkgM16 W3OLa5FnW3eHxsLrFf7OIbxKyQRlT8W+GSx7GTaQgbZanKB8Z16mIZ9GYAl97VA9 nbUNg6SjddWmzwoDihAl3f+LLSKjtdTN+jeSeL2RNr/w/1dm6rjpCJKvCxTTmbV8 ruo6AAfvtP1msKvwGHpyoO9MhmqWMIAg+U+HVjk09baZVx2dxLox/YVrbg== =cFe+ -END PGP SIGNATURE-
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Gustavo, thanks for investigating further. From what I've seen, ivy-mode does not set the org-refile-history variable correctly, always setting the car of this variable to "^" after ivy-completing-read is called. >From what I understand, this is not a bug in Org. I hope you can fix this somehow, maybe upstream. Thanks, -- Bastien
Re: Ask GitHub to add the jekyll-org plugin to their whitelist to publish GitHub pages with Org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Of course, I will raise my hand over there. Thanks for resume this up. Bastien writes: > Hi all, > > Stig started this request more than 3 years ago: > https://github.com/github/pages-gem/pull/335 > > Today, GitHub does not seem to listen to this need. > > If some of you care about the issue, please raise > your hand and make yourselves heard. > > Thanks! - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5GupUUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsO1sAf+OqgIDSzw/DwRsZceSuDYOz612szw RbDkb7UNV26NCKaWDjgruvBs1uhQLmoYLcvrhzccrguEi1MaLJSXVjRYWz5dbNPz phCKC13kXnVtmm6WUZ7MHGvUMOnTJ59ykixDjIsOanuKc/7rEJgcIPkfPlDKiXbk GCNp/R1PllkidcMoodATTukCMfjjNbEFpOZGROjz42m+hM4QJup9FKcDiANql1Pi Ot/7Gx2udXmhZ0qROtVRKIKjTEjwupoehnNSE+j6RGk2Njlch8uf77/1TN/eOZ99 bUvcgZu/aWEZ+r4k7KzKluOhD0LtLPvPjw84zc68BJSLp4hhxUpJO2aQ6Q== =chKl -END PGP SIGNATURE-
Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bastien writes: > stardiviner writes: > >> I've already signed FSF papers before. Actually I contributed some >> patches already. :) > > Argh, yes, sorry, my bad! I was confused because I saw TINYCHANGE in > previous commit messages. It's fine, I know you read many emails, Forgetting some minor stuff is excusable. - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5GuhoUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPZigf+I9N8O/sK59GjD3VnLfYo6Yj1G6cQ FK1a+nZlxFJ/UGMOY5n+pX7LID+RXKOKyoEHflD8ZGJpz24Th8Ai+rdSPbjNjIXA ru0EsR553T1TY+6+UQRy2OGmghZcWRWfcnw5iiqJj1NlI3+i2dAiXlrvLSdk7VZG wumwqnfeyB9atVua/q6WXl8eVnvLfFFZmBgb/NXLebu94484Yz/h4QAtAhhpQPrT cVVaP3IKzSuYfatgVLMa59uQuEk8tmOjClaQ8pZbJU5S0R9urR5LNAeFBQI3IyVP bzVdTJWLjUuPCRcxk/xMdcZG3J78Sg94GNG4ZDLDi+bzDqFLjOZopXOaxg== =VuDO -END PGP SIGNATURE-
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien,
On Fri, Feb 14 2020, Bastien wrote:
I've revisited org-refile-get-location given your new information on
ivy-completing-read but I'm not able to see something wrong in the
current implementation of org-refile-get-location. At the same time,
I don't see why ivy-completing-read would handle arguments differently
than completing-read-default, so _perhaps_ org-refile-get-location
still does something wrong.
That was pretty much my thought too.
If you - or other ivy users - have time to investigate and report,
please do so.
I've tried, when I originally reported, and now again, to pin this
further down. Alas, there is much in 'org-refile-get-location' I don't
understand (in the sense of not understanding why certain things are
being done). I also have much to learn with respect to
'completing-read'. But I can provide an ECM to reproduce it.
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/src/org-mode/lisp"); current master
(setq org-refile-targets '(("~/org/test.org" :maxlevel . 2)))
(setq org-refile-use-outline-path 'file)
(setq org-outline-path-complete-in-steps nil)
#+end_src
- Open file "~/org/test.org", with contents:
#+begin_src org
,* Top heading 1
,* Top heading 2
,** Entry 1
,** Entry 2
#+end_src
- Now, do some refile operations here. Inspecting 'org-refile-history'
will give us:
#+begin_src emacs-lisp
("test.org/Top heading 2/" "test.org/Top heading 2/" "test.org/Top
heading 1/" "test.org/Top heading 1/")
#+end_src
- Now, we reset 'org-refile-history' and start 'ivy-mode':
#+begin_src emacs-lisp
(setq org-refile-history nil)
(add-to-list 'load-path ".emacs.d/elpa/ivy-20200211.1338"); current
Melpa
(require 'ivy)
(ivy-mode)
#+end_src
- After some refile operations, the value of 'org-refile-history' is:
#+begin_src emacs-lisp
("test.org/Top heading 2" "test.org/Top heading 2" "test.org/Top
heading 1" "test.org/Top heading 1")
#+end_src
The difference is, as previously reported, the presence/absence of the
trailing slash (the "extra" in terms of 'org-refile-get-location'). As
far as I can tell, it is inconsequential to the working of the refile
operation, but it did intrigue me.
Environment: Org mode version 9.3.6 (release_9.3.6-298-g0fa69d @
/home/gustavo/src/org-mode/lisp/); GNU Emacs 26.3 (build 1,
x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-11-11;
ivy-20200211.1338
HTH,
Gustavo.
Re: attachment: link type export to HTML invalid attach dir
Okay, I've done my home work :) TL;DR: (1) The change is fresh, let's take the time to work together at making it right before 9.4*; (2) the current state with the line 3216 in org-element.el is not okay; (3) let's try implementing what Nicolas suggests wrt to attachment=>file link resolution. * Sorry that I rushed you into having this discussion by announcing the release with such a short notice, I should have seen this was not resolve. Now into more details. - The new feature for attachments is nice and useful. And I'm quite happy Gustav is now more acquainted with org-element.el -- we need more people with a good knowledge of that core file (thanks!) - My definition of Org core link types = the minimal set of types to which other types can be translated to. Given this definition, an attachment is not a core link type as it can resolve to file type. - org-element.el should only know about core link types. - Link type resolution should happen at exporting time: I think the design consistency is worth the potential parsing time cost. - One advantage of this approach (on top of design consistency) is that exporters won't each depend on org-attach.el to deal with file attachments, as they do right now. Now, I'm not sure who wants to try implementing Nicolas suggestion to let ox.el expand attachments into file links: since you both know the issue better than I do, I suggest one of you can try? We are not pressed by time, so whoever has the energy to finish this. Thanks! -- Bastien
Ask GitHub to add the jekyll-org plugin to their whitelist to publish GitHub pages with Org
Hi all, Stig started this request more than 3 years ago: https://github.com/github/pages-gem/pull/335 Today, GitHub does not seem to listen to this need. If some of you care about the issue, please raise your hand and make yourselves heard. Thanks! -- Bastien
Re: [BUG] Infinite loop in org-agenda-show-new-time
Hi Andrew, thanks a lot for the minimal recipe! Very helpful. I confirm the bug and I have now (finally) fixed it. We can close this bug from... 2013 :) Best, -- Bastien
Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface
Hi Stardiviner, stardiviner writes: > About this patch, last night, I try to test ob-clojurescript eval with CIDER > connection. But no luck, the ClojureScript REPL connection always failed to > start. I have problem on CIDER. So I have a request that can you take a test. > Because on my side, ~(cider-current-connection "cljs")~ returns ~nil~ unable > to > test. I was able to execute #+begin_src clojurescript source blocks only when the containing Org file is itself within a project where cider knows how to launch a clojurescript nrepl. This is what I tried to convey in the ORG-NEWS entry: You can now use =#+begin_src clojurescript= and execute ClojureScript code from Org files. You will need to put the file in an directory from where ClojureScript knows how to start a nrepl connection: e.g. you can put your Org file at the root of a figwheel-main directory. > I think this patch should work. Just for confirm. There was no patch attached to your email, can you resend it? Thanks, -- Bastien
Re: [SOLVED] Re: org-agenda clock table total time only for first clock time column
Hi Stardiviner, stardiviner writes: > Sorry for my misunderstanding. Today I re-check the org-agenda clock table. I > found It's correct. I read this style of display wrong. :) Okay, thanks for confirming! -- Bastien
Re: [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'
Hi Sebastian, Sebastian Miele writes: > Part of me feels that I should find a better explanation and spare you > the trouble of figuring out what I mean. But there seems to be no > (significantly) better explanation I can come up with without going to > greater lengths and especially investing considerable time for working > out very clear terminology for the situation. You explained things very clearly, it is just that I was somehow tired and those things are complex to explain (and figure out) by nature. > I currently feel a tension between not wanting you to have to spend > considerable time understanding what I wrote and not wanting myself to > spend time to try to explain it better. Well, it's always a tradeoff between the time the one reporting the bug can spend producing a sensible report and the time the bug fixer can spend understanding and fixing it. And each side tends to underestimate the time it takes to the other side... the only big asymmetry here is that there are more reporters than fixers :) > However, if it is necessary, I will take the time. Thanks for this... > Please try having it in the back of your mind for some days, maybe even > without actively spending much time on trying to understand it. Then > tell me if struck or not. ... I'll remember it for next times -- but in this case, the lack of understanding was because of me. Best, -- Bastien
bug#38592: 27.0.50; org mode insinuates itself into calendar
Hi Sam, Sam Steingold writes: > If you tell me what to do, I would gladly do it. > I am afraid I am too busy to investigate it myself... if you can share your .emacs file (removing private information) I can try to bisect and find what causes Org to be loaded: you can send it to me in private if you prefer. But in the meantime, I confirm that with Emacs -q (from latest master), Org is *not* loaded and calendar-mode-hook is nil. Best, -- Bastien
Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface
stardiviner writes: > I've already signed FSF papers before. Actually I contributed some > patches already. :) Argh, yes, sorry, my bad! I was confused because I saw TINYCHANGE in previous commit messages. -- Bastien
Re: Custom image link types in LaTeX
Hi Solomon, solomon theNinja writes: > I'll be happy to implement exporting custom image links myself, given > time, if that's the issue. Sure, please go ahead! If your change is more than 15 lines or so, you might need to sign the FSF copyright assignment: https://orgmode.org/request-assign-future.txt > - If it was not clear, in "custom links" I'm referring to links > defined with `org-link-set-parameters` that have a special export > behavior. Yes, that's what they are for. Thanks! -- Bastien
Re: Possible to exclude/include tags for agenda custom commands?
Hi Stig, Stig Brautaset writes: > Thank you! That did indeed do it. Thanks for confirming... > FWIW my stanza looks like this now: ... and sharing. Best, -- Bastien
Re: Provide org-insert-subitem
Hi Adam, Adam Porter writes: > What do you think? I think that's a good idea to promote org-insert-subheading either by binding it to a key or another way. I already have some drafty code that might touch things in this (very sensible) area, so if you don't mind, I'll come back to the details of your suggestions when I can articulate them with the few ideas I have in mind. And after 9.4 is out. But yes, there is room for enhancements here. Don't hesitate to bump this thread in a few weeks if I don't share my ideas since then. Best, -- Bastien
Re: Bug: Symlink handling in org-babel-load-file
Hi Ricky, thanks for the double-check, I've now apply the change as you suggest. Best, -- Bastien
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Gustavo, Gustavo Barros writes: > I've tested it again, and I believe it is working as intended. Thanks for confirming. > I observe, however, a difference of behavior between > "completing-read-default" and "ivy-completing-read" in the workings of > "org-refile-get-location". Namely, with "completing-read-default" the > chosen target is stored in "org-refile-history" with a trailing slash > (the "extra" part), while with "ivy-completing-read" it is stored > without the trailing slash. > > I have no idea why this is so and also don't know if this stems from > Org's end. As far as I can tell, functionality of the feature with > respect to this bug report is working as intended: no duplicate > candidates, and history is honored. But the difference surprised me > and if you think it might be important, I can provide an ECM for it. > Otherwise, I think this can well closed as fixed. I've revisited org-refile-get-location given your new information on ivy-completing-read but I'm not able to see something wrong in the current implementation of org-refile-get-location. At the same time, I don't see why ivy-completing-read would handle arguments differently than completing-read-default, so _perhaps_ org-refile-get-location still does something wrong. If you - or other ivy users - have time to investigate and report, please do so. Thanks, -- Bastien
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Samuel, Samuel Wales writes: > dunno if this is useful (probably not), but i found the following was > necessary to fix ido. What was the problem when refiling with ido? > i didn't really understand it, but it fixed it. I have tested the patch, but I'd like to understand and reproduce the bug before accepting the fix. Thanks, -- Bastien
Re: attachment: link type export to HTML invalid attach dir
Hi Nicolas and Gustav, Nicolas Goaziou writes: > I'm Cc'ing Bastien because that particular point should be solved before > any release, IMO. Thanks for adding me to the loop. I'll take the time today or tomorrow to understand what is at stake here and of course, I won't release Org 9.4 before it is sorted out. Everyone can take a break from this thread :) -- Bastien
