Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Bruno Barbier  writes:

> Arthur Miller  writes:
>
>> Bruno Barbier  writes:
>>
>>> Arthur Miller  writes:
>>>
>>> The hook `org-capture-mode-hook' will be run in your special
>>> capture buffer. You can override the "C-c C-c" binding only there.
>>
>> Yes and in every other capture buffer
>
> No. If you modify the hook only during your call to 'org-capture', it
> will be called only once in your buffer.
>
>>> Even if I could let bind the function at the right time, I would avoid
>>> that solution, as I can't garantuee that this global hack will not break
>>> other parts of Emacs (other captures, output filters, threads, timers,
>>> etc.).
>>
>> Why do you think it will break other parts? This is not a global hack, on 
>> contrary it
>> exactly tries to prevent to be "global" in entire Emacs, by let-binding a 
>> name
>> to a local lambda, which becomes "global" only in that buffer. If that
>> explains.
>
> You are assigning a local value to the global binding. Everything in
> Emacs will use your functions until you exit the cl-letf. It's like if
> you were using 'fset'.

Yes, you are totally correct; unfortunately binding with cl-flet or cl-labels,
does not work, so binding the global is the only one that works.

> Here is an example that uses cl-letf. Note that the call to
> async-shell-command is outside the "local" binding, yet, the cl-letf
> breaks it. You should try this in an other Emacs, just in case.
>
> (defun oops ()
>   (let ((v (async-shell-command "date" "!sh async")))
> (cl-letf
> (((symbol-function 'comint-output-filter)
>   (lambda (proc string)
> (message "async-shell-command is using my binding: %s" string)
> (read-string "What's the password?"
>   (read-string "what: ")
>   )))
> (oops)

Yes, I definitely agree with you about the concerns, which are certainly
valid, but you would get same effect with advice, it is not different at
all. The difference is that let-binding is automatically removed and installed,
and only active during the cl-letf, while advice is manually installed and
active until manually removed. It is not about the tool, but what you do with
the tool.

>> Here is another version on the same theme, where I don't think you could 
>> modify the local
>> environment without let-binding at all:
>>
>> #+begin_src emacs-lisp
>> (defun my-read-string (prompt)
>>   (let ((delta 20 )
>> (minibuffer-mode-map org-mode-map))
>> (window-resize (minibuffer-window) delta)
>> (cl-letf (((symbol-function 'org-ctrl-c-ctrl-c)
>>(lambda ()
>>  (interactive)
>>  (let ((s (buffer-string)))
>>(exit-minibuffer) s)))
>>   ((symbol-function 'minibuffer-mode) #'org-mode)
>>   ((symbol-function 'minibuffer-complete-and-exit) #'org-return)
>>   ((symbol-function 'org-kill-note-or-show-branches) 
>> #'keyboard-escape-quit))
>>   (read-string (concat "# Press C-c C-c to continue, C-c C-k to 
>> cancel\n# " prompt "\n\n")
>> #+end_src
>
> I hope I've convinced you to not do that. I definitely will not try it,
> as Emacs needs a working minibuffer for plenty of things: debugging,
> saving, quitting, etc.

Your minibuffer will continue to work during and after that function. If you
don't use recursive minibuffer, that will only affect the internal buffer
created by read-string.

If recursive minibuffer is enabled, yes they will also be affected. Of course,
there is no reason for you to try that, that was just an example, but I feel a
bit of passive aggressivity here, for no good reason tbh.

>> read-string is written in C and creates its own minibuffer, which is deleted 
>> by
>> the time read-string exits. I don't know of any other way to cutomize exactly
>> *that* minibuffer, without installing a hook or advising some functions, 
>> which I
>> think is way less clean and much more "global" than just running the 
>> function in
>> a local environment. As I understand, let binding for this purpose is a 
>> normal
>> technique in lisps, but I am not an expert as said; I am actually 
>> experimenting
>> with this for the purpose of learning and seeing what is possible.
>
> Yes, let binding is fundamental. But I think it's the first time I see
> 'cl-letf' with the 'symbol-function' place.

https://nullprogram.com/blog/2017/10/27/
https://endlessparentheses.com/understanding-letf-and-how-it-replaces-flet.html
https://stackoverflow.com/questions/39550578/in-emacs-what-is-the-difference-between-cl-flet-and-cl-letf

>> but I am not sure if I can do anything here without introducing at-least an
>> extra keymap, to not install into the org-capture-mode-map, so I can as well
>> create a minor mode, but at this point it is not much different than
>> re-invinting the read-string, so I'll terminate my experiment here :).
>
> You can replace the buffer keymap with a keymap that only contain your custom
> keys, and inherits everything el

Re: Re: [PATCH] Introduce "export features"

[Pedro Andres Aranda Gutierrez]

Hi,

Ihor wrote:
>> Timothy  writes:
>>
>> “export features” allow for the specification of qualities of the org
buffer
>> being exported that imply certain “features”, and how those features may
be
>> implemented in a particular export.

Looks like a cool "feature" that would bring some structure into
my chaotic configuration...

>>(defun org-export-update-features (backend &rest feature-settings)
>>  "Update FEATURE-SETTINGS for BACKEND.

>From what you explain, maybe "...-update-configs" may be a name that tells
me more

>Also, you will need to add ORG-NEWS entry and document the new feature
>system in "13.17 Advanced Export Configuration" and "A.4 Adding Export
>Back-ends" sections of the manual.

But I'd need ^that^ to judge better

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem understanding doc)

[Alain . Cochard]

Ihor Radchenko writes on Sat 11 Feb 2023 18:22:

 > We can indeed at such warning, but it will probably be not very
 > helpful.

I don't understand this.  And isn't it better to have a more accurate
manual anyway?

Apart from that, since the default value in 9.6 is 'smart' ('nil' in
9.5), I wonder if the sentence

   "Setting ‘org-fold-catch-invisible-edits’ to non-‘nil’ helps
   preventing this."

is still the most appropriate.

Also, this is another instance where 'C-h v' with the cursor on
'org-fold-catch-invisible-edits' does not offer it right away in the
minibuffer.  I am surprised since it does so in 9.5 (with
'org-catch-invisible-edit').

 > Only typing, deleting char forward/backward and meta-return are
 > considering invisible edits now.

Thanks.  It is helpful to me to know that.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: Problem with let/cl-letf binding stuff with org-capture

[Bruno Barbier]

Arthur Miller  writes:

> Bruno Barbier  writes:
>
>> Arthur Miller  writes:
>>
>> The hook `org-capture-mode-hook' will be run in your special
>> capture buffer. You can override the "C-c C-c" binding only there.
>
> Yes and in every other capture buffer

