org-datetree-insert-line and org-blank-before-new-entry

[Richard Walker]

A follow-up to the changes made to org-datetree-insert-line
in September 2020.

The definition now begins:

(defun org-datetree-insert-line (year  month day text)
  (delete-region (save-excursion (skip-chars-backward " \t\n") (point)) (point))
  (when (assq 'heading org-blank-before-new-entry)
(insert "\n"))
...

I'm getting blank lines inserted before new entries, and
I found a couple of sources of advice for setting org-blank-before-new-entry
( 
https://emacs.stackexchange.com/questions/51117/org-mode-control-whether-m-ret-inserts-a-newline-or-not-for-plain-lists
and
https://stackoverflow.com/questions/28351465/emacs-orgmode-do-not-insert-line-between-headers
)
that say to do this:

(setf org-blank-before-new-entry '((heading . nil) (plain-list-item . nil)))

Such a setting seems to be consistent with the help text of
org-blank-before-new-entry, and what org--blank-before-heading-p
expects to find. But, having made this setting,
  (when (assq 'heading org-blank-before-new-entry)
(insert "\n"))
still does the insertion, since (assq 'heading org-blank-before-new-entry)
is non-nil.

Change (assq 'heading org-blank-before-new-entry)
to (org--blank-before-heading-p) here?

[PATCH] org-indent: Allow indentation per level to be 0

[David Lukes]

* lisp/org-indent.el (org-indent--compute-prefixes): Prefixes should
only be computed when `org-indent-indentation-per-level' is greater than
0.  For one thing, the current algorithm leads to an error otherwise,
and for another, this makes it possible to use org-indent just to
preserve indentation on continuation lines, without adding any
additional indentation per level (by setting the option to 0).

TINYCHANGE
---
 lisp/org-indent.el | 49 +++---
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/lisp/org-indent.el b/lisp/org-indent.el
index ea7ea071b..b87cc4e5f 100644
--- a/lisp/org-indent.el
+++ b/lisp/org-indent.el
@@ -126,31 +126,32 @@ useful to make it ever so slightly different."
(make-vector org-indent--deepest-level nil))
   (setq org-indent--text-line-prefixes
(make-vector org-indent--deepest-level nil))
-  (dotimes (n org-indent--deepest-level)
-(let ((indentation (if (<= n 1) 0
-(* (1- org-indent-indentation-per-level)
-   (1- n)
-  ;; Headlines line prefixes.
-  (let ((heading-prefix (make-string indentation ?*)))
-   (aset org-indent--heading-line-prefixes
+  (when (> org-indent-indentation-per-level 0)
+(dotimes (n org-indent--deepest-level)
+  (let ((indentation (if (<= n 1) 0
+  (* (1- org-indent-indentation-per-level)
+ (1- n)
+;; Headlines line prefixes.
+(let ((heading-prefix (make-string indentation ?*)))
+ (aset org-indent--heading-line-prefixes
+   n
+   (org-add-props heading-prefix nil 'face 'org-indent))
+ ;; Inline tasks line prefixes
+ (aset org-indent--inlinetask-line-prefixes
+   n
+   (cond ((<= n 1) "")
+ ((bound-and-true-p org-inlinetask-show-first-star)
+  (concat org-indent-inlinetask-first-star
+  (substring heading-prefix 1)))
+ (t (org-add-props heading-prefix nil 'face 
'org-indent)
+;; Text line prefixes.
+(aset org-indent--text-line-prefixes
  n
- (org-add-props heading-prefix nil 'face 'org-indent))
-   ;; Inline tasks line prefixes
-   (aset org-indent--inlinetask-line-prefixes
- n
- (cond ((<= n 1) "")
-   ((bound-and-true-p org-inlinetask-show-first-star)
-(concat org-indent-inlinetask-first-star
-(substring heading-prefix 1)))
-   (t (org-add-props heading-prefix nil 'face 'org-indent)
-  ;; Text line prefixes.
-  (aset org-indent--text-line-prefixes
-   n
-   (org-add-props
-   (concat (make-string (+ n indentation) ?\s)
-   (and (> n 0)
-(char-to-string org-indent-boundary-char)))
-   nil 'face 'org-indent)
+ (org-add-props
+  (concat (make-string (+ n indentation) ?\s)
+  (and (> n 0)
+   (char-to-string org-indent-boundary-char)))
+  nil 'face 'org-indent))
 
 (defsubst org-indent-remove-properties (beg end)
   "Remove indentations between BEG and END."
-- 
2.32.0

Re: org-indent-indentation-per-level may be broken

[David Lukeš]

> No trouble, sometimes the “main people” (Bastien, Nicolas, …) end up
> being a bit snowed under and things take a bit longer than one might
> hope, but we’ll always try to get back to you .

I realize that, I hope I didn't sound snarky, I was being genuinely
thankful :)

> Would you care to make a “proper” patch (commit message and all ) so
> we can apply it to the repo giving you credit?

Sure, sounds great, I'll try and send one in a minute! Let's see how it
goes.

> If you haven’t assigned the FSF copyright, you’ll just need to add
> “TINYCHANGE” to the end of the commit message as per
> .

When properly formatted, the patch looks bigger than it actually is, but
I'm assuming that's not a problem -- that the number of lines of code is
computed using something like "git diff -w"?

David

Re: [BUG] Creating sparse tree with regexp property matches

[Daniel Fleischer]

Hi Timothy,

Attached is my patch. 

Best,

*Daniel Fleischer*
>From 05602a3eb453672893e7e92cc0384e1b6b7784aa Mon Sep 17 00:00:00 2001
From: Daniel Fleischer 
Date: Tue, 31 Aug 2021 20:01:47 +0300
Subject: [PATCH] org-manual: added section about regular expressions

Telling users it's based on Elisp regular expressions, linking to its
info node and putting some links to this new node in places where regexp
are presented.

Signed-off-by: Daniel Fleischer 
---
 doc/org-manual.org | 78 --
 1 file changed, 47 insertions(+), 31 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 10e0baa28..38884ad72 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -916,16 +916,16 @@ ** Sparse Trees
   #+kindex: C-c / /
   #+findex: org-occur
   #+vindex: org-remove-highlights-with-change
-  Prompts for a regexp and shows a sparse tree with all matches.  If
-  the match is in a headline, the headline is made visible.  If the
-  match is in the body of an entry, headline and body are made
-  visible.  In order to provide minimal context, also the full
-  hierarchy of headlines above the match is shown, as well as the
-  headline following the match.  Each match is also highlighted; the
-  highlights disappear when the buffer is changed by an editing
-  command, or by pressing {{{kbd(C-c C-c)}}}[fn:8].  When called with
-  a {{{kbd(C-u)}}} prefix argument, previous highlights are kept, so
-  several calls to this command can be stacked.
+  Prompts for a regexp (see [[*Regular Expressions]]) and shows a sparse
+  tree with all matches.  If the match is in a headline, the headline
+  is made visible.  If the match is in the body of an entry, headline
+  and body are made visible.  In order to provide minimal context,
+  also the full hierarchy of headlines above the match is shown, as
+  well as the headline following the match.  Each match is also
+  highlighted; the highlights disappear when the buffer is changed by
+  an editing command, or by pressing {{{kbd(C-c C-c)}}}[fn:8].  When
+  called with a {{{kbd(C-u)}}} prefix argument, previous highlights
+  are kept, so several calls to this command can be stacked.
 
 - {{{kbd(M-g n)}}} or {{{kbd(M-g M-n)}}} (~next-error~) ::
 
@@ -3663,10 +3663,10 @@ ** Search Options in File Links
 
 - =/REGEXP/= ::
 
-  Do a regular expression search for {{{var(REGEXP)}}}.  This uses the
-  Emacs command ~occur~ to list all matches in a separate window.  If
-  the target file is in Org mode, ~org-occur~ is used to create
-  a sparse tree with the matches.
+  Do a regular expression search for {{{var(REGEXP)}}} (see [[*Regular
+  Expressions]]).  This uses the Emacs command ~occur~ to list all
+  matches in a separate window.  If the target file is in Org mode,
+  ~org-occur~ is used to create a sparse tree with the matches.
 
 As a degenerate case, a file link with an empty file name can be used
 to search the current file.  For example, =[[file:::find me]]= does
@@ -4978,8 +4978,9 @@ ** Tag Hierarchy
 
 Furthermore, the members of a group tag can also be regular
 expressions, creating the possibility of a more dynamic and rule-based
-tag structure.  The regular expressions in the group must be specified
-within curly brackets.  Here is an expanded example:
+tag structure (see [[*Regular Expressions]]).  The regular expressions in
+the group must be specified within curly brackets.  Here is an
+expanded example:
 
 #+begin_example
 ,#+TAGS: [ Vision : {V@.+} ]
@@ -5321,7 +5322,7 @@ ** Property Searches
   tree is created with all entries that define this property with the
   given value.  If you enclose the value in curly braces, it is
   interpreted as a regular expression and matched against the property
-  values.
+  values (see [[*Regular Expressions]]).
 
 ** Property Inheritance
 :PROPERTIES:
@@ -8913,8 +8914,9 @@ *** Matching tags and properties
 
 #+cindex: regular expressions, with tags search
 Instead of a tag, you may also specify a regular expression enclosed
-in curly braces.  For example, =work+{^boss.*}= matches headlines that
-contain the tag =:work:= and any tag /starting/ with =boss=.
+in curly braces (see [[*Regular Expressions]]).  For example,
+=work+{^boss.*}= matches headlines that contain the tag =:work:= and
+any tag /starting/ with =boss=.
 
 #+cindex: group tags, as regular expressions
 Group tags (see [[*Tag Hierarchy]]) are expanded as regular expressions.
@@ -8954,7 +8956,7 @@ *** Matching tags and properties
 
 #+begin_example
 +work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
- +With={Sarah|Denny}+SCHEDULED>="<2008-10-11>"
+ +With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
 #+end_example
 
 #+texinfo: @noindent
@@ -8984,7 +8986,7 @@ *** Matching tags and properties
 not =boss=, which also have a priority value =A=, a =Coffee= property
 with the value =unlimited=, an =EFFORT= property that is numerically
 smaller than 2, a =With= property that is matched by the regular

Re: Bug: Error making documentation 9.4.6

[Marco Wahl]

>> [... issue with make doc ...]

> Sorry about that, I'm new in contributing to org. I found the solution
> in the mailing list[1]. There was an old version of `makeinfo'.

> [1]
> 

Good to know.


Thanks Daniel!
-- 
Marco

Re: Bug: Error making documentation 9.4.6

[Daniel Fleischer]

Hi Marco,

Sorry about that, I'm new in contributing to org. I found the 
solution

in the mailing list[1]. There was an old version of `makeinfo'.

Daniel Fleischer



Footnotes
_

[1] 

Re: New source block results option for attaching file to node

[Ryan Scott]

Great. Yeah I tried to adhere to the commit format the best I could.
org-attach-dir is a function for me (latest org pulled using straight.el)
org/lisp/org-attach.el:327.

The primary use case is src blocks that generate files, in my case usually
gnuplot or graphviz, and return a file path. With a collection of org files
in a directory, organization can get messy, and creating an organizational
scheme essentially recreates the attachment directory design.

Another approach would be to instead only modify org to have hooks (or any
other callback mechanism really) that are run on link insertion and have
access to the result-params for the block. The rest of this could then be a
separate package easily enough. Would that be a better approach as it would
allow the org core to not be so tightly coupled to org-attach?

I'm using magit; I just don't normally restrain myself to the line length.
I'll make sure to do that for submitted patches here.

In terms of this mailing list and overall contribution process, how best to
remedy things for the patch? Just modify it and reply with the modified
patch as an attachment?

On Tue, Aug 31, 2021 at 4:24 AM Timothy  wrote:

> Hi Ryan,
>
> Thanks for submitting your first patch to Org! 
>
> Regarding the purpose of the patch, I take it this is useful with source
> blocks that return a file patch and should be added as an attachment? Would
> you mind expanding on this use case? Oh, and org-attach-dir doesn’t show
> up a function or variable for me, I take it you meant something else?
>
> Lastly, with your commit message, you’ve clearly looked at the requested
> commit message format . There’s the odd typo (“theh”) and the line length
> is too long. It’s good if you hard line-wrap to 72 characters (if you use
> Magit, this should happen automatically FYI). Other than that it looks
> good to me.
>
> All the best,
> *Timothy*
>
> * From*: Ryan Scott <%22ryan+scott%22+%3cr...@vicarious-living.com%3E>
> * Subject*: New source block results option for attaching file to node
> * To*: emacs-orgmode@gnu.org
> <%22emacs-orgm...@gnu.org%22+%3cemacs-orgm...@gnu.org%3E>
> * Date*: Thu, 26 Aug 2021 16:48:50 +0800
> An additional option for use with ":results file" that moves the returned
> path to the node attachment directory (as returned by org-attach-dir),
> creating it if necessary.
>
> First time submitting a patch. Any feedback is appreciated.
>
> -ryan
>
>

Re: Bug: Error making documentation 9.4.6

[Marco Wahl]

Daniel Fleischer  writes:

> Hi,
>
> Pulling master @ 1690fbd88, calling `make doc' leads to error:
>
>
> org-version: 9.4.6 (release_9.4.6-635-g1690fb)
> makeinfo --no-split org.texi -o org.info
> org.texi:6: warning: unrecognized encoding name `UTF-8'.
> org.texi:810: Unknown command `arrow'.
> org.texi:810: Misplaced {.
> org.texi:810: Misplaced }.
> org.texi:810: Unknown command `arrow'.
> org.texi:810: Misplaced {.
> org.texi:810: Misplaced }.
> org.texi:821: Unknown command `arrow'.
> org.texi:821: Misplaced {.
> org.texi:821: Misplaced }.
> org.texi:2627: Unknown command `arrow'.
> org.texi:2627: Misplaced {.
> org.texi:2627: Misplaced }.
> org.texi:2629: Unknown command `arrow'.
> org.texi:2629: Misplaced {.
> org.texi:2629: Misplaced }.
> org.texi:3548: Unknown command `arrow'.
> org.texi:3548: Misplaced {.
> org.texi:3548: Misplaced }.
> org.texi:3548: Unknown command `arrow'.
> org.texi:3548: Misplaced {.
> org.texi:3548: Misplaced }.
> makeinfo: Removing output file `org.info' due to errors; use --force to 
> preserve.
> make[1]: *** [org] Error 1
> make: *** [info] Error 2

Can't reproduce this on my machine.


Best regards
-- 
Marco

Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items

[Nicolas Goaziou]

Hello,

Anders Johansson  writes:

>> I think a proper fix would be to change `org-duration-from-minutes' so
>> it removes any unknown unit from what is provided from fmt or
>> `org-duration-format', and defaults to (special . h:mm) if nothing is
>> left.
>>
>> WDYT?
>>
> Perhaps. I don't understand `org-duration-from-minutes` well enough to
> change it.

You don't really need to understand it. I suggest using a filter as the
very first step of the function.

> I guess the stripping of unknown units from fmt or
> `org-duration-format` would then have to compare either against
> `org-duration-units` or `org-duration-canonical-units` depending on
> the canonical argument.

Exactly.


Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Fix match/maxlevel conflict in colview dynblock

[Nick Dokos]

Timothy  writes:

> Hi Nick,
>
> Thanks for reporting this issue here, and providing a patch. Unfortunately the
> “main maintainers” seem to be rather busy as of late, leaving you hanging for
> quite a while. I’ve had a look at the issue and your patch, and it the issue
> seems clear, and your patch small and straightforward enough that I feel
> confident pushing it should be fine :) it’s now on master with a small tweak 
> to
> the commit message.
>
> Thanks for your efforts.
>

Hi Timothy,

Thanks and no worries! And thanks for working through the backlog!

--
Nick

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

Re:[BUG] Indentation broken after double quote

[Ivan Sokolov]

Yes, I typed your example and got this:

* Some headline "hey"
  "
hey there

#+begin_src sh
'"'
#+end_src

Bug: Error making documentation 9.4.6

[Daniel Fleischer]

Hi,


Pulling master @ 1690fbd88, calling `make doc' leads to error:


org-version: 9.4.6 (release_9.4.6-635-g1690fb)
makeinfo --no-split org.texi -o org.info
org.texi:6: warning: unrecognized encoding name `UTF-8'.
org.texi:810: Unknown command `arrow'.
org.texi:810: Misplaced {.
org.texi:810: Misplaced }.
org.texi:810: Unknown command `arrow'.
org.texi:810: Misplaced {.
org.texi:810: Misplaced }.
org.texi:821: Unknown command `arrow'.
org.texi:821: Misplaced {.
org.texi:821: Misplaced }.
org.texi:2627: Unknown command `arrow'.
org.texi:2627: Misplaced {.
org.texi:2627: Misplaced }.
org.texi:2629: Unknown command `arrow'.
org.texi:2629: Misplaced {.
org.texi:2629: Misplaced }.
org.texi:3548: Unknown command `arrow'.
org.texi:3548: Misplaced {.
org.texi:3548: Misplaced }.
org.texi:3548: Unknown command `arrow'.
org.texi:3548: Misplaced {.
org.texi:3548: Misplaced }.
makeinfo: Removing output file `org.info' due to errors; use --force to preserve.
make[1]: *** [org] Error 1
make: *** [info] Error 2



–
Daniel Fleischer

RE: Bug: Percentage in caption (even escaped) does not work in LaTeX export

[Charest, Luc]

Hello Timothy,

   Yeah, I tried, and it did not worked.

   I had exchanged emails with Eric, we came to the conclusion that the source 
of the problem might be a clash between my emacs version 26 and an updated 
version of the org-mode. I have to try to update my emacs to see where it goes 
from there, but have to find some time to do it.

   I was thinking also I might had screw up my installation some time ago by 
attempting to install Org-roam. It stopped at some point complaining about not 
finding the database, which, from what I understand, was supposed to be 
downloaded and compiled manually.

   Anyway, I'll try updating my emacs with a fresh install, I'll keep you 
inform. 

Thank you for the follow-up ! 

-Message d'origine-
De : Timothy  
Envoyé : 31 août 2021 11:38
À : Charest, Luc 
Cc : Eric S Fraga ; emacs-orgmode@gnu.org
Objet : Re: Bug: Percentage in caption (even escaped) does not work in LaTeX 
export

[You don't often get email from tecos...@gmail.com. Learn why this is important 
at http://aka.ms/LearnAboutSenderIdentification.]

Courriel provenant de l'externe
ATTENTION, avant d'accéder à une pièce jointe ou à un lien de ce courriel, 
assurez-vous que celui-ci provient d'un tiers de confiance.

Hi Luc,

Eric wrote:
> What happens if you do specify a language?
>
> If I specify a language, the export is fine with % unescaped, by the 
> way.

Have you been able to give this a shot?

All the best,
Timothy

Re: Bug: Behavior of org-adapt-indentation [9.4.6 (9.4.6-10-gee652a-elpa @ /home/fsantos/.emacs.d/elpa/org-20210705/)]

[Timothy]

Hi Frédéric,

I tried to reproduce with emacs -Q but I had no luck (see the image attached).
Could you give emacs -Q a go and let us know how it goes?

Frédéric Santos  writes:

> Hi!
>
> This might not be *really* a bug, but since a recent update of Org, I
> noticed an unwanted indentation of code blocks when the variable
> org-adapt-indentation is set to ’headline-data. It can be reproduced
> with this very minimal org config:
>
> (use-package org
>   :config
>   (require ’org-tempo)
>   (setq org-adapt-indentation ’headline-data))
>
> In an org buffer, create a headline, and then:
>
> 1. Type some text which does *not* follow an empty line an press TAB:
> nothing happens (which is the expected behavior).
> 2. Type some text which does follow an empty line an hit TAB: this text
> gets indented according to the current headline level (the help page
> looks unclear to me: it might also be the expected behavior,
> although I don’t really understand the rationale for it).
>
> Point 2. has a side effect: when you still use the old template
> expansion mechanism for code blocks (the one provided by org-tempo.el,
> e.g. type  now get indented according to the headline level (because you press TAB,
> I guess). I think it’s not the expected behavior, since those code
> blocks that follow an empty line will have a different indentation than
> the text before and after them.
>
> Here is an animated gif to better illustrate what I mean:
> 
>
> Is there a workaround to avoid this indentation of code blocks?
>
> All the best,
> Frédéric
>
> ==
> Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, 
> cairo version 1.17.4)
>  of 2021-03-26
> Package: Org mode version 9.4.6 (9.4.6-10-gee652a-elpa @ 
> /home/fsantos/.emacs.d/elpa/org-20210705/)

All the best,
Timothy

Re: Bug: org-deadline drops warning periods from TIME [9.4.6 (9.4.6-10-gee652a-elpaplus @ /home/fap/.emacs.d/elpa/org-plus-contrib-20210712/)]

[Timothy]

Bug confirmed and added to updates.orgmode.org.

Re: [BUG] Indentation broken after double quote

[Timothy]

Hi Ivan,

I just tried this with the following example

┌
│ * Some headline "hey"
│ "
│ hey there
│ 
│ #+begin_src sh
│ '"'
│ #+end_src
└

and I couldn’t reproduce your issue. Are you still seeing this issue?

All the best,
Timothy

Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items

[Anders Johansson]

Hi,
Oh, I sent a response but failed to send it to the list and only to
Nicolas (hard to do things right using the gmail web interface)
I include it below:

> I think a proper fix would be to change `org-duration-from-minutes' so
> it removes any unknown unit from what is provided from fmt or
> `org-duration-format', and defaults to (special . h:mm) if nothing is
> left.
>
> WDYT?
>
Perhaps. I don't understand `org-duration-from-minutes` well enough to
change it. I guess the stripping of unknown units from fmt or
`org-duration-format` would then have to compare either against
`org-duration-units` or `org-duration-canonical-units` depending on
the canonical argument. But the full logic of
org-duration-from-minutes escapes me.
I also noted that the only other invocations of
`org-duration-from-minutes` with the canonical argument is in
`org-columns--format-age` (where a format is provided).
Overall the interaction of these functions across the codebase seems
quite complex now.

Re: Bug: Percentage in caption (even escaped) does not work in LaTeX export

[Timothy]

Hi Luc,

Eric wrote:
> What happens if you do specify a language?
>
> If I specify a language, the export is fine with % unescaped, by the
> way.

Have you been able to give this a shot?

All the best,
Timothy

Re: org-indent-indentation-per-level may be broken

[Timothy]

Hi David,

> Thanks for getting back to me!

No trouble, sometimes the “main people” (Bastien, Nicolas, …) end up being a
bit snowed under and things take a bit longer than one might hope, but we’ll
always try to get back to you .

>> Is the patch in your original email a good fix for this?
>
> Basically yes, though I’ve simplified it to this:
> *snip*

Thanks for this, it’s nice to see something so simple. Would you care to make a
“proper” patch (commit message and all ) so we can apply it to the repo
giving you credit? If you haven’t assigned the FSF copyright, you’ll just need
to add “TINYCHANGE” to the end of the commit message as per
.

All the best,
Timothy

Re: org-indent-indentation-per-level may be broken

[David Lukeš]

Hi Timothy,

Thanks for getting back to me!

> Is the patch in your original email a good fix for this?

Basically yes, though I've simplified it to this:

--8<--->8--

diff --git a/lisp/org-indent.el b/lisp/org-indent.el
index ea7ea07..2091083 100644
--- a/lisp/org-indent.el
+++ b/lisp/org-indent.el
@@ -126,6 +126,7 @@ useful to make it ever so slightly different."
(make-vector org-indent--deepest-level nil))
   (setq org-indent--text-line-prefixes
(make-vector org-indent--deepest-level nil))
+  (when (> org-indent-indentation-per-level 0)
   (dotimes (n org-indent--deepest-level)
 (let ((indentation (if (<= n 1) 0
 (* (1- org-indent-indentation-per-level)
@@ -150,7 +151,7 @@ useful to make it ever so slightly different."
(concat (make-string (+ n indentation) ?\s)
(and (> n 0)
 (char-to-string org-indent-boundary-char)))
-   nil 'face 'org-indent)
+   nil 'face 'org-indent))

 (defsubst org-indent-remove-properties (beg end)
   "Remove indentations between BEG and END."

--8<--->8--

It turns org-indent--compute-prefixes into a no-op, except for
initializing the various prefix vectors, on the assumption that when
org-indent-indentation-per-level is 0, there should simply be no
prefixes.

Disclaimer: I didn't really try to understand the entire reasoning
behind how the prefixes are computed, why it's done the way it's done,
what are the various edge cases etc. But AFAICS, my patch shouldn't
break anything that was working before: when
org-indent-indentation-per-level is greater than 0, everything runs as
before. And when it's 0, then instead of an error, something reasonable
now happens.

If there are disagreements about the details of what should happen, then
they can probably be discussed after this stopgap patch gets merged. For
instance, maybe there's a feature of Org Mode I don't use and which
should get some special treatment when org-indent-indentation-per-level
is 0. But seeing as no one seems to have been inconvenienced by the fact
that it didn't work at all until now, I'm not expecting much of an
uproar :)

Also, maybe it would still make sense to change (if (<= n 1) 0 ...) to
(max 0 ...), as a more catch-all way to ensure that indentation is
reliably greater than 0 (so that (make-string indentation ?*) doesn't
fail)? It's not needed with the when-condition placed as it is in the
patch above, but maybe just to be on the safe side. Dunno.

Best,

David

Re: [patch] priorities range reversed

[Timothy]

Hi Joe,

Thanks for looking into this and figuring out a patch. I’ve just taken a peek at
your patches, and I have two minor comments:
⁃ Why use saved-position instead of save-excursion
⁃ I’m think ascii versions of ② et. al would be preferable

Also, I notice that your patches are just diffs and don’t have a commit message.
Are you planning on writing them later?

Joe Corneli via “General discussions about Org-mode.”  
writes:

> Actually, there some bigger problems with the function as well…
>
> — It didn’t update the priority cookie properly when one had been set before
>
> * [#1] Exercise: update to [#2]
>
> — After fixing that, I noticed that the included save-excursion doesn’t work
>   
> ()
>
> So, here’s a more comprehensive patch, including the previous changes
> (in order to support numeric priorities) and then adjusting the
> update/insert logic so that it makes more sense.

All the best,
Timothy

[PATCH] Re: Bug: org-edit-special indents inline latex [9.5 (nil @ /home/david/.emacs.d/.local/straight/build-27.2/org-mode/)]

[Sébastien Miquel]

Hi,

Ihor Radchenko writes:

Dávid Jakab  writes:

When using org-edit-special to edit inline latex, i.e., equations
between \( and \), in an org-mode buffer, a number of
spaces may get inserted before \( after the latex editing minibuffer is
closed.

The attached patch fixes this as well as a couple other issues with special
editing of latex fragments :
 + the coordinates computation was wrong, so point position inside fragment
   isn't preserved when calling ~org-edit-special~ from an inline fragment.
 + common leading indentation wasn't getting trimmed when editing a 
multiline

   fragment inside an org list such as
   $$abc
   def$$

Thanks for reporting and confirming.

Regards,

--
Sébastien Miquel

>From 5c3254d42e3d359021d41dae9a0549244e6fddff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= 
Date: Mon, 30 Aug 2021 23:18:41 +0200
Subject: [PATCH] org-src.el: Fix special editing of LaTeX fragments

* lisp/org-macs.el (org-do-remove-indentation): Add optional argument
to skip the first line.
* lisp/org-src.el (org-src--coordinates): Fix coordinates for inline
LaTeX fragments.
(org-src--contents-for-write-back): Do not indent first line for LaTeX
fragments.
(org-src--edit-element): Compute block-indentation according to parent
for LaTeX fragments.  Skip first line when removing common indentation
for LaTeX fragments.
---
 lisp/org-macs.el |  9 ++---
 lisp/org-src.el  | 18 ++
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 77458db96..5c90c92f6 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -326,17 +326,19 @@ it for output."
 
 ;;; Indentation
 
-(defun org-do-remove-indentation ( n)
+(defun org-do-remove-indentation ( n skip-fl)
   "Remove the maximum common indentation from the buffer.
 When optional argument N is a positive integer, remove exactly
-that much characters from indentation, if possible.  Return nil
-if it fails."
+that much characters from indentation, if possible.  When
+optional argument SKIP-FL is non-nil, skip the first
+line.  Return nil if it fails."
   (catch :exit
 (goto-char (point-min))
 ;; Find maximum common indentation, if not specified.
 (let ((n (or n
 		 (let ((min-ind (point-max)))
 		   (save-excursion
+ (when skip-fl (forward-line))
 		 (while (re-search-forward "^[ \t]*\\S-" nil t)
 		   (let ((ind (current-indentation)))
 			 (if (zerop ind) (throw :exit nil)
@@ -344,6 +346,7 @@ if it fails."
 		   min-ind
   (if (zerop n) (throw :exit nil)
 	;; Remove exactly N indentation, but give up if not possible.
+(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)))
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 4698c6dd2..2e72b1755 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -324,7 +324,8 @@ a cons cell (LINE . COLUMN) or symbol `end'.  See also
   (if (>= pos end) 'end
 (org-with-wide-buffer
  (goto-char (max beg pos))
- (cons (count-lines beg (line-beginning-position))
+ (cons (count-lines (save-excursion (goto-char beg) (line-beginning-position))
+(line-beginning-position))
 	   ;; Column is relative to the end of line to avoid problems of
 	   ;; comma escaping or colons appended in front of the line.
 	   (- (point) (min end (line-end-position)))
@@ -442,6 +443,7 @@ Assume point is in the corresponding edit buffer."
 		  org-src--content-indentation
 		0
 	(use-tabs? (and (> org-src--tab-width 0) t))
+(preserve-fl (eq org-src--source-type 'latex-fragment))
 	(source-tab-width org-src--tab-width)
 	(contents (org-with-wide-buffer (buffer-string)))
 	(write-back org-src--allow-write-back))
@@ -456,7 +458,8 @@ Assume point is in the corresponding edit buffer."
   ;; Add INDENTATION-OFFSET to every line in buffer,
   ;; unless indentation is meant to be preserved.
   (when (> indentation-offset 0)
-	(while (not (eobp))
+	(when preserve-fl (forward-line))
+(while (not (eobp))
 	  (skip-chars-forward " \t")
 	  (let ((i (current-column)))
 	(delete-region (line-beginning-position) (point))
@@ -504,7 +507,13 @@ Leave point in edit buffer."
 	 (source-tab-width (if indent-tabs-mode tab-width 0))
 	 (type (org-element-type datum))
 	 (block-ind (org-with-point-at (org-element-property :begin datum)
-			  (current-indentation)))
+  (cond
+   ((save-excursion (skip-chars-backward " \t") (bolp))
+			(current-indentation))
+   ((org-element-property :parent datum)
+(org--get-expected-indentation
+ (org-element-property :parent datum) nil))
+   (t (current-indentation)
 	 (content-ind org-edit-src-content-indentation)
 

Re: [PATCH] Fix match/maxlevel conflict in colview dynblock

[Timothy]

Hi Nick,

Thanks for reporting this issue here, and providing a patch. Unfortunately the
“main maintainers” seem to be rather busy as of late, leaving you hanging for
quite a while. I’ve had a look at the issue and your patch, and it the issue
seems clear, and your patch small and straightforward enough that I feel
confident pushing it should be fine :) it’s now on master with a small tweak to
the commit message.

Thanks for your efforts.

> Specifying both `maxlevel’ and `match’ in a columnview dynamic block
> was broken: the `match’ argument is ignored in that case. See the link
> below for a (not so minimal) ECM.
>
> Reported-by: Pablo A Perez-Fernandez
> Link: 
> 
>
> –
> Nick
>
> “There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors.” -Martin Fowler
>
> From 8bcff482e59c24758f87b9b5cdef3bc123dc12f8 Mon Sep 17 00:00:00 2001
> From: Nick Dokos 
> Date: Sun, 11 Jul 2021 22:30:22 -0400
> Subject: [PATCH] Fix match/maxlevel conflict in colview dynblock
>
> * lisp/org-coplview.el (org-columns–capture-view): Combine the match
> and maxlevel arguments properly to construct the MATCH argument of
> `org-map-entries’.
>
> Specifying both `maxlevel’ and `match’ in a columnview dynamic block
> does not work: the `match’ argument is ignored in that case. See the
> link below for a (not so minimal) ECM.
>
> Reported-by: Pablo A Perez-Fernandez
> Link: 
> 
> —
>  lisp/org-colview.el | 5 +++–
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff –git a/lisp/org-colview.el b/lisp/org-colview.el
> index 2e1c29a99..7144308ff 100644
> — a/lisp/org-colview.el
> +++ b/lisp/org-colview.el
> @@ -1398,8 +1398,9 @@ other rows.  Each row is a list of fields, as strings, 
> or
> (org-get-tags
>(push (cons (org-reduced-level (org-current-level)) (nreverse row))
>  table)
> - (or (and maxlevel (format “LEVEL<=%d” maxlevel))
> -  (and match match))
> + (if match
> + (concat match (and maxlevel (format “+LEVEL<=%d” maxlevel)))
> +   (and maxlevel (format “LEVEL<=%d” maxlevel)))
>   (and local ’tree)
>   ’archive ’comment)
>  (org-columns-quit)


All the best,
Timothy

Re: org-indent-indentation-per-level may be broken

[Timothy]

Hi David,

> I got confused when testing the different variations, I was expecting
> the indentation change to happen in the wrong place. Sorry for that!

Glad to hear it’s not as bad as you initially thought.

> So to be clear: setting org-indent-indentation-per-level to 0 is broken
> and leads to the aforementioned error. Setting it to a value >0 behaves
> correctly, as in, the indentation of the heading levels changes
> accordingly.

Mmmm, that’s a pity. Is the patch in your original email a good fix for this? If
not, would you be willing to try to make a patch that neatly solves the 0 issue?

All the best,
Timothy

Insert outline breadcrumbs just before headings text in agenda view

[Shankar Rao]

 In Emacs org-mode, I have a set of TODOs in the following format:

* H1
** H2
*** H3
 TODO [#A] File Taxes

If I activate breadcrumbs in org-agenda-prefix-format (i.e., by
doing (setf (alist-get 'agenda org-agenda-prefix-format)
" %i %-12:c%?-12t% s%b")), when I look at the agenda-todo view, it
shows up as:

H1->H2->H3->TODO [#A] File Taxes

However, I would like it to instead be displayed like this:
TODO [#A] H1->H2->H3->File Taxes

I asked about this on Reddit

and Stack Exchange
,
and since it
appeared that no one had already come up with a solution for
this, I decided to cook up my own using an advice function:
(defvar org-agenda-breadcrumbs-level 1
  "Highest level subtree to include in Org agenda breadcrumb.")

(defun org-agenda-breadcrumbs-string ()
  "Create formatted string with outline of Org subtree at point.

The outline goes up to subtree level
`org-agenda-breadcrumbs-level` and the subtree headings are
separated by `org-agenda-breadcrumbs-separator`."
  (org-format-outline-path (nthcdr (1- org-agenda-breadcrumbs-level)
   (org-get-outline-path))
   (1- (frame-width))
   nil org-agenda-breadcrumbs-separator))

(defun org-agenda-insert-breadcrumbs-before-text (args)
  "In Org agenda, insert outline breadcrumbs just before heading text in ARGS.

This is an advice function for use with `org-agenda-format-item`
by doing:

(advice-add #'org-agenda-format-item :filter-args
#'org-agenda-insert-breadcrumbs-before-text)

Since ARGS is the list of arguments to be passed to
`org-agenda-format-item`, the second list element of ARGS
contains the heading text to be modified."
  (org-with-point-at (org-get-at-bol 'org-marker)
(let* ((txt (org-get-heading t t t t))
   (index (or (cl-search txt (cadr args)) 0))
   (bc (let ((s (org-agenda-breadcrumbs-string)))
 (if (eq "" s)
 ""
   (concat s org-agenda-breadcrumbs-separator)
  (setf (substring (cadr args) index index) bc)
  args)))

(advice-add #'org-agenda-format-item :filter-args
#'org-agenda-insert-breadcrumbs-before-text)

In my init.el, because I don't want the top level headings in the
outline breadcrumbs, I also have the following:

(setq org-agenda-breadcrumbs-level 2)

In my opinion, a feature like this is of sufficiently broad
interest that it should be included in Org so that it can be enabled
without the use of an advice function. However, it's not clear to me
what would be the best interface for configuring it. For example,
it doesn't make sense to add an option for this to
org-agenda-prefix-format, since this modifies the heading text
rather than the prefix.

If people agree that this feature is of broad interest, and have
suggestions on a good configuration interface, I would be happy
to submit this as a patch.

Shankar Rao

Re: ob-R: Error about longer than max-lines even with :result silent

[Timothy]

Hi Yasushi,

> Yes, that’s exactly what I was looking for.
>
> I’m attaching patches to document it.  Nicolas, or anyone with commit
> permission, if you find it useful please merge them.

Thanks for going to the effort to document this Yasushi. I’ve taken a look at
your patches and they look quite good and straightforward to me. I’ve taken the
liberty of pushing them to master.

Thanks again,
Timothy

Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items

[Timothy]

Hi Anders,

Did you have any thoughts on Nicolas’ comments?

Nicolas Goaziou  writes:

> Hello,
>
> Anders Johansson  writes:
>
>> org-duration-from-minutes was called with canonical = t, but without
>> providing a corresponding format only using the canonical units. This
>> broke if the user’s org-duration-format used other than the canonical
>> units.
>
> I think a proper fix would be to change `org-duration-from-minutes’ so
> it removes any unknown unit from what is provided from fmt or
> `org-duration-format’, and defaults to (special . h:mm) if nothing is
> left.
>
> WDYT?

All the best,
Timothy

Re: [BUG] Creating sparse tree with regexp property matches

[Daniel Fleischer]

Timothy [2021-08-31 Tue 19:27]  wrote:

> Hi Cassio,
>
>> Ah! Can’t believe I didn’t try that. Well, at least the docs can
>> benefit from my confusion.
>
> Would you be interested in making a patch for the docs, or would you rather
> leave that to someone else?

Actually I want to do that. I had an idea to add a node (in org)
"reminding" people that all mentions of regex refer to elisp regex,
which could be different than what people usually know (PCRE) and point
them toward the elisp regex node. I think this point can confuse non
technical people when they are starting to use orgmode and there should
be a mention in the org manual. Most notably are the alternation \|
instead of | and \(...\) grouping instead of (...).

Best, 


*Daniel Fleischer*

Re: Bug: `org-fill-paragraph' relies on M-q being bound to `fill-paragraph' [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/mwj/.emacs.d/elpa/org-20210809/)]

[Timothy]

"Marvin J."  writes:

> If you globally rebind M-q, then `org-fill-paragraph' will not work
> properly anymore.
> The reason is that `org-fill-element' has the line
> (src-block (org-babel-do-key-sequence-in-edit-buffer (kbd "M-q")))
> While of course M-q is the default binding for `fill-paragraph', org
> should respect that the user might want to change keybindings.

This looks as if it would only affect src blocks, is this consistent
with your experience? With regards to triggering M-q in the edit buffer,
considering that different modes can have different fill commands, might
you have any suggestions on what command this could be replaced by?

--
Timothy

Re: [BUG] Creating sparse tree with regexp property matches

[Timothy]

Hi Daniel,

>> Would you be interested in making a patch for the docs, or would you rather
>> leave that to someone else?
>
> Actually I want to do that. I had an idea to add a node (in org)
> “reminding” people that all mentions of regex refer to elisp regex,
> which could be different than what people usually know (PCRE) and point
> them toward the elisp regex node. I think this point can confuse non
> technical people when they are starting to use orgmode and there should
> be a mention in the org manual. Most notably are the alternation \|
> instead of | and ... grouping instead of (…).

That sounds like it would be most useful! I look forward to seeing your patch .

All the best,
Timothy

Re: [BUG] Creating sparse tree with regexp property matches

[Cassio Koshikumo]

Hey, great! I was going to patch the example (was just reading the commit
guidelines) but I'll leave it in your hands then. Thanks!

Best,

On Tue, Aug 31, 2021 at 9:33 AM Daniel Fleischer  wrote:
>
> Timothy [2021-08-31 Tue 19:27]  wrote:
>
> > Hi Cassio,
> >
> >> Ah! Can’t believe I didn’t try that. Well, at least the docs can
> >> benefit from my confusion.
> >
> > Would you be interested in making a patch for the docs, or would you rather
> > leave that to someone else?
>
> Actually I want to do that. I had an idea to add a node (in org)
> "reminding" people that all mentions of regex refer to elisp regex,
> which could be different than what people usually know (PCRE) and point
> them toward the elisp regex node. I think this point can confuse non
> technical people when they are starting to use orgmode and there should
> be a mention in the org manual. Most notably are the alternation \|
> instead of | and \(...\) grouping instead of (...).
>
> Best,
>
>
> *Daniel Fleischer*



-- 
Cassio Koshikumo

Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil

[Timothy]

Hi Morgan,

> Great! Thank you for taking a look.

No problem, thanks for making the patch :)

> I used `git send-email` which is listed as being OK on the website:

Huh, I guess it should be fine then. I’ve just never seen the commit message at
the top like that so I assumed you’d done it by hand. :shrug:

All the best,
Timothy

Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil

[Morgan Willcock]

Timothy  writes:

> Hi Morgan,
>
>> I’ve attached a patch to fix an issue where tab characters are generated by
>> the ASCII exporter when `indent-tabs-mode’ has its default value of t.
>
> Thanks for finding this bug, fixing it, and sending us it . I was able to
> reproduce your test case with “emacs -Q” (thanks for that, by the way).
> As you suspected, with the small number of changed lines, this would be fine 
> to
> accept without FSF assignment.

Great! Thank you for taking a look.

> However, your “patch” seems to consist of a diff at the bottom of your email 
> and
> a commit message at the top?? It would be preferable if you could provide a
> “proper” patch, that way you can get attribution for your help instead of just
> someone committing it on your behalf.

I used `git send-email` which is listed as being OK on the website:

  "If you have configured git to use send-email, then you can use that."
 -- https://orgmode.org/contribute.html

The mail can be applied with `git am` and the commit message will be
correct. I'm also happy to resend as a separate patch if that is the
requirement.

Thanks,
Morgan

Re: More options for relative dates when using org-schedule

[Timothy]

Hi Tim,

> currently when I schedule an item, I can enter for example ’+3’ for 3 days 
> from
> now or ’14:00+3’ for ’14:00-17:00’. It would be nice if I could either specify
> fractions, eg ’14:00+0.5’ for ’14:00-14:30’ or a unit ’14:00+30m’ or ’+4w’ 
> for 4
> weeks.
>
> What do you think of this feature request?

I’m not sure about your +0.5, as given +1 is a day I’d guess this to be half a
day. On the other hand, unit-ed versions like +30m seem pretty reasonable to me.
There was a discussion about making times like “2h” and “2h30” work in
org-time-stamp, I’m not sure, but there may be some overlap in functionality
that could be exploited.

All the best,
Timothy

Re: Org + git branches for derived files

[Timothy]

Hi Ken,

It’s been a while, but just to chime in: if you use GitHub you may find
 to be of use.

Let me know if you have any questions, I wrote it a few months ago.

Ken Mankoff  writes:

> Hello,
>
> I think this might be more of a git question than an Org question, but I 
> imagine I might find the answer here and that it might be useful to others, 
> so I ask here.
>
> I’d like to keep derivative products (the LaTeX output, the final PDF, etc.)
> available in Git, but not commit those changes each time I change the Org 
> file.
> Perhaps git-annex as appropriate for this, but seems over-kill.
>
> Is there some way to mostly-seamlessly commit the LaTeX and/or PDF and/or 
> other
> files to their own git branches but in a way that overwrites the history of 
> that
> branch, so that a small Org file that generates a big binary PDF does not
> pollute the git tree?

All the best,
Timothy

Re: [PATCH] ox-ascii.el: Fix justify when `indent-tabs-mode' is non-nil

[Timothy]

Hi Morgan,

> I’ve attached a patch to fix an issue where tab characters are generated by
> the ASCII exporter when `indent-tabs-mode’ has its default value of t.

Thanks for finding this bug, fixing it, and sending us it . I was able to
reproduce your test case with “emacs -Q” (thanks for that, by the way).
As you suspected, with the small number of changed lines, this would be fine to
accept without FSF assignment.
However, your “patch” seems to consist of a diff at the bottom of your email and
a commit message at the top?? It would be preferable if you could provide a
“proper” patch, that way you can get attribution for your help instead of just
someone committing it on your behalf.

All the best,
Timothy

Re: Repeating task not repeating

[Timothy]

Hi Alan,

> This seems like the same issue I was having last month. A patch was posted 
> here:
>
> 
>
> As far as I can see, it has not yet been applied to the official org repo, 
> but I
> applied the patch manually to my local org and everything has worked fine 
> since.
>
> I tried to check  for more info, but got a 502 
> Bad
> Gateway error.

Good to hear that the patch is working well for you. I’ve recently checked
updates.orgmode.org and you may be glad to hear that it appears there :)

The patch itself looks good to me, hopefully it gets merged soon (I’m not
familiar with the org-agenda code).

All the best,
Timothy

Re: Bug: inconsistent handling of empty duration cells in table [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210816/)]

[Timothy]

Hi Jeff,

Thanks for the test case. I’ve been able to reproduce the behaviour, and agree
that the inconsistency is an issue. As such, I’ve marked this as a bug on
updates.orgmode.org.

All the best,
Timothy

Re: org-cite: enable inserting citation (org-cite-insert) after list bullet [9.5 (9.5-7c78aca @ /home/yuu/.config/emacs/straight/build/org/)]

[Bruce D'Arcus]

On Tue, Aug 31, 2021 at 7:21 AM Timothy  wrote:

> Thinking about this situation, inserting citations should be fine as
> long as the `point' isn't before or immediately after the bullet itself
> (i.e. no space).

I agree.

Cites in lists can be useful, including for things like CVs.

Bruce

Re: [PATCH] Update some changed export keybindings [worg]

[Timothy]

Hi Stefan,

Thanks for the patch. I’ve just applied it. I haven’t had a look at the other
“C-c C-e” keybindings, but I’m glad that you brought it up. Hopefully someone
else will take a look at some point.

> The attached patch fixes some incorrect keybindings in worg.
>
> I’d recommend that someone takes a look at all the “C-c C-e …”
> keybindings, as there are some that I was unsure about, and may still
> be incorrect even after this patch.

All the best,
Timothy

Re: Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation! /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and /mnt/c/Users/toz/.

[Timothy]

Hi Maxim,

> Bug: org-src-font-lock-fontify-block should be wrapped with save-match-data
> [9.3.7 (9.3.7-4-gba6ca7-elpaplus @ mixed installation!
> /mnt/c/Users/toz/Weiterbildung/Soft/Emacs/ and
> /mnt/c/Users/toz/.emacs.d/elpa/org-plus-contrib-20200615/)
>
> Notice “mixed installation!”. Often it is source of obscure errors.
> 
>
> Maybe link to FAQ item should be added to bug report template when mixed
> installation is detected. Since mixed installation can be detected, I would
> consider issuing a message during loading of Org mode.

Ah, thanks for highlighting this. It sounds like “mixed installation” is a red
flag which should prompt a request to reproduce the issue with an unmodified
Org.

All the best,
Timothy

Re: [BUG] Creating sparse tree with regexp property matches

[Timothy]

Hi Cassio,

> Ah! Can’t believe I didn’t try that. Well, at least the docs can
> benefit from my confusion.

Would you be interested in making a patch for the docs, or would you rather
leave that to someone else?

All the best,
Timothy

Re: New source block results option for attaching file to node

[Timothy]

Hi Ryan,

Thanks for submitting your first patch to Org! 

Regarding the purpose of the patch, I take it this is useful with source blocks
that return a file patch and should be added as an attachment? Would you mind
expanding on this use case? Oh, and `org-attach-dir' doesn’t show up a function 
or
variable for me, I take it you meant something else?

Lastly, with your commit message, you’ve clearly looked at the requested commit
message format . There’s the odd typo (“theh”) and the line length is too
long. It’s good if you hard line-wrap to 72 characters (if you use Magit, this
should happen automatically FYI). Other than that it looks good to me.

All the best,
Timothy

Re: org-cite: enable inserting citation (org-cite-insert) after list bullet [9.5 (9.5-7c78aca @ /home/yuu/.config/emacs/straight/build/org/)]

[Timothy]

Yuu Yin  writes:

> Invoking ~org-cite-insert~ after list bullets (e.g. ~-~ and ~1.~ )
> doesn't work.

I did a little test myself, and can confirm that it's not currently
possible to insert a citation *immediately* after a bullet and space.
This can be checked with `org-cite--allowed-p'.

Thinking about this situation, inserting citations should be fine as
long as the `point' isn't before or immediately after the bullet itself
(i.e. no space).

I've prepared a patch that fixes this (attached). This is the test case
that I'm adding:

+ ((eq type 'item)
+  (> (point) (+ (org-element-property :begin context)
+(org-get-indentation)
+1)))

As this is so simple, if nobody has any comments I'll push this in a
week or so.

--
Timothy

>From 8a242b6c80c2ec2b384f12c16bb9f70c2d44c9c7 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 31 Aug 2021 19:03:19 +0800
Subject: [PATCH] oc: allow citations following an item bullet

* lisp/oc.el (org-cite--allowed-p): Expand the allowed cases to include
"item", which lets one insert a citation following a bullet, e.g. "- ".
We just have to check to make sure the citation actually is at least one
character away from the bullet.
---
 lisp/oc.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/oc.el b/lisp/oc.el
index 5fcb9da62..7ffe37e57 100644
--- a/lisp/oc.el
+++ b/lisp/oc.el
@@ -1426,6 +1426,11 @@ (defun org-cite--allowed-p (context)
  ((= (point) (org-element-property :begin context)))
  ;; Within recursive object too, but not in a link.
  ((eq type 'link) nil)
+ ;; At the start of a list item is fine, as long as the bullet is unaffected.
+ ((eq type 'item)
+  (> (point) (+ (org-element-property :begin context)
+(org-get-indentation)
+1)))
  ((eq type 'table-cell)
   ;; :contents-begin is not reliable on empty cells, so special
   ;; case it.
-- 
2.33.0

Re: Smart quotes for Greek (questions for a possible patch)

[Juan Manuel Macías]

Hello Protesilaos and Michalis,

Thank you very much, Protesilaos, for the valuable information. It can
be confirmed, then, that the quotation marks rules for current Greek are
identical to the rules for Spanish, so it will be enough to copy the
existing configuration for Spanish in `org-export-smart-quotes-alist'.

It seems that the character U+201F as the first second level quotes
(instead of U+201C), which Yannis Haralambous comments in the article
cited in my first message, although historically attested, has been
abandoned...

Soon I will propose here a patch to support small quotes to
Greek.

Best regards,

Juan Manuel

Protesilaos Stavrou writes:

> Hello Michalis, Juan Manuel,
>
> [ I had no access to a computer and could not get to you sooner.  Expect
>   timely replies from now on. ]
>
> The first level quotes are indeed «».  For the other two, I have to rely
> on what I have encountered before, namely, that the second level is
> denoted with double curly quotes “” and third with single curly quotes
> ‘’.
>
> I have come across those in EU documents.  There is a style guide for
> the European Institutions.[1][2][3]
>
> I do not know latex notation to help you with the technicalities.
> Here are the unicode points:
>
> | « | U+00AB |
> | » | U+00BB |
> | “ | U+201C |
> | ” | U+201D |
> | ‘ | U+2018 |
> | ’ | U+2019 |
>
> All the best,
> Protesilaos
>
> [1] Quotes: .
> [2] General info: .
> [3] Main portal: .

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[Timothy]

Hi NoWayman,

Thanks for your suggestion. At a glance it looks reasonable to me, but would you
be able to explain the default value you’ve set? It isn’t obvious to me how you
arrived at `"[ \t]*[^[:alnum:]_@#%][ \t]*"'. Also, do you think a
one-size-fits-all solution is a good fit here? I don’t do much with tags
personally, so I’m probably not the best person to judge.

> (defconst org-tag-crm-separator “[ ]*[^[:alnum:]_@#%][ ]*”
>   “Regexp used to determine `crm-separator’ when reading multiple tags.”)

All the best,
Timothy

Re: Bug: Unintended column added to table [9.4.6 (9.4.6-gab9f2a @ /home/user/.emacs.d/elpa/org-9.4.6/)]

[Timothy]

Confirming as a Bug on updates.orgmode.org.