Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]

[Max Nikulin]

On 11/03/2022 01:00, Ignacio Casso wrote:

Max Nikulin writes:


On 10/03/2022 19:53, Ignacio Casso wrote:

For example, if we call this:
(let ((org-capture-templates
   '(("d" "default" entry
  (file+headline org-default-notes-file "Tasks")
  "* %?"
  (org-capture nil "d")))
It produces the error:
(error "No capture template referred to by \"d\" keys")


Ignacio, could you, please, try the following?

 (custom-set-variables
  '(org-capture-templates
'(("d" "default" entry
   (file "/tmp/capture-test.org")
   "* %?"
 (org-capture nil "d")



That works, of course, but it's not suitable to my use case. The example
I have provided has been reduced from a larger function I wrote that
relies on org-capture functionality to create new entries in an org
file, using a template specific for that function which is not relevant
for any other Elisp code calling org-capture. Thus the function binds
locally and temporarily org-capture-templates, as I've seen other Elisp
code snippets do. If org-capture is already loaded it works just fine,
and I would expect it to work too when it is not and the function
triggers the autoload, but it doesn't.


Ignacio, I think, you can add (require 'org-capture) inside your 
function just before `let' and it would work almost as lazy loading. I 
am unsure if org-capture is the best approach in your case. Have you 
considered yasnippet or Org specific functions to transform and to 
generate content? Even changing arguments of the `org-capture' function 
or introducing another function that has explicit argument with a 
template might be better then marking the template list variable for 
autoloading.


I have no particular opinion concerning adding autoload cookie to 
`org-capture-templates'. Emacs has enough number of them, but Org has no 
such custom variables. Arguments why autoload should be avoided:


info "(elisp) When to Autoload" 
https://www.gnu.org/software/emacs/manual/html_node/elisp/When-to-Autoload.html

Don’t autoload a user option just so that a user can set it.


The following thread related to Emacs core and linked from 
https://emacs.stackexchange.com/questions/32859/autoloading-defcustoms-good-practice-or-not 
:


Glenn Morris. Re: master f995fbd: * lisp/server.el (server-name): Add 
autoload cookie. (Bug#23576) Thu, 19 May 2016 12:44:49 -0400

https://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00415.html

Org-specific thread:
Achim Gratz. missing autoload cookies for defcustom? Sun, 09 Oct 2011 
17:20:16 +0200 https://list.orgmode.org/87lisub39r.fsf@Rainer.invalid/T/#u


c.buhtz, I am sorry, despite `org-capture-templates' has the :set 
attribute, this is not a really convincing example why 
`custom-set-variables' should be used. The setter was added to ensure 
compatibility with older template format and this example works with 
`setq' as well.

Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]

[Ignacio Casso]

Max Nikulin  writes:

> Ignacio, I think, you can add (require 'org-capture) inside your
> function just before `let' and it would work almost as lazy loading.

Thanks, I was already using (require 'org-capture) in my init file to
solve this. As I said, it's not really a problem for me, I was just
reporting it in case it was a bug. I was not sure since I don't really
know the inner workings of autoloads and custom variables, but since
this snippet works when org-capture is not yet loaded

  (setq org-capture-templates
 '(("d" "default" entry
(file+headline org-default-notes-file "Tasks")
"* %?")))
  (org-capture nil "d")

and this snippet also works

  (let ((my-new-var 2))
(defcustom my-new-var 1 "New variable that did not exist before")
(message "%s" my-new-var)) ;; This prints 2
  (message "%s" my-new-var) ;; This prints 1

I thought that this snippet should work too when org-capture is not yet
loaded, and that the fact that it doesn't could mean that there is a bug
somewhere

  (let ((org-capture-templates
 '(("d" "default" entry
(file+headline org-default-notes-file "Tasks")
"* %?"
(org-capture nil "d")))


> I have no particular opinion concerning adding autoload cookie to
> `org-capture-templates'. Emacs has enough number of them, but Org has
> no such custom variables.

I put an autoload cookie myself and it doesn't fix it, so it's probably
not that. It's the first time I manage autoload cookies though, so I may
have done something wrong. I only tested that the autoload cookie worked
by checking that before loading org-capture, org-capture-templates
appears in the completion list for C-h v, and I can evaluate it.

org-roam to HTML: My needs are unusual?

[c . buhtz]

Hello together,

this post is not about a technical problem but I need your advice and 
opinion as experienced org(roam) users and developers. I am a bit 
frustrated.


Some of you have noticed that I tried to generate HTML files out of my 
org-roam notes. In the current state I am failed. On one side because of 
technical problems/bugs and on the other side because of tools not 
fitting my needs.


At the end I would subscribe my need like that:
I want all my org-roam-v2 notes (means org file with ID-links) 
transformed to HTML-files which I can use via file:// protocol (means 
without a server).


Sounds simple to me but the reality looks different. And I wonder if my 
use case is not so usual as I thought. Am I the only person experience 
that problems?


I tried ox-publish but there are problems (and known bugs [1]) with 
creating correct links/urls between the HTML-files based on the 
org-roam-v2-ID-links. I do not understand the technical details and I am 
not able to surly reproduce the problems. But I heard from many sides 
that I am not the only person with that problem.


ox-hugo with hugo is often mentioned in the context. But ox-hugo is not 
able to export everything out-of-the-box [2]. And the HTML files 
generated by hugo are not usable via the file:// protocol without some 
hacks [3].


My wish would be that the ox-publish would work. I prefer in-build 
things. But I am not sure how the result would look like if it work.


Currently I think about creating a Python tool parsing the org files by 
itself and doing all the needed stuff. But I do not want to waste my 
time here when the ox-publish problem is solved in the next months.


Thanks in advance
Christian

[1] -- 
[2] -- 
[3] -- 

Re: Cannot link to files with no extension

[Colin Baxter]

I see the problem using emacs -Q, as I reported in a previous email.

Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`)

[Denis Bitouzé]

Hi,

here is a feature request about the LaTeX export (another one: the
previous mine, https://list.orgmode.org/87zgmda67z@example.com/,
sadly didn't get any answer).

With `(setq org-latex-listings t)`, `src_⟨language⟩{⟨code snippet⟩}` is
exported from `org-mode` to `LaTeX` into
`\lstinline[language=⟨language⟩]~⟨code snippet⟩~` (here, `~` could be
almost any token): so far, so good.

But one could expect to get the same export with the usual `org-mode`
syntax for code snippets: `~⟨code snippet⟩~` (this supposes the ⟨language⟩
to be declared globally), as in the following example:

--8<---cut here---start->8---
#+OPTIONS:   toc:nil title:nil

#+LaTeX_HEADER: \usepackage{xcolor}
#+LaTeX_HEADER: \usepackage{listings}
#+LaTeX_HEADER: 
\lstset{language=[auto]lisp,basicstyle=\ttfamily,keywordstyle=\color{red}}

#+PROPERTY: header-args :padline no :exports both :noweb yes :eval always

src_lisp{defun} is fun!

~defun~ is fun!
--8<---cut here---end--->8---

For this, it is possible to redefine the `org-latex-code` function:

--8<---cut here---start->8---
;; Inspired by https://emacs.stackexchange.com/q/70720/5267
(defun org-latex-code (code _contents info)
  "Transcode a CODE object from Org to LaTeX.
CONTENTS is nil.  INFO is a plist used as a communication
channel."
  (format "\\lstinline+%s+"
  (org-element-property :value code)))
--8<---cut here---end--->8---

but, IMHO, this should be the default.

WDYT?
-- 
Denis

Re: [PATCH] org-protocol.org: updated Linux setup (Gnome) section

[Max Nikulin]

On 11/03/2022 02:35, Wilko Meyer wrote:


I'd like to suggest an update to the org-protocol.org "Linux setup (Gnome)"
section as it is refering to gconf/gconftool-2 which is deprecated as of
Gnome 3. It may be a good idea to use .desktop-Files (as described in
freedesktop.orgs Desktop Entry/Menu Specification) here to complete this
step (which is what my patch suggests).


Greet, definitely this page is severely outdated. I have a little 
experience with .desktop files so do not hesitate to object to my comments.



diff --git a/org-contrib/org-protocol.org b/org-contrib/org-protocol.org
index 57cab17f..b10ef41e 100644
--- a/org-contrib/org-protocol.org
+++ b/org-contrib/org-protocol.org
@@ -89,10 +89,21 @@ actions. Just register your custom sub-protocol and handler 
with the variable
 
 *** Linux setup (Gnome)

   ^^^
It seems, the approach with the .desktop file works for KDE as well and 
even for minimal setup with simple window manager (no real desktop 
environment). What do you think concerning marking existing sections 
obsolete and adding new universal one for GNU/Linux?



-For this to work, you'll need the Gnome-Libraries to be installed.
+Add a file =org-protocol.desktop= to =~/.local/share/applications/=:
+
+#+begin_example
+[Desktop Entry]

+Name=org-protocol


Since the entry may appear in UI (menu) I would consider adding 
"Comment" field as well to make it self-descriptive. For the same reason 
I would add "Icon=emacs" (it is unlikely that Org Mode icons are 
available in the system in all necessary sizes). I am unsure if 
"GenericName" and "Keywords" should be defined and what they may contain.



+Exec=emacsclient '%u'


Accordingly to "Desktop Entry Specification"
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html


Field codes must not be used inside a quoted argument, the result of
field code expansion inside a quoted argument is undefined. The %F and
%U field codes may only be used as an argument on their own.


For additional security I would add "--" separator to avoid treating 
passed argument as an option:


Exec=emacsclient -- %u


+Type=Application
+Terminal=false
+Categories=System;


I can not suggest a better category, e.g. Utility is hardly better that 
System, but it is not really a system application as well.


Looking into
http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacsclient.desktop
I noticed

   StartupWMClass=Emacs

that might give a hint when a new window is created.


+MimeType=x-scheme-handler/org-protocol;
+#+end_example
+
+Update the cache database of MIME types handled by desktop files via:
 
-: gconftool-2 -s /desktop/gnome/url-handlers/org-protocol/command '/usr/local/bin/emacsclient %s' --type String

-: gconftool-2 -s /desktop/gnome/url-handlers/org-protocol/enabled --type 
Boolean true


When I was setting org-protocol for the first time, I experienced 
various problems. I have seen various recipes, so I think it may be 
helpful to explicitly state that such commands are obsolete instead of 
removing them completely. The intention is to make users aware that such 
approach should not be tried even if they notice it on some other web 
site. I do not insist though.


Side note: I believe, currently the best setup guide is 
https://github.com/sprig/org-capture-extension/



+: update-desktop-database ~/.local/share/applications/
 
 *** Linux setup (KDE)


A note unrelated to your patch. With simple "emacsclient %u" handler a 
problem may happen when a browser is started from command line instead 
of clicking on the icon or from menu. If emacs has no frames then it may 
create a new one in the terminal instead of opening a graphical window 
(Emacs frame). Have you managed to adjust emacs server or general buffer 
settings to ensure new graphical frame (on the same virtual desktop) in 
such cases?

Re: org-roam to HTML: My needs are unusual?

[Kaushal Modi]

Hello Christian,

tl;dr: If you decide to learn how to use Hugo (read its docs, ask questions
on its forum, etc.), this[1] should solve the issues you have faced so far.

---

Details:

On Fri, Mar 11, 2022 at 7:04 AM  wrote:

>
> ox-hugo with hugo is often mentioned in the context. But ox-hugo is not
> able to export everything out-of-the-box [2].
> [2] -- 


Correct, because it is not the job of `ox-hugo` to figure out how the user
needs to export all the Org files. I see users coming with various
use-cases; it is out of scope of my free time to attempt to support all of
that in the ox-hugo package:

- How to export only the Org files that already have the Markdown exported?
- How to export Org files written for  package?
- This didn't work on Windows.
- etc.

So I encourage the users to attempt to learn a bit of elisp or Makefile or
bash to do this batch exporting for them. I have posted one solution to
this here[4], but I won't be surprised if this solution is not exactly what
someone wants (for example, that solution does not update the org-id
locations from everywhere a user has their Org files).


And the HTML files
> generated by hugo are not usable via the file:// protocol without some
> hacks [3].
> [3] -- 
>

Those are not hacks; those are Hugo switches a user can use to generate the
kind of HTML they need (with or without ugly URLs, with or without relative
URLs, with or without RSS, so on and so forth).

[1]:
https://github.com/kaushalmodi/ox-hugo/discussions/585#discussioncomment-2339756
[4]:
https://github.com/kaushalmodi/ox-hugo/discussions/585#discussioncomment-2335203

Re: org-roam to HTML: My needs are unusual?

[Max Nikulin]

On 11/03/2022 19:03, c.bu...@posteo.jp wrote:


At the end I would subscribe my need like that:
I want all my org-roam-v2 notes (means org file with ID-links) 
transformed to HTML-files which I can use via file:// protocol (means 
without a server).


Christian, you may confuse people requiring file: protocol. I think, for 
hugo or for other approaches to export, the goal is to get *relative* 
links something. In such case 
any file may be opened in a browser and links (images, CSS styles) will 
work.


In some cases it is still easier to run a HTTP server bound to loopback 
network interface:
   python3 -m http.server 8080 --bind 127.0.0.1 --directory 
/path/to/your/files


I would suggest to not mix general questions related to org-export and 
org-publish with ones specific to org-roam such as backlinks. The latter 
should be addressed to the developers of org-roam.

Re: ox-publish: Some starting problems

[chris]

Hi Christian,
I've received the following in my personal email box, and I think it is related 
to this thread, 
so I paste it here:
On Thursday, 10 March 2022 06:54:22 CET c.bu...@posteo.jp wrote:
> Hello together,
> 
> I do not understand all details. But it seems to me that currently
> ox-publish is not fully capable to generate a linked together HTML
> files out of org-roam-v2 generated org files because of the ID-linking
> of org-roam-v2.
> 
> In my tests it sometimes work and sometimes not. I was not able to
> reproduce this. While writing to the list about that problem I was
> pointed to that bug report here.
> 
> Kind
> Christian
And I think that I understand the question, and the general setting related to 
it.

So, on the one hand you have `org-mode/org-id` links like 
`[[id:32ba80a3-1982-4f43-becb-
b0e346a91b0d][hello]]`, which seem the thing to do in the 21st century, the 
most sensible 
thing to do IMO, I only use those, `org-roam` only use those.

When with `emacs` the links are followed/resolved through a database. For 
example, the 
database can be updated through functions like `org-id-update-id-locations`, 
part of 
https://github.com/tkf/org-mode/blob/master/lisp/org-id.el[1].

However the use of them is controversial because some deem them as not human 
friendly 
enough. So I suppose guidelines should be defined for anything to happen, but 
I'm not 
sure people would agree on what to do. And internal ID links, resolved locally 
through 
reading in a database, should be thoroughly translated to something accurate 
and 
consistent at export-time, and that seems a lot.

I myself use `org-roam` and `ID`; considering the difficulties of exporting to 
html through 
emacs/org-mode, I just gave up.
Thanks,
Chris
PS: I think you are doing an awesome job at trying to have all that working.


On Wednesday, 9 March 2022 17:39:46 CET c.bu...@posteo.jp wrote:
> Dear Max,
> 
> thank's a lot for your help and your patience with a newbie.
> 
> Am 09.03.2022 16:32 schrieb Max Nikulin:
> >> 3.
> >> I use (setq org-export-with-broken-links t) with and without
> >> ":with-broken-links "mark"" to prevend ox-publish stopping when there
> >> are broken links. I swear and I also checked that there are only a few
> >> of them. But in the HTML output all links are gone. No links. No text
> >> for the links.
> > 
> > If you insist on setq than try
> > 
> >(setq org-export-with-broken-links 'mark)
> > 
> > without :with-broken-links. You can get correct value using easy
> > customization interface. It does not matter for
> > `org-export-with-broken-links', but some custom variables have :set
> > property, so the following may be generally better
> > 
> >(custom-set-variables
> >
> > '(org-export-with-broken-links 'mark))
> 
> Do you mean that (setq org-export-with-broken-links 'mark) is the same
> as :with-broken-links mark? This are just two different ways to set the
> same thing?
> How do I know as a newbie? ;)
> 
> Why using custom-set variables here? Is there something wrong with just
> doing
> (org-export-with-broken-links t)
> ?
> 
> >> I tried to reproduce this in a minimal example with two new nodes. But
> >> for them the links are generated.
> > 
> > It seems, changing project options or global variables does not lead
> > to updating of the files if the sources have not modified.
> 
> I do not understand. Do you a see a solution for the problem?
> 
> > There is a known problem with id links. They may be broken if they
> > lead to another file:
> > inkbottle. org-id with ox-html. Sat, 14 Aug 2021 00:28:35 +0200
> > https://list.orgmode.org/4617246.m1MCmUpgFQ@pluto/

Re: Export (to `LaTeX`) `~⟨code snippet⟩~` into `\lstinline+⟨code snippet⟩+` (just as does `src_⟨language⟩{⟨code snippet⟩}`)

[Nick Dokos]

Hi Denis,

Denis Bitouzé  writes:

> Hi,
>
> here is a feature request about the LaTeX export (another one: the
> previous mine, https://list.orgmode.org/87zgmda67z@example.com/,
> sadly didn't get any answer).
>
> With `(setq org-latex-listings t)`, `src_⟨language⟩{⟨code snippet⟩}` is
> exported from `org-mode` to `LaTeX` into
> `\lstinline[language=⟨language⟩]~⟨code snippet⟩~` (here, `~` could be
> almost any token): so far, so good.
>
> But one could expect to get the same export with the usual `org-mode`
> syntax for code snippets: `~⟨code snippet⟩~` (this supposes the ⟨language⟩
> to be declared globally), as in the following example:
>
> #+OPTIONS:   toc:nil title:nil
>
> #+LaTeX_HEADER: \usepackage{xcolor}
> #+LaTeX_HEADER: \usepackage{listings}
> #+LaTeX_HEADER: 
> \lstset{language=[auto]lisp,basicstyle=\ttfamily,keywordstyle=\color{red}}
>
> #+PROPERTY: header-args :padline no :exports both :noweb yes :eval always
>
> src_lisp{defun} is fun!
>
> ~defun~ is fun!
>
>
> For this, it is possible to redefine the `org-latex-code` function:
>
> ;; Inspired by https://emacs.stackexchange.com/q/70720/5267
> (defun org-latex-code (code _contents info)
>   "Transcode a CODE object from Org to LaTeX.
> CONTENTS is nil.  INFO is a plist used as a communication
> channel."
>   (format "\\lstinline+%s+"
>   (org-element-property :value code)))
>
> but, IMHO, this should be the default.
>
> WDYT?

I have no opinion on whether it should be the default or not, but I
wanted to point out a possibility that might have not occurred to you:
it is possible to define what's called a "derived" exporter, an
exporter that shares most of its code with the exporter that it is
derived from and only overrides one or two functions where you need a
change.

See the doc string of the function `org-export-define-derived-backend'
for some details.  There are also many examples where this feature is
used (a simple one is in the doc string itself), but there are
examples in the Org mode code itself, e.g the beamer exporter
(ox-beamer.el) is derived from the LaTex one (ox-latex.el), as is the
koma-letter exporter (ox-koma-letter.el), and the markdown exporter
(ox-md.el) is derived from the HTML exporter in ox-html.el.

Deriving a new back end from the LaTeX exporter and redefining one or
two functions (like `org-latex-code' above) is IMO the best way
forward. You get an exporter that works as you want and the defaults
are left as-is (developers are wary about changing defaults: that
brings out a lot of complaints of the "it was working fine yesterday
but you broke it" variety). And you can publish your derived mode on
e.g Gitlab/Github/whatever and make it available in MELPA for others
to try out.

HTH.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [PATCH] org-protocol.org: updated Linux setup (Gnome) section

[Wilko Meyer]

Thanks for reviewing my patch and adding remarks! I'll attach an updated
version of my patch to this mail based on these.

> It seems, the approach with the .desktop file works for KDE as well
> and even for minimal setup with simple window manager (no real desktop 
> environment). What do you think concerning marking existing sections
> obsolete and adding new universal one for GNU/Linux?

As the XDG Desktop Entry Specification should be a de facto standard
by now, adding a new universal GNU/Linux section seems to be a good
idea. It should work with KDE and other DEs as well (though I have only
tested Mate and Gnome 3 so far).

> Since the entry may appear in UI (menu) I would consider adding
> "Comment" field as well to make it self-descriptive. For the same
> reason I would add "Icon=emacs" (it is unlikely that Org Mode icons
> are available in the system in all necessary sizes). I am unsure if 
> "GenericName" and "Keywords" should be defined and what they may contain.
>
> For additional security I would add "--" separator to avoid treating
> passed argument as an option:
>
> Exec=emacsclient -- %u
>

These are excellent points. I second that it'll be a good approach to set
expected defaults (such as Icon, Comment, and alike).

GenericName is not required per specification, neither are
Keywords. Keywords seem to be KDE-specific, as it is stated in the
Desktop Entry Specification that those may be prefixed with X-KDE- in
future versions.

> I can not suggest a better category, e.g. Utility is hardly better
> that System, but it is not really a system application as well.

Having considered this I'd advocate to use the "Other" category here.
Utility or System would make sense as well, but as users most likely
won't interact with said .desktop entry via their application menu, it
probably would be beneficial to put it in a more generic place.

> Looking into
> http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/emacsclient.desktop
> I noticed
>
>StartupWMClass=Emacs
>
> that might give a hint when a new window is created.

Yes, the startup notification spec says:

 > StartupWMClass=STRING
 >If true, it is KNOWN that the application will map at least one
 >window with the given string as its WM class or WM name hint.

> When I was setting org-protocol for the first time, I experienced
> various problems. I have seen various recipes, so I think it may be 
> helpful to explicitly state that such commands are obsolete instead of
> removing them completely. The intention is to make users aware that
> such approach should not be tried even if they notice it on some other
> web site. I do not insist though.

I added a sentence stating that formerly mentioned commands may be seen
as obsolote. I'd appreciate feedback/suggestions on how to phrase this
exactly, as I'm not sure if my wording fits.

> Side note: I believe, currently the best setup guide is
> https://github.com/sprig/org-capture-extension/

Agreed. Something I'm unsure of is, wether using the
update-desktop-database command can be seen as universal. It is part of
the package desktop-file-utils in arch linux (emacs has it as a
dependency, so it'll be installed anyways) but I cannot see KDE/plasma
depending on it. I have verified it to be working in a Mate DE, but
wasn't able to verify it using KDE yet. The org-capture guide uses a
different approach than update-desktop-database, so this is something
which should be verified.

> A note unrelated to your patch. With simple "emacsclient %u" handler a
> problem may happen when a browser is started from command line instead 
> of clicking on the icon or from menu. If emacs has no frames then it
> may create a new one in the terminal instead of opening a graphical
> window (Emacs frame). Have you managed to adjust emacs server or
> general buffer settings to ensure new graphical frame (on the same
> virtual desktop) in such cases?

I haven't put much thought into this yet. I ran a quick test by starting
firefox from command line and tried bookmarking a random page via
org-capture. Besides having emacsclient printing some output to STDOUT I
haven't experienced an issues, as the capture frame has been opened in
my running emacs instance. I'll look into this further over this
weekend.

>From 26d34283506cda58ca3e93457ca0d228c40ab3b0 Mon Sep 17 00:00:00 2001
From: Wilko Meyer 
Date: Thu, 11 Mar 2022 21:30:45 +0100
Subject: [PATCH] org-protocol.org: updated GNU/Linux setup section

---
 org-contrib/org-protocol.org | 56 +++-
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/org-contrib/org-protocol.org b/org-contrib/org-protocol.org
index 57cab17f..935366f7 100644
--- a/org-contrib/org-protocol.org
+++ b/org-contrib/org-protocol.org
@@ -80,41 +80,43 @@ actions. Just register your custom sub-protocol and handler with the variable
 
 * Browser / system setup
 
-  - [[Linux setup (Gnome)]]
-  - [[Linux setup (KDE)]]
+  - [[GNU/Linux setup]]
  

Re: [BUG] org-capture autoload bug? [9.5.2 (9.5.2-gfbff08 @ /home/ignacio/.emacs.d/elpa/org-9.5.2/)]

[Tim Cross]

Ignacio Casso  writes:

> Max Nikulin  writes:
>
>> Ignacio, I think, you can add (require 'org-capture) inside your
>> function just before `let' and it would work almost as lazy loading.
>
> Thanks, I was already using (require 'org-capture) in my init file to
> solve this. As I said, it's not really a problem for me, I was just
> reporting it in case it was a bug. I was not sure since I don't really
> know the inner workings of autoloads and custom variables, but since
> this snippet works when org-capture is not yet loaded
>
>   (setq org-capture-templates
>  '(("d" "default" entry
> (file+headline org-default-notes-file "Tasks")
> "* %?")))
>   (org-capture nil "d")
>
> and this snippet also works
>
>   (let ((my-new-var 2))
> (defcustom my-new-var 1 "New variable that did not exist before")
> (message "%s" my-new-var)) ;; This prints 2
>   (message "%s" my-new-var) ;; This prints 1
>
> I thought that this snippet should work too when org-capture is not yet
> loaded, and that the fact that it doesn't could mean that there is a bug
> somewhere
>
>   (let ((org-capture-templates
>  '(("d" "default" entry
> (file+headline org-default-notes-file "Tasks")
> "* %?"
> (org-capture nil "d")))
>
>
>> I have no particular opinion concerning adding autoload cookie to
>> `org-capture-templates'. Emacs has enough number of them, but Org has
>> no such custom variables.
>
> I put an autoload cookie myself and it doesn't fix it, so it's probably
> not that. It's the first time I manage autoload cookies though, so I may
> have done something wrong. I only tested that the autoload cookie worked
> by checking that before loading org-capture, org-capture-templates
> appears in the completion list for C-h v, and I can evaluate it.

While I don't know if this is a bug, it certainly doesn't seem to be
doing the right thing from an 'intuitive' point of view. I would expect
when a variable is bound to a value inside a let and a function is then
called which uses that variable, the initial let bound value should be
used and the result be the same regardless of whether org-capture has or
has not been loaded. It means there is a hidden side-effect here, which
isn't good and probably needs more analysis. If you had set the value
using setq rather than as a let form, it wouldn't be overridden when
org-capture is loaded, so why does it when it is a let binding? 

Might be worth asking a general question on emacs-devel? Stephan or Eli
can probably provide some clarification here (maybe this is somehow
related to the changes associated with the lexical binding stuff?)

helm-org-names: browse the names of code blocks, tables and figures

[Juan Manuel Macías]

Hi all,

I've written this little package to browse with helm through the names
of code blocks, tables and figures in a document. A series of actions
can be executed on the candidate (go to object, edit a code block,
insert a link, etc.). In the list of figures that is displayed in Helm,
each figure name is accompanied by a thumbnail of the image.

A screenshot: https://i.imgur.com/DVIQv8x.png

The GitLab repo:

https://gitlab.com/maciaschain/helm-org-names

I'm afraid the package is still a bit raw, but I think it's usable :-).

Best regards,

Juan Manuel

Problems with babel reading Japanese paths in Windows

[Jonathan Nogueira]

Hi all,

I've been working with emacs and org on Windows 10.0.19042 and was recently
trying to get babel to produce plantuml diagrams.

I've managed to (I think) narrow the issue down to Babel either not being
able to read/write Japanese paths to shell commands, as when I attempt to
build the diagrams in folders with only ASCII paths, they build fine, but
when babel attempts to execute any source code for paths that contain
Japanese characters, babel gives back the cmd error "The System Cannot Find
the Path Specified."

I'm assuming this is a string quotation problem or something similar but
I'm not sure where to look to fix this.

-- 
Thanks,

Jonathan Nogueira