Re: incorrect documentation for file-desc header argument?

[Kyle Meyer]

Matt Huszagh writes:

> The org info documentation states
>
>  The ‘file-desc’ header argument defines the description (see *note
>  Link Format::) for the link.  If ‘file-desc’ has no value, Org uses
>  the generated file name for both the “link” and “description” parts
>  of the link.
>
> However, if I evaluate the
>
> #+BEGIN_SRC asymptote :results value file :file circle.pdf :output-dir img/
>   size(2cm);
>   draw(unitcircle);
> #+END_SRC
>
> I get
>
> #+RESULTS:
> [[file:img/circle.pdf]]
>
> I believe the documentation (and this is corroborated by the discussion
> of the original patch
> (https://lists.gnu.org/archive/html/emacs-orgmode/2012-04/msg00022.html)),
> that the intended result is
>
> #+RESULTS:
> [[file:img/circle.pdf][file:img/circle.pdf]]
>
> Is my assessment correct? Can anyone else confirm this bug?

Yeah, that looks to be the intended result of that thread.  That
thread's patch was applied with a58a4f0ad (new source block header
argument :filelinkdescr, 2012-03-27).  However, shortly after, that
treatment was intentionally changed (670c7f31c, 2012-03-31):

simplified implementation of :file-desc header argument
  
This will no longer insert the value of the :file header argument as
the description if the description is left blank (as this changes
the meaning of the :file header argument).
  
The desc handling logic is moved to the `org-babel-result-to-file'
function.

So, I'd say this is a documentation bug.

Re: incorrect documentation for file-desc header argument?

[Matt Huszagh]

Matt Huszagh  writes:

> Hello,
>
> The org info documentation states
>
>  The ‘file-desc’ header argument defines the description (see *note
>  Link Format::) for the link.  If ‘file-desc’ has no value, Org uses
>  the generated file name for both the “link” and “description” parts
>  of the link.
>
> However, if I evaluate the
>
> #+BEGIN_SRC asymptote :results value file :file circle.pdf :output-dir img/
>   size(2cm);
>   draw(unitcircle);
> #+END_SRC
>
> I get
>
> #+RESULTS:
> [[file:img/circle.pdf]]
>
> I believe the documentation (and this is corroborated by the discussion
> of the original patch
> (https://lists.gnu.org/archive/html/emacs-orgmode/2012-04/msg00022.html)),
> that the intended result is
>
> #+RESULTS:
> [[file:img/circle.pdf][file:img/circle.pdf]]
>
> Is my assessment correct? Can anyone else confirm this bug?
>
> Thanks
> Matt

If this is indeed a bug, is there supposed to be a way to create the
current output?:

#+RESULTS:
[[file:img/circle.pdf]]

incorrect documentation for file-desc header argument?

[Matt Huszagh]

Hello,

The org info documentation states

 The ‘file-desc’ header argument defines the description (see *note
 Link Format::) for the link.  If ‘file-desc’ has no value, Org uses
 the generated file name for both the “link” and “description” parts
 of the link.

However, if I evaluate the

#+BEGIN_SRC asymptote :results value file :file circle.pdf :output-dir img/
  size(2cm);
  draw(unitcircle);
#+END_SRC

I get

#+RESULTS:
[[file:img/circle.pdf]]

I believe the documentation (and this is corroborated by the discussion
of the original patch
(https://lists.gnu.org/archive/html/emacs-orgmode/2012-04/msg00022.html)),
that the intended result is

#+RESULTS:
[[file:img/circle.pdf][file:img/circle.pdf]]

Is my assessment correct? Can anyone else confirm this bug?

Thanks
Matt

Re: Browse Org files through capture mechanism?

[Alan E. Davis]

Yes, it seems to do what I have in mind.   Very nice!

All I have had in mind, up to now, is a way to visit the file directly from
Capture, without needing to use org-agenda.

Thank you,

Alan

On Tue, Jul 28, 2020 at 2:38 PM Kyle Meyer  wrote:

> Alan E. Davis writes:
>
> > It surely must be possible to use the capture mechanism to browse the
> > captured material.
> >
> > I use Org-Mode almost every day, usually in capturing notes to a large
> > number of dedicated files.  My capture templates many---too many,
> perhaps.
> >  It would be really useful to be able to browse the files associated with
> > these templates directly through the capture mechanism.
> >
> > Has this been implemented?
>
> I'm not sure I have a clear picture of what you have in mind, but
> perhaps org-capture's GOTO prefix argument does at least some of what
> you're after.
>


-- 
  "This ignorance about the limits of the earth's ability to absorb
   pollutants should be reason enough for caution in the release
   of polluting substances."
   ---Meadows et al.   1972.  Limits to Growth
.
(p. 81)

Re: Bug: no math-mode detection for align-environment [9.3.7 (9.3.7-13-ge62ca4-elpaplus @ /home/stefi/.emacs.d/elpa/org-plus-contrib-20200713/)]

[Kyle Meyer]

Stefi writes:

> I recently updated my emacs packages and noticed that \begin{align*}
> does not trigger math-mode detection any more, so org-cdlatex does not
> work. However, begin{equation} still does trigger the math-mode
> detection. I have read the documentation of
> "org-inside-LaTeX-fragment-p" and found something about matchers, but
> nothing about equation or align environment and why it might be treated
> differently for math-mode detection.

The default value for :matches is ("begin" "$1" "$" "$$" "\\(" "\\[").
It looks like the value hasn't been touched in a long time, and that
AFAICT the "begin" should cover "align" just as it covers "equation".
And I'm not spotting any recent changes on Org's end that should affect
this.

> My test-file.org:
> 8<-8<-8<-8<-
>
> * blabla
>  \begin{equation}
> \label{eq:1} \frac{}{}
> test_{cds} \frac{}{}
> \end{equation}
>
> \begin{align}
> \label{eq:2}
> test$_d$ fr
> \end{align}
>
> $\frac{}{} fds_{fdsf} \frac{}{}$
>
> \begin{align*}
> fr
> \end{align*}
>
>
> 8<-8<-8<-8<-
>
> - detection works for: \begin{equation}, $$, \[\] (not in testfile)
> - detection does not work for: \begin{align}, begin{align*}; subscript _
>   does insert extra $_{}$, which it should not in math mode, and fr does
>   not get expanded to \frac{}{}
>
> Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20)
>  of 2020-05-19
> Package: Org mode version 9.3.7 (9.3.7-13-ge62ca4-elpaplus @
> /home/stefi/.emacs.d/elpa/org-plus-contrib-20200713/)

On master, maint, and the commit matching your reported version
(e62ca4), I tried org-inside-LaTeX-fragment-p within each block of your
test file, and it returns non-nil, including in the align and align*
blocks.  So I dunno...

Could some org-cdlatex users out there give the test file a try?

Re: Repeating task hourly

[Kyle Meyer]

Kevin Liu writes:

>> Is there any way to do this or are the docs out of date?
>
> I made a few quick changes to org-habit and it works prima facie.  Will
> continue testing for a bit.

The hourly repeater came in ec921a2a6 (Support hourly repeat cookies,
2012-04-20), well after the "less than 1d" guard was added in
org-habit.el.  So, perhaps it'd make sense to update org-habit.el to
support hour repeaters, particularly if habit users say there's a need.

As a non-habit user reading through (info "(org)Tracking your habits"),
I'm a bit worried that your patch only works superficially.  That node
talks about "graphs that show every day" and "colors for each day"; does
that sort of logic break down with your proposed changes?

Re: [PATCH] Fix recommendation in ORG-NEWS (was: Binding RET to org-return-and-maybe-indent)

[Kyle Meyer]

Kévin Le Gouguec writes:

> Jarmo Hurri  writes:
>
>> Kévin Le Gouguec  writes:
>>
>>> Can you tell me whether electric-indent-local-mode works better for
>>> you?  If it does, I'll followup with a patch to ORG-NEWS.
>>
>> Seems to be working fine. Thank you very much.
>
> Thanks for the confirmation.
>
> Here is a patch for ORG-NEWS, then:

Thanks, looks good to me.  Applied (0fd9a6ad6).

Re: Browse Org files through capture mechanism?

[Kyle Meyer]

Alan E. Davis writes:

> It surely must be possible to use the capture mechanism to browse the
> captured material.
>
> I use Org-Mode almost every day, usually in capturing notes to a large
> number of dedicated files.  My capture templates many---too many, perhaps.
>  It would be really useful to be able to browse the files associated with
> these templates directly through the capture mechanism.
>
> Has this been implemented?

I'm not sure I have a clear picture of what you have in mind, but
perhaps org-capture's GOTO prefix argument does at least some of what
you're after.

Browse Org files through capture mechanism?

[Alan E. Davis]

It surely must be possible to use the capture mechanism to browse the
captured material.

I use Org-Mode almost every day, usually in capturing notes to a large
number of dedicated files.  My capture templates many---too many, perhaps.
 It would be really useful to be able to browse the files associated with
these templates directly through the capture mechanism.

Has this been implemented?

Alan Davis

-- 
  "This ignorance about the limits of the earth's ability to absorb
   pollutants should be reason enough for caution in the release
   of polluting substances."
   ---Meadows et al.   1972.  Limits to Growth
.
(p. 81)

Re: [Discuss] separate (recenter window-line) out of org-agenda-redo

[Marco Wahl]

"numbch...@gmail.com"  writes:

> I try to add an idle timer to auto refresh org agenda views.
>
> Here is what I code:
>
> #+begin_src emacs-lisp
> ;;; auto refresh `*Org Agenda*' buffer
> (defun my/org-agenda-auto-refresh ()
>   "Rebuild all agenda views buffers."
>   (org-agenda-redo-all t))
>
> (run-with-idle-timer (* 60 20) t #'my/org-agenda-auto-refresh)
> #+end_src
>
>
> But I got error:
>
> #+begin_example
> Error running timer ‘my/org-agenda-auto-refresh’: (error "‘recenter’ing a
> window that does not display current-buffer.")
> #+end_example

Coming back to your original issue. Possibly it's enough to just
suppress the error.

You could change the function to

--8<---cut here---start->8---

(defun my/org-agenda-auto-refresh-1 ()
  "Rebuild all agenda views buffers."
  (ignore-errors (org-agenda-redo-all t)))

--8<---cut here---end--->8---


HTH,
-- 
Marco

[ANN] integrate Org-capture and YASnippet and Yankpad

[Andrea]

Hi,

TL;DR: I show a way to run a yasnippet or a yankpad snippet from your
org-capture templates.

I would like to share with the community this little hack to integrate
org-capture with the templating systems of YASnippet and Yankpad!

If you like to keep snippets organized and not in the init file, you may
be using YASnippet and/or Yankpad. I found that is not straightforward
to run one of these while creating a task with org-capture so I hacked
my way through.

So this is the screencast of my hack:
https://github.com/ag91/ya-org-capture/blob/master/ya-org-capture-screehcast.gif

And this is a post describing why/what I did: 
https://ag91.github.io/blog/2020/07/28/how-to-integrate-yasnippet-and-yankpad-with-org-capture/

I hope this will be helpful to somebody else too! And any feedback is
welcome, maybe there was an easier way to do it?

Thanks,

Andrea

Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]

[Gustavo Barros]

Hi Marco,

thank you for your answer.

On Tue, 28 Jul 2020 at 17:34, Marco Wahl  wrote:

>> I'm not sure this is a "bug", strictly speaking, or if it is correct
>> unfortunate behavior.  Anyway, is there something that could be done
>> from Org's side?
>
> Also not sure if this is a bug. But you can configure the desired
> behavior by hooking in at activation of visual line mode AFAICS.
>
> You could e.g. add
>
>
> (add-hook 'visual-line-mode-hook
>   (lambda () (when (derived-mode-p 'org-mode)
>(local-set-key (kbd "C-a") #'org-beginning-of-line)
>(local-set-key (kbd "C-e") #'org-end-of-line)
>(local-set-key (kbd "C-k") #'org-kill-line
>
> to your config.
>

This is a good workaround.  I've been doing something else, which is
simply to bind the keys directly (that is not using `[remap ...]') in
`org-mode-map'.  This way the remappings done by `visual-line-mode' find
nothing to remap, and things work as expected.  However, while I'm safe
with this approach in my local settings, because I know I haven't changed
the default bindings for these commands, I don't know how good this
would be as a general solution for Org.

Anyway, it would be nice if this worked out-of-the-box, this can be
baffling behavior, especially for newer users.  But I'm not sure what to
suggest here.

Best,
Gustavo.

Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]

[Marco Wahl]

Hi Gustavo,

> The Org line commands -- `org-beginning-of-line', `org-end-of-line', and
> `org-kill-line' -- all take due care for the presence of
> `visual-line-mode' to do the right thing if it is turned on.  However,
> when `visual-line-mode' is indeed on, the bindings on
> `visual-line-mode-map' shadow Org's bindings, so that we actually get
> `beginning-of-visual-line', `end-of-visual-line', and `kill-visual-line'
> for the usual keybindings, instead of the much nicer specialized Org
> commands.
>
> To check this, start with =emacs -Q=, set load-path to get the proper
> version of Org (as your case may be):
>
> #+begin_src emacs-lisp
> (add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200727")
> #+end_src
>
>
> Then visit an Org file, and enable "M-x visual-line-mode", and check the
> bindings with "C-h k C-a", "C-h k C-e", and "C-h k C-k" to get:
>
> #+begin_example
> beginning-of-visual-line
> end-of-visual-line
> kill-visual-line
> #+end_example
>
> I'm not sure this is a "bug", strictly speaking, or if it is correct
> unfortunate behavior.  Anyway, is there something that could be done
> from Org's side?

Also not sure if this is a bug. But you can configure the desired
behavior by hooking in at activation of visual line mode AFAICS.

You could e.g. add

--8<---cut here---start->8---

(add-hook 'visual-line-mode-hook
  (lambda () (when (derived-mode-p 'org-mode)
   (local-set-key (kbd "C-a") #'org-beginning-of-line)
   (local-set-key (kbd "C-e") #'org-end-of-line)
   (local-set-key (kbd "C-k") #'org-kill-line

--8<---cut here---end--->8---

to your config.


Best,
-- Marco

Re: Capture with (moving) attachment?

[Mikhail Skorzhinskii]

Hi Tim,

I tried to solve the similar problem and come up with the solution with 
external script to do this. This is basically only tested in Linux with KDEv5 
environment, but could be extended to any other DE or to work solely in emacs.

Anyway, the idea of the solution is to provide an interface to the graphical 
file manager, so you can select files and just "send them" to org-mode. For 
this I wrote elisp function that do the attaching on files you provided, then a 
script that pass arguments to this function via emacslcient and then a module 
for file manager for menu to appear.

1. Elsip function for the attaching:

(defun org-user/move-to-file-storage (files)
  "Move FILES at my file system to annex/org file storage."
(save-excursion
  (let ((org-capture-templates org-file-capture-templates)) ;; << don't use 
org-file-capture-template if you don't want separate capture templates variable 
for this
(org-capture))
  ;; Create as many new headings as it need to be created
  (when (> (length files) 1)
(save-excursion
  (org-clone-subtree-with-time-shift (- (length files) 1) '(4
  ;; Edit these headings and attach files to them
  (dolist (file files)
(when (file-exists-p file)
  ;; Just some sane name should be enough
  (org-edit-headline (concat "File: " (file-name-nondirectory file)))
  ;; Attach file to the storage room
  (org-attach-attach file nil 'mv)
  ;; Edit headline once again with the stored file
  (let* ((attach-dir (org-attach-dir))
 (files (org-attach-file-list attach-dir))
 (file (pop files)))
(org-edit-headline
 (format "[[attachment:%s][%s]]" file (org-get-heading t t t t
  ;; Go to the next free heading
  (org-next-visible-heading 1)))
  ;; Make sure that we didn't cancel capture with file that was already 
moved
  (org-capture-finalize)
  ;; Go to the file if we want to say something about it
  (org-capture-goto-last-stored)
  ;; Save buffer just in case
  (save-buffer)))

Function implementation is very far from ideal, but it is working to some 
extent. There is a bug with this function: it inserts one empty headline. 
Should be easy to fix, sorry about that.

2. Define your capture templates

Just like the normal capture templates.

(setq org-file-capture-templates ... )

Now calling this function externally will attach files you provided, save org 
buffers immediately after and leave the frame open on last attached item. Every 
attached file will have separate heading. And every heading will be a link to 
the attached file.

3. Store this script somewhere in your $PATH

#!/bin/bash

# Author: Mikhail Skorzhinskii 
#
# Description: Attach file to the org-mode file storage

files=

for file in "$@"; do
files="${files} \"${file}\""
done;

emacsclient -a "" -c -F '((name . "doom-capture"))' \
-e "(org-user/move-to-file-storage (list ${files}))"

If you save it as "org-attach-files.sh" then you can call it like 

  org-attach-files.sh file1 file2 file3

But make sure to pass absolute paths, as emacs executable will probably 
operating in different directory. I personally don't care as file manager 
always call it with full paths. But easy to fix with readlink -e call. (i.e. 
file=`readlink -e ${file}` before putting it to ${files}.

4. Place this module to .local/share/kservices5/ServiceMenus/emacs.desktop

End name can be anything of course.

[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=all/all;
Actions=org-attach-mv;
X-KDE-Priority=TopLevel

[Desktop Action org-attach-mv]
Name=Send to git-annex
Exec=emacs-org-attach-file %U
Icon=cloud-download

This should work in KDE files managers (like Dolphin). Right-click the file and 
you will have "Send to git annex" menu item.

Mikhail Skorzhinskii

On Wednesday, July 22, 2020 11:48:24 PM CEST Tim Landscheidt wrote:
> Hi,
> 
> I have a capture template to file items to a list:
> | ("i" "inventory" entry
> | 
> |  (file "~/Desktop/Agenda/Inventar.org")
> |  "* %^{Name}" :immediate-finish t)
> 
> Currently, when I want to file an item with an associated
> image, I open the directory of the images with dired, visit
> the image file, use the capture to add an item, kill the im-
> age buffer, use M-0 w in dired to copy the file's name,
> switch to the org file, use C-c C-a m to attach the image by
> moving the file, and then switch back to the dired buffer.
> Lather, rinse, repeat, until the directory with the images
> is empty.
> 
> What I want to do instead is open the image file (via dir-
> ed), have the capture do the attaching by itself (if it is
> called in an image-mode buffer) and then kill the image
> buffer.  (Emacs does not care if the file associated with
> the buffer is deleted in the mean time.)
> 
> First idea was to use %(EXP) to set
> org-capture-after-finalize-hook to attach the file, but