Re: could a :var header argument refer to a data table in another file?

[Michael Welle]

Hello,

Eric S Fraga  writes:

> Hello all,
>
> TL;DR: I have the need to reference a table that is in another file to
> pass as data to a src block in the current file.  Is this possible?
> Hints welcome!
I smell something strange going on here ;). For every Org related
question I had in the last few weeks I found at least one other person
that had the same question roughly at the same time.

I use Org to generate projects, import stuff, set permissions etc. on
several servers for a software engineering course. I think it would be
nice to separate the student's personal data in Org tables from the Org
code that get checked into a repository.

My first attempt was :var data=data.org::remote-table, but the familiar
double colon didn't work, the single colon indeed did the trick.

Regards
hmw

Re: Notes about citations in Org (part 3)

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> This post is an update about "wip-cite-new" branch, which I rebased
> a few minutes ago. 

I'm attaching a call for help to this thread so that more people can
test this before we merge it into master.

Thanks again for this important work!

-- 
 Bastien

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Ihor Radchenko writes:

> I was recently testing Org mode using old Emacs versions. Running make
> on master fails with the following errors and warnings:

Here are a few notes on ones present in maint that I've glanced at.

> Compiling /home/yantar92/Git/org-mode/lisp/ol-eww.el...
>
> In org-eww-store-link:
> ol-eww.el:76:36:Warning: reference to free variable `eww-data'
>
> In end of data:
> ol-eww.el:182:1:Warning: the function `eww-current-url' is not known to be
> defined.

These are guarded by version checks.  Ideally the compatibility kludges
would be done in a way to avoid the warnings (e.g., with boundp/fboundp
guards) or at least wrapped in with-no-warnings, though harmless
warnings on Emacs 24 don't really matter too much at this point.

> In end of data:
> org-agenda.el:10851:1:Warning: the following functions are not known to be
> defined: funcall-interactively, window-font-width

