Re: Feature request
Am Mon, 18 Jan 2021 10:17:11 +0800 schrieb Ihor Radchenko : > Raoul Comninos writes: > > > It works now and its awesome! I cannot believe that they had this > > feature and removed it. I am a very happy man and I cannot thank > > you enough. > > This feature creates a lot of junk text when attachment folder gets > very large. For example, I keep my travel photos as attachments. > There can be hundreds of photos in a single attachment folder. > Showing all the photo names in a property would be not very useful. > > On the other hand, if more people are interested, this feature can be > resurrected as a user-option (disabled by default). As an option I would use it! Detlef > > Best, > Ihor > >
Re: Custom Bulk Functions With Prompt
Kevin Foley writes: > +(`(,_ ,f) > +(when (listp f) > + (let ((args (funcall (nth 1 f))) > +(func (nth 0 f))) > +(setq f (apply #'apply-partially func args > +(setq cmd f) (setq redo-at-end t)) That will not work. pcase will not even match list of 3+ elements using `(,_ ,f): (pcase '(a b c) (`(,_ ,f) (if (listp f) "List!" "Not list!")) (_ "No match!")) => "No match!" You need to add extra matcher `(,_ ,argf ,f). Best, Ihor
Re: self-referencing babel shell code blocks
On Sun, Jan 17, 2021 at 07:12:21PM -0500, John Kitchin wrote: > I guess this is what you mean: > > > * heading L1_12 > ** heading L2_37 > > #+name: this-block > #+header: :var VAR1=(getenv "HOSTNAME") > #+header: :var VAR2=(message user-login-name) [more good stuff elided] Not the OP here, but... thanks a bunch! You just saved me a few hours of hair pulling. Cheers - t signature.asc Description: Digital signature
Re: [BUG] [C-u C-u C-c C-o] open link with external program invalid to open file
On 05/09/2020 14:52, Bastien wrote:
stardiviner writes:
When I press =[C-u C-u C-c C-o]= to open an image file link with system external
program. It can't open the image file.
I cannot reproduce the problem here.
If you still have this issue, can you provide a minimal reproducible
example?
Christopher Miles recently posted a link to askubuntu that shed some
light on the problem.
I have compared the following commands:
(start-process-shell-command "xdg-open" nil "xdg-open
/usr/share/icons/gnome/256x256/actions/stock_print.png")
(start-process-shell-command "eog" nil "eog
/usr/share/icons/gnome/256x256/actions/stock_print.png")
The latter works in my (test) case (Ubuntu-20.04, ubuntu session -
gnome), the former does not. If I do not mistake,
start-process-shell-command is what org mode uses to open file.
Meaningful lines from strace of the emacs process
24108 21:39:51 execve("/bin/bash", ["/bin/bash", "-c", "xdg-open
/usr/share/icons/gnome/"...], 0x7ffcb1c1fdb0 /* 55 vars */
24116 21:39:51 execve("/usr/bin/eog", ["eog",
"/usr/share/icons/gnome/256x256/a"...], 0x55d009672ec8 /* 57 vars */
24108 21:39:51 +++ exited with 0 +++
24116 21:39:51 +++ killed by SIGHUP +++
I think, the problem is that start-process-shell-command creates a "pty"
process. As soon as main command exits, all children, that belong to the
same terminal session created by emacs for the process, got killed.
Calling eog directly works because of it does not attempt to go to
background or demonize.
The solution could be (make-process :connection-type 'pipe ...).
Personally I would prefer to avoid shell as well when it is not really
necessary.
I am surprised that in the discussion of problem related to desktop
integration and perhaps even order in which applications able to handle
particular file format were installed, nobody mentioned such details,
neither for "positive" nor for "negative" results. Probably output of
the following commands (for the proper mime type) could be relevant. The
complication is that there are several mime handler "databases".
grep image/png /etc/mailcap ~/.mailcap
xdg-mime query default image/png
(mailcap-parse-mailcaps)
(mailcap-mime-info "image/png")
For some handlers there might be even a race, sometimes it might work
but might fail as well, depending if child could send a message to its
server quickly enough. In such case providing of ECM might be a challenge.
Re: Why are (UU)IDs limited to the headline level?
aroz...@gmail.com writes: > I'm just getting into Emacs/Org-Mode. It's clearly an amazing system and > the linking via UUID is very useful. My question is: why is linking by UUID > (and, more generally, the creation of properties drawers) limited to > headlines, and not to sub-elements like list elements or paragraphs? > Doesn't all the necessary structural information exist to assign UUIDs to > everything? > > The reason I'm asking is that getting into Org-Roam, the linking for which > relies on Org UUIDs for headlines. If UUIDs were available for all elements > of an Org file, that will allow for more granular linking behavior. You can use <> to make it possible to link to any place in a document. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Why are (UU)IDs limited to the headline level?
"Dr. Arne Babenhauserheide" writes: > You can use <> to make it possible to link to any > place in a document. It does not work globally though. One cannot just put [[id:some-anchor-name]] link in other file. Best, Ihor
Re: [BUG] [C-u C-u C-c C-o] open link with external program invalid to open file
Maxim, thanks for your detailed explanation.
I confirmed the problem:
#+begin_src emacs-lisp
;;; does not work
(start-process-shell-command "xdg-open" nil "xdg-open
/usr/share/icons/gnome/256x256/actions/stock_print.png")
;;; works fine
(start-process-shell-command "feh" nil "feh
/usr/share/icons/gnome/256x256/actions/stock_print.png")
#+end_src
For this problem, do you have any workable solution patch?
Here is my =/etc/mailcap=, don't have =~/.mailcap=.
#+begin_src conf
###
### Begin Red Hat Mailcap
###
audio/*; /usr/bin/xdg-open %s
image/*; /usr/bin/xdg-open %s
application/msword; /usr/bin/xdg-open %s
application/pdf; /usr/bin/xdg-open %s
application/postscript ; /usr/bin/xdg-open %s
text/html; /usr/bin/xdg-open %s ; copiousoutput
#+end_src
Maxim Nikulin writes:
> On 05/09/2020 14:52, Bastien wrote:
>>
>> stardiviner writes:
>>
>>> When I press =[C-u C-u C-c C-o]= to open an image file link with system
>>> external
>>> program. It can't open the image file.
>>
>> I cannot reproduce the problem here.
>>
>> If you still have this issue, can you provide a minimal reproducible
>> example?
>
> Christopher Miles recently posted a link to askubuntu that shed some
> light on the problem.
>
> I have compared the following commands:
>
> (start-process-shell-command "xdg-open" nil "xdg-open
> /usr/share/icons/gnome/256x256/actions/stock_print.png")
> (start-process-shell-command "eog" nil "eog
> /usr/share/icons/gnome/256x256/actions/stock_print.png")
>
> The latter works in my (test) case (Ubuntu-20.04, ubuntu session -
> gnome), the former does not. If I do not mistake,
> start-process-shell-command is what org mode uses to open file.
>
> Meaningful lines from strace of the emacs process
>
> 24108 21:39:51 execve("/bin/bash", ["/bin/bash", "-c", "xdg-open
> /usr/share/icons/gnome/"...], 0x7ffcb1c1fdb0 /* 55 vars */
> 24116 21:39:51 execve("/usr/bin/eog", ["eog",
> "/usr/share/icons/gnome/256x256/a"...], 0x55d009672ec8 /* 57 vars */
>
> 24108 21:39:51 +++ exited with 0 +++
> 24116 21:39:51 +++ killed by SIGHUP +++
>
> I think, the problem is that start-process-shell-command creates a "pty"
> process. As soon as main command exits, all children, that belong to the
> same terminal session created by emacs for the process, got killed.
>
> Calling eog directly works because of it does not attempt to go to
> background or demonize.
>
> The solution could be (make-process :connection-type 'pipe ...).
> Personally I would prefer to avoid shell as well when it is not really
> necessary.
>
> I am surprised that in the discussion of problem related to desktop
> integration and perhaps even order in which applications able to handle
> particular file format were installed, nobody mentioned such details,
> neither for "positive" nor for "negative" results. Probably output of
> the following commands (for the proper mime type) could be relevant. The
> complication is that there are several mime handler "databases".
>
> grep image/png /etc/mailcap ~/.mailcap
> xdg-mime query default image/png
>
> (mailcap-parse-mailcaps)
> (mailcap-mime-info "image/png")
>
> For some handlers there might be even a race, sometimes it might work
> but might fail as well, depending if child could send a message to its
> server quickly enough. In such case providing of ECM might be a challenge.
--
[ stardiviner ]
I try to make every word tell the meaning that I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
signature.asc
Description: PGP signature
[PATCH] capture: Fix handling of time range for :time-prompt
Kyle Meyer writes: > I'm okay with the minimal fix to the regexp, though I wonder if we can > avoid the follow-up call to org-read-date-analyze entirely. I'm running > out of time to test thoroughly tonight, but perhaps something like this > (ignoring the potential cond->if cleanup): Testing that against the cases in your initial report, I believe it leads to the same results as your patch, so here's a cleaned-up version. -- >8 -- Subject: [PATCH] capture: Fix handling of time range for :time-prompt * lisp/org-capture.el (org-capture-set-target-location): Bind org-end-time-was-given around the org-read-date call to get a return value that uses the start time rather than doing custom adjustment of the return value. If org-capture-set-target-location detects that the answer to org-read-date has a time range, it strips the end time from the answer and calls org-read-date-analyze again. (org-read-date already calls it underneath.) The regexp it uses, however, can easily match a date, leading to a bogus result. org-read-date-analyze is already capable of processing the time range in a way that matches org-capture-set-target-location's intent: when org-end-time-was-given is bound, org-read-date-analyze splits off the end value of the range and stores it in org-end-time-was-given. Drop the custom logic and let org-read-date-analyze handle the range. Reported-by: Richard Lawrence Ref: https://orgmode.org/list/87h7obh4ct.fsf@aquinas --- lisp/org-capture.el | 35 +++ 1 file changed, 15 insertions(+), 20 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index f40f2b335..d7b69f228 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -1025,28 +1025,23 @@ (defun org-capture-set-target-location (&optional target) (time-to-days org-overriding-default-time)) ((or (org-capture-get :time-prompt) (equal current-prefix-arg 1)) - ;; Prompt for date. - (let ((prompt-time (org-read-date - nil t nil "Date for tree entry:"))) + ;; Prompt for date. Bind `org-end-time-was-given' so + ;; that `org-read-date-analyze' handles the time range + ;; case and returns `prompt-time' with the start value. + (let* ((org-time-was-given nil) + (org-end-time-was-given nil) + (prompt-time (org-read-date + nil t nil "Date for tree entry:"))) (org-capture-put :default-time - (cond ((and (or (not (boundp 'org-time-was-given)) - (not org-time-was-given)) - (not (= (time-to-days prompt-time) (org-today -;; Use 00:00 when no time is given for another -;; date than today? -(apply #'encode-time 0 0 - org-extend-today-until - (cl-cdddr (decode-time prompt-time - ((string-match "\\([^ ]+\\)-[^ ]+[ ]+\\(.*\\)" - org-read-date-final-answer) -;; Replace any time range by its start. -(apply #'encode-time - (org-read-date-analyze -(replace-match "\\1 \\2" nil nil - org-read-date-final-answer) -prompt-time (decode-time prompt-time - (t prompt-time))) + (if (and (or (not org-time-was-given)) + (not (= (time-to-days prompt-time) (org-today + ;; Use 00:00 when no time is given for another + ;; date than today? + (apply #'encode-time 0 0 + org-extend-today-until + (cl-cdddr (decode-time prompt-time))) +prompt-time)) (time-to-days prompt-time))) (t ;; Current date, possibly corrected for late night base-commit: 9e8215f4a5df7d03ac787da78d28f69a4c18e7d3 -- 2.29.2
How can I keep Org-id links from breaking when moving files?
This question is in the context of using Org-id UUIDs for linking between files. If I understand correctly, Org-id knows where to look for UUIDs (generated by org-id-get-create) by looking at the org-id-locations variable. But what if I move an .org file that I've generated a UUID into another folder? I know I can run org-id-update-id-locations, and there's an org-id-extra-files variable, but is there a way to list all the folders on the system where Org-id should look for UUIDs? Thanks, Alan
