Re: Export from org-mode to latex from the commandline
Hi Sharon,
>
> Could this be customised to export from org-mode to latex, and then
> subsequently I build the pdf file from the already converted latex using
> my program 'pdfbuild'?
>
I'm not sure how helpful this is, but I have a small "project" that I
include with other projects that use git for version control. This
contains a shell script (used as a git-post-commit hook, in my case)
as well as an elisp script called under --batch mode. Together, these
export README.org into README.{md, pdf, txt} each time I check in a
give project that uses them. I suspect these might not be too
difficult to adapt to your use-case.
https://git.sr.ht/~mplscorwin/org-git-hooks
HTH
Corwin
Re: Unable to get current or via use-package
On 10 February 2022 17:57, João Pedro de Amorim Paula wrote: > I had a similar issue in the recent past and was able to come up with a > solution using the built-in package.el. Not sure how to make it work > with use-package, but that at least seems to solve the issue of it not > installing the ELPA version. Forgot to add the link to my previous email, oops! https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00062.html -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: Unable to get current or via use-package
On 09 February 2022 16:51, "Loris Bennett" wrote: > Thanks, that did the trick. I was hoping that when I use the same > init.el on a different machine I wouldn't have to remember anything and > use-package would automatically install the latest version. Seemingly > not :-/ I had a similar issue in the recent past and was able to come up with a solution using the built-in package.el. Not sure how to make it work with use-package, but that at least seems to solve the issue of it not installing the ELPA version. Not really sure if the version installed is the one that Emacs actually uses, though, I am on Emacs 28.0.91 and all of the built-in packages I have are the same version as their ELPA counterpart, so Emacs seems to be prioritizing the built-in version. It could be that this is only the case because they're both the same version; and seem as I'm traveling ATM I couldn't test it against Emacs 27, so it would be great if you could check it. Cheers, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
[PATCH] two small fixes for org-fast-tag-selection
- The first patch fixes the problem of TODO keywords and tags sharing keys
when they are automatically generated and when
`org-fast-tag-selection-include-todo' is set.
- The problem solved by the second patch is the following: when invoking
the fast selection interface, and pressing the key of a tag, the tag is
highlighted to indicate it has been selected, but pressing the key again
doesn't unhighlight it.
From ec433003b77c17ae150c7c399142d9fad6bc5cab Mon Sep 17 00:00:00 2001
From: alexgiorev
Date: Thu, 10 Feb 2022 22:14:51 +0200
Subject: [PATCH 2/2] listp/org.el: unhighlight org-fast-tag-selection tag
* lisp/org.el (org-fast-tag-selection): When the key of a tag is
pressed in the fast selection tag interface, the tag is highlighted,
but when it is pressed again it is not unhighlighted. This patch fixes
this issue.
TINYCHANGE
---
lisp/org.el | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 6fb79f180..c43ac672d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12408,7 +12408,7 @@ Returns the new tags string, or nil to not change the current settings."
(ncol (/ (- (window-width) 4) fwidth))
(i-face 'org-done)
(c-face 'org-todo)
- tg cnt e c char c1 c2 ntable tbl rtn
+ tg cnt e c char c1 c2 ntable tbl rtn todo-marker
ov-start ov-end ov-prefix
(exit-after-next org-fast-tag-selection-single-key)
(done-keywords org-done-keywords)
@@ -12450,6 +12450,9 @@ Returns the new tags string, or nil to not change the current settings."
(unless (zerop cnt)
(setq cnt 0)
(insert "\n"))
+(when (eq tbl (cdr todo-table))
+ (setq todo-marker (point-marker))
+ (set-marker-insertion-type todo-marker nil))
(insert (if (cdr e) (format "%s: " (cdr e)) "") "{ "))
((eq (car e) :endgroup)
(setq ingroup nil cnt 0)
@@ -12505,6 +12508,8 @@ Returns the new tags string, or nil to not change the current settings."
(setq cnt 0)
(setq ntable (nreverse ntable))
(insert "\n")
+(unless todo-marker
+ (setq todo-marker (point-marker)))
(goto-char (point-min))
(unless expert (org-fit-window-to-buffer))
(setq rtn
--
2.25.1
From 120c4fd7d9038fdf22dfcfda7f021b0486813464 Mon Sep 17 00:00:00 2001
From: alexgiorev
Date: Thu, 10 Feb 2022 17:24:36 +0200
Subject: [PATCH 1/2] lisp/org.el: org-tag-fast-selection fix tag/TODO key
overlap
* lisp/org.el (org-tag-fast-selection): Avoid key duplication for tags
and TODO keywords when the keys are automatically generated.
TINYCHANGE
---
lisp/org.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index ef8d460e1..6fb79f180 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12480,8 +12480,8 @@ Returns the new tags string, or nil to not change the current settings."
(setq c1 (string-to-char
(downcase (substring
tg (if (= (string-to-char tg) ?@) 1 0)
- (if (or (rassoc c1 ntable) (rassoc c1 table))
- (while (or (rassoc char ntable) (rassoc char table))
+ (if (or (rassoc c1 ntable) (rassoc c1 fulltable))
+ (while (or (rassoc char ntable) (rassoc char fulltable))
(setq char (1+ char)))
(setq c2 c1))
(setq c (or c2 char)))
--
2.25.1
Re: [PATCH] lisp/org-capture.el: Add hook & hook options to org-capture (Valentin Herrmann)
fwiw... > I've implemented what you're proposing here (and much more) in a > package you may find useful a couple years ago. I pitched adopting > some of the ideas into org-mode proper and was willing to do the > work. My proposal was met with enthusiastic silence: > > https://www.github.com/progfolio/doct i've been using doct for a while, and have been very happy with it. (thanks for implementing it.) cheers, Greg
Re: Unable to get current or via use-package
Ihor Radchenko writes: > Tim Cross writes: > >>> Is that necessary? Can't I just use the package manager to update Org >>> along with any other packages? Or does the issue about not visiting and >>> .org file before installing via the package manager apply to updates >>> too? >>> >> >> Even with updates, it is still important that no existing org >> functionality has been loaded to avoid potential inconsistencies due to >> mixed version installation. For updates within the same version (i.e. >> bug fix updates), the risk is low, but may still result in an >> inconsistent build. > > It looks like there was an attempt to fix mixed compilation issue in > package.el See > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c13baa10d55ec863d3ceaea48c6b2959ece98198 > and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125 > > If I understand that thread correctly, package.el should not have issues > with mixed compilation. Not so sure about straight.el and certainly it > will not solve the problem when part of built-in Org is loaded before > the newer Org version is added to the load-path. > Thanks for the info. However, I'm not confident that has addressed the full issue. I note that patch is from 2014. There has certainly been a number of people report mixed installation problems since that patch would have been applied and part of their current version of package.el. As you point out, we don't know what happens with other package managers like straight.el and you are likely to get this issue if part of the built-in version has been loaded before package.el attempts to load the new version, so that might explain these later reports. Would seem the best approach and simplest solution is still to ensure no org functionality has been loaded before attempting an update.
RE: Unable to get current or via use-package
Hi Loris, > > I tend to use the org-mode from the package manager, but do not do it > > interactively from within emacs. Instead, which when I want to refresh org, > > I do from the command line: > > > > emacs -Q -batch -eval "(progn (require 'package) (package-initialize) > > (package-refresh-contents) (package-install 'org))" > > Is that necessary? Can't I just use the package manager to update Org > along with any other packages? Or does the issue about not visiting and > .org file before installing via the package manager apply to updates > too? AFAIK, what is necessary (though for reasons somewhat beyond my ken) is that org updates be installed in an environment in which no version of org has been loaded. You need some approach to ensure that. This is one such. Agreed it is heavy handed, but it suffices the need. I wish I could express the order dependencies in a reliable fashion with `use-package`. It *might* be the case that execution of the following snippet early enough in your init file is enough for `use-package` to "get it right"(tm). If you try this, let us know the outcome. > > Also, early in my init.el, as extra level of precaution against getting the > > built-in org-mode, I ensure it never gets loaded: > > (require 'cl-seq) (delete (car (cl-member "lisp/org" load-path :test > > #'string-match)) load-path) > > Interesting, although I would generally want at least some version of > Org even if a more recent version is installed but somehow broken. If you can code that logic in lisp, you can conditionally execute the provided snipped. /joke But I get your point. In my case, sometimes I want to run with a git pull from head of org repos rather than a package install. At such times I wind up editing my init file and use the `use-package`'s :load-path and :pin directives: :pin manual :load-path "~/.emacs.d/org-mode/lisp" ;; which was installed with: `cd ~/emacs.d && git clone https://git.savannah.gnu.org/git/emacs/org-mode.git && cd org-mode && make autoloads && make` ;; and can be updated with: `cd ~/emacs.d/org-mode && git pull && make autoloads && make` Point being that I have found that expressing the logic to cover every use case requires me to edit my init.el and interact with the command line "out of band", as it were. YMMV ~Malcolm
Re: Lazy load of org-protocol
On 10/02/2022 02:22, Jim Porter wrote: On 2/9/2022 8:46 AM, Max Nikulin wrote: On a related note, there is still an issue with `--eval' in some cases. It fails to work with emacsclient when invoking an alternate editor: emacsclient --alternate-editor emacs --eval '(message "hi")' If Emacs isn't already running, that will open a new buffer named '(message "hi")'. I think that's just a bug in how emacsclient handles `--eval', though fixing it would make org-protocol links work more reliably (if they used `--eval' as proposed, that is). emacsclient --alternate-editor '' --eval '(message "hi")' But it makes it harder to use it during debugging when -Q -L ~/src/org-mode/lisp options are required. Right, invoking the main Emacs instance as a daemon (i.e. when --alternate-editor is the empty string) works pretty differently from invoking the main Emacs instance directly (i.e. when --alternate-editor is "emacs" or somesuch). In the former case, emacsclient starts "emacs --daemon" and then tries to reconnect to the daemon; in the latter, it just takes the arguments passed to emacsclient and forwards them (well, some of them) to emacs. The end result is that it runs "emacs '(message "hi")'", which isn't correct. It looks like a bug. I believed that other application may be specified as --alternate-editor, so --eval arguments should not be passed to it. Actually I do not like --alternate-editor option at all. It is a single string, not an array of executable and options. It allows quotes but does not support escaping. On linux a solution is to start emacs daemon from systemd session as a socket-activated application.
Re: [PATCH] Fix FAQ entry about mailto links.
On 7 Feb 2022, at 10:59, Max Nikulin wrote:
Robert,
Thank you for pointing out that `org-link-mailto-program' should not
be recommended in FAQ any more.
I prepared an alternative patch that recommends to customize Emacs
variables at first. I hope, an example is safer now, however I can not
test it on MacOS. Could you, please, review the patch, since I may
miss something important from your point of view?
On 07/01/2022 18:03, Max Nikulin wrote:
On 07/01/2022 01:34, Robert Goldman wrote:
+You can also change the function used to a different one. For
+example, the following function (on MacOS) opens =mailto:= links in
+the =MailMate= program:
I am unsure if MailMate is acceptable since it is a proprietary
application. Org is a part of *GNU* Emacs, so it may be better to
mention some free mail user agent.
+#+begin_src elisp
+("mailto" :follow
^
It seems, `org-link-set-parameters' is missed.
I am sorry, I missed that you suggested to customize the
`org-link-parameters' variable, so function call is not necessary
here.
There are a couple of minor issues in the patch you sent (including a
couple of grammatical errors), so attached is a revision.
I'm afraid there are now multiple patch files.
Please note that I have requested clarification at several places in the
comment block.
Best,
R
From b8158af7a839a751e6976cd95d18a5d5f199024a Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman"
Date: Thu, 6 Jan 2022 12:27:59 -0600
Subject: [PATCH 1/4] Fix FAQ entry about mailto links.
The old entry referred to the variable =org-link-mailto-program= which
was removed from org-mode almost eight years ago! See org-mode commit
b9f2e17f07faf01109fc6f7f1eb5a34e0f97eafb
---
org-faq.org | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/org-faq.org b/org-faq.org
index 4b34560c..cac8063e 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1927,13 +1927,13 @@ For example:
#+index: Link!Mailto
You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+changing the entry for =mailto:= links in =org-link-parameters=:
-=M-x customize-variable org-link-mailto-program=
+=M-x customize-variable org-link-parameters=
The default function called is =browse-url=, which opens a mail
composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
+=browse-url= depends on the setting of the variable =mail-user-agent=.
Thus, if you want to ensure that mailto links use Gnus to open a
message buffer, you could add the following to your =.emacs=:
@@ -1941,6 +1941,18 @@ message buffer, you could add the following to your
=.emacs=:
(setq mail-user-agent 'gnus-user-agent)
#+end_src
+You can also change the function used to a different one. For
+example, the following function (on MacOS) opens =mailto:= links in
+the =MailMate= program:
+
+#+begin_src elisp
+("mailto" :follow
+ (lambda
+(path)
+(shell-command
+ (format "open -a MailMate 'mailto:%s'" path
+#+end_src
+
** Can I use CamelCase links?
:PROPERTIES:
:CUSTOM_ID: CamelCase-links
--
2.31.1
From e7f0f2c51950b3c0f181191c5210ea26cafc03f4 Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman"
Date: Thu, 10 Feb 2022 11:20:36 -0600
Subject: [PATCH 2/4] Revert "Fix FAQ entry about mailto links."
This reverts commit b8158af7a839a751e6976cd95d18a5d5f199024a.
---
org-faq.org | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/org-faq.org b/org-faq.org
index cac8063e..4b34560c 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1927,13 +1927,13 @@ For example:
#+index: Link!Mailto
You can customize the function org-mode uses to open mailto links by
-changing the entry for =mailto:= links in =org-link-parameters=:
+setting the variable =org-link-mailto-program=:
-=M-x customize-variable org-link-parameters=
+=M-x customize-variable org-link-mailto-program=
The default function called is =browse-url=, which opens a mail
composition buffer within Emacs. The type of buffer opened by
-=browse-url= depends on the setting of the variable =mail-user-agent=.
+browse-url depends on the setting of the variable =mail-user-agent=.
Thus, if you want to ensure that mailto links use Gnus to open a
message buffer, you could add the following to your =.emacs=:
@@ -1941,18 +1941,6 @@ message buffer, you could add the following to your
=.emacs=:
(setq mail-user-agent 'gnus-user-agent)
#+end_src
-You can also change the function used to a different one. For
-example, the following function (on MacOS) opens =mailto:= links in
-the =MailMate= program:
-
-#+begin_src elisp
-("mailto" :follow
- (lambda
-(path)
-(shell-command
- (format "open -a MailMate 'mailto:%s'" path
-#+end_src
-
** Can I use CamelCase links?
:PROPERTIES:
:CUSTOM_ID: CamelCase-links
--
2.31.1
From
Re: [BUG] Typo in manual [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Ignacio Casso writes: > I would like to report a minor typo in the manual, although I'm not sure > if this is the right place (please point me to it if it's not). Confirmed. And this is the right place to report this bug. Thanks! > In the section Appendix A Hacking -> Using the Mapping API > (https://orgmode.org/manual/Using-the-Mapping-API.html), it says that > org-map-entries returns an alist, but it actually returns a list (as > correctly stated by C-h f org-map-entries). To me this looks like the documentation in the manual started from the documentation of the function. and with time these two documentations diverged. What about removing the (diverged) duplication of the documentation of function org-map-entries from the manual?
Export from org-mode to latex from the commandline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 When you build the documentation from the org-mode git repository, something is calling emacs to build the documents in the background, but what? Where can I find that command please, because I want to try and use it to export org-mode to latex and then build a pdf file in the background, all from the commandline. Seeing the thread 'RE: Unable to get current or via use-package', Malcolm Cook suggests to use 'emacs -Q -batch -eval "(progn (require 'package) (package-initialize) (package-refresh-contents) (package-install 'org))"'. Could this be customised to export from org-mode to latex, and then subsequently I build the pdf file from the already converted latex using my program 'pdfbuild'? Thanks Sharon. - -- A taste of linux = http://www.sharons.org.uk Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.2 -BEGIN PGP SIGNATURE- iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmIE7iIdHGJvdWRpY2Nh c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1tTvxAAxZJA5r+OqQyBanqF LBxkXug+xFaV/eGoxF5aK/2mSvVMM0iF2G57C6B61liTZuqD19dilPZ9dxoR/tZT iBI0MiXGSX+wvDRhbIQA3cb43hkZbR/5PlgYctO0i1KysBgpHyxXBeM+QUpIB1eg YDq0f3SbI7YsidKnFwiRp5RLWGZS5hDjXxYRecnCav/jBEl+p2E3HppqN0DEkGGp S0gbQ0vrpoDw2w5RaEr7UAlwX/oOZSJdthTHZQlQo9K6Wq8NaRtf3a/bOfXiLywZ kxFeLfLHXJsaTNlChnV6nkJqgTJIp1ZpaoD9j8juf3YYHKCw5lzLBXSOku4rKYRF +R3cz0sZXf3XQw2kcsQ+wS4TVAVCN7KJESderqaMT7ZNp0eKPxbkzFEuOYhC+okr UAO8XDYbuKb20RxUN452Vz8BtedXwTjyXT4K8C/91AvnWKMVDqLPdp38yHAbRFb3 jh4bra1cQgso0ba5hWTIxE8UV0RcjwkU7pi1Kto33CwI4YALmvRQ1r9rBeT6RQSk m8RlI/q2lzRZpbEl6jR8yMmkkSg66lnqtGGEbNNInVk4talsC7VaWCCsWKcnprKL JDiR5SSRQGnu1aGnbVGl1+k/wdA88jsZo4rq3boYmM2CwcSz9NAYYtlT92fdfZ2p oY2usvkM/LBUkpr+JrZvM6O25e4= =cT7U -END PGP SIGNATURE-
[BUG] org-capture is not reentrant [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Hello,
I recently tried to use (org-capture '(4) key) (i.e., C-u prefix
argument GOTO, so not actually capturing anything, just
moving to the target) as part of the function passed as target for
another capture template, using file+function, as in the example below:
(setq org-capture-templates
'(("i" "Inner" entry
(file+headline "/tmp/foo.org" "Target")
"* Wrong Heading"
:immediate-finish t)
("o" "Outer" entry
(file+function "/tmp/foo.org" capture-target) ;;
"* It works!!"
:immediate-finish t)))
(defun capture-target ()
(org-capture '(4) "i"))
(org-capture nil "o")
The result was:
* Target
** Wrong heading
So it worked for moving point to the desired target, but it overwrote
other parts of the template. I took a quick look at the code and it
seems that a global property list is used internally for the capture
process, which seems to be only initialized at the start of the capture
process and therefore the inner capture would overwrite it in our
case. I saw also that the global property list is copied to a buffer
local property list for the case of starting a new capture process
before typing C-c C-c in the indirect capture buffer.
Do you think it would be easy to recycle that code to also have a stack
of property lists and allow reentrancy? Would yo consider it useful? I
would, but not really worth it to implement unless it's a low hanging
fruit. If it is, I'd volunteer to do so (although my elisp-fu may be a
little bit lacking yet).
Regards,
Ignacio
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20)
of 2022-01-16
Package: Org mode version 9.5.2 (9.5.2-gfbff08 @
/home/ignacio/.emacs.d/elpa/org-9.5.2/)
[BUG] Typo in manual [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]
Hello, I would like to report a minor typo in the manual, although I'm not sure if this is the right place (please point me to it if it's not). In the section Appendix A Hacking -> Using the Mapping API (https://orgmode.org/manual/Using-the-Mapping-API.html), it says that org-map-entries returns an alist, but it actually returns a list (as correctly stated by C-h f org-map-entries). Regards, Ignacio Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20) of 2022-01-16 Package: Org mode version 9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)
Re: Unable to get current or via use-package
Tim Cross writes: >> Is that necessary? Can't I just use the package manager to update Org >> along with any other packages? Or does the issue about not visiting and >> .org file before installing via the package manager apply to updates >> too? >> > > Even with updates, it is still important that no existing org > functionality has been loaded to avoid potential inconsistencies due to > mixed version installation. For updates within the same version (i.e. > bug fix updates), the risk is low, but may still result in an > inconsistent build. It looks like there was an attempt to fix mixed compilation issue in package.el See https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c13baa10d55ec863d3ceaea48c6b2959ece98198 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125 If I understand that thread correctly, package.el should not have issues with mixed compilation. Not so sure about straight.el and certainly it will not solve the problem when part of built-in Org is loaded before the newer Org version is added to the load-path. Best, Ihor
Re: Unable to get current or via use-package
Loris Bennett writes: > "Cook, Malcolm" writes: > >> >> emacs -Q -batch -eval "(progn (require 'package) (package-initialize) >> (package-refresh-contents) (package-install 'org))" > > Is that necessary? Can't I just use the package manager to update Org > along with any other packages? Or does the issue about not visiting and > .org file before installing via the package manager apply to updates > too? > Even with updates, it is still important that no existing org functionality has been loaded to avoid potential inconsistencies due to mixed version installation. For updates within the same version (i.e. bug fix updates), the risk is low, but may still result in an inconsistent build.
