Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]

[Ihor Radchenko]

Bastien  writes:

>> https://todo.sr.ht/~emacs/emacs/2 could be somewhat useful.
>
> Yes, somewhat: but I'm not yet clear on the steps to set up a mirror.
>
> If anyone can guide me from A to Z, I'd be glad.

The discussion mentions some cron job.

Quick googling yielded
https://git.sr.ht/~janbaudisch/git-mirror
https://www.edwardthomson.com/blog/mirroring_git_repositories.html
https://dzone.com/articles/mirroring-git-changes-from-one-server-to-another-s

Also, we might try to setup the mirror job via builds.sr.ht, but AFAIK
there is no available periodic build trigger, and you may need to
request running the job via direct API request
(https://man.sr.ht/builds.sr.ht/graphql.md)

Hope it helps.

Best,
Ihor

Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> However, https://git.sr.ht/~bzg/org-mode does not appear to sync
> automatically. The last commit in https://git.sr.ht/~bzg/org-mode/log is
> 15 days ago.
>
> Can we setup automatic mirror sync?

Sure.

> https://todo.sr.ht/~emacs/emacs/2 could be somewhat useful.

Yes, somewhat: but I'm not yet clear on the steps to set up a mirror.

If anyone can guide me from A to Z, I'd be glad.

There is no hurry on this.

Thanks!

-- 
 Bastien

Re: About 'inline special blocks'

[Juan Manuel Macías]

Max Nikulin writes:

> If alternative text for images and description of
> links are not convincing [...]

It does convince me, Maxim, that's why I told you in my previous message
that you were right in that example you had put about the alternate
text. And my question was (and still is) if you consider that a scenario
of this type, where the attributes are part of the content and not the
output format (and the latter happens in 90% of the cases) could occur
in the inline special blocks. If so, then I'm fine with inline special
blocks supporting attributes. But in my opinion this data should somehow
go outside the paragraph. Or be hidden as in the links.

I still think, however, that the attributes are unnecessary for inline
special blocks. I can't find any examples where they might be needed and
not something that is resolved at the global style level[1] or via
export filter. But I'm open to considering examples and use cases.

[1] There are cases in LaTeX of commands with more than one argument,
e.g. \foreignlanguage{lang}{content}, \textcolor{color}{content} and
the like. But even those can be simplified from the preamble by defining
macros with a single argument. And in Babel you can also do something
like \babeltags{de = german} and write \textde{text in german}.

The csquotes package is an extreme case, where there are intra-paragraph
commands that take optional arguments to \cite and punctuation, but I
think org-cite would be more appropriate in these cases:

\foreigntextquote{lang}[cite][punct]{text}

Best regards,

Juan Manuel 

Re: Missing from Info

[Colin Baxter]

> Ihor Radchenko  writes:

> Colin Baxter  writes:
>> The latest org-mode info has a section entitled: "13.10.2 LaTeX
>> specific export settings". At the foot of that Section is the
>> line: "The following sections have further details." There is
>> nothing following.

> I do have section 13.10.3 and the subsequent sections on my side.
> Could you please check the location of your info file by running
> M-: default-directory  when inside the info buffer and
> sharing the output?

> Best, Ihor

M-: produces "/home//git/org-mode/doc/"

Is it not that the org version has indeed further sections beneath, but
these are not visible on the single info page?

Best wishes,

Re: About 'inline special blocks'

[Max Nikulin]

On 21/06/2022 02:06, Juan Manuel Macías wrote:

Max Nikulin writes:


I would like to stress that styles can not be a rescue in some
important cases. Let's leave aside ad hoc final tuning of formatting.
In the case of HTML export there are still  and
 attributes that are namely
per-object, not part of style.


You are right, but my question is: Could there be a similar use case
within inline special blocks? Keep in mind that this (for now,
hypothetical) element type would be intended only for very short
segments of text within the paragraph. I don't find a scenario where
it's worth overloading that with options and attributes, IMHO.


Juan Manuel, your answer is not clear for me. Direct formatting is 
another issue. There are cases when attributes are part of *content*, 
not formatting. If alternative text for images and description of links 
are not convincing, there is e.g.


Org document may be exported as
HTML file.

Do you consider inline special blocks solely for formatting and only for 
the kind of it that may be expressed through styles? Then attributes for 
inline objects should be another feature with its own syntax.



in html:
contents>


Concerning  vs. , is it the same for
assistive technologies like screen readers to add
text (or text) and text with "font-weight: bolder;" in CSS?


"contents>": it was my confusion, sorry. I already explained
it here: https://list.orgmode.org/8735g0tnoh@posteo.net/


I am unsure that content should not be supported at all. 
However I admit that difference of the following code may be 
insignificant in reality:


Do not do it!
vs.
Do not do it!

Re: Proposal: 'executable' org-capture-templaes

[Max Nikulin]

On 21/06/2022 11:07, Ihor Radchenko wrote:

Max Nikulin writes:

The other question is altering the org-capture code.
I think that it is too early to discuss org-capture part just yet.
Lets first finalize the generic library itself and discuss the
appropriate adjustments to
org-capture/org-agenda/org-export/org-todo/etc code later.


From my point of view changing menu without adjusting calling logic is 
a kind of trade-off with uncertain net result. New UI may significantly 
affect different user expectations. It seems this is the point of our 
disagreement. You tend to consider menu in isolation trying to postpone 
the question concerning interaction of code running before menu creation 
and handlers of menu items (they are not belong to the same call stack 
any more).


What I am really afraid is words like:


Sure. That somewhere can be buffer-local variable inside the capture
menu buffer. Or global variable. Or closure. How is it relevant to the
capture menu?


I am trying to avoid implementation of menu that would make passing 
state to handlers unreliable or prohibitively complicated.


Global variables are certainly not an option because such approach does 
not allow several instances of menu created in parallel.


To use buffer-local variables some support from the side of menu library 
is required. Buffer does not exist when menu function is called. So 
either some callback should be passed to menu to be invoked when a new 
buffer is created for menu or that buffer should be returned from the 
menu creating function. Unsure if (current-buffer) would be a reliable 
approach.


Closures should work, but would be it convenient enough?

Maybe some intermediate layer should be introduced to make alternative 
implementation of menu (transient, completing read, etc.) easier.


I believe, discussing design of menu without evaluation if it is 
suitable to features that should use it (capture, agenda, etc.), there 
is a risk to create unreasonable restrictions on further steps.


That is why I consider the following aspects of menu design as essential 
ones:
- A clearly determined way to pass some state from a function that 
requests creation of menu to handlers of menu items.
- When a non-blocking technique to wait user decision is used, multiple 
instances of the same menu should be allowed.
- Defined extension points for alternative implementations to avoid code 
duplication and divergence of behavior.


My fear is that if such points are ignored in the beginning, it may 
become impossible later.

Re: [PATCH v3] ol.el: add description format parameter to org-link-parameters

[Max Nikulin]

On 21/06/2022 19:03, Hugo Heagren wrote:

+(defmacro test-ol-with-link-parameters-as (type parameters &rest body)

[...]

+  `(progn
+ (setq orig-parameters org-link-parameters)


I can easily miss something, but wouldn't it be enough to use let-binding

`(let ((org-link-parameters org-link-parameters))
   ,@body)

Otherwise it is better to use something like `condition-case' to restore 
original state even when some error is signaled.



+ (org-link-set-parameters ,type ,@parameters)
+ (let ((rtn (progn ,@body)))
+   (setq org-link-parameters orig-parameters)
+   rtn)))

Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]

[Ihor Radchenko]

Bastien  writes:

>> There is such a SourceHut project: https://sr.ht/~bzg/orgmode/
>
> The sr.ht project is now on https://sr.ht/~bzg/org/ and lists all
> relevant repositories, including a mirror of the official org-mode
> repository at https://git.sr.ht/~bzg/org-mode.

I just found some complaints about stability of savannah:

https://github.com/doomemacs/doomemacs/blob/master/modules/lang/org/packages.el

;; REVIEW I intentionally avoid git.savannah.gnu.org because of SSL
   ;;   issues (see #5655), uptime issues, download time, and lack of
   ;;   shallow clone support.
   :repo "emacs-straight/org-mode"

So, having an official mirror could be handy.

However, https://git.sr.ht/~bzg/org-mode does not appear to sync
automatically. The last commit in https://git.sr.ht/~bzg/org-mode/log is
15 days ago.

Can we setup automatic mirror sync?
https://todo.sr.ht/~emacs/emacs/2 could be somewhat useful.

Best,
Ihor

Implementing ox-beamer property support in ox-latex.

[General discussions about Org-mode.]

Dear list,

I recently fell in love with the properties support provided by ox-beamer. 
Especially in combination with an appropriate column view, this feature allows 
you to create complex presentations and maintain a good overview of all slides, 
layouts and possible transitions. 

Today I attempted to implement similar behaviour for ox-latex, with moderate 
success. 

The problem that I encountered was that you can't easily "close" environments. 
The example below shows what I mean:
* First section
** First subsection
Some text before the definition.
*** Definition 1
:PROPERTIES:
:LATEX_ENV: definition
:END:
This is a definition
*** This title is ignored and very ugly
:PROPERTIES:
:LATEX_ENV: empty
:END:
Some text behind the definition.
** Subsection
This is a new subsection.

Expands to: 
\begin{document}\section{First section}
\subsection{First subsection}
Some text before the definition.
\begin{definition}[Definition 1]
This is a definition
\end{definition}
Some text behind the definition.
\subsection{Subsection}
This is a new subsection.
\end{document}

In order to indicate that the body of definition 1 has endend, I needed to 
create an empty block which is ignored by the exporter. 

Is there an elegant way to solve this problem and to "close" a heading?
Maybe in the form of an alternative carriage return character or a multiple 
line breaks?

Kind regards, 
Bob

RE: [BUG] [9.6 (9.6-??-971eb68 @ c:/Users/xpar/.emacs.d/.local/straight/build-27.2/org/)]

[Ihor Radchenko]

Lourens van der Vliet  writes:

> Org mode version 9.6 (9.6-??-971eb68 @ 
> c:/Users/xpar/.emacs.d/.local/straight/build-27.2/org/)
> I performed this week a sync with doom emacs. This the last version. 

Nope. 971eb68 is a 3 month old commit.
Looking at
https://github.com/doomemacs/doomemacs/blob/master/modules/lang/org/packages.el
Doom should also use a later (1 week old) version.

Can you first update Org and try to reproduce again?

Best,
Ihor

RE: [BUG] [9.6 (9.6-??-971eb68 @ c:/Users/xpar/.emacs.d/.local/straight/build-27.2/org/)]

[Lourens van der Vliet]

Hoi Ihor

Org mode version 9.6 (9.6-??-971eb68 @ 
c:/Users/xpar/.emacs.d/.local/straight/build-27.2/org/)
I performed this week a sync with doom emacs. This the last version. 

Groet,
Lourens

-Original Message-
From: Ihor Radchenko  
Sent: Thursday, June 16, 2022 3:42 PM
To: Lourens van der Vliet 
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] [9.6 (9.6-??-971eb68 @ 
c:/Users/xpar/.emacs.d/.local/straight/build-27.2/org/)]

[U ontvangt vaak geen e-mail van yanta...@gmail.com. Informatie over waarom dit 
belangrijk is op https://aka.ms/LearnAboutSenderIdentification]

Lourens van der Vliet  writes:

> Remember to cover the basics, that is, what you expected to happen and
>
> what in fact did happen.  You don't know how to make a good report?  See

Could you kindly tell us what exactly happened?

Best,
Ihor
CAUTION:   External Sender. Validate sender email address before clicking 
links/attachments or replying.

Re: [PATCH v3] ol.el: add description format parameter to org-link-parameters

[Robert Pluim]

> On Tue, 21 Jun 2022 13:03:32 +0100, Hugo Heagren  said:

Hugo> They're very nearly just right, but for some reason
Hugo> `test-ol-with-link-parameters-as' doesn't always reset the parameters
Hugo> correctly for me. However I have them set to originally, it sets
Hugo> `:default-description' to a lambda. This might be a quirk at my end
Hugo> though -- if someone else could have a look I'd be very grateful.

They way your macro is defined, it uses `orig-parameters' in a way
that it will leak into the global namespace. Better would be to do

(let ((orig-parameters org-link-parameters))
   ...
  (setq org-link-parameters orig-parameters)

Robert
-- 

Re: org-table in comment environments

[Ihor Radchenko]

Uwe Brauer  writes:

> I have a org-table in a comment environment, since I don't want to export it. 
>
> However you can I edit the table using org-table commands, orgtbl-mode
> is ignored, so what shall I do?
>
> That seems as a stupid question, but I can't find its obvious answer.

Everything inside comment is considered verbatim.

I recommend to hide such table inside drawer and set
org-export-with-drawers appropriately.

Best,
Ihor

Re: [PATCH] ox.el: Protect export from auto-formatting hooks

[David Lukeš]

Please ignore this patch!

Apologies, as I was sending another patch today, I thought I hadn't
followed up on my earlier promise to send a patch for this issue. It
turns out I have, it just hasn't been reviewed/merged yet:
https://list.orgmode.org/20220228140750.75761-1-dafydd.lu...@gmail.com/

(I didn't find it at first because I'd searched the mailing list
archive for my surname with diacritics, but the patch is signed with
my surname *without* diacritics.)

The earlier patch is better, please ignore this one. Sorry for wasting
everyone's time.

David

[PATCH] ox.el: Protect export from auto-formatting hooks

[David Lukes]

* ox.el, ox-odt.el: Use `write-region' instead of `write-file' or
`save-buffer' to protect generated export buffers from auto-formatting
hooks.

In particular, `tidy' is often configured as the auto-formatter for HTML
and XML, and it can corrupt the exports.

TINYCHANGE
---
 lisp/ox-odt.el | 4 ++--
 lisp/ox.el | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 9d47067..ec1c360 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -1411,7 +1411,7 @@ original parsed data.  INFO is a plist holding export 
options."
(level (string-to-number (match-string 2
(if (wholenump sec-num) (<= level sec-num) sec-num))
(replace-match replacement t nil
-  (save-buffer 0)))
+  (write-region nil nil buffer-file-name)))
   ;; Update content.xml.
 
   (let* ( ;; `org-display-custom-times' should be accessed right
@@ -4004,7 +4004,7 @@ contextual information."
   ;; Prettify output if needed.
   (when org-odt-prettify-xml
 (indent-region (point-min) (point-max)))
-  (save-buffer 0)
+  (write-region nil nil buffer-file-name)
   ;; Run zip.
   (let* ((target --out-file)
  (target-name (file-name-nondirectory target))
diff --git a/lisp/ox.el b/lisp/ox.el
index c75357b..66d18c4 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6553,14 +6553,14 @@ or FILE."
   (with-temp-buffer
 (insert output)
 (let ((coding-system-for-write ',encoding))
-  (write-file ,file)))
+  (write-region nil nil ,file)))
   (or (ignore-errors (funcall ',post-process ,file)) ,file)))
 (let ((output (org-export-as
backend subtreep visible-only body-only ext-plist)))
   (with-temp-buffer
 (insert output)
 (let ((coding-system-for-write encoding))
- (write-file file)))
+ (write-region nil nil file)))
   (when (and (org-export--copy-to-kill-ring-p) (org-string-nw-p 
output))
 (org-kill-new output))
   ;; Get proper return value.
-- 
2.36.1

Re: [BUG] Editing link hides text

[Ihor Radchenko]

Tor Kringeland  writes:

> Most of the text will then be hidden, with "test" showing as a link, as
> expected.  However if I remove the last ], the link highlighting
> disappears and only "test" is shown like regular text (/i.e./ instead of
> "[[123][test]" as would be expected).  If I insert a character at the
> end or move the text, it is updated and "[[123][test]" shows as
> expected.

Fixed on main via 7c61a3a80.

Best,
Ihor

org-table in comment environments

[Uwe Brauer]

Hi

I have a org-table in a comment environment, since I don't want to export it. 

However you can I edit the table using org-table commands, orgtbl-mode
is ignored, so what shall I do?

That seems as a stupid question, but I can't find its obvious answer.

Regards

Uwe Brauer 

-- 
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. 

Re: [PATCH v3] ol.el: add description format parameter to org-link-parameters

[Hugo Heagren]

I've finally had time to the `:default-description' parameter in
`org-link-parameters'.

Ihor Radchenko  writes:

> I recommend writing tests for org-insert-link in
> testing/lisp/test-ol.el and testing expected behaviour for various
> values of :default-description.

Good advice! I haven't written many tests before, so this was a
challenge. I've attached a patch with some tests for the expected
behaviour. These include a couple of macros and a function, to stop
the definitions being too huge and unwieldy.

All the tests pass on my machine.

They're very nearly just right, but for some reason
`test-ol-with-link-parameters-as' doesn't always reset the parameters
correctly for me. However I have them set to originally, it sets
`:default-description' to a lambda. This might be a quirk at my end
though -- if someone else could have a look I'd be very grateful.

The tests showed that my previous approach doesn't work generally
enough. I've moved where `type' is defined in the code, to cover all
cases.

> Firstly, def will be undefined inside the error clause.

I've defined def a bit further up in a `let', and run the error clause
inside this.

> Secondly, when :default-description is a lambda expression and that
> expression fails, your code will fail with "wrong-type-argument
> symbolp" when executing (symbol-name def). Please consider cases
> when `def' is not a string and not a function symbol.

Dealt with this by just using `message " %S: "', since %S will
print a symbol, a string or a lambda correctly.

Hope this is a bit better!

Best,
Hugo
>From 5a44edfda4e09a95bba1327c2758b2637e5b16bd Mon Sep 17 00:00:00 2001
From: Hugo Heagren 
Date: Tue, 21 Jun 2022 12:45:50 +0100
Subject: [PATCH 2/2] test-ol: tests for default-description param when
 inserting links

Add tests for various values of `:default-description' in
`org-link-parameters'.
---
 testing/lisp/test-ol.el | 77 +
 1 file changed, 77 insertions(+)

diff --git a/testing/lisp/test-ol.el b/testing/lisp/test-ol.el
index 429bb52ee..7524d73af 100644
--- a/testing/lisp/test-ol.el
+++ b/testing/lisp/test-ol.el
@@ -625,5 +625,82 @@ See https://github.com/yantar92/org/issues/4.";
 (test-ol-parse-link-in-text
 "The http://foo.com/(something)?after=parens link"
 
+;;; Insert Links
+
+(defmacro test-ol-with-link-parameters-as (type parameters &rest body)
+  "Pass TYPE/PARAMETERS to `org-link-parameters' and execute BODY.
+
+Save the original value of `org-link-parameters', execute
+`org-link-set-parameters' with the relevant args, execute BODY
+and restore `org-link-parameters'.
+
+TYPE is as in `org-link-set-parameters'.  PARAMETERS is a plist to
+be passed to `org-link-set-parameters'."
+  `(progn
+ (setq orig-parameters org-link-parameters)
+ (org-link-set-parameters ,type ,@parameters)
+ (let ((rtn (progn ,@body)))
+   (setq org-link-parameters orig-parameters)
+   rtn)))
+
+(defun test-ol-insert-link-get-desc (&optional link-location description)
+  "Insert link in temp buffer, return description.
+
+LINK-LOCATION and DESCRIPTION are passed to
+`org-insert-link' (COMPLETE-FILE is always nil)."
+  (org-test-with-temp-text ""
+(org-insert-link nil link-location description)
+(save-match-data
+  (when (and
+ (org-in-regexp org-link-bracket-re 1)
+ (match-end 2))
+(match-string-no-properties 2)
+
+(defun test-ol/return-foobar (_link-test _desc)
+  "Return string \"foobar\".
+
+Take (and ignore) arguments conforming to `:default-description'
+API in `org-link-parameters'.  Used in test
+`test-ol/insert-link-default-description', for the case where
+`:default-description' is a function symbol."
+  "foobar")
+
+(ert-deftest test-ol/insert-link-default-description ()
+  "Test `:default-description' parameter handling."
+  ;; String case
+  (should
+   (string=
+"foobar"
+(test-ol-with-link-parameters-as
+ "id" (:default-description "foobar")
+ (test-ol-insert-link-get-desc "id:foo-bar"
+  ;; Lambda case
+  (should
+   (string=
+"foobar"
+(test-ol-with-link-parameters-as
+ "id" (:default-description (lambda (_link-test _desc) "foobar"))
+ (test-ol-insert-link-get-desc "id:foo-bar"
+  ;; Function symbol case
+  (should
+   (string=
+"foobar"
+(test-ol-with-link-parameters-as
+ "id" (:default-description #'test-ol/return-foobar)
+ (test-ol-insert-link-get-desc "id:foo-bar"
+  ;; `:default-description' parameter is defined, but doesn't return a
+  ;; string
+  (should-error
+   (test-ol-with-link-parameters-as
+"id" (:default-description #'ignore)
+(test-ol-insert-link-get-desc "id:foo-bar")))
+  ;; Description argument should override `:default-description'
+  (should
+   (string=
+"notfoobar"
+(test-ol-with-link-parameters-as
+ "id" (:default-description "foobar")
+ (test-ol-insert-link-get-desc "id:foo-bar" "notfoobar")
+
 (provide 'test-ol)
 ;;; test-ol.el 

Re: Missing from Info

[Ihor Radchenko]

Colin Baxter  writes:

> The latest org-mode info has a section entitled: "13.10.2 LaTeX specific
> export settings". At the foot of that Section is the line: "The
> following sections have further details." There is nothing following.

I do have section 13.10.3 and the subsequent sections on my side.
Could you please check the location of your info file by running
M-: default-directory  when inside the info buffer and sharing the
output?

Best,
Ihor

[PATCH] oc-basic.el: Stringify year from CSL-JSON date-parts

[David Lukes]

* lisp/oc-basic.el (org-cite-basic--parse-json): Make sure year
extracted from date-parts is returned as string.  Raise error if
original type other than number or string.

The stringifiation is motivated by errors like the following on Emacs 28
with nativecomp:

Error during redisplay: (jit-lock-function 544) signaled
(wrong-type-argument "Argument is not a string or a secondary string:
2007")

Additionally, the type check will warn users about problems in their
CSL-JSON bibliographies.

TINYCHANGE
---
 lisp/oc-basic.el | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
index a937f75..f10b95b 100644
--- a/lisp/oc-basic.el
+++ b/lisp/oc-basic.el
@@ -189,7 +189,14 @@ Return a hash table with citation references as keys and 
fields alist as values.
 (cons 'year
   (cond
((consp date)
-(caar date))
+ (let ((year (caar date)))
+   (cond
+ ((numberp year) (number-to-string 
year))
+ ((stringp year) year)
+ (t
+   (error
+ "First element of CSL-JSON 
date-parts should be a number or string, got %s: %S"
+ (type-of year) year)
((stringp date)
 (replace-regexp-in-string
   (rx
-- 
2.36.1

Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)

[David Lukeš]

Bruce: Understood, I was just thinking forward :) Thank you for the
details. As far as I'm concerned, EDTF in CSL JSON sounds like a good
idea (but it's not like my opinion should particularly matter).

Ihor: Thank you for the feedback! I'll send a proper patch then.

Best,

David

Re: [PATCH] Re: [BUG] Adding note to heading without newline at the end

[Ihor Radchenko]

Tor Kringeland  writes:

> Ihor Radchenko  writes:
>
>> Aha. Not saving is an important piece of information.
>> (said the person with compulsive saving syndrome)
>
> Thanks!  This fixes the bug (which was present in both Org 9.5 and 9.6)
> for me.  However, my original bug, which is only present in Org 9.6, is
> still there.  Do the same thing but set org-log-into-drawer to t.  Then
> ...

Confirmed.

Samuel, do you want to try fixing this?
It should be fairly easy to debug.

Best,
Ihor

Re: [PATCH] Re: [BUG] Adding note to heading without newline at the end

[Tim Cross]

Tor Kringeland  writes:

> Ihor Radchenko  writes:
>
>> Aha. Not saving is an important piece of information.
>> (said the person with compulsive saving syndrome)
>
> Thanks!  This fixes the bug (which was present in both Org 9.5 and 9.6)
> for me.  However, my original bug, which is only present in Org 9.6, is
> still there.  Do the same thing but set org-log-into-drawer to t.  Then
>
> #+begin_example
> * test
> #+end_example
>
>
> becomes
>
> #+begin_example
> * tes
> :LOGBOOK:
> - Note taken on [2022-06-21 Tue 12:55]
> :END:
> t
> #+end_example
>
> This bug also only happens if there is no trailing newline in the
> buffer.

Not sure if this makes any difference wrt your bug, but wanted to point
out that your test example block is non-conforming. If you have a line
starting with an '*', you have ot proceed it with a comma to escape the
meaning of the start. If you use org-edit-special to edit the block
contents, the escaping is done for you automatically. Running org-lint
is also useful when you think you might have a bug as it will ensure you
have a relatively clean and correct input file. 

Re: Mastodon link type for capturing toots?

[Christian Moe]

Yes, I probably will write my own (and share it here). Just wanted to
check first if the wheel had already been invented, as I'm feeling
lazy. Thanks for confirming it probably hasn't.

Yours,
Christian

Ihor Radchenko writes:

> Christian Moe  writes:
>
>> Has anyone written a link type for Mastodon that would allow you to
>> org-capture the post/status ("toot") at point?
>>
>> I'm referring to mastodon.el
>> (https://codeberg.org/martianh/mastodon.el), which is available via
>> install-packages.
>
> No AFAIK. But it is very easy to define new link types in Org. You can
> do it yourself. See A.3 Adding Hyperlink Types section of the manual.
>
> Best,
> Ihor

Re: [PATCH] Re: [BUG] Adding note to heading without newline at the end

[Tor Kringeland]

Ihor Radchenko  writes:

> Aha. Not saving is an important piece of information.
> (said the person with compulsive saving syndrome)

Thanks!  This fixes the bug (which was present in both Org 9.5 and 9.6)
for me.  However, my original bug, which is only present in Org 9.6, is
still there.  Do the same thing but set org-log-into-drawer to t.  Then

#+begin_example
* test
#+end_example

becomes

#+begin_example
* tes
:LOGBOOK:
- Note taken on [2022-06-21 Tue 12:55]
:END:
t
#+end_example

This bug also only happens if there is no trailing newline in the
buffer.

[PATCH] org.el (org-read-date): Point to Info documentation

[Robert Pluim]

I was just about to start implementing calendar navigation commands
for org-read-date, except that they all already exist :-). Theyʼre
just not documented in the docstring, only in the manual. Patch
adding a cross-reference attached.

Robert
-- 
>From bded6dfd8d6340d8330f8c1f11a46a140082f3b5 Mon Sep 17 00:00:00 2001
From: Robert Pluim 
Date: Tue, 21 Jun 2022 11:36:24 +0200
Subject: [PATCH] org.el (org-read-date): Point to Info documentation

* lisp/org.el (org-read-date): Add reference to Info documentation,
mainly because that describes all the available calendar navigation
commands.
---
 lisp/org.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 5b034ae12..c1fb8df4f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13327,6 +13327,9 @@ (defun org-read-date (&optional with-time to-time from-string prompt
 While prompting, a calendar is popped up - you can also select the
 date with the mouse (button 1).  The calendar shows a period of three
 months.  To scroll it to other months, use the keys `>' and `<'.
+There are many other calendar navigation commands available, see
+Info node `(org) The date/time prompt' for a full list.
+
 If you don't like the calendar, turn it off with
(setq org-read-date-popup-calendar nil)
 
-- 
2.35.1.607.gf01e51a7cf

Beamer export: Executing LaTeX between two frames

[M . ‘quintus’ Gülker]

Dear list,

I am working on a presentation for a conference (using org-mode and its
beamer export) and want to exchange the entire background for a specific
frame with an image. This is possible with Beamer, see
. It works by issueing
\usebackgroundtemplate /between/ the frame environments. The frame
environment needs to be placed inside an extra group of {}, resulting in
a LaTeX construct like this (example taken from the StackExchange link):

% Local background must be enclosed by curly braces for grouping.
{
\usebackgroundtemplate{\includegraphics[width=\paperwidth]{kitten.jpg}}%
\begin{frame}{Kitten}
\begin{itemize}
\item 1
\item 2
\item 3
\end{itemize}
\end{frame}
}

I tried to use a #+begin_export beamer construct to achieve this from
within org:

* Normal Frame

#+begin_export beamer
{\usebackgroundtemplate{%
\includegraphics[width=\paperwidth,height=\paperheight]{test.jpg}}
\begin{frame}[t]\frametitle{This frame should have another background}
% ...frame content...
\end{frame}
}
#+end_export

* Normal frame again

But that results in a LaTeX compilation error, because the command is
not issued between to frames, but within the frame created for the
"Normal Frame" heading. Breaking the construct up in two #+begin_export
beamer constructs like this therefore also does not work, because the
second heading causes an \end{frame} to be inserted after the
\usebackgroundtemplate group has been opened:

* Normal Frame

#+begin_export beamer
{\usebackgroundtemplate{%
\includegraphics[width=\paperwidth,height=\paperheight]{test.jpg}}
#+end_export

* This frame should have another background

#+begin_export beamer
}
#+end_export

* Normal frame again

So, how do I wrap the \begin{frame}...\end{frame} construct within the
\usebackgroundtemplate group?

  -quintus

--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

Max Nikulin  writes:

> On 20/06/2022 19:10, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> Sure. I was hinting about such functionality in the new library we are
>> discussing. Multiple capture menus are not possible now anyway, so it
>> will be a new feature if we decide that we need it (I am not 100% sure
>> if having multiple menus is not going to be confusing).
>
> In my opinion application logic should be consistent with UI. Do you think
> current behavior of help buffers has no problems? If so I have no chance to
> convince you that upgrade of menu should be accompanied by changes in
> org-capture.
>
> Consider the following case. A user has 2 virtual desktops dedicated to rather
> independent tasks and an Emacs frame on each desktop. On desktop 1 she opens
> help for some function with aim to evaluate if it is appropriate for some
> particular purpose. Next she has to switch to another task and applications 
> for
> it reside on virtual desktop 2. To proceed further she has to read several 
> help
> pages relevant for task 2. After completion of this task it is time to resume
> task 1 and to switch to virtual desktop 1. Does a window with the help buffer
> still display the same content as before switching to task 2? No, context on
> desktop 1 lost due to some actions in the Emacs frame on desktop 2.
>
> Such synchronization is against multitasking and I do not like the idea to get
> it for org-capture as well. Currently read-key and modal prompt is a kind of
> excuse, but the idea of new menu library is non-blocking keymap-based 
> selection.

Yes, that is true, current Emacs help-buffer implementation is not
designed with your use-case in mind. If we leave out "virtual desktops",
it is unimportant detail. What you speak about is that user is working with
two different contexts at the same time and prefers to keep each context
in it's own frame. Emacs as a whole is not designed to work in the way I
percieve it has clean separation between contexts in each frame. Menu
buffer is "global" for entire Emacs process, and there are other
features of Emacs that does not work well in such scenarion. Some people
prefer to keep an Emacs process per project/task for that reason.

I can agree with you, that it would be nice if things were not designed
the way they are, but I don't have an opinion how org-capture should
behave in that regard, and how much work would it be to design it the
way you suggest. With other words, I say neither yes or no to anything
:). I would just like to remind that we are speaking of two things here;
one is menu buffer, that is replacing org-mks & co, as in org-agenda and
other places Ihor mentioned in earlier mails, and the other one is
org-capture itself.

>>> Currently several capture menu instances may be requested though
>>> org-protocol (or calling org-capture from emacsclient). The behavior is
>>> rather confusing. New menu may help to fix the issue, that is why I
>>> raised the question about parallel captures.
>> I am not sure which behavior you have in mind.
>
> try the following commands without selecting a template in an Emacs frame in
> between
>
> emacsclient 'org-protocol:/capture?url=url-A&title=title-A&body=body=A'
> emacsclient 'org-protocol:/capture?url=url-B&title=title-B&body=body=B'
>
>> What I was thinking as a conservative implementation that would not
>> introduce any new features is replacing the old menu with the new one
>> every time the same menu is called. So, every time the user calls menu
>> (e.g. capture menu), only the last capture environment is preserved. The
>> previous, potentially unfinished, capture menus will be destroyed.
>
> Causing loss of user data. Currently it is hard to start new capture before
> selecting a template.

Current org-capture is one at a time because of how org-mks works. There
is nothing that prevents org-capture to open enumerated buffers,
org-caputre<1>, org-capture<2> etc. User has to manually serialize data
anyway, via C-c C-c from withing capture buffer? So in principle it is
still one capture buffer at a time that manipulates the file on the disk
itself?

Problem would arise if serialization takes long time, i.e. there is lots
of data to write to file, and user switches to another org-capture
buffer and tries to save that one. So the serialization itself has to be
guarded somehow, but a mutex or file lock or something. At least I think
so, I am not sure if I am correct completely. Just trying to think loud
about it.

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>> Consider the following case. A user has 2 virtual desktops dedicated to 
>> rather independent tasks and an Emacs frame on each desktop. On desktop 
>> 1 she opens help for some function with aim to evaluate if it is 
>> appropriate for some particular purpose. Next she has to switch to 
>> another task and applications for it reside on virtual desktop 2. To 
>> proceed further she has to read several help pages relevant for task 2. 
>> After completion of this task it is time to resume task 1 and to switch 
>> to virtual desktop 1. Does a window with the help buffer still display 
>> the same content as before switching to task 2? No, context on desktop 1 
>> lost due to some actions in the Emacs frame on desktop 2.
>>
>> Such synchronization is against multitasking and I do not like the idea 
>> to get it for org-capture as well. Currently read-key and modal prompt 
>> is a kind of excuse, but the idea of new menu library is non-blocking 
>> keymap-based selection.
>
> I understand.
> From the perspective of the library being discussed, what you want does
> not look impossible.
>
> The other question is altering the org-capture code.
> I think that it is too early to discuss org-capture part just yet.
> Lets first finalize the generic library itself and discuss the
> appropriate adjustments to
> org-capture/org-agenda/org-export/org-todo/etc code later.
>
I think it sounds like a wise proposal :).

Thanks.