Re: [PATCH] Customizify org-babel-fortran-compiler
Hello, Timothy writes: > Thanks for sending in the patch. Seeing it pointed out, this seems like > a pretty obvious omission. This looks like it should be pretty easy to > merge :) > > Four minor niggles with your commit message: > + Since `defvar' and `defcustom' are elisp symbols, they should be > quoted as such. > + It's probably better to avoid shorthand like "X -> Y", and write out > "Change X to Y" instead. > + You have included "lisp/" in the commit subject, which isn't needed. > Just "ob-fortran.el" or even "ob-fortran" is enough here. > + Your commit subject goes over 50 chars, which is undesirable. > > Here's what I'd recommend: > > #+begin_example > ob-fortran: Use a defcustom for fortran compiler > > * lisp/ob-fortran.el (org-babel-fortran-compiler): Change `defvar' to > `defcustom' > so that the fortran compiler is customizable like almost all other org-babel > compilers. > #+end_example > > This is rather minor though, I mention this mostly as a note for the > future :) Thanks. I went ahead, applied the patch with your recommendation, added a :package-version keyword, and pushed. Thanks. Regards, -- Nicolas Goaziou
Re: [patch] add :url and :doi optional entries for export to BiBTeX
Hello, Eric S Fraga writes: > On Thursday, 1 Jul 2021 at 22:23, Timothy wrote: >> I've not used Org for exporting to BibTeX, so I don't really know what >> I'm on about, but is there any particular reason why only some entries >> have :url ? Other than that, this seems like a fairly straightforward >> patch. > > First of all, it's an optional entry so only exported if present. What > I did was consider which types of publications would tend to have > a URL instead of other bibliographic information and only include for > those where it would likely necessary. For instance, journal articles > will be given a DOI so a URL is less useful; technical reports, > however, are likely to be hosted at an institution's web site so a URL > is likely useful. > > But I must admit that I didn't spend much time thinking about which > ones should have it. I didn't want all of them because I often store > the URL for a journal article in the org file just for quick access > but I do not want it exported to BiBTeX as it would be messy and > superfluous when the paper were cited. > > I'm glad the patch seemed straightforward! Thank you. Applied. Thanks to both of you. Regards, -- Nicolas Goaziou
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Fri, 2 Jul 2021 00:01:59 +0700 > > --- a/lisp/net/mailcap.el > +++ b/lisp/net/mailcap.el > @@ -1177,7 +1177,23 @@ See \"~/.mailcap\", `mailcap-mime-data' and related > files and variables." > (shell-quote-argument (convert-standard-filename file)) > command > nil t)) > -(start-process-shell-command command nil command))) > +;; Handlers such as "gio open" and kde-open5 start viewer in background > +;; and exit immediately. Avoid `start-process' since it assumes > +;; :connection-type 'pty and kills children processes with SIGHUP > +;; when temporary terminal session is finished (Bug#44824). > +;; An alternative is `process-connection-type' let-bound to nil for > +;; `start-process-shell-command' call (with no chance to report failure). > +(make-process > + :name "mailcap-view-file" :connection-type 'pipe :noquery t > + :buffer nil ; "*Messages*" may be suitable for debugging > + :sentinel (lambda (proc event) > + (when (and (memq (process-status proc) '(exit signal)) > +(/= (process-exit-status proc) 0)) > + (message > +"Command %s: %s." > +(mapconcat #'identity (process-command proc) " ") > +(substring event 0 -1 > + :command (list shell-file-name shell-command-switch command I have two issues with this change: First, you replace start-process-shell-command with make-process, and I'm not sure I understand why. If all you want is to use pipes, why not simply bind process-connection-type around the call to start-process-shell-command? Does it not work for some reason? And second, I'm not sure we should make this change unconditionally. It isn't guaranteed that the handler will be one of those which have the problem, is it? And with other handlers, this could be an incompatible behavior change if the handler behaves differently when its standard handles are connected to a pipe rather than a terminal device. So I'd rather make this a conditional change, ideally only when one of the affected handlers is used (assuming we can detect that somehow). Thanks.
Re: getting "before first headline at position xxx in buffer *Org Note*" when clocking out
Hello Timothy On Thu, 1 Jul 2021 at 21:12, Timothy wrote: > > Thanks for going to the effort of working out a series of steps to > reproduce the issue, it's most helpful. If you wouldn't mind, do you > think you could try testing the current HEAD/master and seeing if you > still encounter the issue? I tried the steps on the current master, and I was not able to reproduce this. I think this has been already fixed https://orgmode.org/list/CAP=AKM_MLob51bZx85CtpjDtLNfc+HOe4Ki8xsdmw=ezvhd...@mail.gmail.com/ -- Bhavin Gandhi (bhavin192) | https://geeksocket.in
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
On 01/06/2021 13:56, Lars Ingebrigtsen wrote: So I've now added this to Emacs 28 under the name `mailcap-view-file'. I am attaching a patch similar to proposed to Org mode that should help to avoid obscure failures of viewers due to unnecessary terminal sessions. >From de55b623810736df04641a4d8f6027ccb04caa7f Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Thu, 1 Jul 2021 23:41:16 +0700 Subject: [PATCH] mailcap.el: Avoid xdg-open silent failure * lisp/net/mailcap.el (mailcap-view-file): Use 'pipe :connection-type instead of 'pty to prevent killing of background process on handler exit. Avoid regression similar to Bug#44824. Problem happens only in some desktop environments where mailcap handler launches actual viewer (as defined in .desktop files and obtained from mimeapps.list) in background. E.g. xdg-open invokes "gio open" or kde-open5 for Gnome or KDE accordingly and these handlers launch e.g. eog or okular in background. As soon as main process exits, temporary terminal session created by `start-process-shell-command' is terminated. As a result background processes receive SIGHUP. Previously command were executed with no buffer as well, so the change does not affect "needsterminal" and "copiousoutput" mailcap features, they are not supported as earlier. If main process of the handler fails then show a message with exit reason. Output (including error messages) is ignored as before. Gtk applications tend to report significant amount of failed asserts hardly informative for majority of users. --- lisp/net/mailcap.el | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el index 54f7f416ab..a53e385662 100644 --- a/lisp/net/mailcap.el +++ b/lisp/net/mailcap.el @@ -1177,7 +1177,23 @@ See \"~/.mailcap\", `mailcap-mime-data' and related files and variables." (shell-quote-argument (convert-standard-filename file)) command nil t)) -(start-process-shell-command command nil command))) +;; Handlers such as "gio open" and kde-open5 start viewer in background +;; and exit immediately. Avoid `start-process' since it assumes +;; :connection-type 'pty and kills children processes with SIGHUP +;; when temporary terminal session is finished (Bug#44824). +;; An alternative is `process-connection-type' let-bound to nil for +;; `start-process-shell-command' call (with no chance to report failure). +(make-process + :name "mailcap-view-file" :connection-type 'pipe :noquery t + :buffer nil ; "*Messages*" may be suitable for debugging + :sentinel (lambda (proc event) + (when (and (memq (process-status proc) '(exit signal)) +(/= (process-exit-status proc) 0)) + (message +"Command %s: %s." +(mapconcat #'identity (process-command proc) " ") +(substring event 0 -1 + :command (list shell-file-name shell-command-switch command (provide 'mailcap) -- 2.25.1
Re: how to use complex excel formula in org
Just an idea (especially given I havent touched Excel formulae for a v. long time): Have you considered using (G)awk? It could be possible to build up a list of arrays containing data and formulae and then perform as result in the end block. It could get onerous to do and may be hackish/bespoke but Awk can be quite satisfying a tool. Im sure somebody is sitting on a more correct approach however. Jonathan McHugh indieterminacy@libre.brussels July 1, 2021 6:31 PM, "Uwe Brauer" wrote: > Hi > > I currently have to collaborate with an excel file that contains quite a > bit of complex formula. I cannot simply import the file via > xlsx-->csv-->org > > Since csv does no know about excel formulas. > > Does anybody know about a tool a trick to use that excel formula. > > Regards > > Uwe Brauer
how to use complex excel formula in org
Hi I currently have to collaborate with an excel file that contains quite a bit of complex formula. I cannot simply import the file via xlsx-->csv-->org Since csv does no know about excel formulas. Does anybody know about a tool a trick to use that excel formula. Regards Uwe Brauer
Re: Bug: clock-in from org-agenda freezes thread when enforce + todo keywords [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Marking as a patch for Woof.
csv2xlsx problems Ubuntu and MacOS 10.15
Hi I usually use gnumeric, to export to xlsx (org-->csv-->xlsx), but I cannot use gnumeric in my MacOS 10.15 and that is why I tried out csv2xlsx. While xlsx2csv works reasonable well, I have difficulties with csv2xlsx, either in Ubutunu 16.04 with python 3.5 or MacOS with python 3.8. So does anybody use xlsx2csv (googling show my various candidates, so far only https://github.com/hyogeunpark/csv2xlsx.git works but not the one I install via pip Regards Uwe Brauer
Re: allow HTML block to escape from outline-text div? WAS: BUG? unable to surround subtrees with html tag
Matt Price writes: >> I would like to be able to surround some portion of a subtree with a tag, > Sorry for the noise, I believe this is user error. I misread the exported > source code, and firefox's developer tools added the closing tag for me, so > I kept not seeing my mistake. The error here was not realizing that section > contents get wrapped in their own div with class ~outline-text-N~, so my > ~~ resulted in malformed HTML. > > I don't know if there is a way to somehow slide my own html in between the > outine-text element and the outline-container element for a child subtree. > If someone knows a way to do this, I'd appreciate a pointer, but for now I > think I have to find another way to accomplish this. As it so happens, this is something which has come up for me too. I think in the future it could be worth adding a property that can be used to wrap a section in certain HTML tag(s). For now though... the best solution would be what Richard suggests. -- Timothy
Re: [patch] add :url and :doi optional entries for export to BiBTeX
On Thursday, 1 Jul 2021 at 22:23, Timothy wrote: > I've not used Org for exporting to BibTeX, so I don't really know what > I'm on about, but is there any particular reason why only some entries > have :url ? Other than that, this seems like a fairly straightforward > patch. First of all, it's an optional entry so only exported if present. What I did was consider which types of publications would tend to have a URL instead of other bibliographic information and only include for those where it would likely necessary. For instance, journal articles will be given a DOI so a URL is less useful; technical reports, however, are likely to be hosted at an institution's web site so a URL is likely useful. But I must admit that I didn't spend much time thinking about which ones should have it. I didn't want all of them because I often store the URL for a journal article in the org file just for quick access but I do not want it exported to BiBTeX as it would be messy and superfluous when the paper were cited. I'm glad the patch seemed straightforward! Thank you. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-570-g7666d6 : Latest paper written in org: https://arxiv.org/abs/2106.05096
Re: prettify-symbols-mode in org agenda?
Hi Ihor, This thread is looking promising! Just wondering if you might have time to respond to William's latest reply? -- Timothy
Re: getting "before first headline at position xxx in buffer *Org Note*" when clocking out
Hi Dave, Thanks for going to the effort of working out a series of steps to reproduce the issue, it's most helpful. If you wouldn't mind, do you think you could try testing the current HEAD/master and seeing if you still encounter the issue? -- Timothy Dave D writes: > Hi all, > > I recently started getting the message "before first headline at position > xxx in buffer *Org Note*" when clocking out items. > > After much frustration and testing I've summarized these steps to reproduce > the issue. > > 1. Download https://orgmode.org/org-9.4.6.tar.gz and extract to ~/org-9.4.6 > 2. Start emacs with emacs -Q > I've tried both 27 and 28, 28 has native comp. same result. > 3. evaluate (add-to-list 'load-path "~/org-9.4.6/lisp") > 4. create a new org file, create a heading and clock in > 5. evaluate (setq org-log-note-clock-out t) > 6. clock out. > > I think there is a good chance another person can reproduce the issue too > with the steps above. > Would anybody be kind enough to try to reproduce the issue? > > Many thanks > Dave -- Timothy
Re: [PATCH] Customizify org-babel-fortran-compiler
Marking as closed in favour of 2nd email.
Re: [PATCH] Customizify org-babel-fortran-compiler
Hi Nico, Thanks for sending in the patch. Seeing it pointed out, this seems like a pretty obvious omission. This looks like it should be pretty easy to merge :) Four minor niggles with your commit message: + Since `defvar' and `defcustom' are elisp symbols, they should be quoted as such. + It's probably better to avoid shorthand like "X -> Y", and write out "Change X to Y" instead. + You have included "lisp/" in the commit subject, which isn't needed. Just "ob-fortran.el" or even "ob-fortran" is enough here. + Your commit subject goes over 50 chars, which is undesirable. Here's what I'd recommend: #+begin_example ob-fortran: Use a defcustom for fortran compiler * lisp/ob-fortran.el (org-babel-fortran-compiler): Change `defvar' to `defcustom' so that the fortran compiler is customizable like almost all other org-babel compilers. #+end_example This is rather minor though, I mention this mostly as a note for the future :) -- Timothy Nico Sonack writes: > Hey there, > > I've been using org-mode for quite a while already and am pretty > happy with it! > > Today I noticed a minor oddity, that occured when I tried to run some > Fortran code with org-babel: it failed with the compiler not being > found. Looking at the custom variables of the org-babel group, I was > unable to find a compiler option for Fortran. Thus, I quickly patched > the ob-fortran.el and turned the defvar of > `org-babel-fortran-compiler' into a defcustom such that it is a little > more consistent with the rest of the org-babel languages. > > The patch is attached to this mail. Please let me know if I should > correct anything. > > Nico
Re: [patch] add :url and :doi optional entries for export to BiBTeX
Hi Eric, I've not used Org for exporting to BibTeX, so I don't really know what I'm on about, but is there any particular reason why only some entries have :url ? Other than that, this seems like a fairly straightforward patch. -- Timothy Eric S Fraga writes: > I introduced an error in the previous patch. Please use this one. > Thank you, > eric
Re: BUG: org-lint reports macros defined in org-export-global-macros as undefined
Hi Michael, > I have a lot of global macros defined in org-export-global-macros. Wherever > they are used in my org files org-lint reports them as undefined. > > It seems that org-lint just checks against org-macro-templates (collected > with (org-macro-initialize-templates)) and a few default macros. Unfortunately I have yet to look at the internals of org-lint, so I can't provide any particular insight, but this does seem like something which should be supported. Hopefully someone else will have time to look into this :) -- Timothy
Re: [PATCH] Fix erroneous tangling of blocks
Hello, Timothy writes: > I've just taken a look at your patch and it looks good :) glad to see > you've also followed the commit message format. I hope this gets merged > soon. Applied. Thanks for the patch, and thanks for the review. Regards, -- Nicolas Goaziou
Re: [PATCH] Fix erroneous tangling of blocks
HI Jacopo, I've just taken a look at your patch and it looks good :) glad to see you've also followed the commit message format. I hope this gets merged soon. -- Timothy p.s. Just a little note for the future: it's good if you have full sentences in the description of the changes. Jacopo De Simoi writes: > Dear All, > > Please find attached a patch (against master) which takes care of the > following issue. Assume I have a block like this > > #+begin_src sh :tangle no > This should not be tangled > #+end_src > > Then the block is correctly ignored when tangling the whole file, but > erroneously tangled (to a file named "no") when tangling is run with the > universal argument (so that only the current block should be tangled) > > This happens because the check for the "no" option is not performed when > tangling a single block. In the proposed patch I address this issue by > checking for the "no" option in the function org-babel-effective-tangled- > filename
Re: org-mode-map binds [tab]
Hello, Daniel Mendler writes: > `org-mode-map` binds `[tab]` which is unnecessary and harmful, since it > takes precendence over bindings of TAB even in keymaps with higher > precedence. Thou shalt not have precedence over Org mode! Fixed. Thank you! Regards, -- Nicolas Goaziou
[PATCH] Fix erroneous tangling of blocks
Dear All, Please find attached a patch (against master) which takes care of the following issue. Assume I have a block like this #+begin_src sh :tangle no This should not be tangled #+end_src Then the block is correctly ignored when tangling the whole file, but erroneously tangled (to a file named "no") when tangling is run with the universal argument (so that only the current block should be tangled) This happens because the check for the "no" option is not performed when tangling a single block. In the proposed patch I address this issue by checking for the "no" option in the function org-babel-effective-tangled- filenameFrom 4ae3b326750e094b359de5c920cc9695edbea16d Mon Sep 17 00:00:00 2001 From: Jacopo De Simoi Date: Wed, 30 Jun 2021 23:33:56 -0400 Subject: [PATCH 2/2] ob-tangle.el: Parse correctly tangle options * lisp/ob-tangle.el (org-babel-effective-tangled-filename): Check for the "no" parameter in this function to avoid erroneous tangling of a single block (e.g. with C-u C-c C-v t) even with the parameter :tangle no TINYCHANGE --- lisp/ob-tangle.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 02379d44e..585020364 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -359,6 +359,7 @@ as computed by `org-babel-tangle-single-block'." ((string= "yes" src-tfile) ;; Use the buffer name (file-name-sans-extension buffer-fn)) +((string= "no" src-tfile) nil) ((> (length src-tfile) 0) src-tfile))) (ext (or (cdr (assoc src-lang org-babel-tangle-lang-exts)) src-lang))) (when base-name -- 2.31.1 attachment.asc Description: PGP signature
Bug: org-mode-map binds tab [9.4.6 (9.4.6-gab9f2a @ /home/user/.config/emacs/elpa/org-9.4.6/)]
`org-mode-map` binds `[tab]` which is unnecessary and harmful, since it takes precendence over bindings of TAB even in keymaps with higher precedence. Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0) of 2021-02-09, modified by Debian Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ /home/user/.config/emacs/elpa/org-9.4.6/) I've observed this problem with my GNU ELPA package Corfu, which installs a keymap with higher precedence than org-mode. In order to override Org, it also has to bind [tab], which is undesired. On 6/27/21 11:11 AM, Daniel Mendler wrote: > On 6/26/21 4:02 PM, Stefan Monnier wrote: >>> +(define-key map [tab] #'corfu-complete) >> >> Please avoid binding `tab`: the `tab` event (only generated under GUIs) >> is supposed to be remapped to the TAB char-event (aka `C-i`) and this is >> what you should bind to if you want your binding to work both under ttys >> and GUIs. >> >> More importantly, if you bind to `tab` than this binding will take >> precedence over all other bindings to TAB, even those in keymaps that >> have higher precedence. >> >> The same holds for `return` vs RET, and `escape` vs ESC. > > Hello Stefan, > > I am aware of the unfortunate implications of these bindings. > Originally I avoided these bindings for the exact reasons you mention > and I hoped I could do without those (only binding RET/TAB and > remappings). However I have to use these keys since Org-mode seems to > override these keys too. Otherwise my keymap will not take precedence > over the Org-mode keymap. > > Daniel >
[PATCH} Do not throw error when parameter of :tangle is not a string
Dear All, in the current master branch, if the parameter :tangle of a src block is not a string, tangling fails by throwing an error when calling `file-name- directory' This patch checks if the parameter is a string before calling `file-name-directory'. This makes construct such as :tangle (when condition-applies "filename") work again (as they did a few versions ago…) Thanks for your time Best JacopoFrom f08ecdb79ec71ecc94fe006043bd8eacc8ac41a0 Mon Sep 17 00:00:00 2001 From: Jacopo De Simoi Date: Mon, 28 Jun 2021 15:42:29 -0400 Subject: [PATCH 1/2] ob-tangle.el: Handle non-string arguments more gracefullu * lisp/ob-tangle.el (org-babel-tangle-single-block): If the argument to :tangle is nil (e.g. when parsing conditional tangling such as (when condition "yes") the current code throws an error in `file-name-directory'. This commit checks if the argument is a string before calling the fun TINYCHANGE --- lisp/ob-tangle.el | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 562776ae8..02379d44e 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -469,6 +469,7 @@ non-nil, return the full association list to be used by (match-end 0) (point-min (point) + (src-tfile (cdr (assq :tangle params))) (result (list start-line (if org-babel-tangle-use-relative-file-links @@ -476,11 +477,12 @@ non-nil, return the full association list to be used by file) (if (and org-babel-tangle-use-relative-file-links (string-match org-link-types-re link) - (string= (match-string 1 link) "file")) + (string= (match-string 1 link) "file") + (stringp src-tfile)) (concat "file:" (file-relative-name (substring link (match-end 0)) (file-name-directory - (cdr (assq :tangle params) + src-tfile))) link) source-name params @@ -489,8 +491,7 @@ non-nil, return the full association list to be used by (org-trim (org-remove-indentation body))) comment))) (if only-this-block -(let* ((src-tfile (cdr (assq :tangle (nth 4 result - (file-name (org-babel-effective-tangled-filename +(let* ((file-name (org-babel-effective-tangled-filename (nth 1 result) src-lang src-tfile))) (list (cons file-name (list (cons src-lang result) result))) -- 2.31.1 attachment.asc Description: PGP signature
Re: Export Org mode files to (gag, barf) MS Office?
Brandon Taylor writes: I know we’re not supposed to really even TALK about proprietary software in FOSS communities like this one, but I can’t help but wonder if someone might consider making (an) Emacs plugin(s) that allow(s) a user to export Org mode files to Microsoft Office file formats such as .docx, .xlsx and the like? Or is/are there already (a) plugin(s) in the MELPA that can do this? Brandon Taylor Sent from Mail for Windows 10 The ox-pandoc package works here for .docx, running on Linux - here are the settings I use, but you may have to experiment (use-package ox-pandoc :defer 7 :config (setq org-pandoc-options '((standalone . t)) ;; cancel above settings only for 'docx' format org-pandoc-options-for-docx '((standalone . nil)) ;; special settings for beamer-pdf and latex-pdf exporters org-pandoc-options-for-beamer-pdf '((pdf-engine . "xelatex")) org-pandoc-options-for-latex-pdf '((pdf-engine . "xelatex" atb Glyn
org-mode-map binds [tab]
`org-mode-map` binds `[tab]` which is unnecessary and harmful, since it takes precendence over bindings of TAB even in keymaps with higher precedence. Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0) of 2021-02-09, modified by Debian Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ /home/user/.config/emacs/elpa/org-9.4.6/) I've observed this problem with my GNU ELPA package Corfu, which installs a keymap with higher precedence than org-mode. In order to override Org, it also has to bind [tab], which is undesired. On 6/27/21 11:11 AM, Daniel Mendler wrote: > On 6/26/21 4:02 PM, Stefan Monnier wrote: >>> +(define-key map [tab] #'corfu-complete) >> >> Please avoid binding `tab`: the `tab` event (only generated under GUIs) >> is supposed to be remapped to the TAB char-event (aka `C-i`) and this is >> what you should bind to if you want your binding to work both under ttys >> and GUIs. >> >> More importantly, if you bind to `tab` than this binding will take >> precedence over all other bindings to TAB, even those in keymaps that >> have higher precedence. >> >> The same holds for `return` vs RET, and `escape` vs ESC. > > Hello Stefan, > > I am aware of the unfortunate implications of these bindings. > Originally I avoided these bindings for the exact reasons you mention > and I hoped I could do without those (only binding RET/TAB and > remappings). However I have to use these keys since Org-mode seems to > override these keys too. Otherwise my keymap will not take precedence > over the Org-mode keymap. > > Daniel >
Re: Export Org mode files to (gag, barf) MS Office?
Hi Brandon, * Brandon Taylor wrote: > --_000_SA1PR13MB4799DBE017BDC4DA869BA10BA2059SA1PR13MB4799namp_ > Content-Type: text/plain; charset="Windows-1252" > Content-Transfer-Encoding: quoted-printable > > I know we=92re not supposed to really even TALK about proprietary software = > in FOSS communities like this one, but I can=92t help but wonder if someone= > might consider making (an) Emacs plugin(s) that allow(s) a user to export = > Org mode files to Microsoft Office file formats such as .docx, .xlsx and th= > e like? Or is/are there already (a) plugin(s) in the MELPA that can do this= > ? If you go down the pandoc path and you need to comply with company templates and such, you might want to read https://karl-voit.at/2017/12/17/pandoc-docx-reference/ where you can place a docx file at a specific path and you end up with nice end results. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
