Re: searching agenda from TRAMP

[Adam Porter]

JARZz  writes:

> Hello all, 
>
> I have a case of a somewhat irregular org mode setup. Here are the givens: 
>
> 1 I have many org files. One for each week of the year, including a
> couple of generic ones, IE journal.org, routines.org, wiki.org,
> etc. All in all it's about 120 files or so, all loaded to my
> org-agenda.

120 files is a lot, but the overhead is generally in setting up each Org
buffer, activating org-mode and calling hooks, etc.  Once a buffer is
open, searching them should be fast enough, depending on size, search
type, etc.

> 3 I need to use agenda searches with specific information, such as
> user names, machines names, program names etc. in my agenda to find
> specific cases.

You might give org-ql a try, as its searching is generally much faster,
although it won't solve any TRAMP-related problems.

> As long as I worked with my files locally, things were OK. TRAMP slows
> me down a lot, though. I know the problem is not the connection
> because scp and ssh session works like a breeze. It seems the issues
> happens with indexing the files.

> I don't know what happens behind the scenes exactly, but it takes a
> good minute or to load my agenda with all the files, and it can take
> 10-15 minutes to search through them for a specific string. This
> problem also happens when I used sshfs, which makes me believe more
> strongly the problem is, again, not with the ssh connection itself,
> but with the indexing.

There is no indexing.  :)  (org-ql does implement a per-buffer, per-query
cache for repeated queries, though.  And org-roam does offer a database
that searches some parts of Org files, although I've no idea if it's
compatible with TRAMP.)

> Is there a way to seep this up? Or perhaps a workaround you think
> might work? I want to use the GUI Emacs. What do you think? Also, what
> causes this?

As you probably know, Emacs and Org are full of configuration and
state.  I have little experience with TRAMP, but from what I do have,
I've seen that state and configuration can cause major performance
issues in unexpected ways.  So I'd suggest that you try to reproduce the
problem in a clean, or as minimal as possible, Emacs configuration.  My
with-emacs.sh script would help with that:

https://github.com/alphapapa/with-emacs.sh

If it still happens in a clean Emacs, then you should try using the
latest version of everything: Emacs, Org, and related packages.  (Again,
with-emacs.sh makes it easy to test in separate configs, and something
like Guix can help with running newer Emacs versions.)  If it doesn't
happen in a clean Emacs, then you could try using the bug-hunter package
to bisect your config.

If none of that helps, you'll probably have to dig in to the problem,
use the profiler, etc, to try to find what exactly is taking so long.
This kind of problem usually isn't easy to troubleshoot.  :(

Good luck!

Adam

Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)

[Ihor Radchenko]

Nicolas Goaziou  writes:

> I'm not sure. I wrote this some years ago. I guess the rationale at that
> time was that it didn't feel useful to apply a format to an empty cell.
> For example, if you use `:fmt "$%s$"', I assume you wouldn't want to get
> "$$" in otherwise empty cells.

Also makes sense.

At this point, third-party code is likely to rely on the existing logic,
so I do not see any reason to insist on changing org-table.

To avoid confusion, can we change the docstring explicitly saying that
empty cells are ignored? (see the attached)

Best,
Ihor

>From 60365a164147dfc71f0047661c143b54064a459b Mon Sep 17 00:00:00 2001
Message-Id: <60365a164147dfc71f0047661c143b54064a459b.1633060596.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Fri, 1 Oct 2021 11:40:54 +0800
Subject: [PATCH] orgtbl-to-generic: Mention that :fmt is ignored for empty
 cells

* lisp/org-table.el (orgtbl-to-generic): Amend docstring mentioning
that :fmt is ignored for empty table cells.
---
 lisp/org-table.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/org-table.el b/lisp/org-table.el
index 89c57fb06..3fed15054 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -5649,6 +5649,9 @@ (defun orgtbl-to-generic (table params)
 
 (:fmt (2 \"$%s$\" 4 (lambda (c) (format \"$%s$\" c
 
+  The format is ignored for empty fields.  Use :raw t with non-nil
+  :backend option to force formatting empty fields.
+
 :hlstart :hllstart :hlend :hllend :hsep :hlfmt :hllfmt :hfmt
 
  Same as above, specific for the header lines in the table.
-- 
2.32.0

Re: Release 9.5

[Jarmo Hurri]

Bastien  writes:

> Org 9.5 is out, available from GNU ELPA.

Exciting!

I just ran 'git pull' and got a warning and an error:

warning: redirecting to https://git.savannah.gnu.org/git/emacs/org-mode.git/
Your configuration specifies to merge with the ref 'refs/heads/maint'
from the remote, but no such ref was fetched.

Do I need to start a new clone from scratch, or is there a fix for this?

(I honestly have _no recollection_ of what changes I have made, and what
changes need to be made, to the cloned repository locally in order for
'make' to run successfully.)

Have fun and stay safe.

Jarmo

Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)

[Ihor Radchenko]

Ihor Radchenko  writes:

> The attached patch should fix the issue, though it may be more
> reasonable to fix orgtbl-to-generic logic.

Given Nicholas' reply, changing orgtbl-to-generic may not be a good idea
and break other code using orgtbl-to-generic.

Applied as ddee7b617 on bugfix

Best,
Ihor



Fixed

Re: Visibility cycling with inline tasks 2

[No Wayman]

I can confirm the issue you've outlined on latest 'main'.
To me it looks like the problem is in `org-inline-hide-tasks'.
I don't use inline tasks, so I'm not sure what the exact expected 
behavior is,
but that function uses a `while' during `org-cycle-hook' to 
iterate through all of the headings.
My intuition is that it's overshooting a boundary and toggling 
visibility on more than it should.


Does the attached patch behave more in line with what you expect? 

>From 04ed84c36a4cc04838b5b75e18858996af125f77 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 23:31:50 -0400
Subject: [PATCH] org-inlinetask.el: Limit children visibility toggle to
 subtree

* org-inlinetask: (org-inlinetask-toggle-visibility): Limit toggling
to subtree.

Not sure if this is correct behavior or not. Just a suggestion.
---
 lisp/org-inlinetask.el | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el
