Re: [O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]
Attached patch I didn't realize that org-protocol-capture is documented for URLs, since the concept of capturing through org-protocol is useful for non-web browser contexts. Anyway, I'm not interested in updating the documentation for org-protocol-capture at the moment, but even if org-protocol-capture is documented to need a URL, it seems wrong for it to corrupt org-stored-links but otherwise function correctly if a URL was not provided. On Tue, Dec 11, 2018 at 7:18 PM Allen Li wrote: > > Using Org protocol capture without supplying a URL inserts a corrupt > entry into org-stored-links (nil ""). The nil causes a type error later > in org-insert-link. > > (defun org-protocol-do-capture (info) > "Perform the actual capture based on INFO." > (let* ((temp-parts (org-protocol-parse-parameters info)) > (parts > (cond >((and (listp info) (symbolp (car info))) info) >((= (length (car temp-parts)) 1) ;; First parameter is exactly one > character long > (org-protocol-assign-parameters temp-parts '(:template :url :title > :body))) >(t > (org-protocol-assign-parameters temp-parts '(:url :title :body) > (template (or (plist-get parts :template) >org-protocol-default-template-key)) > (url (and (plist-get parts :url) (org-protocol-sanitize-uri (plist-get > parts :url > (type (and url (string-match "^\\([a-z]+\\):" url) (match-string 1 url))) > (title (or (plist-get parts :title) "")) > (region (or (plist-get parts :body) "")) > (orglink (if url > (org-make-link-string >url (if (string-match "[^[:space:]]" title) title url)) > title)) > (org-capture-link-is-already-stored t)) ;; avoid call to org-store-link > (setq org-stored-links > (cons (list url title) org-stored-links)) > > > Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) > of 2018-07-05 > Package: Org mode version 9.1.14 (9.1.14-1059-gadec50-elpaplus @ > /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/) From 112ef17dec8aa7dfaba5d6ee0018d8fe3b6639e6 Mon Sep 17 00:00:00 2001 From: Allen Li Date: Tue, 11 Dec 2018 19:32:56 -0800 Subject: [PATCH] org-protocol: Don't corrupt org-stored-link if url is nil * lisp/org-protocol.el (org-protocol-do-capture): Handle nil case. --- lisp/org-protocol.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el index c0eb52c2b..81ab47698 100644 --- a/lisp/org-protocol.el +++ b/lisp/org-protocol.el @@ -503,8 +503,8 @@ Now template ?b will be used." url (if (string-match "[^[:space:]]" title) title url)) title)) (org-capture-link-is-already-stored t)) ;; avoid call to org-store-link -(setq org-stored-links - (cons (list url title) org-stored-links)) +(when url + (push (if (string= title "") (list url) (list url title)) org-stored-links)) (org-store-link-props :type type :link url :description title -- 2.20.0
[O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]
Using Org protocol capture without supplying a URL inserts a corrupt entry into org-stored-links (nil ""). The nil causes a type error later in org-insert-link. (defun org-protocol-do-capture (info) "Perform the actual capture based on INFO." (let* ((temp-parts (org-protocol-parse-parameters info)) (parts (cond ((and (listp info) (symbolp (car info))) info) ((= (length (car temp-parts)) 1) ;; First parameter is exactly one character long (org-protocol-assign-parameters temp-parts '(:template :url :title :body))) (t (org-protocol-assign-parameters temp-parts '(:url :title :body) (template (or (plist-get parts :template) org-protocol-default-template-key)) (url (and (plist-get parts :url) (org-protocol-sanitize-uri (plist-get parts :url (type (and url (string-match "^\\([a-z]+\\):" url) (match-string 1 url))) (title (or (plist-get parts :title) "")) (region (or (plist-get parts :body) "")) (orglink (if url (org-make-link-string url (if (string-match "[^[:space:]]" title) title url)) title)) (org-capture-link-is-already-stored t)) ;; avoid call to org-store-link (setq org-stored-links (cons (list url title) org-stored-links)) Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-07-05 Package: Org mode version 9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)
[O] Org-Publish of a PDF ??
Have a question about org-publish-project. I have a bunch of org files
that work fine and I've been able to publish my project to PDF fine, but
I'd like to refine the setting, but I can't find the documentation for
what I want. Basically, I have the following:
(setq org-publish-project-alist
'(("pdfDrop"
:base-directory "~/directory1/"
:base-extension "org"
:publishing-directory "~/directory2/"
:publishing-function org-latext-publish-to-pdf)))
When I publish my project, I find that my org files are first generated
into tex and pdf files in directory1 and then the tex/pdf files are
copied to directory2. What I would like is for the tex/pdf files to be
directly generated in directory2 with no "extras" in directory1.
My reason is that I sync my directory1 to other (backup) locations and I
would rather not pick up the extras or have to modify the sync to know
and ignore what is extra which could change from time to time.
Why isn't this documented better in the Org documentation?
--
David
Re: [O] ODT export --> opening in Okular?
On Tue, 11 Dec 2018 01:00:15 +0800 wrote
> Check your ~/.mailcap and/or /etc/mailcap file as well: there are indeed
> many twisty passages through org-open-file, so you may end up calling
> whatever the system has set up (correctly or not).
> Nick
Aha, that was the answer. Apparently installing Okular adds this bit of
silliness into /etc/mailcap:
application/vnd.oasis.opendocument.text; okular %s --icon okular -caption
Okular; test=test -n "$DISPLAY"
... which I find now has also been reported to Debian as a bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857443
I still think it's insane, but at least now it's clear where the insanity lies:
with Okular's inflated sense of self-importance :D
But, what I still don't understand is, after adding an ODT entry to
org-file-apps, why did org revert to querying mailcap...?
Value: ((auto-mode . emacs)
("\\.mm\\'" . default)
("\\.x?html?\\'" . "/usr/bin/firefox %s")
("\\.odt\\'" . "/usr/bin/libreoffice6.0 %s")
("\\.pdf\\'" . "/usr/bin/okular %s"))
Original value was
((auto-mode . emacs)
("\\.mm\\'" . default)
("\\.x?html?\\'" . default)
("\\.pdf\\'" . default))
... this has exactly zero effect. Org ignores the odt line here, where I would
expect an org-specific preference setting to override the system default.
hjh
Re: [O] Bug: org-map-entries narrowing smaller than entry [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]
On Tue, Dec 11, 2018 at 8:27 AM Nicolas Goaziou wrote: > > (((headline (:raw-value "stuff" :begin 17 :end 36 :pre-blank 0 > > :contents-begin 26 :contents-end 36 ...)) 17 35)) > > `org-element-at-point' ignores narrowing. Yes, but my issue is with the fact that the entry bounds reported by org-element-at-point disagrees with the bounds used by org-map-entries narrowing, in specific edge cases. For example, when running org-map-entries on a tree, the bounds reported by org-element-at-point can be used *except* for the last entry, which will extend one character past the narrowing. It seems to me that whatever Org mode considers the bounds for an entry should be used consistently. I looked into this and it seems this behavior is deliberate in org-narrow-to-subtree. I can see why this behavior exists, because if point is at the end of an entry (after the newline), it is considered to be pointing at the next entry. Thus the narrowing is artificially tightened to make it impossible to position point at the end of an entry. Example, the bounds of an entry/subtree delimited by $: * A $* B ** foo ** bar $* C The bounds used by narrowing: * A $* B ** foo ** bar$ * C If one were to narrow to a subtree and delete the entire visible region, it would leave an extra newline that should be considered part of the deleted subtree. If such an operation were repeated, it would leave behind many extra newlines. I think this issue is medium/low priority and difficult to resolve. I have worked around it for my use case. However, I still think it is an issue since it's an edge case that users of org-map-entries will need to take into account. > > Regards, > > -- > Nicolas Goaziou
Re: [O] Bug: org-map-entries narrowing smaller than entry [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]
Hello, Allen Li writes: > org-map-entries narrows the buffer to narrower than the given entry. > > 1. Run: cat > /tmp/tmp.org < * some headline > ** stuff > some text > ** asdf asdf > EOF > > 2. emacs -Q > 3. M-g M-g 2 RET > 4. M-: (org-map-entries (lambda () (list (org-element-at-point) > (point-min) (point-max))) nil 'tree) RET > > Actual: > > (((headline (:raw-value "stuff" :begin 17 :end 36 :pre-blank 0 > :contents-begin 26 :contents-end 36 ...)) 17 35)) `org-element-at-point' ignores narrowing. Regards, -- Nicolas Goaziou
Re: [O] Quoting of macros with eval
Hello,
Jens Lechtenboerger writes:
> Hi there,
>
> given a macro like
>
> #+MACRO: foo (eval (message "%s" $1))
>
> I need to call {{{foo("text")}}} with Org mode 9.1.14-9-g131531-elpa.
>
> On the master branch, that call will include the quotation marks as
> part of the string, so I need to call {{{foo(text)}}} (documented in
> the manual, but I didn’t notice that until now).
>
> Could the master branch offer backward compatible functionality,
> please? I’m thinking about checking for and removing leading and
> trailing quotation marks...
A simple function replacing such occurrences should be easy to write.
I suggest to do that.
It is in "Incompatible changes" for a reason :)
Regards,
--
Nicolas Goaziou
Re: [O] [PATCH] ox.el: Define subtitle macro
Hello, Jens Lechtenboerger writes: > Hi there, > > On 2017-11-21, Nicolas Goaziou wrote: > >> For the record, I implemented a "keyword" macro (master branch). > > That has been in master for over a year now. Are there plans for > inclusion in a release? (Or did I overlook that?) master branch is meant to be released... at some point. For the record, I cannot do it myself. Regards, -- Nicolas Goaziou
[O] Quoting of macros with eval
Hi there,
given a macro like
#+MACRO: foo (eval (message "%s" $1))
I need to call {{{foo("text")}}} with Org mode 9.1.14-9-g131531-elpa.
On the master branch, that call will include the quotation marks as
part of the string, so I need to call {{{foo(text)}}} (documented in
the manual, but I didn’t notice that until now).
Could the master branch offer backward compatible functionality,
please? I’m thinking about checking for and removing leading and
trailing quotation marks...
Best wishes
Jens
Re: [O] [PATCH] ox.el: Define subtitle macro
Hi there, On 2017-11-21, Nicolas Goaziou wrote: > For the record, I implemented a "keyword" macro (master branch). That has been in master for over a year now. Are there plans for inclusion in a release? (Or did I overlook that?) Best wishes Jens