Adding a compatibility function for window-font-width is tricky.  We
can't just add something like below to org-compat because font-info (C
code) wasn't added until Emacs 25.

  (if (fboundp 'window-font-width)
  (defalias 'org-window-font-width 'window-font-width)
(defun org-window-font-width ( window face)
  (with-selected-window (window-normalize-window window t)
(if (display-multi-font-p)
(let* ((face (if face face 'default))
   (info (font-info (face-font face)))
   (width (aref info 11)))
  (if (> width 0)
  width
(aref info 10)))
  (frame-char-width)

> In org-display-inline-images:
> org.el:16554:57:Warning: reference to free variable `image-map'

This warning is now gone (df84100d0), though functionally it was fine
due to a version check.

> In end of data:
> org.el:21292:1:Warning: the function `make-process' is not known to be
> defined.

This should be addressed by 869b7a21b.

Re: [PATCH] Fix numbering of captioned images

[Kyle Meyer]

Pablo Barraza Cornejo writes:

> Sounds good to me! I've modified the patch to reflect this change.
[...]
> Subject: [PATCH] ox-html.el/inline-image export: Fix caption numbering

Thanks.  Pushed (390063d8d).

Re: Big problem: org agenda freezes my process

[Ihor Radchenko]

torys.ander...@gmail.com (Tory S. Anderson) writes:

> Lately, when I try to view an orgmode agenda it seems that two things make it 
> cause my emacs CPU threat to spin to max and freeze up, which is a huge 
> problem since I'm an exwm user and live in my agenda view. As far as I've 
> been able to tell, when an item from today is clocked into multiple times in 
> the same day, it prompts most agenda actions to result in a freeze and some 
> kind of loop that is binding up my system. It has some gaps, so if I spam C-g 
> I will eventually, usually, escape given 30 seconds to 2 minutes.

Few generic things that may produce behaviour when Emacs is not reacting
to C-g:

Do you use any kind of fontification packages/customisation dealing with
org agenda? Does disabling font-lock-mode in agenda help? Do you have
any mode line customisation that may be affected? 

Best,
Ihor

Bug: org-columns does not respect global-visual-line-mode for long text within headlines

[Nick Savage]

Hello everyone,

I'm filing a bug in relation to org-columns and its interactions with 
global-visual-line-mode, which I do not think is expected behaviour.


1. Start `emacs -Q'
2. Create /tmp/test.org (or something like this)
3. Enable M-x global-visual-line-mode
4. Insert the following (or something like it, the purpose is to have a 
line that wraps on your screen with global-visual-line-mode enabled, you 
may need to add more characters if necessary)

* test headline
cc

5. Collapse headline, activate org-columns (C-c C-x C-c) on the headline.
6. Toggle visibility of headline, note that the line no longer wraps and 
instead acts as if global-visual-line-mode was not enabled.


I am investigating now but I thought I would post this as a bug 
regardless. The trace below is for the release of org-mode with 28.0.50, 
but I can confirm that it is the same on the current master.


Emacs  : GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 
3.24.5, cairo version 1.16.0)

 of 2021-01-15
Package: Org mode version 9.4.4 (release_9.4.4 @ 
/usr/local/share/emacs/28.0.50/lisp/org/)


current state:
==
(setq
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)

 org-occur-hook '(org-first-headline-recenter)
 org-babel-pre-tangle-hook '(save-buffer)
 org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-hide-drawers org-cycle-show-empty-lines

          org-optimize-window-after-visibility-change)
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-agenda-loop-over-headlines-in-active-region nil
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

 org-confirm-shell-link-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300
\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-show-all append local] 5]
         #[0 "\300\301\302\303\304$\207" [add-hook 
change-major-mode-hook org-babel-show-result-all append local] 5]

         org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-link-shell-confirm-function 'yes-or-no-p
 org-link-parameters '(("attachment" :follow org-attach-follow 
:complete org-attach-complete-link) ("id" :follow org-id-open)

           ("eww" :follow org-eww-open :store org-eww-store-link)
           ("rmail" :follow org-rmail-open :store org-rmail-store-link)
           ("mhe" :follow org-mhe-open :store org-mhe-store-link)
           ("irc" :follow org-irc-visit :store org-irc-store-link 
:export org-irc-export)
           ("info" :follow org-info-open :export org-info-export 
:store org-info-store-link)

           ("gnus" :follow org-gnus-open :store org-gnus-store-link)
           ("docview" :follow org-docview-open :export 
org-docview-export :store org-docview-store-link)
           ("bibtex" :follow org-bibtex-open :store 
org-bibtex-store-link)
           ("bbdb" :follow org-bbdb-open :export org-bbdb-export 
:complete org-bbdb-complete-link :store

            org-bbdb-store-link)
           ("w3m" :store org-w3m-store-link) ("file+sys") 
("file+emacs") ("shell" :follow org-link--open-shell)
           ("news" :follow #[514 "\301\300\302Q\"\207" ["news" 
browse-url ":"] 6 "\n\n(fn URL ARG)"])
           ("mailto" :follow #[514 "\301\300\302Q\"\207" 
["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"])
           ("https" :follow #[514 "\301\300\302Q\"\207" ["https" 
browse-url ":"] 6 "\n\n(fn URL ARG)"])
           ("http" :follow #[514 "\301\300\302Q\"\207" ["http" 
browse-url ":"] 6 "\n\n(fn URL ARG)"])
           ("ftp" :follow #[514 "\301\300\302Q\"\207" ["ftp" 
browse-url ":"] 6 "\n\n(fn URL ARG)"])
           ("help" :follow org-link--open-help) ("file" :complete 
org-link-complete-file)
           ("elisp" :follow org-link--open-elisp) ("doi" :follow 
org-link--open-doi))

 org-export-before-parsing-hook '(org-attach-expand-links)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-link-elisp-confirm-function 'yes-or-no-p
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)

 )

Re: stability of toc links

[Greg Minshall]

in this thread...

> > The publish feature only means exporting several files at once. 

> You can publish a single file, too. It makes sense when a file is always
> exported to the same location, possibly with the same configuration.

my model is that exporting is to publishing as, well, as org mode is to
latex.  the former is more user friendly; the latter gives me more
control (and more repeatability).

cheers, Greg

Re: Bug: First file opened does not colorize (tested with 9.3.7 and 9.4.5)

[Tim Cross]

What about running emacs -Q and then opening the org file. Does the
syntax highlighting work then?

Dominick Samperi  writes:

> Changing the suffix to .org does not help. Still the first file opened
> does not colorize.
> I first observed this problem about six months ago (and have been
> using a function
> key to fix with 'org-mode-restart).
>
> The problem does not appear on a new desktop, running
> the same version of Emacs, same version of org-mode, and same .emacs.d.
>
> The only notable difference between the new machine and the older machines
> where the problem occurs is that the newer machine has an solid state drive,
> whereas the other machines have conventional hard drives.
>
> On Fri, Apr 30, 2021 at 8:51 PM Samuel Wales  wrote:
>>
>> what if .org?
>>
>> On 4/30/21, Dominick Samperi  wrote:
>> > The first org mode file opened (.txt suffix) is not colorized. To force
>> > colorize I use 'org-mode-restart. Subsequently opened txt files are
>> > properly colorized. This happens under Windows 10 using Emacs 27.1 and
>> > 27.2, and org-mode 9.3.7 and 9.4.5. There are no problems under Ubuntu
>> > Linux.
>> >
>> > Oddly, the problem does not appear on my new desktop (Lenovo). It
>> > happens on my ASUS laptop. I'm using the same version of org-mode and
>> > Emacs on both machines.
>> >
>> > I copied .emacs.d from the desktop to the laptop
>> > to be sure the environments are the same, and I installed Emacs 27.1
>> > and 27.2 on the laptop. The colorize problem occurs on the laptop no
>> > matter the environment. It also occurred with my old desktop.
>> >
>> >
>>
>>
>> --
>> The Kafka Pandemic
>>
>> Please learn what misopathy is.
>> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html


-- 
Tim Cross

Re: Bug: First file opened does not colorize (tested with 9.3.7 and 9.4.5)

[Dominick Samperi]

Changing the suffix to .org does not help. Still the first file opened
does not colorize.
I first observed this problem about six months ago (and have been
using a function
key to fix with 'org-mode-restart).

The problem does not appear on a new desktop, running
the same version of Emacs, same version of org-mode, and same .emacs.d.

The only notable difference between the new machine and the older machines
where the problem occurs is that the newer machine has an solid state drive,
whereas the other machines have conventional hard drives.

On Fri, Apr 30, 2021 at 8:51 PM Samuel Wales  wrote:
>
> what if .org?
>
> On 4/30/21, Dominick Samperi  wrote:
> > The first org mode file opened (.txt suffix) is not colorized. To force
> > colorize I use 'org-mode-restart. Subsequently opened txt files are
> > properly colorized. This happens under Windows 10 using Emacs 27.1 and
> > 27.2, and org-mode 9.3.7 and 9.4.5. There are no problems under Ubuntu
> > Linux.
> >
> > Oddly, the problem does not appear on my new desktop (Lenovo). It
> > happens on my ASUS laptop. I'm using the same version of org-mode and
> > Emacs on both machines.
> >
> > I copied .emacs.d from the desktop to the laptop
> > to be sure the environments are the same, and I installed Emacs 27.1
> > and 27.2 on the laptop. The colorize problem occurs on the laptop no
> > matter the environment. It also occurred with my old desktop.
> >
> >
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Bug: First file opened does not colorize (tested with 9.3.7 and 9.4.5)

[Samuel Wales]

what if .org?

On 4/30/21, Dominick Samperi  wrote:
> The first org mode file opened (.txt suffix) is not colorized. To force
> colorize I use 'org-mode-restart. Subsequently opened txt files are
> properly colorized. This happens under Windows 10 using Emacs 27.1 and
> 27.2, and org-mode 9.3.7 and 9.4.5. There are no problems under Ubuntu
> Linux.
>
> Oddly, the problem does not appear on my new desktop (Lenovo). It
> happens on my ASUS laptop. I'm using the same version of org-mode and
> Emacs on both machines.
>
> I copied .emacs.d from the desktop to the laptop
> to be sure the environments are the same, and I installed Emacs 27.1
> and 27.2 on the laptop. The colorize problem occurs on the laptop no
> matter the environment. It also occurred with my old desktop.
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Bug: First file opened does not colorize (tested with 9.3.7 and 9.4.5)

[Dominick Samperi]

The first org mode file opened (.txt suffix) is not colorized. To force
colorize I use 'org-mode-restart. Subsequently opened txt files are
properly colorized. This happens under Windows 10 using Emacs 27.1 and
27.2, and org-mode 9.3.7 and 9.4.5. There are no problems under Ubuntu Linux.

Oddly, the problem does not appear on my new desktop (Lenovo). It
happens on my ASUS laptop. I'm using the same version of org-mode and
Emacs on both machines.

I copied .emacs.d from the desktop to the laptop
to be sure the environments are the same, and I installed Emacs 27.1
and 27.2 on the laptop. The colorize problem occurs on the laptop no
matter the environment. It also occurred with my old desktop.

Re: How to create a macro that inserts multiline text with :B_ignoreheading: tag?

[Richard Stanton]

That works. Thanks Juan Manuel!

> On Apr 30, 2021, at 1:40 PM, Juan Manuel Macías  
> wrote:
> 
> Hi Richard,
> 
> Richard Stanton  writes:
> 
>> I’d like to define a macro called, say, articletext, to insert this
>> header into my document before exporting to LaTeX, so the org file
>> would look something like this:
>> 
>> {{{article text}}}
>> This text appears only in the article version.
> 
> Macro definitions do not allow spaces.
> 
> You can try something like:
> 
> #+MACRO: article_text (eval (concat "*** More explanation coming" "\s" 
> ":B_ignoreheading:\n:PROPERTIES:\n:BEAMER_env: ignoreheading\n:END:"))
> 
> {{{article_text}}}
> 
> Best regards,
> 
> Juan Manuel 

Re: wip-cite status question and feedback

[Denis Maier]

Hi Nicolas,

thanks for all you work on this one. I don't have a setup where I can 
test this, but from what I can tell this looks quite good already.


Am 30.04.2021 um 15:28 schrieb Nicolas Goaziou:
[...]



OK. I wrote a POC, and I would appreciate some feedback about it.

In order to test it, one need to evaluate the following, from an
up-to-date "wip-cite-new" branch:

--8<---cut here---start->8---
(defun org-cite--swap-punctuation (object info)
   "Move punctuation following OBJECT before it, if applicable.

When OBJECT is followed by some terminal punctuation character, such as
a period or a question mark, and preceded by some text, move the punctuation
at the end of the previous text.  If that text ends with a double quote,
move the punctuation before that quote, too.

INFO is the export state, as a property list."
   (let ((next (org-export-get-next-element object info))
 (previous
  (org-last
   (org-element-map (org-export-get-previous-element object info)
   'plain-text
 #'identity info)))
 (punct-re
  (rx string-start
  (group (or "." "!" "?" "..." "…"))
  (or eol (any " " "\t")
 (when (and previous
(stringp next)
(string-match punct-re next))
   (let* ((punct (match-string 1 next))
  (new-next (substring next (match-end 1)))
  (quote-re
   (rx (opt (and (group (or string-start (not (any "." "!" "?" 
"…"
 (group "\"")))
   (group (0+ (any " " "\t")))
   string-end))
  (new-previous
   (replace-regexp-in-string
quote-re (concat "\\1" punct "\\2\\3") previous)))
 (org-element-set-element next new-next)
 (org-element-set-element previous new-previous)

(defun org-cite-wrap-citation (citation info  move-punctuation)
   "Wrap an anonymous inline footnote around CITATION object in the parse tree.

INFO is the export state, as a property list.  When optional argument
MOVE-PUNCTUATION is non-nil, move punctuation character following citation 
before
it, when applicable.  If a quotation mark precedes the citation, move
punctuation before it, too.

The parse tree is modified by side-effect."
   (let ((footnote
  (list 'footnote-reference
(list :label nil
  :type 'inline
  :contents-begin (org-element-property :begin citation)
  :contents-end (org-element-property :end citation)
  :post-blank (org-element-property :post-blank 
citation)
 ;; Remove any white space before citation.
 (org-cite--set-previous-post-blank citation 0 info)
 ;; Possibly swap punctuation around citation.
 (when move-punctuation (org-cite--swap-punctuation citation info))
 ;; Footnote swallows citation.
 (org-element-insert-before footnote citation)
 (org-element-adopt-elements footnote
 (org-element-extract-element citation

;; test citation processor

(defun test-export-citation (citation nil nil info)
   (org-cite-wrap-citation citation info t)
   "...")

(org-cite-register-processor 'test
   :export-citation #'test-export-citation)
--8<---cut here---end--->8---

For example, the following document:

--8<---cut here---start->8---
#+cite_export: test

This is a test [cite:@a].

This is a test [cite:@a]?

This is a test [cite:@a]...

This is a "test" [cite:@a].

This is a "test." [cite:@a].

This is a *"test"* [cite:@a].

This is a *some /covoluted/ "test"* [cite:@a].

# Do nothing in the following cases.

This is a test [cite:@a]

This is a test. [cite:@a]

[cite:@a].

This is a "test" [cite:@a]
--8<---cut here---end--->8---

would become in ASCII export (without the uninteresting footnotes part):

--8<---cut here---start->8---
This is a test.[1]

This is a test?[2]

This is a test…[3]

This is a « test. »[4]

This is a « test. ».[5]

This is a *« test. »*[6]

This is a *some /covoluted/ « test. »*[7]

This is a test[8]

This is a test.[9]

[10].

This is a « test »[11]
--8<---cut here---end--->8---

Is it what you had in mind?


Yes, this should be equivalent to the behaviour in pandoc.

However, as I've said before, this behaviour is only correct in American 
English. TO quuote the Chicago Manual of Style 6.9: "In an alternative 
system, sometimes called British Style (as described in the /New Oxford 
Style Manual ...) ... only those punctuation points that appeared in the 
original material are included within the quotation marks." The same 
would be correct for German. Do you have an idea if/how this could be 
implemented?




Also, I have questions about punctuation.

Currently, 

Re: stability of toc links

[Tim Cross]

Nicolas Goaziou  writes:

> Hello,
>
> Samuel Loury  writes:
>
>> The publish feature only means exporting several files at once. 
>
> You can publish a single file, too. It makes sense when a file is always
> exported to the same location, possibly with the same configuration.
>
>> IIUC, what was written was that when using the publish feature, the exported
>> html pages will be coherent and a link in one document pointing to
>> another document of the same publish call won't be broken.
>>
>> But IIUC, publishing the whole stuff again will result in totally
>> different links. They will still be coherent and no broken link from one
>> document of the whole to another. But a browser bookmark pointing the
>> published lot the first time won't work with the same lot the second
>> time.
>>
>> Did I understand correctly?
>
> That's correct. 
>
> Org provides a mechanism, called `org-export-get-reference', for
> creating internal references, which relies on randomness + cache. But it
> explicitly removes internal references not actually used from there (see
> `org-publish--store-crossrefs'). Keeping those references instead would
> make all links stable, of course.
>

Given this is not the first time we have seen a similar discussion
regarding link stability for external references, perhaps it would be
good to summarise and put it on worg for reference?

First attempt - let me know if I've got it close!

- If you need stability in TOC links between generated versions, use
  Org's publish facility rather than plain HTML export.

- Publish can be used to publish a single file.

- 'something' in the published output needs to reference the TOC links
  to ensure consistency.

HTML export lacks the internal caching/tracking necessary to have
internal link consistency across exported versions. Adding such
capability would significantly complicate the HTML export code base.
This is hard to justify when this export facility is also used for
things like HTML fragments and because internal link stability is only
required in a sub-set of use cases.

The org publish facility already includes the necessary internal
facilities to support internal link consistency across published
versions. You can use publish to publish a single file. Currently, the
internal links need to be referenced/used in order to ensure consistency
across published versions.

If stability of TOC links across versions is required, using publish is
the preferred mechanism. If we would want to make it easier for the user
to create published pages with consistent internal TOC links, we would
be better off enhancing the publish mechanism rather than trying to add
such facilities to the HTML export function. 

-- 
Tim Cross

Re: Big problem: org agenda freezes my process

[Tim Cross]

torys.ander...@gmail.com (Tory S. Anderson) writes:

> I've been trying to debug a nearly show-stopping issue for a few weeks now; 
> the
> next step is a more thorough bisection of my setup, but I wanted to send this 
> in
> case anyone else experiences this or already knows the solution.
>
> Lately, when I try to view an orgmode agenda it seems that two things make it
> cause my emacs CPU threat to spin to max and freeze up, which is a huge 
> problem
> since I'm an exwm user and live in my agenda view. As far as I've been able to
> tell, when an item from today is clocked into multiple times in the same day, 
> it
> prompts most agenda actions to result in a freeze and some kind of loop that 
> is
> binding up my system. It has some gaps, so if I spam C-g I will eventually,
> usually, escape given 30 seconds to 2 minutes.
>
> I first ran into this problem thinking it was because I had an entry with a
> "+1d" note on it, so it would always show up; but inconsistent results led me 
> to
> the more precise discovery that it's apparently when it is logged in to 
> multiple
> times in the day AND when it is shown with =(org-agenda-show-log t)=, which I
> had on my default. At its worst, even moving the cursor in the agenda buffer
> would trigger the freezing, let alone actually clocking in/out of anything.
> However, when I am not showing the log, it seems like it's ok. I've tried
> =toggle-debug-on-quit" but I don't recognize anything in the stack trace that
> actually tells me what it is doing when it spins to a halt.
>
> I'm currently on org mode version 9.3.7. I've tried with different versions 
> but
> without a change in behavior. This, combined with the fact that the issues 
> seem
> to have begun in the past month, indicates that it probably isn't orgmode 
> itself
> causing this issue, but I haven't located what it IS yet. If anyone has ideas 
> on
> how to debug this without a bisection, or an has dealt with this before, I'm
> more than eager to hear it; in the meanwhile, I'll perform a more thorough
> bisection of my init file as time permits.
>

Does the problem also occur if your not running exwm? I stopped using
exwm for a very similar reason i.e. every now and then, I would try to
do something and the CPU load would peak, everything would become
unresponsive and either I had to wait (for minutes) or start killing
things to try and get back control. Probably first thing to do is see if
you can reproduce the issue without exwm. If you can, the next thing to
do would be to come up with a minimal org config and recipe to reproduce
as this will allow others here to try and help debug the issue. 

BTW I gave up on exwm as I found a few issues and found it often got
slow. I switched to Stumpwm (Common Lisp WM), which I found great as I
was then able to have a window manager which worked like Emacs, could
have same keyboard interface and could be modified 'on the fly' with
lisp. I only stopped using it when I started experimenting with Wayland.


-- 
Tim Cross

Re: How to create a macro that inserts multiline text with :B_ignoreheading: tag?

[Juan Manuel Macías]

Hi Richard,

Richard Stanton  writes:

> I’d like to define a macro called, say, articletext, to insert this
> header into my document before exporting to LaTeX, so the org file
> would look something like this:
>
> {{{article text}}}
> This text appears only in the article version.

Macro definitions do not allow spaces.

You can try something like:

#+MACRO: article_text (eval (concat "*** More explanation coming" "\s" 
":B_ignoreheading:\n:PROPERTIES:\n:BEAMER_env: ignoreheading\n:END:"))

{{{article_text}}}

Best regards,

Juan Manuel 

Big problem: org agenda freezes my process

[Tory S. Anderson]

I've been trying to debug a nearly show-stopping issue for a few weeks now; the 
next step is a more thorough bisection of my setup, but I wanted to send this 
in case anyone else experiences this or already knows the solution.

Lately, when I try to view an orgmode agenda it seems that two things make it 
cause my emacs CPU threat to spin to max and freeze up, which is a huge problem 
since I'm an exwm user and live in my agenda view. As far as I've been able to 
tell, when an item from today is clocked into multiple times in the same day, 
it prompts most agenda actions to result in a freeze and some kind of loop that 
is binding up my system. It has some gaps, so if I spam C-g I will eventually, 
usually, escape given 30 seconds to 2 minutes.

I first ran into this problem thinking it was because I had an entry with a 
"+1d" note on it, so it would always show up; but inconsistent results led me 
to the more precise discovery that it's apparently when it is logged in to 
multiple times in the day AND when it is shown with =(org-agenda-show-log t)=, 
which I had on my default. At its worst, even moving the cursor in the agenda 
buffer would trigger the freezing, let alone actually clocking in/out of 
anything. However, when I am not showing the log, it seems like it's ok. I've 
tried =toggle-debug-on-quit" but I don't recognize anything in the stack trace 
that actually tells me what it is doing when it spins to a halt.

I'm currently on org mode version 9.3.7. I've tried with different versions but 
without a change in behavior. This, combined with the fact that the issues seem 
to have begun in the past month, indicates that it probably isn't orgmode 
itself causing this issue, but I haven't located what it IS yet. If anyone has 
ideas on how to debug this without a bisection, or an has dealt with this 
before, I'm more than eager to hear it; in the meanwhile, I'll perform a more 
thorough bisection of my init file as time permits.

- Tory

Re: [PATCH] Bug: fragile org refile cache

[Maxim Nikulin]

On 29/04/2021 23:08, Ihor Radchenko wrote:

Did you do any benchmarks? I just tried

Outline path without cache:


I have expanded your tests to make them more close to org-get-outline-path

org-get-outline-path without cache
| 5.459114059 | 12 | 1.205358000987 |
org-get-outline-path with cache
| 2.166378543 |  5 | 0.501118777003 |

Custom code to track outline path during scan
| 0.718288205 | 4 | 0.400503434992 |
The same without (org-trim ...) stuff
| 0.208798040 | 0 |0.0 |

From my point of view avoiding org-get-outline-path allows to 
significantly improve performance. Removing cookies, etc. is far from 
being negligible.


Test file is org-manual.org with 404 headings. Since it is not so much, 
I set minimal CPU frequency.


Notice that outline cache is cleared before each scan to simulate the 
case when org-goto is invoked just after emacs start or after 
adding/removing some lines in the beginning of the file. Actually it is 
a problem of outline cache that it easily became stale due to e.g. extra 
line close to buffer start.


Details:

#+begin_example bash
for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ;
do
echo powersave >"$i" ;
done
#+end_example

#+begin_src elisp
  (byte-compile-file (expand-file-name "~/src/emacs/org-mode/lisp/org.el"))
  (defun nm-count-headings (headings)
(let ((n 0))
  (dolist (h headings)
(setq n (+ n (length h
  (list (length headings) n)))
#+end_src

#+RESULTS:
: nm-count-headings

#+begin_src elisp
  (defun ir-tst-scan (buffer use-cache)
(with-current-buffer buffer
  (goto-char 1)
  (let ((result nil))
(while (re-search-forward "^\\*+[ \t]" nil t)
  (beginning-of-line)
  (let ((case-fold-search nil))
(looking-at org-complex-heading-regexp))
  (push (org-get-outline-path t use-cache) result)
  (end-of-line))
result)))
  (byte-compile 'ir-tst-scan)
  (mapcar
   (lambda (use-cache)
 (let ((headings))
   (append
(list use-cache)
(benchmark-run 10
  (progn
(setq org-outline-path-cache nil)
(setq headings
  (ir-tst-scan "org-manual.org" use-cache
(nm-count-headings headings
   '(nil t))
#+end_src

#+RESULTS:
| nil | 5.459114059 | 12 | 1.205358000987 | 404 | 1069 |
| t   | 2.166378543 |  5 | 0.501118777003 | 404 | 1069 |

| use-cache | benchmark | |   | headings | outline 
components |


#+begin_src elisp
  (defun nm-tst-scan (buffer clean-headers)
(with-current-buffer buffer
  (goto-char 1)
  (let ((result nil))
(let ((outline-path))
  (while (re-search-forward "^\\*+[ \t]" nil t)
(beginning-of-line)
(let ((case-fold-search nil))
  (looking-at org-complex-heading-regexp))
(let ((heading (match-string-no-properties 4))
  (heading-level (length (match-string-no-properties 1
  (while (and outline-path (<= heading-level (caar outline-path)))
(pop outline-path))
  (push (cons heading-level
  (if (not heading)
  ""
(if (not clean-headers)
heading
  (org-trim
   (org-link-display-format
(replace-regexp-in-string
 "\\[[0-9]+%\\]\\|\\[[0-9]+/[0-9]+\\]" ""
 heading))
outline-path))
(end-of-line)
(push (mapcar #'cdr outline-path) result)))
result)))
  (byte-compile 'nm-tst-scan)
  (mapcar
   (lambda (clean-headers)
 (let ((headings))
   (append
(list clean-headers)
(benchmark-run 10
  (progn
(setq org-outline-path-cache nil)
(setq headings
  (nm-tst-scan "org-manual.org" clean-headers
(nm-count-headings headings
   '(nil t))
#+end_src

#+RESULTS:
| nil | 0.208798042 | 0 |0.0 | 404 | 1069 |
| t   | 0.718288205 | 4 | 0.400503434992 | 404 | 1069 |

| clean-headers | benchmark |   || headings | 
outline components |

How to create a macro that inserts multiline text with :B_ignoreheading: tag?

[Richard Stanton]

I’m using org mode to create Beamer presentations, also using beamerarticle so 
I can create an article version of my slides with extra text. This article by 
James Harkins was very helpful in getting started:

https://orgmode.org/worg/exporters/beamer/beamer-dual-format.html 


One issue, noted in the article, is that text you want to have appear in 
article mode but not in a slide needs to be outside the frame environment, 
which means you need to tell org to end one slide without starting another. 
This can be achieved by inserting a header like this into the org file before 
the article text:

*** More explanation coming :B_ignoreheading:
:PROPERTIES:
:BEAMER_env: ignoreheading
:END:

I’d like to define a macro called, say, articletext, to insert this header into 
my document before exporting to LaTeX, so the org file would look something 
like this:

{{{article text}}}
This text appears only in the article version.

However, I can’t find any way to actually define this macro and get it to work 
as I want. From my experiments so far, it seems that including 
:B_ignoreheading: in the macro definition causes problems, but I’m not 100% 
sure. Anyway, I’d be very grateful if anyone can see an obvious way to get this 
to happen.

Thanks for any suggestions!

Richard Stanton

Re: Programmatically set TODO labels per file?

[Arthur Miller]

Arthur Miller  writes:

If anyone is interested, this is how I understand the org TODO per file
parsing:

The file is parsed in org-collect-keywords-1 in org.el.

Each #+TODO: line is lumped into one single string, which is a problem
when strings with spaces a concerned. Multiple #+TODO: lines will end up
in final multiple strings added into an alist which has a first element
a "TODO" string. The right thing would be to parse multiple strings per
each #+TODO: line. Now the org-collect-keyword-1 is not a trivial one,
so it would take me quite some time to understand, so I'll pass.

The thing I did that worked for me is wrong super-hackish thing, just an
experiment, so to say.

I have simply refactored the code where the string obtained from
org-collect-keywords is parsed, which is the very last part of
org-set-regexps-and-options, where main action seems to take place. That
let's me do what I wanted. It will completely replace whatever was
specified with #+ syntax, and the fontification won't be done
either. Also if file is reverted than #+ will completely replace what
was set with lisp. So not a clean thing, probably nothing to be used by
anyone, but it does what I roughly need for my init file :-).

#+TODO: one two
#+TODO: three
#+TODO: four

#+begin_src emacs-lisp
(defun org-todo-per-file-keywords (kwds)
  "Sets per file TODO labels. Takes as argument a list of strings to be used as
labels."
  (let (alist)
(push "TODO" alist)
(dolist (kwd kwds)
  (push kwd alist))
(setq alist (list (nreverse alist)))
;; TODO keywords.
(setq-local org-todo-kwd-alist nil)
(setq-local org-todo-key-alist nil)
(setq-local org-todo-key-trigger nil)
(setq-local org-todo-keywords-1 nil)
(setq-local org-done-keywords nil)
(setq-local org-todo-heads nil)
(setq-local org-todo-sets nil)
(setq-local org-todo-log-states nil)
(let ((todo-sequences alist))
  (dolist (sequence todo-sequences)
	(let* ((sequence (or (run-hook-with-args-until-success
			  'org-todo-setup-filter-hook sequence)
			 sequence))
	   (sequence-type (car sequence))
	   (keywords (cdr sequence))
	   (sep (member "|" keywords))
	   names alist)
	  (dolist (k (remove "|" keywords))
	(unless (string-match "^\\(.*?\\)\\(?:(\\([^!@/]\\)?.*?)\\)?$"
  k)
	  (error "Invalid TODO keyword %s" k))
	(let ((name (match-string 1 k))
		  (key (match-string 2 k))
		  (log (org-extract-log-state-settings k)))
	  (push name names)
	  (push (cons name (and key (string-to-char key))) alist)
	  (when log (push log org-todo-log-states
	  (let* ((names (nreverse names))
		 (done (if sep (org-remove-keyword-keys (cdr sep))
			 (last names)))
		 (head (car names))
		 (tail (list sequence-type head (car done) (org-last done
	(add-to-list 'org-todo-heads head 'append)
	(push names org-todo-sets)
	(setq org-done-keywords (append org-done-keywords done nil))
	(setq org-todo-keywords-1 (append org-todo-keywords-1 names nil))
	(setq org-todo-key-alist
		  (append org-todo-key-alist
			  (and alist
			   (append '((:startgroup))
   (nreverse alist)
   '((:endgroup))
	(dolist (k names) (push (cons k tail) org-todo-kwd-alist))
(setq org-todo-sets (nreverse org-todo-sets)
	  org-todo-kwd-alist (nreverse org-todo-kwd-alist)
	  org-todo-key-trigger (delq nil (mapcar #'cdr org-todo-key-alist))
	  org-todo-key-alist (org-assign-fast-keys org-todo-key-alist))
;; Compute the regular expressions and other local variables.
;; Using `org-outline-regexp-bol' would complicate them much,
;; because of the fixed white space at the end of that string.
(unless org-done-keywords
  (setq org-done-keywords
	(and org-todo-keywords-1 (last org-todo-keywords-1
(setq org-not-done-keywords
	  (org-delete-all org-done-keywords
			  (copy-sequence org-todo-keywords-1))
	  org-todo-regexp (regexp-opt org-todo-keywords-1 t)
	  org-not-done-regexp (regexp-opt org-not-done-keywords t)
	  org-not-done-heading-regexp
	  (format org-heading-keyword-regexp-format org-not-done-regexp)
	  org-todo-line-regexp
	  (format org-heading-keyword-maybe-regexp-format org-todo-regexp)
	  org-complex-heading-regexp
	  (concat "^\\(\\*+\\)"
		  "\\(?: +" org-todo-regexp "\\)?"
		  "\\(?: +\\(\\[#.\\]\\)\\)?"
		  "\\(?: +\\(.*?\\)\\)??"
		  "\\(?:[ \t]+\\(:[[:alnum:]_@#%:]+:\\)\\)?"
		  "[ \t]*$")
	  org-complex-heading-regexp-format
	  (concat "^\\(\\*+\\)"
		  "\\(?: +" org-todo-regexp "\\)?"
		  "\\(?: +\\(\\[#.\\]\\)\\)?"
		  "\\(?: +"
		  ;; Stats cookies can be stuck to body.
		  "\\(?:\\[[0-9%%/]+\\] *\\)*"
		  "\\(%s\\)"
		  "\\(?: *\\[[0-9%%/]+\\]\\)*"
		  "\\)"
		  "\\(?:[ \t]+\\(:[[:alnum:]_@#%%:]+:\\)\\)?"
		  "[ \t]*$")
	  org-todo-line-tags-regexp
	  (concat "^\\(\\*+\\)"
		  "\\(?: +" org-todo-regexp "\\)?"
		  "\\(?: +\\(.*?\\)\\)??"
		  "\\(?:[ \t]+\\(:[[:alnum:]:_@#%]+:\\)\\)?"
		  "[ \t]*$"))

Re: Fwd: Bug: Texinfo export: Inline images are NOT rendered in INFO viewer [9.4.5 (release_9.4.5-354-g40b70c @ /home/rameshnedunchezian/src/org-mode/lisp/)]

[Nicolas Goaziou]

Hello,

Ramesh Nedunchezian  writes:

> Bug: Texinfo export: Inline images are NOT rendered in INFO viewer

Fixed. Thank you.

Regards,
-- 
Nicolas Goaziou

Re: wip-cite status question and feedback

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> But an example from American English for illustration, derived from
> Denis' examples.
>
> "A simple quote" [cite:@doe].
>
> When rendered, that should be this in an author-date style:
>
> "A simple quote" (Doe 2021).
>
> ... and this in a note style:
>
> "A simple quote."[^1]
>
> So that rule would suggest something like:
>
> - if a citation concludes a sentence, move the note mark and whatever
> trailing quotation mark, outside the period.
>
> But, Denis continues, "While this is perfectly acceptable in American
> English, it is not in German, or even in British English. Here we have
> to know whether the final period is part of the original quotation. If
> yes, it will be put inside the quotes, otherwise outside." I'll paste
> the rest of his examples at the end.
>
> It's possible his rule here is more general, and would still be
> acceptable in American English.
>
> Does that help explain?

OK. I wrote a POC, and I would appreciate some feedback about it.

In order to test it, one need to evaluate the following, from an
up-to-date "wip-cite-new" branch:

--8<---cut here---start->8---
(defun org-cite--swap-punctuation (object info)
  "Move punctuation following OBJECT before it, if applicable.

When OBJECT is followed by some terminal punctuation character, such as
a period or a question mark, and preceded by some text, move the punctuation
at the end of the previous text.  If that text ends with a double quote,
move the punctuation before that quote, too.

INFO is the export state, as a property list."
  (let ((next (org-export-get-next-element object info))
(previous
 (org-last
  (org-element-map (org-export-get-previous-element object info)
  'plain-text
#'identity info)))
(punct-re
 (rx string-start
 (group (or "." "!" "?" "..." "…"))
 (or eol (any " " "\t")
(when (and previous
   (stringp next)
   (string-match punct-re next))
  (let* ((punct (match-string 1 next))
 (new-next (substring next (match-end 1)))
 (quote-re
  (rx (opt (and (group (or string-start (not (any "." "!" "?" 
"…"
(group "\"")))
  (group (0+ (any " " "\t")))
  string-end))
 (new-previous
  (replace-regexp-in-string
   quote-re (concat "\\1" punct "\\2\\3") previous)))
(org-element-set-element next new-next)
(org-element-set-element previous new-previous)

(defun org-cite-wrap-citation (citation info  move-punctuation)
  "Wrap an anonymous inline footnote around CITATION object in the parse tree.

INFO is the export state, as a property list.  When optional argument
MOVE-PUNCTUATION is non-nil, move punctuation character following citation 
before
it, when applicable.  If a quotation mark precedes the citation, move
punctuation before it, too.

The parse tree is modified by side-effect."
  (let ((footnote
 (list 'footnote-reference
   (list :label nil
 :type 'inline
 :contents-begin (org-element-property :begin citation)
 :contents-end (org-element-property :end citation)
 :post-blank (org-element-property :post-blank citation)
;; Remove any white space before citation.
(org-cite--set-previous-post-blank citation 0 info)
;; Possibly swap punctuation around citation.
(when move-punctuation (org-cite--swap-punctuation citation info))
;; Footnote swallows citation.
(org-element-insert-before footnote citation)
(org-element-adopt-elements footnote
(org-element-extract-element citation

;; test citation processor

(defun test-export-citation (citation nil nil info)
  (org-cite-wrap-citation citation info t)
  "...")

(org-cite-register-processor 'test
  :export-citation #'test-export-citation)
--8<---cut here---end--->8---

For example, the following document:

--8<---cut here---start->8---
#+cite_export: test

This is a test [cite:@a].

This is a test [cite:@a]?

This is a test [cite:@a]...

This is a "test" [cite:@a].

This is a "test." [cite:@a].

This is a *"test"* [cite:@a].

This is a *some /covoluted/ "test"* [cite:@a].

# Do nothing in the following cases.

This is a test [cite:@a]

This is a test. [cite:@a]

[cite:@a].

This is a "test" [cite:@a]
--8<---cut here---end--->8---

would become in ASCII export (without the uninteresting footnotes part):

--8<---cut here---start->8---
This is a test.[1]

This is a test?[2]

This is a test…[3]

This is a « test. »[4]

This is a « test. ».[5]

This is a *« test. »*[6]

This is a *some /covoluted/ « test. »*[7]

This is a test[8]

This is a test.[9]

[10].

Re: org-attach-attach in an org-capture template?

[Ihor Radchenko]

Tim Visher  writes:

> I also believe I could do this with one of the org-capture hooks but
> examining them I didn't see the obvious right one to add my function to. I
> would think it would be the org-capture-prepare-finalize-hook and I may
> just give that a try.

Capture hooks should be the right place to do what your want. I
recommend org-capture-before-finalize-hook since it will not run if you
abort the capture for any reason. Otherwise, you may attach the file,
abort capture (via C-c C-k or because of some error), and your attached
file will hang somewhere unreferenced. Your first idea with
%()-expansion have the same problem.

> ... I further assume then that I'd need to to apply the
> advice here
> 
> and
> check for what template I'm in with (plist-get org-capture-plist :key) or
> similar.

I recommend using doct [1] with :before-finalize keyword. It will take
care that your function runs for the right template.

[1] https://github.com/progfolio/doct#hooks

> So my question is whether there's anything I can do to get org-attach-attach 
> to
> recognize the file it's in. I'm assuming that when it's expanding it's in a
> temporary buffer of some kind which is why it's failing.

You are right, template expansion is done in separate "*Capture*" buffer
using org-capture-fill-template. The buffer is not associated with any
file.

Best,
Ihor

[PATCH] Possibility of using alternative separators in macros

[Juan Manuel Macías]

Hi all,

I would like to propose (patch attached) the possibility of using an
alternate character for separate arguments in replacement macros,
following a suggestion from Nicolas Goaziou in this (closed) thread:
https://orgmode.org/list/87o8ead42u@nicolasgoaziou.fr/

The idea would be to explicitly indicate the separator just before the
parentheses. The allowed characters are any character other than a
letter, a number, a space, a dash, a low line or a parenthesis.

A new property `:sep' is added to `org-element-macro-parser', whose
default value is a comma.

Example of use. Suppose we define this macro:

#+MACRO: foo (eval (format "%s and %s" $1 $2))

Under normal conditions, the expected separator will be the comma:

{{{foo(x,z\, y)}}}

=> x and z, y

But we can also do this:

{{{foo@(x@z, y \@)}}}

=> x and z, y @

I think sometimes it may be preferable to separate the arguments by an
alternative character. For example, let's imagine we define a macro
(named 'lg') for LaTeX export, which admits two arguments, exactly the
same args as the Babel (LaTeX) macro \foreignlanguage{lang}{short-text}:
{{{lg(lang,short-text)}}}.

It would be much more comfortable something like:

{{{lg|(latin|trado, tradidi, traditur)}}}

instead of having to escape commas in:

{{{lg(latin,trado\, tradidi\, traditur)}}}

Best regards,

Juan Manuel 

>From 400d5779508fd7206a353bdb444c3cba382b8f01 Mon Sep 17 00:00:00 2001
From: juanmanuel 
Date: Fri, 30 Apr 2021 14:45:54 +0200
Subject: [PATCH] Alternative args separator for replacement macros

---
 lisp/org-element.el | 9 +++--
 lisp/org-macro.el   | 9 +
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index a675bf512..34a9b880a 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -3279,21 +3279,25 @@ CONTENTS is the contents of the object, or nil."
   "Parse macro at point, if any.
 
 When at a macro, return a list whose car is `macro' and cdr
-a plist with `:key', `:args', `:begin', `:end', `:value' and
+a plist with `:key', `:args', `:begin', `:end', `:sep', `:value' and
 `:post-blank' as keywords.  Otherwise, return nil.
 
 Assume point is at the macro."
   (save-excursion
-(when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\((\\([^\000]*?\\))\\)?}}}")
+(when (looking-at "{{{\\([a-zA-Z][-a-zA-Z0-9_]*\\)\\([^a-zA-Z\s()]*[^-a-zA-Z0-9_\s]*\\)\\((\\([^\000]*?\\))\\)?}}}")
   (let ((begin (point))
 	(key (downcase (match-string-no-properties 1)))
 	(value (match-string-no-properties 0))
 	(post-blank (progn (goto-char (match-end 0))
 			   (skip-chars-forward " \t")))
 	(end (point))
+(sep (if (not (equal (match-string-no-properties 2) ""))
+		  (match-string-no-properties 2)
+		","))
 	(args (pcase (match-string-no-properties 3)
 		(`nil nil)
 		(a (org-macro-extract-arguments
+sep
 			(replace-regexp-in-string
 			 "[ \t\r\n]+" " " (org-trim a)))
 	(list 'macro
@@ -3302,6 +3306,7 @@ Assume point is at the macro."
 		:args args
 		:begin begin
 		:end end
+:sep sep
 		:post-blank post-blank))
 
 (defun org-element-macro-interpreter (macro _)
diff --git a/lisp/org-macro.el b/lisp/org-macro.el
index 29c403658..e047cd78e 100644
--- a/lisp/org-macro.el
+++ b/lisp/org-macro.el
@@ -294,20 +294,21 @@ of `org-macro-extract-arguments'."
 	  nil t)
 	 s)
 
-(defun org-macro-extract-arguments (s)
+(defun org-macro-extract-arguments (sep s)
   "Extract macro arguments from string S.
 S is a string containing comma separated values properly escaped.
-Return a list of arguments, as strings.  This is the opposite of
+SEP is the character used to separate arguments.  Return a list
+of arguments, as strings.  This is the opposite of
 `org-macro-escape-arguments'."
   ;; Do not use `org-split-string' since empty strings are
   ;; meaningful here.
   (split-string
(replace-regexp-in-string
-"\\(*\\),"
+(format "\\(*\\)%s" sep)
 (lambda (str)
   (let ((len (length (match-string 1 str
 	(concat (make-string (/ len 2) ?\\)
-		(if (zerop (mod len 2)) "\000" ","
+		(if (zerop (mod len 2)) "\000" (format "%s" sep)
 s nil t)
"\000"))
 
-- 
2.26.0

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Bastien]

Eric S Fraga  writes:

> I get this when I try:

Thanks - I see what's wrong, I'll fix it.

-- 
 Bastien

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Eric S Fraga]

On Friday, 30 Apr 2021 at 20:16, Timothy wrote:
> Thank you for taking the time to check this in what sounds like a busy
> day, and the backtrace. It's much appreciated :)

Thank you.  All days are busy (for all/most of us, I'm sure) but org is
a major part of my day's work so always happy to try to contribute in
some way.

> It seems like for you (org-element-property :post-affiliated context)
> was unexpectedly nil. (or 0 ...) would be a quick-fix, but I find it odd
> that this is a issue, and am yet to be able to reproduce this myself.

It could very well be something I have done (inadvertently, but not
surprisingly).  I don't know what the above means so please suggest what
I can do.  It seems that C-c C-c on a table (no C-u) also fails
sometimes.  So it's probably (likely) me doing something wrong.

> p.s. Good luck with the presentation!

Thank you! :-)

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-394-g7fc090

Re: stability of toc links

[Maxim Nikulin]

On 30/04/2021 13:24, Timothy wrote:

Dominique Dumont  writes:


For what it's worth, DNS servers faces a similar problem where host names can
contain any unicode character, but DNS servers support only ascii char. In DNS
cases, this is worked around using punycode. (1)

Using the example above, a host named "こんにちは.example" is converted to
"xn--28j2a3ar1p.example".

Punycode is available in Emacs through libidn (2)


Thanks! I'm now making use of it as of 
https://github.com/tecosaur/emacs-config/commit/1ccbadd


Personally, I do not see any point in using of punycode. The result is 
not human readable.


I was not sure that url-hexify-string is a reliable solution, but 
surprisingly it is used by wikipedia now

https://ru.wikipedia.org/wiki/Emacs#%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F[8][9]
Could you, please, provide some details concerning problem you have noticed?

Earlier wikipedia was used another approach:
https://ru.wikipedia.org/wiki/%D0%98%D0%B2%D0%B0%D0%BD_%D0%A4%D1%91%D0%B4%D0%BE%D1%80%D0%BE%D0%B2#.D0.91.D0.B8.D0.BE.D0.B3.D1.80.D0.B0.D1.84.D0.B8.D1.8F
(random URL found in browser history).

Both pure (percent) encode or encode followed by s/%/./g produce 
unreadable result.


I would like to see something like
https://support.mozilla.org/ru/kb/zaprosy-na-razresheniya-dlya-rasshirenij-firefox
I was never interested in this topic enough to check if other 
implementations, e.g. wordpress (or some plugin) use the same technique 
as python's unidecode or something else. Certainly, unidecode should not 
be hard dependency, but if installed it could be used instead of less 
intelligent default method.


On 24/04/2021 03:51, Samuel Wales wrote:

[and also that i was merely looking at the examples and maxim's
analysis which i agree with, not tec's or others' code.]


To be clear: my message was in support to Timothy's initiative.

On 24/04/2021 03:46, Samuel Wales wrote:

i think the principle of
least surprise applies; many users will want to export not publish.


Unsure, but names might be considered confusing. "Publish" to local 
files is a flavor of export that is accordingly to Nicolas stabilize 
link anchors (the feature you miss in "export"). Nobody forces you to 
transfer exported files to your hosting using "publish".


Simple export is suitable for transient fragments or for tools like
https://github.com/jkitchin/ox-clip

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Timothy]

Eric S Fraga  writes:

> I have updated org.  Problem persists.
>
> Attached is a full backtrace after hitting C-u C-c C-c on a table.  The
> document itself has 2 headings and a small table.
>
> I unfortunately cannot spend more time on this at the moment as I have a
> presentation to make this afternoon and it's not quite ready...

Thank you for taking the time to check this in what sounds like a busy
day, and the backtrace. It's much appreciated :)

It seems like for you (org-element-property :post-affiliated context)
was unexpectedly nil. (or 0 ...) would be a quick-fix, but I find it odd
that this is a issue, and am yet to be able to reproduce this myself.

Is anybody else willing to try this and weigh in?

--
Timothy

p.s. Good luck with the presentation!

Re: W3C violations in Org's HTML export

[Bruce D'Arcus]

On Fri, Oct 23, 2020 at 3:46 PM TEC  wrote:

> ** Suggestion
>Make the subtitle an independent element, is can still be a
>p.subtitle, just not /inside/ the h2 title

Have you seen this?

Suggests wrapping title h* and p within a header.

https://www.w3.org/TR/html52/common-idioms-without-dedicated-elements.html#subheadings-subtitles-alternative-titles-and-taglines

Bruce

Re: [PATCH] ob-sql: blocks without :engine get stuck in org-edit-src-code on indent

[Ivan Sokolov]

> what you want to do?

I want to indent some sql in the src block in an org file.

> what happens instead

Buffer becomes unusable -- text is entered in the opposite direction
until the Org-Src buffer is closed. NOTE: I am not opening this buffer
myself, it is opened by org-indent-line, but is not closed because
sql-set-product throws a user-error.

> how the patch fixes the problem?

It ignores user-error thrown by sql-set-product.

---

Debugger entered--entering a function:
* signal(user-error ("SQL product nil is not supported; treated as ANSI"))
* user-error("SQL product %s is not supported; treated as ANSI" nil)
* #f(compiled-function (product) "Set `sql-product' to PRODUCT and enable 
appropriate highlighting." (interactive #f(compiled-function () #)) #)(nil)
* apply(#f(compiled-function (product) "Set `sql-product' to PRODUCT and enable 
appropriate highlighting." (interactive #f(compiled-function () #)) #) nil)
* sql-set-product(nil)
  org-babel-edit-prep:sql(("sql" "select foo\n" ((:results . "replace") 
(:exports . "code") (:tangle . "no") (:hlines . "no") (:noweb . "no") (:cache . 
"no") (:session . "none")) "" nil 1 "(ref:%s)"))
  org-edit-src-code()
  org-babel-do-key-sequence-in-edit-buffer("\11")
  org-indent-line()
  indent-according-to-mode()
  electric-indent-post-self-insert-function()
  self-insert-command(1)
  newline(nil 1)
  org--newline(nil nil 1)
  org-return(nil nil 1)
  funcall-interactively(org-return nil nil 1)
  call-interactively(org-return nil nil)
  command-execute(org-return)

Re: stability of toc links

[Nicolas Goaziou]

Hello,

Samuel Loury  writes:

> The publish feature only means exporting several files at once. 

You can publish a single file, too. It makes sense when a file is always
exported to the same location, possibly with the same configuration.

> IIUC, what was written was that when using the publish feature, the exported
> html pages will be coherent and a link in one document pointing to
> another document of the same publish call won't be broken.
>
> But IIUC, publishing the whole stuff again will result in totally
> different links. They will still be coherent and no broken link from one
> document of the whole to another. But a browser bookmark pointing the
> published lot the first time won't work with the same lot the second
> time.
>
> Did I understand correctly?

That's correct. 

Org provides a mechanism, called `org-export-get-reference', for
creating internal references, which relies on randomness + cache. But it
explicitly removes internal references not actually used from there (see
`org-publish--store-crossrefs'). Keeping those references instead would
make all links stable, of course.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Eric S Fraga]

I have updated org.  Problem persists.

Attached is a full backtrace after hitting C-u C-c C-c on a table.  The
document itself has 2 headings and a small table.

I unfortunately cannot spend more time on this at the moment as I have a
presentation to make this afternoon and it's not quite ready...

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-394-g7fc090
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  <(240 nil)
  (and (< (point) (org-element-property :post-affiliated context)) 
(org-match-line "[ \11]*#\\+plot:"))
  (cond ((and (< (point) (org-element-property :post-affiliated context)) 
(org-match-line "[ \11]*#\\+plot:")) (org-plot/gnuplot)) ((eq 
(org-element-property :type context) 'table\.el) (message "%s" 
(substitute-command-keys "\\Use `\\[org-edit-special]' to edit 
t..."))) ((or (eq type 'table) (and (eq type 'table-row) (= (point) 
(org-element-property :end context (save-excursion (if (org-at-TBLFM-p) 
(progn (require 'org-table) (org-table-calc-current-TBLFM)) (goto-char 
(org-element-property :contents-begin context)) (org-call-with-arg 
'org-table-recalculate (or arg t)) (orgtbl-send-table 'maybe (t 
(org-table-maybe-eval-formula) (cond (arg (call-interactively 
#'org-table-recalculate)) ((org-table-maybe-recalculate-line)) (t 
(org-table-align)
  (let nil (cond ((and (< (point) (org-element-property :post-affiliated 
context)) (org-match-line "[ \11]*#\\+plot:")) (org-plot/gnuplot)) ((eq 
(org-element-property :type context) 'table\.el) (message "%s" 
(substitute-command-keys "\\Use `\\[org-edit-special]' to edit 
t..."))) ((or (eq type 'table) (and (eq type 'table-row) (= (point) 
(org-element-property :end context (save-excursion (if (org-at-TBLFM-p) 
(progn (require 'org-table) (org-table-calc-current-TBLFM)) (goto-char 
(org-element-property :contents-begin context)) (org-call-with-arg 
'org-table-recalculate (or arg t)) (orgtbl-send-table 'maybe (t 
(org-table-maybe-eval-formula) (cond (arg (call-interactively 
#'org-table-recalculate)) ((org-table-maybe-recalculate-line)) (t 
(org-table-align))
  (cond ((memq type '(src-block inline-src-block)) (let nil (if 
org-babel-no-eval-on-ctrl-c-ctrl-c nil (org-babel-eval-wipe-error-buffer) 
(org-babel-execute-src-block current-prefix-arg (org-babel-get-src-block-info 
nil context) ((org-match-line "[ \11]*$") (let nil (or 
(run-hook-with-args-until-success 'org-ctrl-c-ctrl-c-final-hook) (user-error 
(substitute-command-keys "`\\[org-ctrl-c-ctrl-c]' can do nothing useful 
here") ((memq type '(inline-babel-call babel-call)) (let nil (let ((info 
(org-babel-lob-get-info context))) (if info (progn (org-babel-execute-src-block 
nil info)) ((eq type 'clock) (let nil (org-clock-update-time-maybe))) ((eq 
type 'dynamic-block) (let nil (save-excursion (goto-char (org-element-property 
:post-affiliated context)) (org-update-dblock ((eq type 
'footnote-definition) (let nil (goto-char (org-element-property 
:post-affiliated context)) (call-interactively 'org-footnote-action))) ((eq 
type 'footnote-reference) (let nil (call-interactively #'org-footnote-action))) 
((memq type '(inlinetask headline)) (let nil (save-excursion (goto-char 
(org-element-property :begin context)) (call-interactively 
#'org-set-tags-command ((eq type 'item) (let nil (if (or radio-list-p (and 
(boundp org-list-checkbox-radio-mode) org-list-checkbox-radio-mode)) 
(org-toggle-radio-button arg) (let* ((box (org-element-property :checkbox 
context)) (struct (org-element-property :structure context)) (old-struct 
(copy-tree struct)) (parents (org-list-parents-alist struct)) (prevs 
(org-list-prevs-alist struct)) (orderedp (org-not-nil ...))) 
(org-list-set-checkbox (org-element-property :begin context) struct (cond (... 
"[-]") (... "[ ]") (... nil) (... "[ ]") (t "[X]"))) (org-list-struct-fix-ind 
struct parents 2) (org-list-struct-fix-item-end struct) 
(org-list-struct-fix-bul struct prevs) (org-list-struct-fix-ind struct parents) 
(let ((block-item ...)) (if (and box ...) (if ... ... ...) 
(org-list-struct-apply-struct struct old-struct) 
(org-update-checkbox-count-maybe)) (if block-item (progn ...))) ((eq type 
'plain-list) (let nil (if (or radio-list-p (and (boundp 
org-list-checkbox-radio-mode) org-list-checkbox-radio-mode)) 
(org-toggle-radio-button arg) (let* ((begin (org-element-property 
:contents-begin context)) (struct (org-element-property :structure context)) 
(old-struct (copy-tree struct)) (first-box (save-excursion ... ... ...)) 
(new-box (cond ... ... ... ...))) (cond (arg (let ... ...)) ((and first-box 
...) (org-list-set-checkbox begin struct new-box))) (if (equal 
(org-list-write-struct struct ... old-struct) old-struct) (progn (message 
"Cannot update this checkbox"))) (org-update-checkbox-count-maybe) ((eq 
type 'keyword) (let nil (let ((org-inhibit-startup-visibility-stuff t) 
(org-startup-align-all-tables nil)) (if (boundp 'org-table-coordinate-overlays) 
(progn (mapc 

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Eric S Fraga]

On Friday, 30 Apr 2021 at 16:52, Timothy wrote:
> I checked the docs for `org-table-recalculate' and based on manually
> calling it compared the behaviour to C-u C-c C-c on a table and noticed
> no difference, but I'm not familiar with the intended functionality so
> an example from Eric (or someone else) of what should happen would be
> very helpful.

I get this when I try:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  org-ctrl-c-ctrl-c((4))
  funcall-interactively(org-ctrl-c-ctrl-c (4))
  command-execute(org-ctrl-c-ctrl-c)

I will update org (noting that the patch has been incorporated) and will report 
back with a proper backtrace.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty

Re: Additional indices in TexInfo exporter: FR or may be just a note ...

[Nicolas Goaziou]

Hello,

Ramesh Nedunchezian  writes:

> 1. (May be) support for additional indices in TexInfo exporter.

You can use

#+texinfo: @fooindex whatever

> 2. Use `info' function--as opposed to `info' binary--to open an
>exported INFO file. IOW, don't use `org-open-file', but use `info'
>function directly.

You can add, e.g,

  ("info" . (lambda (file _) (info file)))

to `org-file-apps'.

Regards,
-- 
Nicolas Goaziou

Re: Programmatically set TODO labels per file?

[Arthur Miller]

Nick Dokos  writes:

> Arthur Miller  writes:
>
>> I have a simple question, but I wasn't able to find answer on the web,
>> so finally I'll try my luck here.
>>
>
>> I know I can setq org-todo-keywords with a list '((sequence "TODO"
>> DONE")), as an example. But what variable is used for per-file keywords?
>> Once that are set with #+TODO: ... line?
>>
>> I guess when org mode parses a file when starting up the mode, it has to
>> parse that line into some var, where do I find it?
>>
>
> It is parsed into a buffer-local variable by the name of
> `org-todo-keywords-1'. Do `C-h v org-todo-keywords' and `C-h v
> org-todo-keywords-1' for all the details.
>
> BTW, when the interwebs fail you (or even before that), use the source :-)

Yes indeed! I used the source Luke! :)

I found that one, unfortunately it is not enough to set that one to my
keywords. There are also two lists in play org-todo-kwd-alist and
org-todo-key-alist which are set in one mastodont method, but I think I
can refactor that out. I have to figure out how to build alist comming
from out org-collect-keywords which is input to that part of
code. Didn't had time last night, will see if I have time today.

Re: Bug: Texinfo export: Inline images are NOT rendered in INFO viewer [9.4.5 (release_9.4.5-354-g40b70c @ /home/rameshnedunchezian/src/org-mode/lisp/)]

[Ramesh Nedunchezian]

On 30/04/21 3:34 pm, Ramesh Nedunchezian wrote:

> 1. Unzip the attached zip file.

Forgot to remove '.git' folder in the root before zipping.  Sorry
about this.

So, when you unzip the file, and you see a bunch of git-ted files,
don't be confused.  The MWE is still in there.

Re: stability of toc links

[Samuel Loury]

Hi.

I understood differently.

Tim Cross  writes:

[...]

> A question to help me understand this issue.
>
> If I understand correctly, exporting to HTML does not guarantee
> stability of TOC links. If you export as HTML, send someone a link from
> the toc and then re-export the document, the link will possibly be
> broken. Essentially, exporting to HTML has no guarantee of stability in
> toc links.

I think this is right.

> However, if you use publish instead of exporting to HTML, there is a
> guarantee of stability in toc links. When publishing a second time, the
> link will be consistent and still valid.

The publish feature only means exporting several files at once. IIUC,
what was written was that when using the publish feature, the exported
html pages will be coherent and a link in one document pointing to
another document of the same publish call won't be broken.

But IIUC, publishing the whole stuff again will result in totally
different links. They will still be coherent and no broken link from one
document of the whole to another. But a browser bookmark pointing the
published lot the first time won't work with the same lot the second
time.

Did I understand correctly?
-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature

Re: W3C violations in Org's HTML export

[Timothy]

Bastien  writes:

>> ** Suggestion
>>Make the subtitle an independent element, is can still be a
>>p.subtitle, just not /inside/ the h2 title
>
> Agreed, can you provide a patch for this?

I'll add that to my todo list.

>> ** Suggestion
>>Remove the ' type="text/javascript"' part of that.
>
> Done.

Nice.

>> [SVGs]
> Can you confirm the two issues above are already fixed?

As of d96e897579 I'm not seeing any more W3C complaints :)

>> * Error: Duplicate ID org0424ed6.
>>   Clearly, this can happen. I'm not sure how.
>>   I'd like to draw attention to this email I sent a while ago
>>   (excuse
>>   the mangled start)
>>   https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/
>
> I cannot reproduce this.

This may have been a low-chance once off / short-lived strange bug.
If nobody else has seen this happen, I'd be inclined to dismiss this.

>> * Error: Character reference expands to a control character
>>   (U+0002).
>>
>>   I suspect this may be htmlize, but I'm not sure, and it's
>>   Org-related,
>>   so I'll include it.
>
> I don't observe this, a reproducible recipe is welcome.

I'll come back to this if I can find out more.

>> * (not an error) Difficulty in 'wrapping' sections
>>   It's quite reasonable (IMO) to want to wrap a (sub*)section in a
>>   certain element, such as a link. Indeed I've wanted to do this
>>   to create clickable 'cards' on the homepage of my org website
>>   revamp. Unfortunately there doesn't seem to be any property like
>>   :HTML_WRAP: etc. that can be applied, forcing me to try this:
>>   [...]
>
> Please open a separate proposal for this.

Will do once I've thought a bit about what would be a good
interface/implementation for this.

> Once all issues listed here are handles, please close the call for
> help with "X-Woof-Help: close" as a header.

Will do 

Thanks for reminding me about this,

Timothy.

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Timothy]

Bastien  writes:

> Eric S Fraga  writes:
>
>> Further on this, I don't have time to debug right now but the patch
>> seems to have broken org table recalculation, specifically C-u C-c C-c
>> on a table.
>
> Thanks for reporting - Tim can you double-check this?

I checked the docs for `org-table-recalculate' and based on manually
calling it compared the behaviour to C-u C-c C-c on a table and noticed
no difference, but I'm not familiar with the intended functionality so
an example from Eric (or someone else) of what should happen would be
very helpful.

--
Timothy

Re: W3C violations in Org's HTML export

[Bastien]

Hi Timothy,

TEC  writes:

> * Error: Element p not allowed as child of element h2 in this 
>   context
>   Org currently seems to put a p.subtitle inside the heading.
>   This violates the "phrasing content" restriction.
>   
> https://html.spec.whatwg.org/multipage/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements
>
> ** Suggestion
>Make the subtitle an independent element, is can still be a
>p.subtitle, just not /inside/ the h2 title

Agreed, can you provide a patch for this?

> * Warning: The type attribute is unnecessary for JavaScript 
>   resources.
>   This seems to be from the 

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Bastien]

Eric S Fraga  writes:

> On Thursday, 29 Apr 2021 at 02:04, Timothy wrote:
>> Have you had a chance to test this out?
>
> Further on this, I don't have time to debug right now but the patch
> seems to have broken org table recalculation, specifically C-u C-c C-c
> on a table.

Thanks for reporting - Tim can you double-check this?

-- 
 Bastien

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Eric S Fraga]

On Thursday, 29 Apr 2021 at 02:04, Timothy wrote:
> Have you had a chance to test this out?

Further on this, I don't have time to debug right now but the patch
seems to have broken org table recalculation, specifically C-u C-c C-c
on a table.

Have to run to a meeting but will try to check this out later today if I
have time.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> Compiling /home/yantar92/Git/org-mode/lisp/ob-gnuplot.el...
>
> In end of data:
> ob-gnuplot.el:299:1:Warning: the function ‘file-local-name’ is not known to be
> defined.
>
> Compiling /home/yantar92/Git/org-mode/lisp/org.el...
>
> In org-display-inline-images:
> org.el:16554:57:Warning: reference to free variable ‘image-map’

could you provide a patch for these two warnings for the maint branch?

-- 
 Bastien

Additional indices in TexInfo exporter: FR or may be just a note ...

[Ramesh Nedunchezian]

TLDR:

1. (May be) support for additional indices in TexInfo exporter.

2. Use `info' function--as opposed to `info' binary--to open an
   exported INFO file. IOW, don't use `org-open-file', but use `info'
   function directly.

(2) would be nice to have.



I had a need to create an index of EIEIO classes in =helm= package.  

See

(info "(texinfo) New Indices")

I had to customize the default TexInfo exporter to achieve this
end. You can see the end result here:
https://rnchzn.github.io/helm/doc/helm-classes.html#Class-Index

This is what I did to create the additional index.

(defun org-texinfo-keyword+ (keyword contents info)
  (let* ((v (org-element-property :value keyword))
 (k (org-element-property :key keyword))
 (c (org-texinfo-keyword keyword contents info)))
(if c c
  (when (string-match  "\\(?:\\`\\(?1:.+\\)INDEX\\'\\)" k)
(format "@%sindex %s" (downcase (match-string 1 k)) v)

(defun org-texinfo-export-to-texinfo+ ()
  (interactive)
  (let ((outfile (org-export-output-file-name ".texi"))
(org-export-coding-system org-texinfo-coding-system))
(org-export-to-file 'my-texinfo outfile)))

(org-export-define-derived-backend 'my-texinfo 'texinfo
  :translate-alist '((keyword . org-texinfo-keyword+)))

Since I had to do multiple edit, compile, preview passes, I also
created the following "make-shift" command to make the process more
easier.  

(global-set-key (kbd "")
(defun make-shift ()
  (interactive)
  (let* ((info-buf-name (format "*info: %s*"
(file-name-sans-extension
 (file-name-nondirectory
  (buffer-file-name))
(when-let ((info-buf (get-buffer info-buf-name)))
  (kill-buffer info-buf))
(info (org-texinfo-compile (org-texinfo-export-to-texinfo+))
  info-buf-name

Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Bastien]

Hi Tim and everyone,

Tim Cross  writes:

> I do think it is probably time to drop support for Emacs 24 in the next
> major release. However, we cannot drop it 'mid release'.

yes, I'm in favor of dropping support for Emacs < 25.1 for Org 9.5.

Unless Nicolas, Kyle and Jack think otherwise, I'll announce this in
the release notes.

-- 
 Bastien

Re: [PATCH] org-protocol: Fix missing '+' in js snippet

[Bastien]

Hi Maxim,

Maxim Nikulin  writes:

> On 28/04/2021 12:40, you wrote:
>> Hi Maxim,
>> Would you like to volunteer as the maintainer for org-protocol.el?
>> For now org-protocol.el indicates that Sebastian Rose, the original
>> author, is the maintainer, but I don't think he would mind handing it
>> to someone else.
>
> I am proud to get such offer, but I am afraid, it is too early. I do
> not have enough experience with elisp and emacs. Beware of putting a
> vimer into maintainer position...

Fine :)

> Example of my ignorance: I suspect, I did not recognize that
> apostrophe needs special escaping in doc strings
> https://orgmode.org/list/s4hsag$ogg$1...@ciao.gmane.io/
>
> Actually, I do not think, org-protocol requires a dedicated
> maintainer. There are a few things that may be improved, but they
> should be discussed at first. It seems, all current user already
> managed to configure their handlers and prefer to not experiment any
> more. So there is a little interest in this area.

I don't use org-protocol.el myself and I'd rather have someone using
it being able to reproduce bugs and help maintainers fix problems.

Anyway, glad to have your input/patches on org-protocol.el anyway.

Thanks,

-- 
 Bastien

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Bastien]

Hi Timothy,

Timothy  writes:

> Now that Eric and I have both tested this, and Nicolas' comments have
> been taken into account, it would be great if a core maintainer could
> consider applying this patch :)

Done with commit aea31b065 in master, thanks to everyone in this thread.

I allowed myself to shortene the commit message a little bit, avoiding
personal statements ("as I think").

Also note that this patch did not land on updates.orgmode.org because
it was sent as a reply - I'll try to fix Woof! here.

Thanks,

-- 
 Bastien

Re: [PATCH] fix point position shifting in some org-src instances

[Bastien]

Hi Timothy,

thanks for reporting this.

Timothy  writes:

> I've noticed for a while that if you have a block with
> overlays/invisible characters that editing it with `org-edit-special'
> moves the point around.
>
> For example, with Org pretty entities enabled, and █ indicating the
> cursor, if I call org-edit-special on a LaTeX fragment like:
>   \( \alpha +█\beta \)
> which is displayed as \( α +█β \)
> The point is moved on creation of the org-src buffer
>   \( \alpha + \beta █\)
> Then if I move it back to after the "+", on calling `org-edit-src-exit'
> the point is moved to
>   \(█ \alpha + \beta \)
> In the original buffer.
>
> This may seem quite minor, but if you're editing a lot of LaTeX
> fragments having the point constantly jumping around can be quite a
> pain.
>
> After investigating this, I tried shifting org-src--{goto-}coordinates
> to a point-based approach from a column-based approach, and it seems to
> have fixed the problem.

Can someone else please test this patch and report any possible problem?

I guess tests come a bit short for such fixes.

Thanks,

-- 
 Bastien

Re: [PATCH] ob-sql: blocks without :engine get stuck in org-edit-src-code on indent

[Bastien]

Hi Ivan,

thanks for the bug report.

Ivan Sokolov  writes:

> user-error in sql-set-product interrupts normal execution flow in
> org-indent-line for sql blocks without :engine.

Sorry, I don't really understand what is the exact problem here.
Can you restate it by explaining what you want to do, what happens
instead, and how the patch fixes the problem?

Thanks,

-- 
 Bastien

Re: [PATCH] Have C-c C-c recognise #+plot lines

[Timothy]

Now that Eric and I have both tested this, and Nicolas' comments have
been taken into account, it would be great if a core maintainer could
consider applying this patch :)

--
Timothy

p.s. I'm specifically making a new reply to the version of the patch
that should be looked at, in the hope that this might help with clarity
when there are 4 different patches in this thread.

Re: Bug: [patch] fix: ox-rss died when an entry had an empty date [ ( @ /home/arne/.guix-profile/share/emacs/site-lisp/)]

[Bastien]

Hi Kyle and Arne,

Kyle Meyer  writes:

> I'm not an ox-rss user and don't know if there are more realistic ways
> to hit this error, but I was able to trigger it by taking an already
> exported buffer of
>
> * h1
>   :PROPERTIES:
>   :ID:   76841adc-b233-4f6d-8446-3478f263544b
>   :PUBDATE:  <2021-01-10 Sun 17:46>
>   :END:
>
> and then setting PUBDATE to an empty string and exporting again.
>
> I'm not sure if the error you see is indicative of a larger issue,
> though either way guarding against an empty string as your patch does
> seems fine.  

Indeed, thanks Arne for reporting this.

> Also, a bit downstream I see
>
>   (if (not pubdate0) "" ;; Skip entries with no PUBDATE prop
>
> It seems like this should be updated to look at pubdate rather than
> pubdate0 to avoid "nil" for the empty string
> case.

Indeed too.  Applied as commit 8ab1e30db in maint.

Thanks,

-- 
 Bastien

Re: [PATCH] ol.el: Fix confusing variable name

[Bastien]

Applied in maint as commit e2ffee96d - thanks Aaron for the patch and
Tim for the confirmation.

-- 
 Bastien

Re: [PATCH] ob-eval.el: Refactoring `org-babel-eval' to improve readability

[Bastien]

Hi Nick,

Nick Savage  writes:

> I have attached a patch to refactor `org-babel-eval' and
> `org-babel--shell-command-on-region' to improve readability and to
> make local variables more consistent between functions.

That's useful, thanks a lot.

> This also removes two parameters from
> `org-babel--shell-command-on-region', START and END. The function was
> created as a simplified `shell-command-on-region' that does only part
> of what it does. Those two parameters were included. As far as I can
> tell, `org-babel--shell-command-on-region' is only ever called by
> `org-babel-eval', and there is never any uncertainty over the contents
> of START and END as they are only ever (point-min) and
> (point-max). Given how specialized this function is, I believe it
> highly unlikely this is called anywhere else. I searched github too
> and didn't find anywhere where where code is calling this so I felt it
> was safe. I'm happy to change it back if necessary.

Agreed - thanks for taking the time to check on the web whether this
would break anything.

Applied in master as commit c212b7dae.

Thanks,

-- 
 Bastien

Re: stability of toc links

[Timothy]

Dominique Dumont  writes:

> For what it's worth, DNS servers faces a similar problem where host names can
> contain any unicode character, but DNS servers support only ascii char. In DNS
> cases, this is worked around using punycode. (1)
>
> Using the example above, a host named "こんにちは.example" is converted to
> "xn--28j2a3ar1p.example".
>
> Punycode is available in Emacs through libidn (2)

Thanks! I'm now making use of it as of 
https://github.com/tecosaur/emacs-config/commit/1ccbadd

--
Timothy