index 3379a2e46..3bdc03ae4 100644
--- a/lisp/org-inlinetask.el
+++ b/lisp/org-inlinetask.el
@@ -334,11 +334,13 @@ This function is meant to be used in `org-cycle-hook'."
 	   (org-inlinetask-goto-end)
 (`children
  (save-excursion
-   (while
-	   (or (org-inlinetask-at-task-p)
-	   (and (outline-next-heading) (org-inlinetask-at-task-p)))
-	 (org-inlinetask-toggle-visibility)
-	 (org-inlinetask-goto-end))
+   (save-restriction
+ (org-narrow-to-subtree)
+ (while
+ (or (org-inlinetask-at-task-p)
+ (and (outline-next-heading) (org-inlinetask-at-task-p)))
+   (org-inlinetask-toggle-visibility)
+   (org-inlinetask-goto-end)))
 
 (defun org-inlinetask-remove-END-maybe ()
   "Remove an END line when present."
-- 
2.33.0

Re: org-element.el change in emacs.git

[Adam Porter]

Hi Kyle,

Kyle Meyer  writes:

> Thanks for the heads up.
>
> I monitor Org-related changes to the Emacs repo and port them to Org's.
> Entering into Emacs release periods, I tend to look at least once a day
> so that porting doesn't hold up cutting a bugfix release and syncing.
> Other times, it's not as frequent, but usually not less than once a
> week. 

Well, I guess I need to follow the mailing list more closely; if I did,
I'd probably have already known that.  :)

> None of that is to say that flagging an important commit isn't
> appreciated.  Just setting expectations about what the normal intake
> looks like.

I don't know, for what we're paying you, I think something like a 1-hour
turnaround time would be more appropriate...  ;)

> (Fwiw a log of the considered commits is available at
> .)

I didn't know about that URL.  That's 8 years of faithful, thankless
maintenance.  Thanks for your work on Org.  :)

By the way, I'm curious, not having always followed the internal details
of Org's development over the years: why are changes like that made to
emacs.git and merged back into Org, instead of being made in Org and
then merged back into Emacs with the next sync?  It seems like it could
be a burden, requiring someone like you to track them and merge them,
but there's probably a good reason for this workflow.

searching agenda from TRAMP

[JARZz]

Hello all,

I have a case of a somewhat irregular org mode setup. Here are the givens:

- I have many org files. One for each week of the year, including a couple of 
generic ones, IE journal.org, routines.org, wiki.org, etc. All in all it's 
about 120 files or so, all loaded to my org-agenda.

- I've set up Emacs on a mac at work. I do not want my org files stored locally 
on that machine since it does not belong to me. Instead, I utilized using TRAMP 
to load the files. I access my remote ssh server with a key and it works OK.

- I need to use agenda searches with specific information, such as user names, 
machines names, program names etc. in my agenda to find specific cases.

As long as I worked with my files locally, things were OK. TRAMP slows me down 
a lot, though. I know the problem is not the connection because scp and ssh 
session works like a breeze. It seems the issues happens with indexing the 
files.

I don't know what happens behind the scenes exactly, but it takes a good minute 
or to load my agenda with all the files, and it can take 10-15 minutes to 
search through them for a specific string. This problem also happens when I 
used sshfs, which makes me believe more strongly the problem is, again, not 
with the ssh connection itself, but with the indexing.

Is there a way to seep this up? Or perhaps a workaround you think might work? I 
want to use the GUI Emacs. What do you think? Also, what causes this?

Re: org-element.el change in emacs.git

[Kyle Meyer]

Adam Porter writes:

> I noticed this recent commit on emacs.git making a change to
> org-element.el:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58102466e32d4dd9c7d816cdc3f4595a2145f332

Thanks for the heads up.

I monitor Org-related changes to the Emacs repo and port them to Org's.
Entering into Emacs release periods, I tend to look at least once a day
so that porting doesn't hold up cutting a bugfix release and syncing.
Other times, it's not as frequent, but usually not less than once a
week.

None of that is to say that flagging an important commit isn't
appreciated.  Just setting expectations about what the normal intake
looks like.

(Fwiw a log of the considered commits is available at
.)

> I don't see that change in org-mode.git, and it seems like it could be
> an important one, so I wanted to make sure it doesn't go unnoticed.

It came in with c763b9ae6 (Backport commit 58102466e from Emacs,
2021-09-30), and it looks like it was merged into the bugfix branch
about ten minutes before your message landed, but I probably _pushed_ a
bit after you hit send :)

org-element.el change in emacs.git

[Adam Porter]

Hi Bastien, et al,

I noticed this recent commit on emacs.git making a change to
org-element.el:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=58102466e32d4dd9c7d816cdc3f4595a2145f332

I don't see that change in org-mode.git, and it seems like it could be
an important one, so I wanted to make sure it doesn't go unnoticed.

-- 
Thanks,
Adam

Re: [PATCH] Accept more :tangle-mode specification forms

[Tom Gillespie]