No. If you modify the hook only during your call to 'org-capture', it
will be called only once in your buffer.

>> Even if I could let bind the function at the right time, I would avoid
>> that solution, as I can't garantuee that this global hack will not break
>> other parts of Emacs (other captures, output filters, threads, timers,
>> etc.).
>
> Why do you think it will break other parts? This is not a global hack, on 
> contrary it
> exactly tries to prevent to be "global" in entire Emacs, by let-binding a name
> to a local lambda, which becomes "global" only in that buffer. If that
> explains.

You are assigning a local value to the global binding. Everything in
Emacs will use your functions until you exit the cl-letf. It's like if
you were using 'fset'.

Here is an example that uses cl-letf. Note that the call to
async-shell-command is outside the "local" binding, yet, the cl-letf
breaks it. You should try this in an other Emacs, just in case.

(defun oops ()
  (let ((v (async-shell-command "date" "!sh async")))
(cl-letf
(((symbol-function 'comint-output-filter)
  (lambda (proc string)
(message "async-shell-command is using my binding: %s" string)
(read-string "What's the password?"
  (read-string "what: ")
  )))
(oops)


>
> Here is another version on the same theme, where I don't think you could 
> modify the local
> environment without let-binding at all:
>
> #+begin_src emacs-lisp
> (defun my-read-string (prompt)
>   (let ((delta 20 )
> (minibuffer-mode-map org-mode-map))
> (window-resize (minibuffer-window) delta)
> (cl-letf (((symbol-function 'org-ctrl-c-ctrl-c)
>(lambda ()
>  (interactive)
>  (let ((s (buffer-string)))
>(exit-minibuffer) s)))
>   ((symbol-function 'minibuffer-mode) #'org-mode)
>   ((symbol-function 'minibuffer-complete-and-exit) #'org-return)
>   ((symbol-function 'org-kill-note-or-show-branches) 
> #'keyboard-escape-quit))
>   (read-string (concat "# Press C-c C-c to continue, C-c C-k to cancel\n# 
> " prompt "\n\n")
> #+end_src

I hope I've convinced you to not do that. I definitely will not try it,
as Emacs needs a working minibuffer for plenty of things: debugging,
saving, quitting, etc.


> read-string is written in C and creates its own minibuffer, which is deleted 
> by
> the time read-string exits. I don't know of any other way to cutomize exactly
> *that* minibuffer, without installing a hook or advising some functions, 
> which I
> think is way less clean and much more "global" than just running the function 
> in
> a local environment. As I understand, let binding for this purpose is a normal
> technique in lisps, but I am not an expert as said; I am actually 
> experimenting
> with this for the purpose of learning and seeing what is possible.

Yes, let binding is fundamental. But I think it's the first time I see
'cl-letf' with the 'symbol-function' place.


> ...
> but I am not sure if I can do anything here without introducing at-least an
> extra keymap, to not install into the org-capture-mode-map, so I can as well
> create a minor mode, but at this point it is not much different than
> re-invinting the read-string, so I'll terminate my experiment here :).

You can replace the buffer keymap with a keymap that only contain your custom
keys, and inherits everything else from org-capture-mode-map.


>
> But I wouldn't speak in some generic terms like "use hooks" or "advise" 
> instead
> of let-binding.

I didn't mean to say to not use let bindings. I'm trying to say that
using 'fset' (i.e. cl-letf + the symbol-function place) looks like a
really bad idea to me. And, in this case, hooks and adivces are what is
usually used.



> (defun org-project-new-project ()
>   (interactive)
>   (let ((org-capture-templates org-project-templates))
> (org-capture)))
>
> ...

> I don't know what would be the alternative, but let-binding on
> org-capture-templates, let me clearly re-use the functionality without 
> polluting
> the global org-capture-templates variable and without re-implementing pretty
> much anything.

That looks to me like a perfect use of a let binding.  You bind a dynamic
*variable* using *let*, and, that variable is rebound, and used, during, and
only during 'org-capture'.



> I am very interested to hear more on the topic, since I would definitely like 
> to
> learn more about different techniques.

Variables are designed to be overriden (let bounds). Functions are not
(as there is only one binding at any given time).


> Hope that explains a bit more on the background of the experiment :).

I'm still confused about the i

Re: [BUG] Problems with :exports results for shell and plantuml code [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dzu/.emacs.d/straight/build/org-mode/)]

[Detlev Zundel]

Hi Bruno,

[...]

> Maybe:
>
>:exports result
> =>
>:exports results
>
> ?

Yes, indeed - you are 100% right.  Looking at it so long, I was blind.
It was good writing things down as I found my mistake soon after sending
my initial mail ;)

https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00295.html

Thanks for taking the time to getting back to me!

Best wishes
  Detlev

-- 
#define KSAMTIB_CIGAM_2SFFJ 0x8519 /* For detecting wrong-endian fs */
  -- include/linux/jffs2.h

Re: Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem understanding doc)

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> At any rate, shouldn't "2.2.3 Catching invisible edits" be a little
> bit more specific about what kind of invisible edits are concerned?
> Or perhaps just a warning that it is not all of them.

We can indeed at such warning, but it will probably be not very helpful.
Only typing, deleting char forward/backward and meta-return are
considering invisible edits now.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: How is org-enforce-todo-dependencies supposed to work?

[Ihor Radchenko]

Robert Nikander  writes:

> I’m trying to use todo dependencies.  I created the following tree, and set 
> the variable to `t` by evaluating the setq expression. But nothing changes. I 
> can use S- to cycle the TODO state of “Test Project" (none - TODO - 
> DONE) even though the children items are not DONE. Is that expected?
>
> ** TODO Test Project
> :PROPERTIES:
> :ORDERED: t
> :END:
> Test org-enforce-todo-dependencies. (setq org-enforce-todo-dependencies t)

This variable is supposed to be set via customization interface or via
setopt/custom-set-variables. Or before loading Org. 

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

How is org-enforce-todo-dependencies supposed to work?

[Robert Nikander]

Hi,

I’m trying to use todo dependencies.  I created the following tree, and set the 
variable to `t` by evaluating the setq expression. But nothing changes. I can 
use S- to cycle the TODO state of “Test Project" (none - TODO - DONE) 
even though the children items are not DONE. Is that expected?

** TODO Test Project
:PROPERTIES:
:ORDERED: t
:END:
Test org-enforce-todo-dependencies. (setq org-enforce-todo-dependencies t)
*** DONE One
*** TODO Two
*** TODO Three

thanks,
Rob

(org-version) => 9.6.1
(emacs-version) => GNU Emacs 28.2

Re: Should we extend org-catch-invisible-edits to more interactive commands? (was: Catching invisible edits: problem understanding doc)

[Alain . Cochard]

Ihor Radchenko writes on Fri 10 Feb 2023 09:56:

 > Only a handful of interactive commands support invisible edit
 > checks. In particular: self-insert-command (typing), deleting char
 > forward/backward, and `org-meta-return'.
 > 
 > I guess we may instead provide a defcustom and hook the check into
 > `pre-command-hook'. Would it be of interest?

Thank you for the feedback.  Let me add that the issue I raised was
not at all a theoretical/abstract one for me.  I constantly use 'undo'
to see where in the buffer I was working (then, I insert a space, do
'undo undo', and can resume what I was doing).  So obviously it would
be of a huge interest for me if org-catch-invisible-edits worked in
that case...

At any rate, shouldn't "2.2.3 Catching invisible edits" be a little
bit more specific about what kind of invisible edits are concerned?
Or perhaps just a warning that it is not all of them.



 > > PS: a very minor incidental point: after 'bar' has disappeared, the
 > > headline is then void, so I tend to say that the ellipsis should
 > > immediately disappear as well.
 > 
 > The headline still contains newlines.

Right.  Thanks.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: [PATCH] Introduce "export features"

[No Wayman]

often we include content in export templates that is only 
relevant in

particular situations.

“export features” allow for the specification of qualities of 
the org buffer
being exported that imply certain “features”, and how those 
features may be

implemented in a particular export.


now `\usepackage{svg}' is automatically added when exporting a 
buffer that

includes SVG images.



┌
│ (org-export-update-features 'beamer
│   (beamer-metropolis
│:condition (string-match-p \"metropolis$\" (plist-get info 
:beamer-theme))

│:snippet my-org-beamer-metropolis-tweaks
│:order 3))
└


As discussed on the Doom Emacs Discord, I strongly suggest 
renaming to avoid overloading the term "feature".
To me, your description indicates sinppets are inserted 
contextually.
Org has a similar notion of contexts with 
`org-capture-templates-contexts'.
A similar name would be better as it does not overload the term 
"feature", which already has a different meaning in elisp.

e.g. org-export-backend-contexts

Re: Problem with let/cl-letf binding stuff with org-capture

[Ihor Radchenko]

Arthur Miller  writes:

> Based on a Reddit thread:
>
> https://www.reddit.com/r/emacs/comments/10xhvd8/a_little_readstring_utility_using_an_org_mode/j7xziao/?context=3
>
> I did a small experiment to see if I can re-use org-capture, to just capture a
> string from a buffer, without actually writing to any file.

You can use a template target set to function pointing to temporary
buffer. + org-capture-before-finalize-hook

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Bruno Barbier  writes:

> Arthur Miller  writes:
>
>>> Bruno Barbier  writes:
>>> If you really want to just get the piece of text, you might be able to
>>> use the hook `org-capture-mode-hook' to replace the key binding to
>>> 'C-c C-c' in the capture buffer, so that it calls your own function that
>>> will take the string and call `org-capture-kill'.
>>
>> In this case you wouldn't like to replace the key binding, it would affect 
>> all
>> org-capture buffers; the point is just to replace it when called in certain
>> context (my-read-line). Let-binding the function in this context achieves
>> exactly the same effect of C-c C-c beng bound to my function but without
>> affecting all org-capture-buffers.
>
> The hook `org-capture-mode-hook' will be run in your special
> capture buffer. You can override the "C-c C-c" binding only there.

Yes and in every other capture buffer, so I would either have to test on some
variable, make another mode, or mode-map or something similar. Just to customize
on the key, instead of the value bound to that key.

>>
>> Yes, I am aware of both hooks and advising; but again, with those I would 
>> affect
>> all uses of the function, and that would lead to checking some global state 
>> or
>> variable to switch on, which is not optimal either. With let-binding we can 
>> have
>> different behaviour only in a certain context.
>
> Even if I could let bind the function at the right time, I would avoid
> that solution, as I can't garantuee that this global hack will not break
> other parts of Emacs (other captures, output filters, threads, timers,
> etc.).

Why do you think it will break other parts? This is not a global hack, on 
contrary it
exactly tries to prevent to be "global" in entire Emacs, by let-binding a name
to a local lambda, which becomes "global" only in that buffer. If that
explains.

Here is another version on the same theme, where I don't think you could modify 
the local
environment without let-binding at all:

#+begin_src emacs-lisp
(defun my-read-string (prompt)
  (let ((delta 20 )
(minibuffer-mode-map org-mode-map))
(window-resize (minibuffer-window) delta)
(cl-letf (((symbol-function 'org-ctrl-c-ctrl-c)
   (lambda ()
 (interactive)
 (let ((s (buffer-string)))
   (exit-minibuffer) s)))
  ((symbol-function 'minibuffer-mode) #'org-mode)
  ((symbol-function 'minibuffer-complete-and-exit) #'org-return)
  ((symbol-function 'org-kill-note-or-show-branches) 
#'keyboard-escape-quit))
  (read-string (concat "# Press C-c C-c to continue, C-c C-k to cancel\n# " 
prompt "\n\n")
#+end_src

read-string is written in C and creates its own minibuffer, which is deleted by
the time read-string exits. I don't know of any other way to cutomize exactly
*that* minibuffer, without installing a hook or advising some functions, which I
think is way less clean and much more "global" than just running the function in
a local environment. As I understand, let binding for this purpose is a normal
technique in lisps, but I am not an expert as said; I am actually experimenting
with this for the purpose of learning and seeing what is possible.

Of course, we can always write our own read-string function and re-implement the
function from scratch, which author of that blog actually did. The experiment
was to test if I can modify the existing functionality to re-use, rather than to
re-invent something. Since read-string functions does not let us specify buffer,
mode, etc, let binding is one way of doing it locally.

Considering how org-capture works, the same technique of just modifying the
local environment is not really applicable; now when you reminded me that
capture buffer lives longer then let-binding, I understand what happens. I can
access the buffer after org-capture exits, in my-read-string:

(with-current-buffer
(try-completion "CAPTURE" (mapcar #'buffer-name (buffer-list)))
 (  do the thng  )

but I am not sure if I can do anything here without introducing at-least an
extra keymap, to not install into the org-capture-mode-map, so I can as well
create a minor mode, but at this point it is not much different than
re-invinting the read-string, so I'll terminate my experiment here :).

But I wouldn't speak in some generic terms like "use hooks" or "advise" instead
of let-binding. Let binding is a powerful and legitimate technique to modify
local environment of functions. I am not really sure where it stands in
abstraction, if it is sort-of template, or interface programming, since I am not
that familiar with lisp (yet), but I do understand it has very good and powerful
uses. Consider this (you can actually eval an run from gnus, or in scartch):

#+begin_src emacs-lisp
 Project folder - org-capture related code
(defvar org-project-root-dir nil)
(defvar org-project-templates nil)
(defvar org-project-finalize-hooks nil)

(setq org-project-

Re: export to html, colored dates: org-mime export works but org to html does not

[Uwe Brauer]

> [ Adding Org ML back to CC ]
> Uwe Brauer  writes:


> See "13.9.12 CSS support" section of Org manual.

Thanks!

#+OPTIONS: html-style:nil

Works, maybe is too blunt, but good enough for me

-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

Re: export to html, colored dates: org-mime export works but org to html does not

[Ihor Radchenko]

[ Adding Org ML back to CC ]

Uwe Brauer  writes:

>>> | Will this work?
>>> | {{{IDATE(<2023-02-11>)}}}
>>> `
>>> 
>>> Does not work for me 
>> 
>> It does work. It's just that default css style for timestamps sets the
>> color of its own.
>
> Well but then what should I do on a practical level, how can I convince org
> To export with colored time stamps

See "13.9.12 CSS support" section of Org manual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ol.el: Recommend `browse-url' to `:follow' links

[Ihor Radchenko]

Max Nikulin  writes:

>> Maybe better add this to "A.3 Adding Hyperlink Types" section of the manual?
>
> If you you believe that the (info "(org) Adding Hyperlink Types") 
> section should be expanded then a complete example is necessary, some 
> ideas may be picked from
>
> https://orgmode.org/worg/org-faq.html#mailto-links
> https://orgmode.org/worg/org-faq.html#mid-url-handler
>
> While the manual section and the `org-link-parameters' docstring as the 
> reference may be cross-linked, some note on `browse-url' still may be 
> helpful in the latter.

I believe that examples like yours really belong to the manual, not to
the docstring. Your example is the shortest possible way to define a new
link type as opposed to writing a whole new library - something rather
hard to achieve for less experienced users.

So, I suggest to
1. Put your example to the beginning of "Adding Hyperlink Types" section
   of the manual as the simplest way to define a new link type and
   use ol-man as a more complex example if more features are needed.

2. Refer to (info "(org) Adding Hyperlink Types") from the docstring of
   `org-link-parameters'.

WDYT?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Ihor Radchenko]

Kevin Brubeck Unhammer  writes:

>> (defcustom org-clock-clocktable-language-setup
>> Contributions for other languages are also welcome.
>
> Here's Norwegian Nynorsk:
>
>   (setq org-clock-clocktable-language-setup
> '(
>
>   ("nn" "Fil"  "N"  "Tidspunkt" "Overskrift" "Tid" "ALT" "Total 
> tid" "Filtid" "Tid stempla ved")
>
>   ))
>
> Looking forward when I can delete that line from my init.el :)

Applied, onto main. On your behalf.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d2952e14d

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [HELP] Things to help Org that do not involve programming

[Ihor Radchenko]

Kevin Brubeck Unhammer  writes:

 More things also require translation in `org-export-dictionary'.
>
> The missing Norwegian Nynorsk "nn" org-export-dictionary entries:

Thanks!
Applied, onto main. On your behalf.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bd34cb3f9

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Async evaluation in ob-shell

[Ihor Radchenko]

Matt  writes:

> It seems to me like 02-ob-shell-async-non-file.patch is all that's needed for 
> basic async in ob-shell.  I'm able to run long processes like `guix pull' and 
> `guix package -u' calls without issue and the results look like I expect.  
> Similarly for running a web server, such as `python3 -m http.server' and 
> killing it.  
>
> Unless there's something you or others think needs to be done, I can get it 
> committed (and try to write a test or two for it).

1. You should provide all the docstrings.
2. I generally feel that separate async and separate session code are
   either duplicating the same code or edge cases considered by session
   code may popup in async code unexpectedly.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: export to html, colored dates: org-mime export works but org to html does not

[Ihor Radchenko]

Uwe Brauer  writes:

> | #+MACRO: IDATE @@html:@@$1@@html:@@
> | 
> | * Title <{{{IDATE(2023-02-11)}}}>  o {{{IDATE(<2023-02-11>)}}}
> | 
> | Will this work?
> | {{{IDATE(<2023-02-11>)}}}
> `
>
> Does not work for me 

It does work. It's just that default css style for timestamps sets the
color of its own.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [TIP] Exporting Maxima results to LaTeX

[Max Nikulin]

On 09/02/2023 03:40, Leo Butler wrote:

On Wed, Feb 08 2023, Max Nikulin wrote:

I am curious if it is possible to avoid duplication by e.g. using noweb.


... I am not aware of how to
remove that duplication--all the examples I have found in the worg
source do what I have done above.


I have tried

 >8 
#+begin_src elisp :exports results :results silent
  (require 'ob-org)
#+end_src

#+begin_src org :exports both :results drawer replace
  ,#+begin_src elisp :exports results
'((1 2 3) (4 5 6))
  ,#+end_src
#+end_src
 8< 

It is exported to LaTeX as

 >8 
\begin{verbatim}
#+begin_src elisp :exports results
  '((1 2 3) (4 5 6))
#+end_src
\end{verbatim}

\begin{center}
\begin{tabular}{rrr}
1 & 2 & 3\\[0pt]
4 & 5 & 6\\[0pt]
\end{tabular}
\end{center}
 8< 

For debugging of the inner src block it is necessary to swap escaping 
with the outer #+begin_src. I have not figured out how to add some text 
in between of the exported source code example and its result.

Re: [PATCH] Introduce "export features"

[Ihor Radchenko]

Timothy  writes:

> “export features” allow for the specification of qualities of the org buffer
> being exported that imply certain “features”, and how those features may be
> implemented in a particular export.
>
> This is done by augmenting the backend struct with two new fields:
> `feature-conditions' and `feature-implementations'.
>
> The feature conditions are resolved during the annotation of `info', in the 
> Org
> buffer after `#+include' expansion and the removal of comments.
>
> The feature implementations are expanded by the backend itself, in the case of
> `ox-latex' this currently means during preamble construction.

I am in favour of this.

Some comments on the code are below.

> +  `(("^[ \t]*#\\+print_bibliography:" . bibliography)

This will also match bibliography statements, which are not keywords.
For example, inside quote blocks.

> +  :group 'org-export-general
> +  :type '(alist :key-type
> +(choice (regexp :tag "Feature test regexp")
> +(variable :tag "Feature variable")
> +(function :tag "Feature test function"))
> +:value-type
> +(choice (symbol :tag "Feature symbol")
> +(repeat symbol :tag "Feature symbols"

:package-version is missing in this defcustom. It should be added.

> +(defun org-export-detect-features (info)
> +  "Detect features from `org-export-conditional-features' in INFO."
> +  (let (case-fold-search)

This unconditionally sets case-sensitive search. Thus, for example,
#+PRINT_BIBLIOGRAPHY (as opposed to #+print_bibliography) will not be
recognized as 'bibliography feature.

> +(delete-dups
> + (mapcan
> +  (lambda (construct-feature)

This lambda could be a private function instead. A function would be
byte-compiled.

>  (defcustom org-latex-default-packages-alist
>'(("AUTO" "inputenc"  t ("pdflatex"))
>  ("T1"   "fontenc"   t ("pdflatex"))
> -("" "graphicx"  t)

You need to update :package-version upon changing the defcustom value.

> + Generated preamble
> +
> +(defcustom org-latex-conditional-features

defcustom :keywords are missing here. Please, add.

> +(,(lambda (info)
> +(org-element-map (plist-get info :parse-tree)
> +'link
> +  (lambda (link)
> +(and (member (org-element-property :type link)
> + '("http" "https" "ftp" "file"))
> + (file-name-extension (org-element-property :path link))
> + (equal (downcase (file-name-extension
> +   (org-element-property :path link)))
> +"svg")))
> +  info t))
> + . svg)

This is a duplicate of an entry in `org-export-conditional-features'. Is
it intentional?

> +(defcustom org-latex-feature-implementations

:package-version is missing.

> +  "Alist describing how export features should be supported in the preamble.
> +
> +Implementation alist has the feature symbol as the car, with the
> +cdr forming a plist with the following keys:
> +- :snippet, which is either,
> +  - A string, which should be included in the preamble verbatim.
> +  - A variable, the value of which should be included in the preamble.
> +  - A function, which is called with two arguments — the export info,
> +and the list of feature flags. The returned value is included in
> +the preamble.
> +- :requires, a feature or list of features which are needed.
> +- :when, a feature or list of features which imply this feature.
> +- :prevents, a feature or list of features that should be masked.
> +- :order, for when inclusion order matters. Feature implementations
> +  with a lower order appear first.  The default is 0."
> +  :group 'org-export-general

What is this group?

> +  :type '(plist :key-type
> +  (choice (const :snippet)
> +  (const :requires)
> +  (const :when)
> +  (const :prevents)
> +  (const :order)
> +  (const :trigger))
> +  :value-type
> +  (choice (string :tag "Verbatim content")
> +  (variable :tag "Content variable")
> +  (function :tag "Generating function"

The docstring and :type are rather generic wrt backend. Can they be
abstracted away?

> -(defun org-latex-guess-inputenc (header)
> +(defun org-latex-guess-inputenc (info)

It is a breaking change. Can we make something to not break existing
third-party code?

> -(defun org-latex-guess-babel-language (header info)
> +(defun org-latex-guess-babel-language (info)

Again, backwards-incompatible.

> -(defun org-latex-guess-polyglossia-language (header info)
> +(defun org-latex-guess-polyglossia-language (info)

backwards-incompatible

> +(concat
> + ;; Time-stamp.
> + (and (plist-get info :time-stamp-file)
> +  (format-time-string "%% Created %Y-%m-%d %a %H:%M\n"))

May it also be a feature?

> + ;;

Re: export to html, colored dates: org-mime export works but org to html does not

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

   > Uwe Brauer  writes:
   >> <2023-02-11>
   >> 
   >> But I would like to having the same result org-mime obtains
   >> 
   >> Namely 
   >> 
   >>  11.02.2023 
   >> 
   >> Any chance to get that also?

   > #+MACRO: IDATE @@html:@@$1@@html:@@

Thanks but 
,
| 
| #+LANGUAGE: 
| #+EXPORT_FILE_NAME: /home/oub/Desktop/testdate.html
| #+OPTIONS: toc:nil  
| #+HTML_HEAD_EXTRA:  body {font-size:150%}
| #+MACRO: IDATE @@html:@@$1@@html:@@
| 
| * Title <{{{IDATE(2023-02-11)}}}>  o {{{IDATE(<2023-02-11>)}}}
| 
| Will this work?
| {{{IDATE(<2023-02-11>)}}}
`

Does not work for me 


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

Re: [BUG] Smart quotes do not work in export when language is en-gb

[Ihor Radchenko]

ch.emacs--- via "General discussions about Org-mode."
 writes:

> When exporting a document to LaTeX with smart quotes enabled, I found 
> that this had been ignored (e.g. "hello" vs ``hello'' in the output). I 
> had the document language set to en-gb, which it seems disables smart 
> quotes, as there is no corresponding entry in org-export-smart-quotes 
> alist. This is inconsistent with org-latex-language-alist, which 
> correctly handles the en-gb case for babel and polyglossia.

Patches welcome.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: export to html, colored dates: org-mime export works but org to html does not

[Ihor Radchenko]

Uwe Brauer  writes:

> <2023-02-11>
>
> But I would like to having the same result org-mime obtains
>
> Namely 
>
>  class="timestamp"> 11.02.2023 
>
> Any chance to get that also?

#+MACRO: IDATE @@html:@@$1@@html:@@

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: export to html, colored dates: org-mime export works but org to html does not

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>>> #+MACRO: IDATE @@html:$1@@
>> 
>>> {{{IDATE(<2023-02-11>)}}}
>> ...
>> * Title {{{<2023-02-11>}}}
>> {{{(<2023-02-11>)}}}
>> 
>> 
>> Does not work when exporting to html, and I have recent developer org
>> version installed

> You forgot to specify IDATE macro name.

Oops that is true. Sorry, Now it works, but it does not do what I expect

I obtain 


<2023-02-11>

But I would like to having the same result org-mime obtains

Namely 

 11.02.2023 

Any chance to get that also?




-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

Re: export to html, colored dates: org-mime export works but org to html does not

[Bruno Barbier]

Uwe Brauer  writes:

 "BB" == Bruno Barbier  writes:
>
>> Uwe Brauer  writes:
>> ..
>
>>> (add-to-list 'org-export-filter-plain-text-functions 'my-html-red)
>> ..
>
>>> But if I have 
>>> #<2023-02-11>#
>>> in an org file and export it to html, no color is added to the timestamp.
>>> 
>>> I don't know how to debug this.
>>> 
>>> Any idea?
>
>> In org, "<2023-02-11>" is a date, not plain text. Thus, your function
>> doesn't get called with a text matching your date.
>
>> Note that using macros, you could get almost what you want. 
>
>> #+MACRO: IDATE @@html:$1@@
>
>> {{{IDATE(<2023-02-11>)}}}
>
>> And maybe ther is a way to also customize date format to get rid of the
>> brackets.
>
> Thanks, did you test it?
> I am asking because for me


I even did! :-)

You need to call the macro named 'IDATE' like this:

 * Title {{{IDATE(2023-02-11)}}}
 {{{IDATE(2023-02-11)}}}

See:
   (info "(org) Macro Replacement")

And it will work for you too.

Bruno
   

>
> #+LANGUAGE: 
> #+EXPORT_FILE_NAME: /home/oub/Desktop/testdate.html
> #+OPTIONS: toc:nil  
> #+HTML_HEAD_EXTRA:  body {font-size:150%}
> #+MACRO: IDATE @@html:$1@@
>
> * Title {{{<2023-02-11>}}}
> {{{(<2023-02-11>)}}}
>
>
> Does not work when exporting to html, and I have recent developer org
> version installed
>
> Uwe 
> -- 
> Warning: Content may be disturbing to some audiences
> I strongly condemn Putin's war of aggression against the Ukraine.
> I support to deliver weapons to Ukraine's military. 
> I support the ban of Russia from SWIFT.
> I support the EU membership of the Ukraine. 
> https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: export to html, colored dates: org-mime export works but org to html does not

[Ihor Radchenko]

Uwe Brauer  writes:

>> #+MACRO: IDATE @@html:$1@@
>
>> {{{IDATE(<2023-02-11>)}}}
> ...
> * Title {{{<2023-02-11>}}}
> {{{(<2023-02-11>)}}}
>
>
> Does not work when exporting to html, and I have recent developer org
> version installed

You forgot to specify IDATE macro name.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: export to html, colored dates: org-mime export works but org to html does not

[Uwe Brauer]

>>> "BB" == Bruno Barbier  writes:

> Uwe Brauer  writes:
> ..

>> (add-to-list 'org-export-filter-plain-text-functions 'my-html-red)
> ..

>> But if I have 
>> #<2023-02-11>#
>> in an org file and export it to html, no color is added to the timestamp.
>> 
>> I don't know how to debug this.
>> 
>> Any idea?

> In org, "<2023-02-11>" is a date, not plain text. Thus, your function
> doesn't get called with a text matching your date.

> Note that using macros, you could get almost what you want. 

> #+MACRO: IDATE @@html:$1@@

> {{{IDATE(<2023-02-11>)}}}

> And maybe ther is a way to also customize date format to get rid of the
> brackets.

Thanks, did you test it?
I am asking because for me 

#+LANGUAGE: 
#+EXPORT_FILE_NAME: /home/oub/Desktop/testdate.html
#+OPTIONS: toc:nil  
#+HTML_HEAD_EXTRA:  body {font-size:150%}
#+MACRO: IDATE @@html:$1@@

* Title {{{<2023-02-11>}}}
{{{(<2023-02-11>)}}}


Does not work when exporting to html, and I have recent developer org
version installed

Uwe 
-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

Re: export to html, colored dates: org-mime export works but org to html does not

[Bruno Barbier]

Uwe Brauer  writes:


..

>   (add-to-list 'org-export-filter-plain-text-functions 'my-html-red)
..

> But if I have 
> #<2023-02-11>#
> in an org file and export it to html, no color is added to the timestamp.
>
> I don't know how to debug this.
>
> Any idea?

In org, "<2023-02-11>" is a date, not plain text. Thus, your function
doesn't get called with a text matching your date.

Note that using macros, you could get almost what you want. 

#+MACRO: IDATE @@html:$1@@

{{{IDATE(<2023-02-11>)}}}

And maybe ther is a way to also customize date format to get rid of the
brackets.


Bruno

export to html, colored dates: org-mime export works but org to html does not

[Uwe Brauer]

Hi

The following drives me a bit crazy.

I have two functions, one for email.


(defun my-color-red-html ()
  (interactive)
  (while (re-search-forward "#\\([^#]*\\)#" nil t)
(replace-match "\\1")))

I put this function into  two hooks

  (add-hook 'org-mime-html-hook 'my-color-red-html)


(defun my-html-red (text backend info)
(when (org-export-derived-backend-p backend 'html)
  (replace-regexp-in-string "#\\([^#]*\\)#"
"\\1"
text)))

  (add-to-list 'org-export-filter-plain-text-functions 'my-html-red)

Now if I have 
#<2023-02-11>#
in an email it gets replaced by 

 11.02.2023 


But if I have 
#<2023-02-11>#
in an org file and export it to html, no color is added to the timestamp.

I don't know how to debug this.

Any idea?

Regards

Uwe Brauer 

-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [BUG] Problems with :exports results for shell and plantuml code [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dzu/.emacs.d/straight/build/org-mode/)]

[Bruno Barbier]

Detlev Zundel  writes:

> Hi orgmode-list!
>
> I currently have a problem while exporting org-babel blocks to html or
> latex output.  Even though I explicitely specify ':exports result' for
> the blocks, the exported document contains both the (syntax colored)
> code block and the code.  I noticed this in a plantuml block that I use
> to generate inline diagrams.  Exporting to PDF actually yields a PDF
> looking like it contains only the results, but there are errors in the
> '*Org PDF LaTeX Outupt*' buffer, saying that pygmentize misses a lexer
> for plantuml.  Checking the generated LaTeX code indeed shows that the
> code is exported to LaTeX, even though ':exports result' is passed as a
> header argument.

Maybe:

   :exports result
=>
   :exports results

?

Bruno