Custom link type that attaches file in :follow
Hi! I am having some trouble adding a link via =org-link-set-parameters=. I want to have a custom =xournalpp=-link type that behaves as follows: - follow :: Open attached file - exists :: open the file - don't exist :: create attachment directory and copy template file into it - export :: Use [[https://xournalpp.github.io/][Xournalpp]] to export the file as an svg. Inline this svg. #+begin_src emacs-lisp (org-link-set-parameters "xournalpp" :follow (lambda (path) (let ((xoppfile (concat (org-attach-dir-get-create) "/" path)) (template "/home/tarjei/repos/konturer/maler/skisse.xopp")) (cond ((not (file-exists-p xoppfile)) (copy-file template xoppfile))) (org-attach-sync) (shell-command (format "xournalpp %s" xoppfile :export (lambda (path desc backend) (let ((xoppfile (concat (org-attach-dir-get-create) "/" path)) (tempfile "/home/tarjei/temp/xournal_export.svg")) (shell-command (format "xournalpp --create-img %s %s" tempfile xoppfile)) (with-temp-buffer (insert-file tempfile) (buffer-string) #+end_src Something seems to go wrong during the export, however, where a new attachment directory is created. Is my assumption that the export will run with =point= at the link incorrect? All other feedback on the implementation would be much appreciated, I seem to repeat myself way more than should be necessary. Regards, Tarjei Bærland
Re: Custom link type that attaches file in :follow
Hello, Tarjei Bærland writes: > Something seems to go wrong during the export, however, where a new > attachment directory is created. Is my assumption that the export will > run with =point= at the link incorrect? Yes, this assumption is incorrect. The export process operates on a parse tree, and doesn't need to move point at all. Current buffer is not even the original buffer. You may use hooks that are run before parsing happens, i.e., `org-export-before-parsing-hook' and `org-export-before-processing-hook. I didn't look at your export function, so take my advice with a grain of salt. Regards, -- Nicolas Goaziou
Re: wip-cite status question and feedback
Hello, "Bruce D'Arcus" writes: > Maybe since Nicolas has been around lately, he can weigh in? I guess I can make a summary about the current state of the citations branch, i.e., what is done, what is missing. There are three major steps to complete in order to add citations in Org: defining the syntax, designing the Org API for citation processors, and writing a default processor. The syntax is complete in "wip-cite-new" branch. For the record, in its full glory, it can look like this: [cite/style: global prefix; prefix -@key suffix ; ... ; global suffix] "/style", "global prefix", "prefix", "-" marker, "suffix" and "global suffix" are all optional. So, in its minimal form, it can be as simple as: [cite:@Doe:1995a] The syntax also includes a new #+bibliography keyword, which, when paired with a new `org-cite-global-bibliography', defines global or local bibliographies. For exporting needs, I also introduced #+print_bibliography, #+citation_style and #+bibliography_style keywords. Now about the API, which is partly implemented on a local branch. Citations processors, in addition to any tools they may provide, can integrate into Org in three distinct areas: opening (with `org-open-at-point'), fontification, and export. - "opening" action is straightforward. All is needed for the processor is to provide a function accepting two arguments: the citation key, as a string, and possibly a universal argument, which it may ignore, or not. All this is already implemented locally. - "exporting" action is trickier, because there are multiple ways to do the integration, and, since I'm not an implementor for citation processors, I don't have an accurate view about what is the best design. Anyway, here is the First, export happens as pre-process, before export back-ends are introduced. IOW, export back-ends are never going to see a citation object, which means no support whatsoever is needed on their end. Support export requires two functions. The first function is responsible for rendering a bibliography. Its arguments are the list of citations in the document, the list of bibliography files, the style, if any, and the export back-end. It should return a string. The second mandatory function is obviously responsible for rendering citations. It is called with a citation object, the desired style, if any, and the export back-end, the full list of citations objets in the document, and the list of bibliography files. It should also return a string. Org provides a helper function to determine the footnote containing a citation (and its label, or number) from a citation object. In the functions described above, I don't know if the arguments are sufficient. I would love to hear about citeproc-org and org-ref developers about this. Also, note that style is an indication. Export is requested to handle regular [cite:...] syntax. Unknown styles should fall-back to this. - "fontification" is meant to give full access to face selection, what is really displayed, additional keymaps, all using a single function. At the moment, I have no idea about what arguments would be useful. I think John Kitchin gave ideas about this already on this ML. I have to re-read his posts on the subject. In any case, feedback welcome. This not implemented yet. A citation processor does not need to provide integration in all these areas. Users may be able to mix and match processors. This is another (minor) point which is yet to be designed. How is a user supposed to select a processor for each integration area? It could be done through three variables, e.g., (setq org-cite-display-processor 'org-ref) (setq org-cite-export-processor 'citeproc) (setq org-cite-follow-processor 'default) I think it is unlikely for a user to locally select "display" and "follow" processors. However, we need a way to use a local export processor for a given document. I may need to introduce a #+citation_processor keyword during export. Any other idea? The last step is implementing a default processor. The point is to provide a self-contained, very basic processor handling all three areas described above. I started implementing one. It relies on built-in bibtex.el library, so it assumes bibliography is written as a BibTex file. At the moment it properly "follows" citations. It also exports citations as (Name, date). However, it doesn't export bibliographies yet. It does not fontify either. As a conclusion, besides the syntax, the branch is not ready for inclusion yet. There are a few design questions about the API to answer. Once done, and as long as no one has high expectations about the default processor, this last part should not be too hard to complete. Regards, -- Nicolas Goaziou
Bug: TexInfo exporter doesn't handle list items in a footnote [9.4.5 (release_9.4.5-283-gbf98b1 @ /home/rameshnedunchezian/src/org-mode/lisp/)]
(Resending my earlier mail. My internet connection flip-flopped while sending
the previous email.)
See the attached files. Export works fine with html and odt, btw.
Here is the relevant node.
(info "(texinfo) Footnotes")
lists-in-footnote.texi:4: warning: @settitle missing argument
lists-in-footnote.texi:11: warning: @title missing argument
lists-in-footnote.texi:33: misplaced }
lists-in-footnote.texi:22: @bye seen before @footnote closing brace
\input texinfo@c -*- texinfo -*-
@c %**start of header
@setfilename lists-in-footnote.info
@settitle
@documentencoding UTF-8
@documentlanguage en
@c %**end of header
@finalout
@titlepage
@title
@author Ramesh Nedunchezian
@end titlepage
@contents
@ifnottex
@node Top
@top
Emacs completion is based on the @strong{minibuffer}. Helm completion is
based on the @strong{completion window}.@footnote{See
@itemize
@item
@uref{https://github.com/emacs-helm/helm/issues/495, Different way of invoking commands}
@item
@uref{https://github.com/emacs-helm/helm/issues/222, Lack of tab completion}
@item
@uref{https://groups.google.com/g/emacs-helm/c/zaBbg2tFAuM, Finding files}
@end itemize}
@end ifnottex
@bye
lists-in-footnote.org
Description: Lotus Organizer
Bug: TexInfo exporter doesn't handle list items in a footnote [9.4.5 (release_9.4.5-283-gbf98b1 @ /home/rameshnedunchezian/src/org-mode/lisp/)]
See the attached files. Export works fine with html and odt, btw.
Here is the relevant node.
(info "(texinfo) Footnotes")
lists-in-footnote.texi:4: warning: @settitle missing argument
lists-in-footnote.texi:11: warning: @title missing argument
lists-in-footnote.texi:33: misplaced }
lists-in-footnote.texi:22: @bye seen before @footnote closing brace
\input texinfo@c -*- texinfo -*-
@c %**start of header
@setfilename lists-in-footnote.info
@settitle
@documentencoding UTF-8
@documentlanguage en
@c %**end of header
@finalout
@titlepage
@title
@author Ramesh Nedunchezian
@end titlepage
@contents
@ifnottex
@node Top
@top
Emacs completion is based on the @strong{minibuffer}. Helm completion is
based on the @strong{completion window}.@footnote{See
@itemize
@item
@uref{https://github.com/emacs-helm/helm/issues/495, Different way of invoking commands}
@item
@uref{https://github.com/emacs-helm/helm/issues/222, Lack of tab completion}
@item
@uref{https://groups.google.com/g/emacs-helm/c/zaBbg2tFAuM, Finding files}
@end itemize}
@end ifnottex
@bye
lists-in-footnote.org
Description: Lotus Organizer
Re: [Patch] to correctly sort the items with emphasis marks in a list
Nicolas Goaziou writes: > I cannot reproduce it. With your initial list, and a minimal init file, > I get: > > - /a/ > - a > - b > - /v/ > > Could you try with a minimal Emacs, too? That's weird ... I have tried launching emacs -q in a virtual machine, and I keep getting the wrong result (git version, master branch): - /a/ - /v/ - a - b I have tried with the typical keyboard shortcut and also with M-: and evaluating (org-sort-list t? a nil nil nil) Best regards, Juan Manuel
Re: [Patch] to correctly sort the items with emphasis marks in a list
This is my result after doing "org-sort-list a": - /a/ - /v/ - a - b Regards
Re: wip-cite status question and feedback
Dear All, thank you very much for bringing this forward and thanks to Nicholas for his work and detailed write-up on the API! Unfortunately, I'm extremely busy right now, but will try to comment in detail on the coming days, most probably on Thursday. I'm very excited by the new developments! best regards, András On Mon, 12 Apr 2021 at 15:19, Nicolas Goaziou wrote: > > Hello, > > "Bruce D'Arcus" writes: > > > Maybe since Nicolas has been around lately, he can weigh in? > > I guess I can make a summary about the current state of the citations > branch, i.e., what is done, what is missing. > > There are three major steps to complete in order to add citations in > Org: defining the syntax, designing the Org API for citation processors, > and writing a default processor. > > The syntax is complete in "wip-cite-new" branch. For the record, in its > full glory, it can look like this: > > [cite/style: global prefix; prefix -@key suffix ; ... ; global suffix] > > "/style", "global prefix", "prefix", "-" marker, "suffix" and "global > suffix" are all optional. So, in its minimal form, it can be as simple > as: > > [cite:@Doe:1995a] > > The syntax also includes a new #+bibliography keyword, which, when > paired with a new `org-cite-global-bibliography', defines global or > local bibliographies. > > For exporting needs, I also introduced #+print_bibliography, > #+citation_style and #+bibliography_style keywords. > > Now about the API, which is partly implemented on a local branch. > > Citations processors, in addition to any tools they may provide, can > integrate into Org in three distinct areas: opening (with > `org-open-at-point'), fontification, and export. > > - "opening" action is straightforward. All is needed for the processor > is to provide a function accepting two arguments: the citation key, > as a string, and possibly a universal argument, which it may ignore, > or not. > > All this is already implemented locally. > > - "exporting" action is trickier, because there are multiple ways to > do the integration, and, since I'm not an implementor for citation > processors, I don't have an accurate view about what is the best > design. Anyway, here is the > > First, export happens as pre-process, before export back-ends are > introduced. IOW, export back-ends are never going to see a citation > object, which means no support whatsoever is needed on their end. > > Support export requires two functions. The first function is > responsible for rendering a bibliography. Its arguments are the list > of citations in the document, the list of bibliography files, the > style, if any, and the export back-end. It should return a string. > > The second mandatory function is obviously responsible for rendering > citations. It is called with a citation object, the desired style, > if any, and the export back-end, the full list of citations objets > in the document, and the list of bibliography files. It should also > return a string. Org provides a helper function to determine the > footnote containing a citation (and its label, or number) from > a citation object. > > In the functions described above, I don't know if the arguments are > sufficient. I would love to hear about citeproc-org and org-ref > developers about this. > > Also, note that style is an indication. Export is requested to > handle regular [cite:...] syntax. Unknown styles should fall-back to > this. > > - "fontification" is meant to give full access to face selection, what > is really displayed, additional keymaps, all using a single > function. > > At the moment, I have no idea about what arguments would be useful. > I think John Kitchin gave ideas about this already on this ML. > I have to re-read his posts on the subject. In any case, feedback > welcome. > > This not implemented yet. > > A citation processor does not need to provide integration in all these > areas. Users may be able to mix and match processors. This is another > (minor) point which is yet to be designed. How is a user supposed to > select a processor for each integration area? It could be done through > three variables, e.g., > > (setq org-cite-display-processor 'org-ref) > (setq org-cite-export-processor 'citeproc) > (setq org-cite-follow-processor 'default) > > I think it is unlikely for a user to locally select "display" and > "follow" processors. However, we need a way to use a local export > processor for a given document. I may need to introduce > a #+citation_processor keyword during export. Any other idea? > > The last step is implementing a default processor. The point is to > provide a self-contained, very basic processor handling all three areas > described above. > > I started implementing one. It relies on built-in bibtex.el library, so > it assumes bibliography is written as a BibTex file. At the moment it > properly
Bug: HTML export of src_c{*foo} inserts a stray comma (,) before *foo [9.4 (9.4-31-g49f4c3-elpa @ /home/davemarq/.emacs.d/elpa/org-20201109/)]
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.
Exporting this small file to HTML
#+PROPERTY: header-args :exports code
Set src_c{*foo} to 1.
yields, after all the prolog CSS,
Set ,*foo to 1.
Note the comma (,) before "*foo".
I dig "git bisect" on the source tree, running "make" then "make
vanilla" then exporting for each release tag from release_9.4 back to
release_8.3. The comma persisted. I gave up when I built release_8.2
but the "vanilla" make target no longer existed.
Emacs : GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.27, cairo version 1.16.0)
of 2021-03-27
Package: Org mode version 9.4 (9.4-31-g49f4c3-elpa @
/home/davemarq/.emacs.d/elpa/org-20201109/)
current state:
==
(setq
org-duration-format 'h:mm
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-latex-listings t
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-enforce-todo-dependencies t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-latex-pdf-process '("pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f"
"pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f"
"pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f")
org-agenda-files '("~/org/aix.org" "~/org/ibm.org" "~/pers/personal.org")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-modules '(ol-bbdb ol-bibtex ol-docview ol-eww ol-gnus ol-info ol-irc
ol-mhe ol-rmail ol-w3m)
org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
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)
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-mime-src-mode-hook '(org-mime-src-mode-configure-edit-buffer)
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 '((emacs-lisp . t) (gnuplot . t) (ditaa . t) (dot .
t) (mscgen . t))
org-clock-clocktable-default-properties '(:maxlevel 2 :scope file :formula %)
org-export-backends '(org odt icalendar gfm md html beamer latex ascii)
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-agenda-loop-over-headlines-in-active-region nil
org-icalendar-include-todo t
org-occur-hook '(org-first-headline-recenter)
org-log-into-drawer t
org-agenda-include-diary t
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO(t)" "WAIT(w@)" "|" "DONE(d)"
"CANCELED(c@)"))
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-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("w3m" :store
org-w3m-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("eww" :follow org-eww-open :store org-eww-store-link)
("docview" :fo
BUG?: Are TAGs case sensitive? ('org-agenda-show-tags')
I have been using upper-case TAGs and just noticed that 'org-agenda-show-tags' is reporting them in lower-case which is not right since I have another TAG that is the lower-case version of the upper-case TAG (sort of a visual importance indicator). -- David Masterson
Re: Bug: HTML export of src_c{*foo} inserts a stray comma (,) before *foo [9.4 (9.4-31-g49f4c3-elpa @ /home/davemarq/.emacs.d/elpa/org-20201109/)]
After I filed this I got the bright idea to try exporting to Github
Flavored Markdown and ASCII text. In all cases, src_c{*foo} was
exported as ",*foo". So this has something to do with export C code or
code in general. It could still be a backend issue if these backends
share code.
---
On Mon, Apr 12 2021, Dave Marquardt wrote:
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.
Exporting this small file to HTML
#+PROPERTY: header-args :exports code
Set src_c{*foo} to 1.
yields, after all the prolog CSS,
Set ,*foo to 1.
Note the comma (,) before "*foo".
I dig "git bisect" on the source tree, running "make" then "make
vanilla" then exporting for each release tag from release_9.4 back to
release_8.3. The comma persisted. I gave up when I built release_8.2
but the "vanilla" make target no longer existed.
Emacs : GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.27, cairo version 1.16.0)
of 2021-03-27
Package: Org mode version 9.4 (9.4-31-g49f4c3-elpa @
/home/davemarq/.emacs.d/elpa/org-20201109/)
current state:
==
(setq
org-duration-format 'h:mm
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-latex-listings t
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-enforce-todo-dependencies t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-latex-pdf-process '("pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f"
"pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f"
"pdflatex -shell-escape -interaction nonstopmode
-output-directory %o %f")
org-agenda-files '("~/org/aix.org" "~/org/ibm.org" "~/pers/personal.org")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-modules '(ol-bbdb ol-bibtex ol-docview ol-eww ol-gnus ol-info ol-irc
ol-mhe ol-rmail ol-w3m)
org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
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)
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-mime-src-mode-hook '(org-mime-src-mode-configure-edit-buffer)
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 '((emacs-lisp . t) (gnuplot . t) (ditaa . t) (dot .
t) (mscgen . t))
org-clock-clocktable-default-properties '(:maxlevel 2 :scope file :formula %)
org-export-backends '(org odt icalendar gfm md html beamer latex ascii)
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-agenda-loop-over-headlines-in-active-region nil
org-icalendar-include-todo t
org-occur-hook '(org-first-headline-recenter)
org-log-into-drawer t
org-agenda-include-diary t
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO(t)" "WAIT(w@)" "|" "DONE(d)"
"CANCELED(c@)"))
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-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("w3m" :store
org-w3m-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :
Is it possible to #+include: src blocks and tangle them too?
I have been wanting to include a number of small Common Lisp snippets in individual files which I then include into a "master" .org file using: #+include: "snippet.org" src lisp Within snippet.org I have a src block such as: #+NAME: hello_test #+BEGIN_SRC lisp :tangle yes (defun hello () :hello) #+END_SRC Ideally I would like to have some specific comments that will be part of the Literate Program I would develop from these individual files. However, it seems as though tangling doesn't work. Export does. I read somewhere that this is not possible in orgmode. Is this true? And if not, can you point me to the right documentation? Many thanks. Rama Lakshmanan
Re: Bug: HTML export of src_c{*foo} inserts a stray comma (,) before *foo [9.4 (9.4-31-g49f4c3-elpa @ /home/davemarq/.emacs.d/elpa/org-20201109/)]
Hello,
Dave Marquardt writes:
> After I filed this I got the bright idea to try exporting to Github
> Flavored Markdown and ASCII text. In all cases, src_c{*foo} was
> exported as ",*foo". So this has something to do with export C code or
> code in general. It could still be a backend issue if these backends
> share code.
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: Is it possible to #+include: src blocks and tangle them too?
Hello, Ramachandran Lakshmanan writes: > I have been wanting to include a number of small Common Lisp snippets in > individual files which I then include into a "master" .org file using: > > #+include: "snippet.org" src lisp > > Within snippet.org I have a src block such as: > [...] > I read somewhere that this is not possible in orgmode. Is this true? And > if not, can you point me to the right documentation? #+include is a keyword specific to export. I doubt it would work with tangling out of the box. However, you may try calling `org-export-expand-include-keyword' from `org-babel-pre-tangle-hook'. Untested. Regards, -- Nicolas Goaziou
Re: Bug: HTML export of src_c{*foo} inserts a stray comma (,) before *foo [9.4 (9.4-31-g49f4c3-elpa @ /home/davemarq/.emacs.d/elpa/org-20201109/)]
Thanks!
---
On Mon, Apr 12 2021, Nicolas Goaziou wrote:
Hello,
Dave Marquardt writes:
> After I filed this I got the bright idea to try exporting to Github
> Flavored Markdown and ASCII text. In all cases, src_c{*foo} was
> exported as ",*foo". So this has something to do with export C code or
> code in general. It could still be a backend issue if these backends
> share code.
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: Bug: TexInfo exporter doesn't handle list items in a footnote [9.4.5 (release_9.4.5-283-gbf98b1 @ /home/rameshnedunchezian/src/org-mode/lisp/)]
Hello, Ramesh Nedunchezian writes: > See the attached files. Export works fine with html and odt, btw. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [Patch] to correctly sort the items with emphasis marks in a list
Hi Ypo, Ypo writes: > This is my result after doing "org-sort-list a": > > - /a/ > - /v/ > - a > - b > > Regards Thanks for trying. So it seems that you can reproduce the problem as well... I wonder if anyone else is able to reproduce it, preferably in a minimal emacs. Best regards, Juan Manuel
Re: [Patch] to correctly sort the items with emphasis marks in a list
probably not a relevant non-confirmation but in recent maint, my config: - a - /a/ - b On 4/12/21, Juan Manuel Macías wrote: > Hi Ypo, > > Ypo writes: > >> This is my result after doing "org-sort-list a": >> >> - /a/ >> - /v/ >> - a >> - b >> >> Regards > > Thanks for trying. So it seems that you can reproduce the problem as > well... I wonder if anyone else is able to reproduce it, preferably in a > minimal emacs. > > Best regards, > > Juan Manuel > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Is it possible to #+include: src blocks and tangle them too?
Nicolas Goaziou writes: > Hello, > > Ramachandran Lakshmanan writes: > >> I have been wanting to include a number of small Common Lisp snippets in >> individual files which I then include into a "master" .org file using: >> >> #+include: "snippet.org" src lisp >> >> Within snippet.org I have a src block such as: >> > > [...] > >> I read somewhere that this is not possible in orgmode. Is this true? And >> if not, can you point me to the right documentation? > > #+include is a keyword specific to export. I doubt it would work with > tangling out of the box. I tried it but didn’t get it to work. As solution I turned to autotools: Variable definitions: https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/configure.ac?ref=9b6d7459f2b1#L40 AC_SUBST_FILE(tabelle_kernantriebe) tabelle_kernantriebe=$srcdir/tabelle-kernantriebe.org Replacement definition: https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/configure.ac?ref=9b6d7459f2b1#L69 AC_CONFIG_FILES([chargen.org]) Usage: https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?ref=9b6d7459f2b1#L552 @tabelle_kernantriebe@ Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Bug: TexInfo exporter doesn't handle list items in a footnote [9.4.5 (release_9.4.5-283-gbf98b1 @ /home/rameshnedunchezian/src/org-mode/lisp/)]
On 13/04/21 4:08 am, Nicolas Goaziou wrote: > Hello, > > Ramesh Nedunchezian writes: > >> See the attached files. Export works fine with html and odt, btw. > > Fixed. Thank you. Verified. Thank you.
