Re: [BUG] manual should explain how to insert literal dollar sign

[Ihor Radchenko]

Paul Rubin  writes:

> Context: I wanted to mention in a document that a certain item cost 
> "$12.98+$.77 s/h".  Since the period after the second $ is punctuation, 
> the parsing heuristic interpreted that as LaTeX, giving math output in 
> the html export.  So I spent a while muddling around trying to figure 
> out how to escape the dollar sign, then sought help on IRC, where I got 
> the answer: write \dollar and the Org entity parser will turn it into a 
> literal dollar sign.  I would not have figured this out myself.
>
> Requested fix: explain the \dollar escape in the Org manual section 
> "LaTeX fragments".

Thanks for reporting!
Fixed, on main.
I also added a linter, so that M-x org-lint will report such cases.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cf2349d14
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dc70878fc

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

Re: [BUG] incorrect org-mode dynamic blocks docs [9.5.4 (release_9.5.4-3-g6dc785 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

[Ihor Radchenko]

pva-outd...@yandex.ru writes:

> 1. It seems that dynamic blocks can't have inner headlines (the
> org-dblock-write:xxx should not produce them). Otherwise the block will
> be parsed incorrectly (not mentioned in docs for org-mode).

That's Org markup. Headings have the top priority - any "*...* "
starting at the beginning of line is a heading that ends at the next
"*...* " or end of buffer.

> Example: Create the following 1.org and export it to unicode text (press
> C-c C-e t U). You will see "#+BEGIN: block2" as text.
>
>   * Block2
>   
>   #+BEGIN: block2
>   ** Section 1
>   asdasdsad
>   #+END:

There is no block in the above example.
What you have is


* Block2


#+BEGIN: block2


** Section 1

asdasdsad
#+END:




We intentionally do not prohibit such scenario for dynamic block
functions to keep flexibility.
   
> 2. Org-mode info file says:
>
>  Dynamic blocks, like any other block, can be narrowed with
>   ‘org-narrow-to-block’.
>
> That would not work because of implementation of org-narrow-to-block:
>
> (defun org-narrow-to-block ()
>   "Narrow buffer to the current block."
>   (interactive)
>   (let* ((case-fold-search t)
>(blockp (org-between-regexps-p "^[ \t]*#\\+begin_.*"  <
>   "^[ \t]*#\\+end_.*")))
> (if blockp
>   (narrow-to-region (car blockp) (cdr blockp))
>   (user-error "Not in a block"

Agree.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=85aa3c185

> There is also a minor bug in org-mode (sould I report it
> in it's own mail?):
>
> If you press C-c C-, [RET] [RET] You'll get:
>
> #+begin_
> #+end_nil
>
> while one could expect either begin_nil or end_. 

An error will be thrown now.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=64a0a624d

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

Re: [PATCH] org: fix symbol names and grammar in docstrings

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> The docstrings of `org-outline-level' and `org-current-level' contain
> the undefined symbol name `org-odd-levels'.
>
> The same lines of the docstrings contain also wording like
> "Unlike to `org-current-level'" and "Unlike to `org-outline-level'"
>   where "to" should not be there.
>
> This patch changes the symbol names to `org-odd-levels-only' and
> removes the "to" typos.

Thanks!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a4586f0d7

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

Re: batch breaks bugfix

[Ihor Radchenko]

Samuel Wales  writes:

> - bugfix and main sorting still not getting ts-down tsia-down right.
> maint gets it right.

maint is obsolete and no longer used.

> - having said that it was a relief to have had this script for so many
> years as i was able to be confident that the agenda was picking up
> every relevant task, not picking up others, sorting, formatting
> correctly, org version changes, .emacs...]

Understood. That's why Org has regression tests as well :)

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

[PATCH v5] Re: Improve the performance of `org-set-tags-command` on large `org-tag-alist`

[Christopher M. Miles]

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> I improved the code a little. Can't figure out how to implement upper logic.
>> Can you finish the last part? Thanks
>>
>> #+begin_src emacs-lisp
>> (setq tbl (let* ((tags-grouped (org-tag-alist-to-groups fulltable))
>>...
>
> I tried to improve the code readability in `org-fast-tag-selection'.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a19654583c6f2070096402bc712591a0a2c80d01
>
> May you look at it again and see if you can manage to implement a full
> patch now?

Ok, I update and re-generated the patch, also add new document and Org NEWS 
entries.

Review it, if has problem, notify me to modify. Thanks



0001-org-Improve-the-tags-fast-selection-performance.patch
Description: 

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: Add final hooks to S-/M-/S-M-cursor commands

[Ihor Radchenko]

Evgenii Klimov  writes:

> `org-shiftup' and other S-cursor commands not only provide initial
> hooks but also final hooks, while M-cursor and S-M-cursor commands
> lack them. These patches add final hooks to all of these commands and
> document both hooks in the docstring if they are not already present.

Thanks for the patch!
May you please squash it into one, add TINYCHANGE cookie (unless you
have FSF copyright assignment; see
https://orgmode.org/worg/org-contribute.html#first-patch), and document
your changes in /etc/ORG-NEWS file?

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

Re: [PATCH] org-faq.org: Inline comments

[Ihor Radchenko]

Max Nikulin  writes:

>> The proposed FAQ entry is overwhelming. It would work fine as a blog,
>
> A blog with a couple of posts a year has a little sense. Moreover it is 
> closer to a wiki article because it is supposed to be updated. That is 
> why I asked for an alternative location on Worg for bonus or extra 
> material for the manual.

I have no idea about alternative location.
Maybe someone more familiar with WORG. Bastien?

>> FAQ is probably fine. We may add a CSS there that will fold the
>> answers by default.
>
> When all entries are opened, it is possible to use search in browser. I 
> am against the idea of hiding answers. However the table of contents, 
> that is rather long and revealed on hover only, makes it harder to 
> search in the TOC at first.

Maybe we can add a proper TOC at the top? Or convert the on-hover TOC
into proper one. TOC on top + detailed answers is how many FAQ pages are
designed.

> I have tried a random query "org-mode renumber footnotes" that is quite 
> close to an entry from the document. Nether Google nor Bing offered FAQ 
> on first 2 pages of search results. So FAQ is not friendly to search 
> engines for some reasons. I am unsure if the rank may be improved by 
> e.g. microdata schema.org attributes.

I wish we had somebody who is familiar with these things. I personally
have no idea what can be wrong and where to start to solve this problem.

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

Re: exporting to PDF multi-lingual document

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> I think you have to solve this on the LaTeX-side: including packages
> that support the required unicode.

Well. Org does provide support for non-English languages. For example,
see org-latex-language-alist and org-latex-guess-babel-language.

It would be nice if Org could handle LaTeX language property, without
users doing all the LaTeX workarounds on their own. (It is not like this
problem is new or uncommon in LaTeX community).

We just need to figure out a good universal preamble that can be
generated according to the #+LANGUAGE settings.

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

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Ihor Radchenko]

Sébastien Miquel  writes:

> Ihor Radchenko writes:
>> But why do we need to avoid indenting empty lines?
>
> In the following link, Greg Minshal argues for preserving empty lines:
> https://list.orgmode.org/725763.1632663...@apollo2.minshall.org/T/

Thanks for the reference!
I can see that non-empty blank line below might be annoying for some users.

\t#+begin_src lang
\t  line1
\t  line2
^\t  $
\t#+end_src

However, I do not see why Org should clear blank lines created by the
lang-mode itself

\t#+begin_src lang
\t  line1:
\t  \tline2:
^\t \t\t$
\t#+end_src

If source code in the edit buffer contains non-empty blank lines, it is
not Org's responsibility to clear them. In fact, it will go against
possible user settings!

So, I agree that we should not indent empty lines. However, I do not
agree that we should not indent non-empty blank lines.

---

The code in your patch is confusing, considering the above
considerations.

> -(setq org-src--preserve-blank-line preserve-blank-line)
> +(setq org-src--indent-current-empty-line (and blank-line
> +  (not empty-line)))

Here, you have a variable named "empty-line" set when (not empty-line). ??

Also,

>   (while (not (eobp))
> -   (skip-chars-forward " \t")
> -  (when (or (not (eolp))   ; not a blank 
> line
> -(and (eq (point) (marker-position marker)) ; current line
> +  (when (or (not (eolp)) ; not an empty line
> +;; If the current line is empty, we may
> +;; want to indent it.
> +(and (eq (point) (marker-position marker))
>   preserve-blank-line))
>(insert indent-str))
> (forward-line)))

removed `skip-chars-forward' call, so the loop will always check every
bol and (not (eolp)) will be t for every line, except ^$.
Then, considering that preserve-blank-line is set when (not empty-line),
your second condition will never trigger.

I feel that something is fishy in the logic.

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

Re: [PATCH v5] Re: Improve the performance of `org-set-tags-command` on large `org-tag-alist`

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> Ok, I update and re-generated the patch, also add new document and Org NEWS 
> entries.

Thanks!
See my comments below.

> * lisp/org.el (org-fast-tag-selection): Filter out only maximum number
> limited tags has fast selection bound when `org-use-fast-tag-selection'
> is 'auto and tags has fast select bound keys.

Why only for 'auto?

> * doc/org-manual.org (org-fast-tag-selection-maximum-tags): Add new
> custom option document.

*documentation.

> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -5073,6 +5073,16 @@ effect: start selection with {{{kbd(C-c C-c C-c)}}} 
> instead of
>  the special window is not even shown for single-key tag selection, it
>  comes up only when you press an extra {{{kbd(C-c)}}}.
>  
> +#+vindex: org-fast-tag-selection-maximum-tags
> +Limit the tags table when you have many tags. You can set the maximum

#+vindex entry will not be visible in the rendered manual. So, the first
 sentence of the paragraph reads awkwardly.

Also, please use double space between sentences. It is the convention
for Org manual, docstrings, and commit messages. See
doc/Documentation_Standards.org

> +(defcustom org-fast-tag-selection-maximum-tags 26
> +  "Set the maximum tags number for fast tag selection."
> +  :group 'org-tags
> +  :type 'number
> +  :safe #'numberp)

Why 26?
We use a-zA-Z{|}~

;; Characters available for auto-assignment.
 (tag-binding-char-list
  (eval-when-compile
(string-to-list 
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ{|}~")))

Also, please add :package-version keyword in the defcustom.

>(let* (;; Combined alist of all the tags and todo keywords.
> - (tag-alist (append tag-table todo-table))
> + (tag-alist (let* ((tags-table (append tag-table todo-table))
> +   (binding-tags (seq-filter 'cdr tags-table)))
> +  (cl-case org-use-fast-tag-selection
> +(auto (if (length> binding-tags 
> org-fast-tag-selection-maximum-tags)
> +  binding-tags
> +(seq-take tags-table 
> org-fast-tag-selection-maximum-tags)))
> +(t tags-table

May you please instead:

1. Store the total number of bound tags, but using a bit more complex
   filter (`(:startgroup "foo")', `(:endgroup "bar")' are also valid alist
   members, but do not correspond to tag bindings). See `(pcase
   tag-binding-spec ...)'
2. Store the total number of tag in tag groups. See `ingroup'.
3. Add these two numbers and compare them with
   `org-fast-tag-selection-maximum-tags', calculating how many extra
   tags can be displayed.
4. Do not filter `tag-alist', but instead plug a code into `(while (setq
   tag-binding-spec (pop tag-alist)) ...)', counting how many tags are in
   There, in `;; Insert the tag.', only insert the tag when (1) tag has
   binding - (cdr tag-binding-spec); (2) tag is in a group - ingroup;
   (3) we still have space for extra tags, according to (3), then also
   decrease the leftover tag count.

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

Re: [RFC] Refactoring org-element API (was: [DISCUSSION] Refactoring fontification system)

[Ihor Radchenko]

Ihor Radchenko  writes:

> In order not to turn org-element into another org-agenda, I am proposing
> to factor out Org syntax tree API into a separate file
> org-element-ast.el and add a number of breaking changes how the syntax
> tree is structured.

Applied, onto main.

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

Re: Add final hooks to S-/M-/S-M-cursor commands

[Ihor Radchenko]

Evgenii Klimov  writes:

> On July 1, 2023 11:40:07 AM GMT+01:00, Ihor Radchenko  
> wrote:
>>Thanks for the patch!
>>May you please squash it into one
>>
>
> Don't you mind if I also add the final hook to `org-meta-return'? I
> didn't do it right away because it requires a little bit of refactoring:
> everything after the initial hook is currently run with
> `call-interactively'.

Should be fine, I think. Although I am not 100% sure if it is going to
be useful in practice.

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

Re: [PATCH] org-faq.org: Inline comments

[Ihor Radchenko]

Max Nikulin  writes:

>> FAQ is probably fine. We may add a CSS there that will fold the
>> answers by default.
>
> When all entries are opened, it is possible to use search in browser. I 
> am against the idea of hiding answers. However the table of contents, 
> that is rather long and revealed on hover only, makes it harder to 
> search in the TOC at first.

I am now watching
https://fosdem.org/2023/schedule/event/a11y_eaa_bfsg_wcag_wai_aria_wtf/

They suggest a combination of  to keep hidden text
searchable. See 
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary

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

Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)]

[Sébastien Miquel]

Ihor Radchenko writes:

+ ;; Trim contents: `org-src--contents-for-write-back' may have
+ ;; added indentation at the beginning, which we remove.


May you also mention that we remove the indentation to avoid adding
spaces to latex fragments in the middle of a paragraph?


On second thought, I don't think moving the LaTeX fragment logic away
from `org-src--contents-for-write-back` makes sense. This part of the
function does the opposite of `org-do-remove-indentation`, and the
latter has a boolean argument `skip-fl`, so it makes sense to keep it
the same here. It is simple enough.

If you're worried about consistency with inline src blocks, I find it
weird for them to have newlines, let alone newlines mixed with org's
indentation. But if we do want to treat them the same, then we also
need to modify `org-do-remove-indentation` to skip the first line for
them as well.

I've taken this part off the patch for now.


If source code in the edit buffer contains non-empty blank lines, it is
not Org's responsibility to clear them. In fact, it will go against
possible user settings!

So, I agree that we should not indent empty lines. However, I do not
agree that we should not indent non-empty blank lines.


The patch I propose does indent non-empty blank lines. The issue is
with =org-do-remove-indentation= which empties blank lines. I've added
a fix to this.


-(setq org-src--preserve-blank-line preserve-blank-line)
+(setq org-src--indent-current-empty-line (and blank-line
+  (not empty-line)))


Here, you have a variable named "empty-line" set when (not empty-line). ??


I've renamed it yet again!




  (while (not (eobp))
- (skip-chars-forward " \t")
-  (when (or (not (eolp))   ; not a blank 
line
-(and (eq (point) (marker-position marker)) ; current line
+  (when (or (not (eolp)) ; not an empty line
+;; If the current line is empty, we may
+;; want to indent it.
+(and (eq (point) (marker-position marker))
  preserve-blank-line))
   (insert indent-str))
  (forward-line)))


removed `skip-chars-forward' call, so the loop will always check every
bol and (not (eolp)) will be t for every line, except ^$.
Then, considering that preserve-blank-line is set when (not empty-line),
your second condition will never trigger.

I feel that something is fishy in the logic.


What happens is: in the org buffer, the line is not empty, because it
has the org indentation (which was possibly just added by
org-indent-line), but in the edit buffer, the line is empty, because
the common org indentation was removed. In that case, we want to add
back the org indentation.

--
Sébastien MiquelFrom ecc87b4a75dec7ff8fba4c86635ba3cdb43444ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Tue, 27 Jun 2023 09:23:01 +0200
Subject: [PATCH] org-src.el: Use native value of `indent-tabs-mode' for
 indentation

* lisp/org-macs.el (org-do-remove-indentation): Preserve
indentation (spaces vs tabs) past the common indentation to remove.
Do not empty blank lines.
* lisp/org-src.el (org-src--contents-for-write-back): Preserve the
native indentation (spaces vs tabs).  If necessary, add a common org
indentation to the block according to org's `indent-tabs-mode'.
(org-src-font-lock-fontify-block): In case of mixed indentation,
display the tab characters with a fixed width, according to the native
tab width value.
* testing/lisp/test-org-src.el (test-org-src/indented-blocks): Update
tests.  Indentation no longer obeys `indent-tabs-mode' from the org
buffer, but is separated in two parts.
---
 lisp/org-macs.el |  9 +++--
 lisp/org-src.el  | 45 --
 testing/lisp/test-org-src.el | 75 ++--
 3 files changed, 85 insertions(+), 44 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 51dbfe118..ea210dc60 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -483,9 +483,12 @@ line.  Return nil if it fails."
 (when skip-fl (forward-line))
 	(while (not (eobp))
 	  (let ((ind (progn (skip-chars-forward " \t") (current-column
-	(cond ((eolp) (delete-region (line-beginning-position) (point)))
-		  ((< ind n) (throw :exit nil))
-		  (t (indent-line-to (- ind n
+	(cond ((< ind n)
+   (if (eolp) (delete-region (line-beginning-position) (point))
+ (throw :exit nil)))
+		  (t (delete-region (line-beginning-position)
+(progn (move-to-column n t)
+   (point)
 	(forward-line)))
 	;; Signal success.
 	t
diff --git a/lisp/org-src.el b/lisp/org-src.el
index f15ba8e99..9e6031016 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -474,11 +474,15 @@ Assume point is

Re: exporting to PDF multi-lingual document

[andrés ramírez]

Hi. Ihor.

> "Ihor" == Ihor Radchenko  writes:

[...]


Ihor> We discussed a similar issue previously in
Ihor> https://list.orgmode.org/orgmode/87h6z7jq4o.fsf@localhost/

I have dowloaded de whole thread. And I got something that shows
'quotation marks' in place of Japanese characteres.

I think the problem is the font (probably a different font is
needed). So let me know If You know any hints:
--8<---cut here---start->8---
#+TITLE: Doc multi-lingual
#+options: author:nil email:nil toc:nil num:nil date:nil
#+LATEX_COMPILER: lualatex
#+LANGUAGE: jp
#+LaTeX_Header: \usepackage[AUTO]{polyglossia}
#+LaTeX_Header: \usepackage{fontspec}
#+LaTeX_Header: \setmainfont{FreeSerif}
* Español
Hola
* English
Hi
* French 
Ceci c'est en Français
* Japanese
ダウンロード
--8<---cut here---end--->8---

Best Regards
Andrés Ramírez

Re: exporting to PDF multi-lingual document

[andrés ramírez]

Hi. Arne.

> "Arne" == Arne Babenhauserheide  writes:


[...]


Arne> I think you have to solve this on the LaTeX-side: including packages 
that support the
Arne> required unicode.

[...]


Thanks. That helped. It ended like this:
--8<---cut here---start->8---
#+TITLE: Doc multi-lingual
#+options: author:nil email:nil toc:nil num:nil date:nil
#+LATEX_HEADER: \usepackage{CJKutf8}
* Español
Hola
* English
Hi
* French 
Ceci c'est en Français
* Japanese
@@latex:\begin{CJK}{UTF8}{min}@@
ダウンロード
@@latex:\end{CJK}@@
--8<---cut here---end--->8---

Best Regards
Andrés Ramírez

Re: [PATCH] org-element-timestamp-interpreter: Return daterange anyway, if DATERANGE is non-nil

[Ilya Chernyshov]

Hello!

In the new patch I added :range-type timestamp property, adjusted
interpreter,
parser functions, added tests for the property.



On Wed, Feb 22, 2023 at 11:21 AM Ihor Radchenko  wrote:

> I suggest introducing a new timestamp property :range-type. It can be
> nil, timerange, or daterange.
>
> Changing :type values will not be backwards-compatible.
>
From d95418110897bdde85a74734bb5b5fa7a3c77b92 Mon Sep 17 00:00:00 2001
From: Ilya Chernyshov 
Date: Sat, 18 Feb 2023 14:55:39 +0700
Subject: [PATCH] New timestamp property :range-type

* lisp/org-element (org-element-timestamp-interpreter): For ranges:
When :range-type is nil or `timerange', return timerange () if date-start and date-end are equal; return
daterange(<...>--<...>) otherwise. When :range-type is `daterange',
return daterange anyway. Refactor the code.

* lisp/org-element (org-element-timestamp-parser): Add :range-type property

* testing/lisp/test-org-element
(test-org-element/timestamp-interpreter): Add new tests.
(test-org-element/timestamp-parser): Add testing for :range-type
property.
---
 lisp/org-element.el  | 168 ++-
 testing/lisp/test-org-element.el |  86 +---
 2 files changed, 149 insertions(+), 105 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index bfb1d206e..13dd41e5d 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4043,7 +4043,7 @@ Assume point is at the target."
   "Parse time stamp at point, if any.
 
 When at a time stamp, return a new syntax node of `timestamp' type
-containing `:type', `:raw-value', `:year-start', `:month-start',
+containing `:type', `:range-type', `:raw-value', `:year-start', `:month-start',
 `:day-start', `:hour-start', `:minute-start', `:year-end',
 `:month-end', `:day-end', `:hour-end', `:minute-end',
 `:repeater-type', `:repeater-value', `:repeater-unit',
@@ -4077,6 +4077,10 @@ Assume point is at the beginning of the timestamp."
 			 (activep 'active)
 			 ((or date-end time-range) 'inactive-range)
 			 (t 'inactive)))
+ (range-type (cond
+  (date-end 'daterange)
+  (time-range 'timerange)
+  (t nil)))
 	 (repeater-props
 	  (and (not diaryp)
 		   (string-match "\\([.+]?\\+\\)\\([0-9]+\\)\\([hdwmy]\\)"
@@ -4123,6 +4127,7 @@ Assume point is at the beginning of the timestamp."
 	(org-element-create
  'timestamp
 	 (nconc (list :type type
+  :range-type range-type
 		  :raw-value raw-value
 		  :year-start year-start
 		  :month-start month-start
@@ -4142,98 +4147,75 @@ Assume point is at the beginning of the timestamp."
 
 (defun org-element-timestamp-interpreter (timestamp _)
   "Interpret TIMESTAMP object as Org syntax."
-  (let* ((repeat-string
-	  (concat
-	   (pcase (org-element-property :repeater-type timestamp)
-	 (`cumulate "+") (`catch-up "++") (`restart ".+"))
-	   (let ((val (org-element-property :repeater-value timestamp)))
-	 (and val (number-to-string val)))
-	   (pcase (org-element-property :repeater-unit timestamp)
-	 (`hour "h") (`day "d") (`week "w") (`month "m") (`year "y"
-	 (warning-string
-	  (concat
-	   (pcase (org-element-property :warning-type timestamp)
-	 (`first "--") (`all "-"))
-	   (let ((val (org-element-property :warning-value timestamp)))
-	 (and val (number-to-string val)))
-	   (pcase (org-element-property :warning-unit timestamp)
-	 (`hour "h") (`day "d") (`week "w") (`month "m") (`year "y"
-	 (build-ts-string
-	  ;; Build an Org timestamp string from TIME.  ACTIVEP is
-	  ;; non-nil when time stamp is active.  If WITH-TIME-P is
-	  ;; non-nil, add a time part.  HOUR-END and MINUTE-END
-	  ;; specify a time range in the timestamp.  REPEAT-STRING is
-	  ;; the repeater string, if any.
-	  (lambda (time activep &optional with-time-p hour-end minute-end)
-	(let ((ts (format-time-string
-   (org-time-stamp-format with-time-p)
-		   time)))
-	  (when (and hour-end minute-end)
-		(string-match "[012]?[0-9]:[0-5][0-9]" ts)
-		(setq ts
-		  (replace-match
-		   (format "\\&-%02d:%02d" hour-end minute-end)
-		   nil nil ts)))
-	  (unless activep (setq ts (format "[%s]" (substring ts 1 -1
-	  (dolist (s (list repeat-string warning-string))
-		(when (org-string-nw-p s)
-		  (setq ts (concat (substring ts 0 -1)
-   " "
-   s
-   (substring ts -1)
-	  ;; Return value.
-	  ts)))
-	 (type (org-element-property :type timestamp)))
-(pcase type
-  ((or `active `inactive)
-   (let* ((minute-start (org-element-property :minute-start timestamp))
-	  (minute-end (org-element-property :minute-end timestamp))
-	  (hour-start (org-element-property :hour-start timestamp))
-	  (hour-end (org-element-property :hour-end timestamp))
-	  (time-range-p (and hour-start hour-end minute-start minute-end
- (or (/= hour-start hour-end)
-			

Re: [BUG] incorrect org-mode dynamic blocks docs [9.5.4 (release_9.5.4-3-g6dc785 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

[Ihor Radchenko]

[ Adding Org ML back to CC; Please use Reply-All or wide reply to
  include the mailing list in the discussion ]

pva-outd...@yandex.ru writes:

> Try the following:
>
> 1. Create "1.org" buffer (C-x b 1.org [RET]) and make it org-mode (M-x
>org-mode [RET]).
> ...
>I believe it is the same as if you create a function:
>
>--EXAMPLE-HERE--
>(defun org-dblock-write:expands-some (params-map)
>  (insert "
>** Section 2
>
>With some text
>"))
>--END-OF-EXAMPLE--
>
>And a org-mode buffer with the content:
> ...
> The "#+BEGIN: expands-some" will not appear if
> `org-dblock-write:expands-some` is not generating headings (i.e. lines
> maching regex "^[*]+ ").
>
> So I think either there is a bug in dynamic blocks expansion or it's
> documentation should have notice on including headings inside dynamic
> blocks.

It looks like you misunderstand Org syntax.
Headings in Org files are context-free.
It means that any appearance of a ***  always starts a new
heading, breaking any other syntax element.
You may refer to https://orgmode.org/worg/org-syntax.html

You can similarly break Org syntax structure in many other ways. For
example, by putting #+END: in the block expansion.

All these are side effects of plain text nature of Org.
We could shield the dynamic block output from edge cases like what you
observe or like I provided in my example with #+END:, but we see this
behaviour as a feature. If necessary, you can wrap your dynamic block
output into `org-escape-code-in-string' to ensure that surrounding Org
markup is not affected.

> I found this behavior while implementing a template document which fills
> some sections depending on conditions (automatic documentation from
> OpenAPI). Thus ability to generate subheadings with dynamic blocks
> became a key feature here. That is why I recommend describing this
> restriction in documentation (probably "A.6 Dynamic Blocks" section) if
> this behavior is desired.

This restriction is not limited to dynamic blocks. Similar restriction
applies to example blocks, other blocks, drawers, etc.
I guess we can add documentation describing these gotchas about Org
syntax, though I am not sure if A.6 is the most suitable section.
Probably, we can add a dedicated Appending and then refer to it from
other places. Patches welcome!

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

Re: exporting to PDF multi-lingual document

[Dr. Arne Babenhauserheide]

andrés ramírez  writes:

> Arne> I think you have to solve this on the LaTeX-side: including 
> packages that support the
> Arne> required unicode.
> Thanks. That helped. It ended like this:

I’m glad to hear that! Thank you for posting your solution.

> #+LATEX_HEADER: \usepackage{CJKutf8}
> * Japanese
> @@latex:\begin{CJK}{UTF8}{min}@@
> ダウンロード
> @@latex:\end{CJK}@@

This still seems like a lot of manual deciding whether something is
Japanese or not. I’m not sure whether there’s an easier solution,
though.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: batch breaks bugfix

[Samuel Wales]

i still use maint as a comparison against bugfix and main to make sure
they didn't intro regressions.  i even tested 8 for a long time so i
could go back and check formatting changes etc.  if maint gets it
right tht might be a clue is all.


On 7/1/23, Ihor Radchenko  wrote:
> Samuel Wales  writes:
>
>> - bugfix and main sorting still not getting ts-down tsia-down right.
>> maint gets it right.
>
> maint is obsolete and no longer used.
>
>> - having said that it was a relief to have had this script for so many
>> years as i was able to be confident that the agenda was picking up
>> every relevant task, not picking up others, sorting, formatting
>> correctly, org version changes, .emacs...]
>
> Understood. That's why Org has regression tests as well :)
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: basic git

[Max Nikulin]

On 01/07/2023 05:15, Samuel Wales wrote:

On 6/30/23, Max Nikulin wrote:

Do you have history of last git commands, e.g. in an emacs eshell
buffer? Please, post them.


It is unclear what was the current branch before (a custom local one, 
"bugfix" or "main" tracking the upstream) and whether all local changes 
were committed.



   502  ado git-pullv # says what's new etc.


I have no idea concerning "ado" and "git-pullv". The "git pull" command 
should add changes from the tracked remote branch to your local one.



   503  git branch --set-upstream-to=origin/bugfix bugfix
#i was told to do this.  it worked ok before.  but now it tells me i
have to do something.


This command was necessary just once per local branch when you were 
switching from the orgmode.org git repository to savannah. Another use 
case is when you want associate a new local branch with a remote one.



   504  cd $delbig
   505  cd 9bugfix #symlink


So the commands above and below were executed in unrelated clones.


   506  git status
   507  ado git-pullv
   508  git pull
   509  git fetch --tags origin #desperation sets in


"git pull" should fetch changes from the remote branch. "git fetch" 
obtains changes for all remote branches (remotes/origin/bugfix, etc.) 
without touching the local one. So "git fetch" should not break anything.


Perhaps you had a branch that was tracking remotes/origin/main, you 
forced to set tracked branch to remotes/origin/bugfix and "git pull" 
failed in the process of merging changes from these branches. Usually 
the reasonable action is to abort by the command suggested in the "git 
status" output to get the state before "git pull".



   510  git status
   511  ado git-pullv
# this is the !@#$ it moment.  should work for sure.  ha ha.
   512  git clone https://git.savannah.gnu.org/git/emacs/org-mode.git
   513  mv org-mode ../new
   514  cd ..
   515  mv org-mode--vanilla-bugfix--ok-to-pull--xyzzy-nomost
../obsolescent--xyzzy-nomost/
   516  mv new org-mode--vanilla-bugfix--ok-to-pull--xyzzy-nomost
   517  cd org-mode--vanilla-bugfix--ok-to-pull--xyzzy-nomost


I am lost whether you are in the directory with the fresh clone. I would 
assume it.



   518  git status
   519  git gc


Unnecessary in a fresh clone. You may make it impossible recover local 
changes if you run it when you are unsure where you are. Will you throw 
away garbage when you lost some precious thing and there is a chance 
that you put it into the bin with a heap of other stuff?



   520  git status
   521  git branch bugfix


This may be a cause of confusion. The default branch of the org 
repository is "main" (am I right?) and in the fresh clone you should be 
on "main". By this command you created a local branch named "bugfix" but 
unrelated to the upstream branch. The current (HEAD) commit of the local 
"bugfix" points to the current commit.



   522  git status
   523  git branch
   524  git checkout bugfix


This would be a correct command that creates local "bugfix" tracking 
remote "bugfix" unless you executed "git branch bugfix" before. Now you 
are on a commit from "main".



   525  git status
   526  ado git-pullv
   527  ado diffoldnew cat .git/config
   528  git branch --set-upstream-to=origin/bugfix bugfix


I may be wrong with my assumption, but you created local "bugfix" 
pointing to a commit from remotes/origin/main and forced it to track 
remotes/origin/bugfix. The message from your first post is the plausible 
consequence of "git pull" from this state.


If you goal is a clean clone with "bugfix" as the current branch you may do

git clone https://git.savannah.gnu.org/git/emacs/org-mode.git \
org-mode--vanilla-bugfix--ok-to-pull--xyzzy-nomost
cd org-mode--vanilla-bugfix--ok-to-pull--xyzzy-nomost
git checkout bugfix

Do you need to recover commits with your local changes or your are 
experimenting with clean upstream "bugfix" and "main" branches?

Re: org-insert-link completion by description (Re: what is the purpose of "This link has already been stored"?)

[Max Nikulin]

On 01/07/2023 13:12, Max Nikulin wrote:

On 01/07/2023 12:15, Samuel Wales wrote:

emacs -q 9.6.7, vaniila except for whatever -q loads, opens a links
window that shows descrtipition and truncated link.


Ignore the links window and try to type first letter of a link 
description and TAB.


...and TAB once more to make the completions window appeared. If default 
completion works then it is necessary to debug ido and customization to 
realize why data passed by `org-insert-link' is not enough for ido in 
your case.

Re: org-insert-link completion by description (Re: what is the purpose of "This link has already been stored"?)

[Samuel Wales]

another window would not work for me but using completion as i do with
e.g. refile goto would.

On 7/1/23, Max Nikulin  wrote:
> On 01/07/2023 13:12, Max Nikulin wrote:
>> On 01/07/2023 12:15, Samuel Wales wrote:
>>> emacs -q 9.6.7, vaniila except for whatever -q loads, opens a links
>>> window that shows descrtipition and truncated link.
>>
>> Ignore the links window and try to type first letter of a link
>> description and TAB.
>
> ...and TAB once more to make the completions window appeared. If default
> completion works then it is necessary to debug ido and customization to
> realize why data passed by `org-insert-link' is not enough for ido in
> your case.
>
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Org FAQ design (Re: [PATCH] org-faq.org: Inline comments)

[Max Nikulin]

On 01/07/2023 22:24, Ihor Radchenko wrote:

Max Nikulin writes:


FAQ is probably fine. We may add a CSS there that will fold the
answers by default.


When all entries are opened, it is possible to use search in browser. I
am against the idea of hiding answers. However the table of contents,
that is rather long and revealed on hover only, makes it harder to
search in the TOC at first.


I am now watching
https://fosdem.org/2023/schedule/event/a11y_eaa_bfsg_wcag_wai_aria_wtf/


I have skimmed through the presentation.


They suggest a combination of  to keep hidden text
searchable. See 
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary


Unsupported by Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1724299
Implement auto-expanding 

I am unsure if it is possible to implement auto-expanding on link to 
specific question for Firefox.


However  is better than accordions in most cases.

I would consider to put TOC into 

P.S. Have you noticed that MDN pages have "skip to content" link hidden 
by default, but revealed on using keyboard (TAB).

Re: org-insert-link completion by description (Re: what is the purpose of "This link has already been stored"?)

[Max Nikulin]

On 02/07/2023 12:02, Samuel Wales wrote:

another window would not work for me but using completion as i do with
e.g. refile goto would.


Samuel, you claimed that completion by description does not work for 
`org-insert-link'. I expect that it is fixed in Org-9.6 since I do not 
see the issue with the default completion. It is the reason why I asked 
you to confirm that *default completion* works for you as well. I 
suspect that the cause of your problem is either ido or your customization.


I see no connection of `org-refile' and `org-goto' with the code in 
`org-insert-link'.

Re: org-insert-link completion by description (Re: what is the purpose of "This link has already been stored"?)

[Samuel Wales]

there is not supposed to be any connection between org refile or org
goto with the code in org insert link.

completion works to select ol paths for org refile and also for org
refile when it is doing goto.  i just want the same for links.

On 7/1/23, Max Nikulin  wrote:
> On 02/07/2023 12:02, Samuel Wales wrote:
>> another window would not work for me but using completion as i do with
>> e.g. refile goto would.
>
> Samuel, you claimed that completion by description does not work for
> `org-insert-link'. I expect that it is fixed in Org-9.6 since I do not
> see the issue with the default completion. It is the reason why I asked
> you to confirm that *default completion* works for you as well. I
> suspect that the cause of your problem is either ido or your customization.
>
> I see no connection of `org-refile' and `org-goto' with the code in
> `org-insert-link'.
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

[Bug] org-insert-link removes on one link from 2 added by org-store-link

[Max Nikulin]

When some heading has the CUSTOM_ID property

 8< 
* title
:PROPERTIES:
:CUSTOM_ID: a-heading
:END:
 >8 

M-x org-store-link adds 2 entries:
- [[*title][title]]
- [[#a-heading][title]]

however `org-insert-link' (C-c C-l) removes from the stored link only 
one of them. As a result the number of unused stored links increases 
during an Emacs session.


My expectation is that
- either `org-store-links' adds a single option (my preference is 
#custom_id)

- or `org-insert-link' removes the whole group.

I have no idea how to implement second variant keeping backward 
compatibility.



Ihor Radchenko. Re: [BUG] org-store-link-functions advertizes that the 
first non-nil return value is used, but it is not how org-store-link 
handles it. Wed, 28 Sep 2022 09:03:59 +0800.

https://list.orgmode.org/87bkr0gvi8.fsf@localhost


Would you mind reporting this and MWE in a new thread?
It will be easier to track then.