I strongly oppose this patch. It adds far too much complexity to the
org grammar. Representation of numbers is an extremely nasty part of
nearly every language, and I suggest that org steer well clear of
trying to formalize this. With an eye to future portability I suggest
that no special cases be given to something as important for security
as tangle mode without very careful consideration. Emacs lisp closures
have clear semantics in Org and the number syntax is clear. If users
are concerned about the verbosity of (identity #o0600) they could go
with the sorter (or #o0600). Best,
Tom

Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> Nicolas,
>
> Is there a rationale behind bypassing :fmt and :hfmt for empty table
> cells in `org-table--to-generic-cell'? In this patch, I have to work
> around this using :raw parameter in `orgtbl-to-generic' call. I do not
> feel like such workaround should be needed.

I'm not sure. I wrote this some years ago. I guess the rationale at that
time was that it didn't feel useful to apply a format to an empty cell.
For example, if you use `:fmt "$%s$"', I assume you wouldn't want to get
"$$" in otherwise empty cells.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Don't fill displayed equations

[Nicolas Goaziou]

Timothy  writes:

> I think there are also some relevant points which I haven’t mentioned so far,
> separate from my thoughts that since we’re using the LaTeX syntax we should be
> consistent with how LaTeX treats this.

I'm not convinced about this. I don't think it is even possible.

>> As I wrote above, they do not belong to the same category of syntax.
>> There’s no reason to special case 
>
> I think we already do special-case `\[ ... \]' somewhat. When refer to inline
> elements like bold, verbatim, italic, etc. they sit in the text. Semantically,
> this doesn’t hold for `\[ ... \]' either. The semantically inline maths 
> element is
> `\( ... \)'. Considering other “inline” syntax elements, like bold, verbatim,
> italic, etc. if you spread the delimiters across multiple lines that doesn’t
> work. So I’d argue the ship has already sailed on treating `\[ ... \]' 
> differently
> to other inline elements.

I'm not sure about what you mean. \[...\] is no different than, e.g.,
verbatim. It's an inline element, with all that it implies.

Now, if you want to discuss changing syntax for \[...\] and make it
a block element, you can of course do it to your heart's content (it has
been discussed already in this ML and I don't have an opinion on the
subject), but please don't make filling do bizarre things (not all Org
users use LaTeX or even like LaTeXisms), just because LaTeX modes behave
differently.

> If you’re wondering why I’m so opposed to the current behaviour, that is 
> probably
> best explained by a more realistic demo that what I have in the commit 
> message.
>
> ┌
> │ Since \(\cos\) is an even function, we can negate the numerator of the 
> argument
> │ without changing the result, giving
> │ \[
> │   \cos \left( \pi \frac{C_1-x}{2C_1+D} \right) \ , \quad C_1 = \frac{D}{2}.
> │ \]
> │ this will be positive over \(x \in (0,D)\), and so we can rewrite 
> \(\tilde{y}\) as,
> │ \[
> │   \tilde{y}(x) = \frac{2D}{\pi} \log \cos \left( \pi 
> \frac{\frac{D}{2}-x}{2D} \right) + C_2.
> │ \]
> │ Once again considering that \(y(0)=y(D)=0\), it is clear that
> │ \[
> │   C_2 = - \frac{2D}{\pi} \log \cos \left( \frac{\pi}{4} \right) = - 
> \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = \frac{D}{\pi} \log 2.
> │ \]
> │ The complete solution for \(\tilde{y}\) is hence,
> │ \[
> │   \tilde{y} = \frac{2D}{\pi} \log \cos \left( \pi \frac{D-2x}{4D} \right) + 
> \frac{D}{\pi} \log 2.
> │ \]
> └

In every case above, you can already use
\begin{equation*}...\end{equation*}, so I don't see the point. You
already have all you need without breaking filling function for the rest
of us.

> Basically, this leads to a worse experience when using Org in what
> I would think to be a perfectly reasonably way.

I don't think it is a worse experience, unless you apply expectations
from LaTeX to Org. It just doesn't work. Notwithstanding filling
behaviour, \[...\] in Org is much more limited than \[...\] in LaTeX.
They just happen to use the same syntax for convenience in simple cases.
The same holds for, e.g., LaTeX commands. To put it differently, you
cannot just paste some LaTeX code in an Org buffer and expect Org to
properly deal with it. But that's fine. If you need to write or copy
"advanced" LaTeX code, Org provides dedicated environments.

Regards,

Re: [PATCH] Don't fill displayed equations

[Tim Cross]

Nicolas Goaziou  writes:

> Hello,
>
> Colin Baxter  writes:
>
>>> Nicolas Goaziou  writes:
>>
>> > Timothy  writes:
>> >> Nicolas Goaziou  writes:
>> >> 
>> >>> I strongly disagree with this. \[...\] is an inline element, not
>> >>> a block element. As such, it can be filled, and filling function
>> >>> should obey to the inner structure of the document.
>> >>> 
>> >>> You can use a real block element here, e.g.,
>> >>> \begin{equation*}...\end{equation*}, which will not be filled.
>> >> 
>> >> Given that \[ ... \] is an alias for \begin{equation*} ...
>> >> \end{equation*}
>>
>> > This is true in LaTeX, not in Org, obviously.
>>
>> But shouldn't org be consistent with LaTeX. 
>
> Org supports, as a small part of its syntax, some limited LaTeX markup.
> It doesn't imply it should strive for consistency with LaTeX. Actually,
> I think it's quite the opposite. Org is not a LaTeX front-end.
>

I think this is an important point. Org, like other 'markdown' style
abstractions is a lot more than just a convenience abstraction for
writing Latex. Like other markdown dialects which have an 'escape hatch'
which allows you to embed raw HTML in your document, org allows
embedding 'latex' fragments, but that does not mean it is a latex
front-end. How document elements are displayed in the buffer should not
be determined just by what/how latex does it - it might provide some
guidance, but should not be the sole decider (i.e. because this is how
latex does it is not sufficient justification in itself).

With respect to this patch, I can see both sides having merit. Timothy's
points make sense from an end user's perspective and how things look in
the buffer. However, Nicolas point is also very relevant, especially if
we hope to have a markup syntax which is consistent and parsed
consistently. I'm not convinced that one inline element should be
treated differently  because in some situations, it is easier to
read/edit. Changing the visual representation of this inline block may
also have impact on user expectations for export and could lead to
further confusion. 

Re: [PATCH] Don't fill displayed equations

[Nicolas Goaziou]

Hello,

Colin Baxter  writes:

>> Nicolas Goaziou  writes:
>
> > Timothy  writes:
> >> Nicolas Goaziou  writes:
> >> 
> >>> I strongly disagree with this. \[...\] is an inline element, not
> >>> a block element. As such, it can be filled, and filling function
> >>> should obey to the inner structure of the document.
> >>> 
> >>> You can use a real block element here, e.g.,
> >>> \begin{equation*}...\end{equation*}, which will not be filled.
> >> 
> >> Given that \[ ... \] is an alias for \begin{equation*} ...
> >> \end{equation*}
>
> > This is true in LaTeX, not in Org, obviously.
>
> But shouldn't org be consistent with LaTeX. 

Org supports, as a small part of its syntax, some limited LaTeX markup.
It doesn't imply it should strive for consistency with LaTeX. Actually,
I think it's quite the opposite. Org is not a LaTeX front-end.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Nicolas,

I think there are also some relevant points which I haven’t mentioned so far,
separate from my thoughts that since we’re using the LaTeX syntax we should be
consistent with how LaTeX treats this.

> As I wrote above, they do not belong to the same category of syntax.
> There’s no reason to special case 

I think we already do special-case `\[ ... \]' somewhat. When refer to inline
elements like bold, verbatim, italic, etc. they sit in the text. Semantically,
this doesn’t hold for `\[ ... \]' either. The semantically inline maths element 
is
`\( ... \)'. Considering other “inline” syntax elements, like bold, verbatim,
italic, etc. if you spread the delimiters across multiple lines that doesn’t
work. So I’d argue the ship has already sailed on treating `\[ ... \]' 
differently
to other inline elements.

If you’re wondering why I’m so opposed to the current behaviour, that is 
probably
best explained by a more realistic demo that what I have in the commit message.

┌
│ Since \(\cos\) is an even function, we can negate the numerator of the 
argument
│ without changing the result, giving
│ \[
│   \cos \left( \pi \frac{C_1-x}{2C_1+D} \right) \ , \quad C_1 = \frac{D}{2}.
│ \]
│ this will be positive over \(x \in (0,D)\), and so we can rewrite 
\(\tilde{y}\) as,
│ \[
│   \tilde{y}(x) = \frac{2D}{\pi} \log \cos \left( \pi \frac{\frac{D}{2}-x}{2D} 
\right) + C_2.
│ \]
│ Once again considering that \(y(0)=y(D)=0\), it is clear that
│ \[
│   C_2 = - \frac{2D}{\pi} \log \cos \left( \frac{\pi}{4} \right) = - 
\frac{2D}{\pi} \log 2^{-\frac{1}{2}} = \frac{D}{\pi} \log 2.
│ \]
│ The complete solution for \(\tilde{y}\) is hence,
│ \[
│   \tilde{y} = \frac{2D}{\pi} \log \cos \left( \pi \frac{D-2x}{4D} \right) + 
\frac{D}{\pi} \log 2.
│ \]
└
is currently filled to
┌
│ Since \(\cos\) is an even function, we can negate the numerator of the 
argument
│ without changing the result, giving \[ \cos \left( \pi \frac{C_1-x}{2C_1+D}
│ \right) \ , \quad C_1 = \frac{D}{2}. \] this will be positive over \(x \in 
(0,D)\),
│ and so we can rewrite \(\tilde{y}\) as, \[ \tilde{y}(x) = \frac{2D}{\pi} \log 
\cos \left( \pi
│ \frac{\frac{D}{2}-x}{2D} \right) + C_2. \] Once again considering that
│ \(y(0)=y(D)=0\), it is clear that \[ C_2 = - \frac{2D}{\pi} \log \cos \left(
│ \frac{\pi}{4} \right) = - \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = 
\frac{D}{\pi} \log 2.
│ \] The complete solution for \(\tilde{y}\) is hence, \[ \tilde{y} = 
\frac{2D}{\pi} \log \cos
│ \left( \pi \frac{D-2x}{4D} \right) + \frac{D}{\pi} \log 2. \]
└

Suffice to say, I find the second terrible to read compared to the first.
Furthermore, when using org-latex-preview, wrapped `\[ ... \]' blocks join 
lines,
resulting in lines that are displayed going off edge of the page after filling.

Basically, this leads to a worse experience when using Org in what I would think
to be a perfectly reasonably way.

All the best,
Timothy

[BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

The attached patch addresses org-src.el's checkdoc warnings spare 
the following (IMO spurious) warnings:


 >158 0 notee-f-cLisp symbol ‘split-window-below’ 
 >should appear in quotes


split-window-below is a value used in org-src-window-setup (along 
with split-window-right, other-window, other-frame), but these 
values do not necessarily map onto their functions. e.g. 
other-window displays via `switch-to-buffer-other-window'.


 >80050  notee-f-cKeycode C-c embedded in doc string. 
 >Use \\ & \\[function] instead


The embedded keycodes in `org-src-do-key-sequence-at-code-block' 
are just for the sake of example.

Re: [PATCH] Don't fill displayed equations

[Timothy]

Nicolas Goaziou  writes:

>> Given that \[ ... \] is an alias for \begin{equation*} ...
>> \end{equation*}
>
> This is true in LaTeX, not in Org, obviously.

Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$,
and \begin{env} ... \end{env} and constructs in Org to be consistent
with LaTeX?

--
Timothy

Re: [PATCH] Don't fill displayed equations

[Colin Baxter]

> Nicolas Goaziou  writes:

> Timothy  writes:
>> Nicolas Goaziou  writes:
>> 
>>> I strongly disagree with this. \[...\] is an inline element, not
>>> a block element. As such, it can be filled, and filling function
>>> should obey to the inner structure of the document.
>>> 
>>> You can use a real block element here, e.g.,
>>> \begin{equation*}...\end{equation*}, which will not be filled.
>> 
>> Given that \[ ... \] is an alias for \begin{equation*} ...
>> \end{equation*}

> This is true in LaTeX, not in Org, obviously.

But shouldn't org be consistent with LaTeX. In both org-mode and LaTeX I
would write an in-line equation as $1+3=3$ and not as \[1+2=3\]. I would
reserve the latter for an unlabelled block equation. As has been said,
\[ is an alias for \begin{equation*}. For me, I would rather not write
equations in org-mode differently from LaTeX.

Best wishes,

Colin Baxter.

Re: Would it be possible to color horizontal lines in org mode?

[John Kitchin]

This looks correct. Some people prefer to use named functions for this,
so it is easier to remove them, but this works fine.

Alper Alimoglu  writes:

> Thank you Professor Kitchin. Would something like follows would work?
> #+BEGIN_SRC emacs-lisp :results silent
> (add-hook 'org-mode-hook (lambda () (font-lock-add-keywords
>  nil
>  '(("^-\\{5,\\}"  0 '(:foreground "red" 
> :weight bold))
> #+END_SRC
>
> -Alper 
>
> On Tue, Sep 28, 2021 at 8:18 PM John Kitchin  wrote:
>
>  you can add a rule like this in an org-mode hook:
>
>  #+BEGIN_SRC emacs-lisp :results silent
>  (font-lock-add-keywords
>   nil
>   '(("^-\\{5,\\}"  0 '(:foreground "red" :weight bold
>  #+END_SRC
>
>  that will make a line starting with at least 5 - be red and bold in color.
>
>  John
>
>  ---
>  Professor John Kitchin (he/him/his)
>  Doherty Hall A207F
>  Department of Chemical Engineering
>  Carnegie Mellon University
>  Pittsburgh, PA 15213
>  412-268-7803
>  @johnkitchin
>  http://kitchingroup.cheme.cmu.edu
>
>  On Tue, Sep 28, 2021 at 4:00 AM Eric S Fraga  wrote:
>
>  You could use hi-lock-mode to define your own colouring for such
>  lines.  But I'm sure those that under font-locking better might be able
>  to add appropriate rules for this horizontal line construct.
>
>  -- 
>  : Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
>  : Latest paper written in org: https://arxiv.org/abs/2106.05096


-- 
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
Pronouns: he/him/his

Re: [PATCH] Don't fill displayed equations

[Nicolas Goaziou]

Timothy  writes:

> Nicolas Goaziou  writes:
>
>> I strongly disagree with this. \[...\] is an inline element, not a block
>> element. As such, it can be filled, and filling function should obey to
>> the inner structure of the document.
>>
>> You can use a real block element here, e.g.,
>> \begin{equation*}...\end{equation*}, which will not be filled.
>
> Given that \[ ... \] is an alias for \begin{equation*} ...
> \end{equation*}

This is true in LaTeX, not in Org, obviously.

> I don't see why it should be treated any differently
> when filling.

As I wrote above, they do not belong to the same category of syntax.
There's no reason to special case \[...\]. 

Filling is a red herring, its outcome depends on the syntax of the
underlying object, as expected. So, as long as \[...\] is an inline
element, it should be filled.

Regards,

Re: [PATCH] Don't fill displayed equations

[Timothy]

Nicolas Goaziou  writes:

> I strongly disagree with this. \[...\] is an inline element, not a block
> element. As such, it can be filled, and filling function should obey to
> the inner structure of the document.
>
> You can use a real block element here, e.g.,
> \begin{equation*}...\end{equation*}, which will not be filled.

Given that \[ ... \] is an alias for \begin{equation*} ...
\end{equation*} I don't see why it should be treated any differently
when filling.

--
Timothy

Re: [PATCH] Don't fill displayed equations

[Nicolas Goaziou]

Hello,

Timothy  writes:

> If a displayed equation (`\[ ... \]') starts on its own line, I don’t think it
> should be filled into the rest of the text. I.e.,
>
> ┌
> │ some nice text
> │ \[
> │   1+1=2
> │ \]
> │ more text.
> └
> should not become,
> ┌
> │ some nice text \[ 1+1=3 \] more text.
> └
>
> While the above example may not look bad, with non-trivial equations
> this can become quite messy.

I strongly disagree with this. \[...\] is an inline element, not a block
element. As such, it can be filled, and filling function should obey to
the inner structure of the document.

You can use a real block element here, e.g.,
\begin{equation*}...\end{equation*}, which will not be filled.

Regards,
-- 
Nicolas Goaziou

[PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hello,

Currently, the only way to set a file mode when tangling seems to be 
:tangle-mode (identity #o755)

In a [prior thread], Jeremy proposed that :tangle-mode should convert octal
number strings to the required decimal form. I think we should go further, and
so have prepared the attached patch based on a snippet I shared in the thread.

To quote the docstring of the new function I’m introducing, this patch now
accepts the following :tangle-mode forms:
• an integer (returned without modification)
• “#o755” (elisp-style octal)
• “0755” (c style octal)
• “755” (chmod style octal)
• “rwxrw-r–” (ls style specification)
• “a=rw,u+x” (chmod style)
• “rwx” (interpreted as “u=rwx”)

Why be so permissive? I’d refer you to my reasoning in the prior thread:

I think there are a few arguably “sensible” formats that a user could reasonably
assume, and if we can support most of them without introducing ambiguity in
parsing or interpretation (and I think we can), can’t we make everyone happy?

All the best,
Timothy


[prior thread] 

>From 5087de0d70151c33d66eb13dda84d78a361d7053 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 1 Oct 2021 02:02:22 +0800
Subject: [PATCH] ob-tangle: Accept more :tangle-mode forms

* lisp/ob-tangle.el (org-babel-tangle): Accept many more forms for
:tangle-mode, including octal strings (#o755, 0755, 755), ls forms (rwx,
rw-r--r--), and chmod forms (a=rw,u+x).  The interpretation of the input
is now handled by the new function `org-babel-interpret-file-mode' which
references the new variable `org-babel-tangle-default-mode' when
considering relative mode forms.
---
 lisp/ob-tangle.el | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2dd1d031c..28a235429 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -140,6 +140,14 @@ (defcustom org-babel-process-comment-text 'org-remove-indentation
   :version "24.1"
   :type 'function)
 
+(defcustom org-babel-tangle-default-mode #o544
+  "The default mode used for tangled files, as an integer.
+The default value 356 correspands to the octal #o544, which is
+read-write permissions for the user, read-only for everyone else."
+  :group 'org-babel
+  :version "9.6"
+  :type 'integer)
+
 (defun org-babel-find-file-noselect-refresh (file)
   "Find file ensuring that the latest changes on disk are
 represented in the file."
@@ -255,7 +263,7 @@ (defun org-babel-tangle ( arg target-file lang-re)
 		(when she-bang
 			  (unless tangle-mode (setq tangle-mode #o755)))
 		(when tangle-mode
-			  (add-to-list 'modes tangle-mode))
+			  (add-to-list 'modes (org-babel-interpret-file-mode tangle-mode)))
 		;; Possibly create the parent directories for file.
 		(let ((m (funcall get-spec :mkdirp)))
 			  (and m fnd (not (string= m "no"))
@@ -298,6 +306,38 @@ (defun org-babel-tangle ( arg target-file lang-re)
 	   path-collector))
 	path-collector
 
+(defun org-babel-interpret-file-mode (mode)
+  "Determine the integer representation of a file MODE specification.
+The following forms are currently recognised:
+- an integer (returned without modification)
+- \"#o755\" (elisp-style octal)
+- \"0755\" (c style octal)
+- \"755\" (chmod style octal)
+- \"rwxrw-r--\" (ls style specification)
+- \"a=rw,u+x\" (chmod style) *
+- \"rwx\" (interpreted as \"u=rwx\") *
+
+* The interpretation of these forms relies on `file-modes-symbolic-to-number',
+  and uses `org-babel-tangle-default-mode' as the base mode."
+  (cond
+   ((integerp mode) mode)
+   ((not (stringp mode))
+(error "File mode %S not recognised as a valid format." mode))
+   ((string-match-p "^0?[0-7][0-7][0-7]$" mode)
+(string-to-number mode 8))
+   ((string-match-p "^#o[0-7][0-7][0-7]$" mode)
+(string-to-number (substring mode 2) 8))
+   ((string-match-p "^[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\(,[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\)*$" mode)
+(file-modes-symbolic-to-number mode org-babel-tangle-default-mode))
+   ((string-match-p "^[rwx-]\\{3\\}$" mode)
+(file-modes-symbolic-to-number (concat "u=" mode) org-babel-tangle-default-mode))
+   ((string-match-p "^[rwx-]\\{9\\}$" mode)
+(file-modes-symbolic-to-number (concat  "u=" (substring mode 0 3)
+",g=" (substring mode 3 6)
+",a=" (substring mode 6 9))
+   0))
+   (t (error "File mode %S not recognised as a valid format." mode
+
 (defun org-babel-tangle-clean ()
   "Remove comments inserted by `org-babel-tangle'.
 Call this function inside of a source-code file generated by
-- 
2.33.0

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Timothy]

Hi  Jeremy,

> I love it! Much better than my proposed patch.

I’m about to send a patch based on my snippet, so I’m marking this patch as 
cancelled.

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

The initial patch was just slightly off. Here's a correct version.

Timothy  writes:
> As such, I have attached a patch which adds fill “cuts” around `\[' and
> `\]', when `\[' occurs at the start of a line. This leaves the display 
> equation
> delimiters on their own line.

>From d6d2221a7a9bf5e3cf93265c13cb643bcfe46929 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 1 Oct 2021 01:14:21 +0800
Subject: [PATCH] org: Don't fill displayed equations into text

* list/org.el (org-fill-element): If a displayed equation (\[ ... \])
starts on its own line, it should not be filled into the rest of the
text. I.e.,

some nice text
\[
  1+1=2
\]
more text.

should not become,

some nice text \[ 1+1=3 \] more text.

While the above example may not look bad, with non-trivial equations
this can become quite messy.
---
 lisp/org.el | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 405f0f0f9..ff86a9dd0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19551,16 +19551,26 @@ (defun org-fill-element ( justify)
 			 (org-element-property :contents-end element
 	   ;; Do nothing if point is at an affiliated keyword.
 	   (if (< (line-end-position) beg) t
-	 ;; Fill paragraph, taking line breaks into account.
 	 (save-excursion
 	   (goto-char beg)
 	   (let ((cuts (list beg)))
+ ;; Cut fill on line breaks.
 		 (while (re-search-forward "[ \t]*\n" end t)
 		   (when (eq 'line-break
 			 (org-element-type
 			  (save-excursion (backward-char)
 	  (org-element-context
 		 (push (point) cuts)))
+ ;; Cut fill on displayed equations.
+ (while (re-search-forward "^[ \t]*\\[" end t)
+   (let ((el (org-element-context)))
+ (when (eq 'latex-fragment (org-element-type el))
+   (setf cuts (append
+   (list (org-element-property :end el)
+ (- (org-element-property :end el) 2)
+ (+ (org-element-property :begin el) 2)
+ (org-element-property :begin el))
+   cuts)
 		 (dolist (c (delq end cuts))
 		   (fill-region-as-paragraph c end justify)
 		   (setq end c
-- 
2.33.0

[PATCH] Don't fill displayed equations

[Timothy]

Hi All,

If a displayed equation (`\[ ... \]') starts on its own line, I don’t think it
should be filled into the rest of the text. I.e.,

┌
│ some nice text
│ \[
│   1+1=2
│ \]
│ more text.
└
should not become,
┌
│ some nice text \[ 1+1=3 \] more text.
└

While the above example may not look bad, with non-trivial equations
this can become quite messy.

As such, I have attached a patch which adds fill “cuts” around `\[' and
`\]', when `\[' occurs at the start of a line. This leaves the display equation
delimiters on their own line.

I think this motivation for this change is fairly clear, and so without feedback
I intend to push this in a few days, however I if anybody has comments on the 
way
I’m currently implementing this, I’d like to hear your thoughts.

All the best,
Timothy
>From d008ff3c2218e19bb501137715b05e06a0c511e3 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 1 Oct 2021 01:14:21 +0800
Subject: [PATCH] org: Don't fill displayed equations into text

* list/org.el (org-fill-element): If a displayed equation (\[ ... \])
starts on its own line, it should not be filled into the rest of the
text. I.e.,

some nice text
\[
  1+1=2
\]
more text.

should not become,

some nice text \[ 1+1=3 \] more text.

While the above example may not look bad, with non-trivial equations
this can become quite messy.
---
 lisp/org.el | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 405f0f0f9..daf1d91b4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19551,10 +19551,10 @@ (defun org-fill-element ( justify)
 			 (org-element-property :contents-end element
 	   ;; Do nothing if point is at an affiliated keyword.
 	   (if (< (line-end-position) beg) t
-	 ;; Fill paragraph, taking line breaks into account.
 	 (save-excursion
 	   (goto-char beg)
 	   (let ((cuts (list beg)))
+ ;; Cut fill on line breaks.
 		 (while (re-search-forward "[ \t]*\n" end t)
 		   (when (eq 'line-break
 			 (org-element-type
@@ -19562,6 +19562,16 @@ (defun org-fill-element ( justify)
 	  (org-element-context
 		 (push (point) cuts)))
 		 (dolist (c (delq end cuts))
+ ;; Cut fill on displayed equations.
+ (while (re-search-forward "^[ \t]*\\[" end t)
+   (let ((el (org-element-context)))
+ (when (eq 'latex-fragment (org-element-type el))
+   (setf cuts (append
+   (list (org-element-property :end el)
+ (- (org-element-property :end el) 2)
+ (+ (org-element-property :begin el) 2)
+ (org-element-property :begin el))
+   cuts)
 		   (fill-region-as-paragraph c end justify)
 		   (setq end c
 	 t)))
-- 
2.33.0

Re: Release 9.5

[autofrettage]

> Org 9.5 is out, available from GNU ELPA.

I bow to the ground in utter and humble gratitude!

> Enjoy!

I will, that is as certain as taxes and death!

Cheers
Rasmus

[org-cite] next steps for documentation?

[Bruce D'Arcus]

We have some initial documentation for org-cite included in the manual
to accompany the release of Org 9.5.

https://orgmode.org/manual/Citation-handling.html#Citation-handling

But it still needs a fair bit of work.

Questions:

1. What else should/must be added to the manual?
2. What might we instead add to Worg?

My view on 1:

1. input format discussion (bibtex, biblatex, CSL JSON)
2. styles/variants, ideally with a table like Timothy has in his
recent blog post [1]
3. how to use the oc-basic insert processor

Bruce

[1] https://blog.tecosaur.com/tmio/2021-07-31-citations.html

Re: worg: org-protocol.html - 404 Not Found

[Bastien]

Hi Max,

Max Nikulin  writes:

> It seems, something is wrong with worg deployment

https://builds.sr.ht/~bzg/job/598512 hints that a link was unresolved.

I just fixed this link, the export should process fine.

Thanks for reporting this!

-- 
 Bastien

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

[Bastien]

Hi Sébastien,

Sébastien Miquel  writes:

> I've rebased the patch on main. It is still relevant (Ihor and I have
> provided
> reproducers earlier in the thread).

Applied in bugfix, thanks!

-- 
 Bastien

Re: Release 9.5

[Bastien]

Hi Pankaj,

Pankaj Jangid  writes:

> One Q: what is the schedule for 9.5 to be included in Emacs-28?

Org 9.5 have been merged in the Emacs master branch, from which the
Emacs release branch for 28.1 will be cut anytime soon.

Then we will work on 9.5.1 for important bugfixes and merge 9.5.1
in the Emacs release branch.

I don't know when Emacs 28.1 will be released.

HTH,

-- 
 Bastien

Re: Suggestions for improved suffix parsing in oc-biblatex

[Denis Maier]

Am 30.09.2021 um 09:23 schrieb Nicolas Goaziou:

Hello,

Denis Maier  writes:


Well, there are even cases like this one:

[cite:@doe especially 4, 12, and 15]

[cite:@doe e.g. 4, 12, and 15]

[cite:@doe among others 4, 12, and 15]

[cite:@doe 4, but also 12 and 15]

AFAIU, all these cases are already handled by the locator parsing
algorithm used in oc-csl.el. If that is correct, my point is still the
same: there are very few cases where an explicit locator delimiter would
be necessary.


So, you're suggesting that locator parsing algorithm should be ported to 
oc-biblatex instead? That would obviously be a neat solution.

If so, I can provide a couple of examples so we can see if that could work.

Denis

[checkbox in tables] (was: [SOLVED])

[Uwe Brauer]

>>> "MN" == Max Nikulin  writes:

> On 29/09/2021 11:07, Timothy wrote:
>> 
>>> Any idea how to export checkboxes to odt?
>>> I mean not just simply having [ ] in the odt document but having them 
>>> translated as actual boxes.
>>> 
>>> Either using latex ⊠
>>> or   UTF8 ☒
>> I’m wondering, would this be worth adding to ox-odt?

> LibreOffice has some object called "checkbox" that could be inserted
> using "Form Controls" toolbar. I have never used this feature, so
> unsure whether it is a proper representation for Org checkboxes.

I should add, that I need to generate an odt document, in which checkboxes are 
placed in tables, a feature that is not supported by org mode as of today, 
unfortunately.



smime.p7s
Description: S/MIME cryptographic signature

Re: [new patch] Re: [PATCH] make org-notify support for macOS desktop notification

[Max Nikulin]

On 26/09/2021 15:52, Bastien wrote:

stardiviner writes:


Here is the new patch which invokes notifications though Emacs
built-in API `ns-do-applescript`.


Applied in the main branch, thanks.


Notice that applied patch has a minor issue: backslashes are not escaped 
before argument is passed to osa-script interpreter, so e.g. trailing 
backslash leads to syntax error

(https://list.orgmode.org/sc1hdn$12dt$1...@ciao.gmane.io).

Disclaimer: I am not a macOS user.

From discussion in this thread I had impression that patched for macOS 
versions work much better and they do not require this patch. Introduced 
clause has higher priority than notify-send however the latter works 
even on mac at least for some users.

Re: [BUG] Conflict between org-emphasis and org-latex

[Max Nikulin]

On 27/09/2021 00:05, Léo Ackermann wrote:

Le 26 sept. 2021 à 19:01, Timothy a écrit :
You write:

Nevertheless, I think that this bug has been introduced recently (I never 
noticed it before) and has to be corrected properly (as this is a really basic 
use of
org-mode).
Unfortunately, I can barely understand elisp... so writing a patch is far away 
from what I can do :/


Do you think you might be able to identify a "good" commit and bisect
the bug? That would be a tremendous help for solving it, and shouldn't
require any elisp.


It is not bisect, though results for "emacs -Q" or "emacs -q" are 
identical for the following Org versions:


- Org mode version 9.5 (release_9.5-6-g59cb39 ...) - current main
- Org mode version 9.3.1 (9.3.1-dist ...) - elpa-org package from 
Ubuntu-20.04
- Org mode version 9.1.9 (release_9.1.9-65-g5e4542 ...) - bundled with 
emacs-26.3 Ubuntu-20.04 package


- "and" is bold in the buffer (wrong)
- Export to LaTeX (correct): "Consider \(a^{*}\) and \(b^{*}\)"

I do not think that some problem has been introduced recently.

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

[Max Nikulin]

On 25/09/2021 23:04, Bastien wrote:

(I'm marking this as a confirmed bug, even if a first patch as been applied.)


Since it was there earlier, it is tracked twice now:
- User input is combined with format string in org-latex-src-block
- Bug: Percentage in caption does not work in LaTeX export

Let's assume that one entry is to fix "minted" and another one for 
"listings" environment. Though one more obscure issue remains: 
"multicolumn" option does do what can be expected from its name.

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

[Ihor Radchenko]

Sébastien Miquel  writes:

> I had done some testing, and some more recently. The patch only affects
> latex-fragments and org entities to be edited which do not need to start 
> at a
> beginning of line (latex-fragments, inline src blocks, footnote 
> definitions).

Also looks fine for me.

Best,
Ihor

Re: BUG: org-table: table option “:missing” not working (in ob-gnuplot.el)

[Ihor Radchenko]

Robert Klein  writes:

> When trying to run a table with missing values with ob-gnuplot.el
> there's a “:missing value” option.  ob-gnuplot is supposed to put the
> “value” into the place of empty cell values before calling on gnuplot.
> It doesn't do this currently.

Confirmed

The problem is partially because of the way `org-table--to-generic-cell'
works. It disallows custom processing of empty table cells unless both
:raw and :backend arguments are supplied to `orgtbl-to-generic'.

The attached patch should fix the issue, though it may be more
reasonable to fix orgtbl-to-generic logic.

Nicolas,

Is there a rationale behind bypassing :fmt and :hfmt for empty table
cells in `org-table--to-generic-cell'? In this patch, I have to work
around this using :raw parameter in `orgtbl-to-generic' call. I do not
feel like such workaround should be needed.

Best,
Ihor

>From 7033289d7e717eb841d550fbdbc0cc878b96cd32 Mon Sep 17 00:00:00 2001
Message-Id: <7033289d7e717eb841d550fbdbc0cc878b96cd32.1633005978.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Thu, 30 Sep 2021 20:40:37 +0800
Subject: [PATCH] ob-gnuplot: Honour :missing argument

* lisp/ob-gnuplot.el (org-babel-gnuplot-table-to-data): Force applying
`org-babel-gnuplot-quote-tsv-field' to empty table cells when
converting org tables to gnuplot input.  By default,
`orgtbl-to-generic' ignores :fmt for empty table cells.  We need to
set :raw to non-nil AND :backend to non-nil to force custom formatting
of empty table cells.

Fixes https://orgmode.org/list/20210617211347.59e4d...@happy.intern.roklein.de
---
 lisp/ob-gnuplot.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-gnuplot.el b/lisp/ob-gnuplot.el
index 6489c23f5..120aaa18e 100644
--- a/lisp/ob-gnuplot.el
+++ b/lisp/ob-gnuplot.el
@@ -272,7 +272,7 @@ (defun org-babel-gnuplot-table-to-data (table data-file params)
 	  (orgtbl-to-generic
 	   table
 	   (org-combine-plists
-		'(:sep "\t" :fmt org-babel-gnuplot-quote-tsv-field)
+		'(:sep "\t" :fmt org-babel-gnuplot-quote-tsv-field :raw t :backend ascii)
 		params)
   data-file)
 
-- 
2.32.0

Re: [PATCH] Rename headline to heading

[André A . Gomes]

Bastien  writes:

> Hi André,
>
> I agree this change is a welcome improvement: thanks a lot for working
> on this patch.  I would like to suggest a step by step approach:
>
> 1. Updating occurrences in the documentation: manual, guide,
>docstrings, worg occurences, etc.
>
> 2. Updating Org internals without impacting users' configuration
>(i.e. update the functions and variables name, but don't update
>the "file+headline" config string.)
>
> 3. If the "file+headline" config string is the only part of a config
>that can be impacted by this change, support both the new and old
>strings for backward compatibility.
>
> We don't need a transition period for the first two changes, and we
> don't need one either for the third one if we implement the backward
> compatible solution.  We need a transition period if we remove it, but
> I'm not convinced removing it is really needed now.
>
> What do you think?

Hi Bastien,

Sorry for my late reply.

Overall, I agree with the suggested approach.

Here's something I wasn't sure about when I worked on it.  How should I
distribute the changes commit-wise?  Tom Gillespie, for instance,
suggested separating documentation and docstring from internals.

I think it's ok to separate internals from documentation (manuals).  But
when it comes to docstrings, it feels a bit odd.  Say there's a function
named foo-headline whose docstring contains the string headline.  Then
there would be a commit where the function continues to have headline in
its definition, but the docstring contains heading.  Shouldn't we avoid
such a "grey area" snapshot?

I could create a bunch of small and well documented patches, that in the
end would be squashed before merging into master.  Perhaps it would even
make sense to have a branch for a while so that people would test it.
This way everyone gets a fine grain for inspection, while in the end we
get a huge "/s/headline/heading" commit.

If someone has better ideas, please share.  I will take a look at this
perhaps next week.  Thank you.


-- 
André A. Gomes
"Free Thought, Free World"

worg: org-protocol.html - 404 Not Found

[Max Nikulin]

It seems, something is wrong with worg deployment

curl -I https://orgmode.org/worg/org-contrib/org-protocol.html
HTTP/1.1 404 Not Found
Server: nginx/1.14.2
Date: Thu, 30 Sep 2021 12:10:08 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 169
Connection: keep-alive

org-contrib/org-protocol.org file is still in the worg repository, it is 
referenced from https://orgmode.org/worg/org-contrib/index.html


The file contains a lot of outdated information but I have not noticed 
any sign that it has been hidden intentionally.

Re: [PATCH] Rename headline to heading

[André A . Gomes]

Timothy  writes:

> Sorry that you haven’t heard anything in a while. I’ve been hoping that 
> Bastien
> or Nicolas might have been able to take a look at this and give their 
> thoughts,
> but unfortunately judging from their recent activity they both seem to be 
> quite
> busy as of late. I dream of the day when Org could actually employ a full-time
> maintainer via opencollective (or similar).

Hi Timothy,

Sorry for my late reply as well.

Well, excuse me for my impudence, but I would be happy to maintain
org-mode in exchange for some money.  I live in Russia so I don't need
much :)

> In the meantime, I’ve flagged this message in my own mail client, and it 
> appears
> on  so you can at least be sure that this won’t 
> be
> forgotten about.
>
>> I’m still waiting for the FSF to send me back my form signed.  I’ve sent
>> it on the 31st of July.
>
> Could you let us know if the FSF have got back to you on this?

Yes, everything's ready.  It was pretty fast and straightforward.  Do I
need to send it to you?

Thanks.


-- 
André A. Gomes
"Free Thought, Free World"

Re: [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 Bastien,

Bastien writes:


Sébastien, have you been able to test this patch heavily and is it
still needed, or has it been made somehow irrelevant?  (I see it does
apply well on the bugfix branch, but not on main.)

Thanks for any feedback,

I've rebased the patch on main. It is still relevant (Ihor and I have 
provided

reproducers earlier in the thread).

I had done some testing, and some more recently. The patch only affects
latex-fragments and org entities to be edited which do not need to start 
at a
beginning of line (latex-fragments, inline src blocks, footnote 
definitions).


Regards,

--
Sébastien Miquel
From b80124aa6edbd3b6992817dd8c37253705c82ae3 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 bf1340b0a..1ef89a04d 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 3b25fad60..d78f46186 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -327,7 +327,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)))
@@ -445,6 +446,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
(let ((eol (line-end-position)))
@@ -466,7 +468,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")
   (when (or (not (eolp))   ; not a blank line
 (and (eq (point) (marker-position marker)) ; current line
@@ -518,7 +521,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)
  (blank-line 

Re: The align of time is not beautiful as 9.4 when I update to org 9.5.

[Eric S Fraga]

On Thursday, 30 Sep 2021 at 18:59, Ihor Radchenko wrote:
> However, the problem is not reproducible. Are you able to provide a
> recipe?

For the record, I see the same as the OP: alignment on the first
character of the time string, not on the :.

However, my org is not quite up to date and don't wish to update it
right now as busy preparing teaching materials for start of the teaching
term!  (they're all written in org mode, of course)

-- 
: Eric S Fraga via Emacs 28.0.50, Org 9.5-g9a4a24
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: The align of time is not beautiful as 9.4 when I update to org 9.5.

[Ihor Radchenko]

tumashu  writes:

> Hello:
>
>
> When I update to org 9.5,  I find that  the align of time like "7:00" has 
> been changed.
>
> I think the new style is not beautiful as old style.
>  
> 1. New style look like not align to  the first char, for the width of 9 looks 
> like > 1
> 2. the old style is align ":"

It has been reported in
https://orgmode.org/list/87czr6uhhk@alphapapa.net

However, the problem is not reproducible. Are you able to provide a
recipe?

Best,
Ihor

Re: [PATCH] org-manual.org: Some correction of Installation section

[Ihor Radchenko]

Max Nikulin  writes:

> - I am in doubts whether "emacs -Q -L ~/src/org-mode/lisp" way to try 
> version from git is important enough for the manual.  I have added a 
> separate patch however to discuss such change.

I feel that it should not be in the manual. However, it may be helpful
addition to https://orgmode.org/contribute.html

Also, I'd recommend "emacs -Q -L ~/src/org-mode/list -l org", making
sure that the right version of Org mode is loaded regardless of the
local config.

Best,
Ihor

Re: Visibility cycling with inline tasks 2

[Ihor Radchenko]

Michael Dauer  writes:

> I wanted to help you with testing. But I could not find a branch dev in
> that repo.

I did not mean literally "dev" branch. The default branch there is my
local patches I plan to merge to Org eventually.

> Anyway, I'll wait for it to be populated into the main repo. When should I
> retry there?

I will prepare the patch for the main repo and post a reply to your
original bug report once I get time to do it.

Best,
Ihor

Re: Release 9.5

[Pankaj Jangid]

Bastien  writes:

> Org 9.5 is out, available from GNU ELPA.
>
> Thanks a lot to every contributor.
>

Thanks a lot for your work, Bastien. I want to thank all the
contributors.

One Q: what is the schedule for 9.5 to be included in Emacs-28?

Regards ~Pankaj

Re: Suggestions for improved suffix parsing in oc-biblatex

[Nicolas Goaziou]

Hello,

Denis Maier  writes:

> Well, there are even cases like this one:
>
> [cite:@doe especially 4, 12, and 15]
>
> [cite:@doe e.g. 4, 12, and 15]
>
> [cite:@doe among others 4, 12, and 15]
>
> [cite:@doe 4, but also 12 and 15]

AFAIU, all these cases are already handled by the locator parsing
algorithm used in oc-csl.el. If that is correct, my point is still the
same: there are very few cases where an explicit locator delimiter would
be necessary.

Note that for clarity, it would help to also specify, along with your
examples, what is the expected locator, and possibly the expected
output.


Regards,
-- 
Nicolas Goaziou

Re: Grabbing the link to a message on the archive

[Greg Minshall]

Timothy,

> If you use mu4e, the following may be of some interest:
> ┌
> │ (defun +mu4e-ml-message-link (msg)
> │   (cond
> │((string= "emacs-orgmode.gnu.org" (mu4e-message-field msg :mailing-list))
> │ (message "Link %s copied to clipboard" (gui-select-text (format 
> "https://list.orgmode.org/%s; (mu4e-message-field msg :message-id)
> │(t (user-error "Mailing list %s not supported" (mu4e-message-field msg 
> :mailing-list)
> │ (add-to-list 'mu4e-view-actions (cons "link to message ML" 
> #'+mu4e-ml-message-link t))
> └

awesome!  i didn't realize that the Message-ID was the key to the
specific e-mail at list.orgmode.org!

cheers, Greg