Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

2023-07-22 Thread Eric Abrahamsen
Jens Schmidt  writes:

> On 2023-07-22  15:48, Ihor Radchenko wrote:
>
>> I am not familiar with Gnus, but looking at the code, may it be that
>> a Gnus article is open when Gnus summary buffer is not?
>
> Theoretically yes, if you actively and malignantly kill the summary
> buffer, for example.  In practice and through Gnus key bindings, this
> should not happen.  IOW, Gnus stops behaving reasonably as well if you
> kill the summary buffer other than through Gnus key bindings
> ("Selecting deleted buffer", etc.).
>
> If you check function `gnus-summary-work-articles' from gnus-sum.el, the
> main work horse for article processing and also good for calling in
> article buffers, you will note (focusing on the default case) the same
> paradigm
>
>   (with-current-buffer gnus-summary-buffer
> (cond
>  [...]
>  (t
>   ;; Just return the current article.
>   (list (gnus-summary-article-number))
>
> As a last resort we could also try to drag in Andrew Cohen as a
> reviewer, he has been helpful already with one or two of my Gnus bugs.

We should definitely be using the paradigm above (using the
gnus-summary-buffer as the current buffer). The article number fetching
only works by accident in the article buffer, and other stuff (like
finding the original nnselect group name) won't work at all.

Later in the function we've got this:

(save-window-excursion
  (save-excursion
(gnus-article-show-summary)
(gnus-summary-article-header)))

If we're currently in article-mode. The call to
`gnus-article-show-summary' would protect against the case where the
summary buffer has been killed in the meantime, but I agree that's kind
of a pathological case.

Probably it would be enough to wrap the whole containing `let*' in a
(with-current-buffer gnus-summary-buffer ...). If we're already in the
summary buffer, no harm done.

Eric




Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

2023-07-22 Thread Gavin Downard
Max Nikulin  writes:
> On 19/07/2023 09:36, Gavin Downard wrote:
>> +++ b/lisp/org-table.el
>> @@ -2253,8 +2253,7 @@ LOCATION is a buffer position, consider the formulas 
>> there."
>>  ((not (match-end 2)) m)
>>  ;; Is it a column reference?
>>  ((string-match-p "\\`\\$\\([0-9]+\\|[<>]+\\)\\'" m) m)
>> -;; Since named columns are not possible in
>> -;; LHS, assume this is a named field.
>> +;; This is either a named field or column.
>>  (t (match-string 2 string)
>>  (rhs (match-string 3 string)))
>>  (push (cons lhs rhs) eq-alist)
>
> Notice
>  "Double definition `%s=' in TBLFM line, please fix by hand"
>
> below. A bit more code is required to keep this sanity check for named 
> columns.
>

Oh, good catch. Specifically, I think this should be caught inside of
`org-table-recalculate', where it catches conflicting direct column
references (eg "$1") and end-relative column references ("$<").
>   let* ((rhs (org-table-formula-substitute-names
>(org-table-formula-handle-first/last-rc (cdr eq
>  (old-lhs (car eq))
>  (lhs
>   (org-table-formula-handle-first/last-rc
>(cond
> ((string-match "\\`@-?I+" old-lhs)
>  (user-error "Can't assign to hline relative reference"))
> ((string-match "\\`\\$[<>]" old-lhs)
>  (let ((new (org-table-formula-handle-first/last-rc
>  old-lhs)))
>(when (assoc new eqlist)
>  (user-error "\"%s=\" formula tries to overwrite \
> existing formula for column %s"
^ right here
>  old-lhs
>  new))
>new))
> (t old-lhs)

Also, this should probably be addressed in a different patch, but the
above code doesn't catch two different end-relative column references
that refer to the same column, such as "$<" and "$>>" in a two-column table.

I have also modified the manual to reflect the addition of named
columns; I'll send an updated patch after I add the check for double 
definitions.

Max Nikulin  writes:
>
> `if-let' is not available in Emacs-26
>

Are you sure? It looks like `if-let' was introduced in Emacs 25.



Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

2023-07-22 Thread Jens Schmidt

On 2023-07-22  15:48, Ihor Radchenko wrote:


I am not familiar with Gnus, but looking at the code, may it be that
a Gnus article is open when Gnus summary buffer is not?


Theoretically yes, if you actively and malignantly kill the summary 
buffer, for example.  In practice and through Gnus key bindings, this

should not happen.  IOW, Gnus stops behaving reasonably as well if you
kill the summary buffer other than through Gnus key bindings ("Selecting 
deleted buffer", etc.).


If you check function `gnus-summary-work-articles' from gnus-sum.el, the
main work horse for article processing and also good for calling in
article buffers, you will note (focusing on the default case) the same
paradigm

  (with-current-buffer gnus-summary-buffer
(cond
 [...]
 (t
  ;; Just return the current article.
  (list (gnus-summary-article-number))

As a last resort we could also try to drag in Andrew Cohen as a
reviewer, he has been helpful already with one or two of my Gnus bugs.



Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

2023-07-22 Thread Ihor Radchenko
Jens Schmidt  writes:

> The most obvious symptom is this:
>
> - Create an nnselect group and open an article from that.  In the
>article buffer, do M-x org-store-link RET, then paste the link with
>C-c C-l in some Org mode buffer.  The resulting link looks like
>
>  gnus:#e18xcfu-0004ht...@fencepost.gnu.org
>
>That is, it lacks the group name before the hash sign.  Correct would
>have been:
>
>  gnus:nnml+archive:test01#e18xcfu-0004ht...@fencepost.gnu.org
>
>Starting with Emacs 30, you even more obviously get an error:
>
>  Debugger entered--Lisp error: (wrong-type-argument 
> number-or-marker-p nil)

Thanks for reporting!
ol-gnus is not very actively maintained, so there be dragons.

> The root cause is that some of the Gnus functions used in
> `org-gnus-store-link' must be called only in summary buffers, and not in
> article buffers.  These are:
>
>gnus-summary-article-number
>nnselect-article-group
>
> Not sure about these, but it is probably also better to call these in
> summary buffers only:
>
>nnvirtual-map-article
>nnir-article-group
>
> The remedy for these issues is simple: When calling above functions just
> temporarily and unconditionally switch to the summary buffer with
>
>(with-current-buffer gnus-summary-buffer ...)
>
> where buffer-local variable `gnus-summary-buffer' in an article buffer
> points to the summary buffer where the articles comes from.  (And for
> a summary buffer the variable points to the summary buffer itself.)

I am not familiar with Gnus, but looking at the code, may it be that a
Gnus article is open when Gnus summary buffer is not?

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



Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

2023-07-22 Thread Ihor Radchenko
Max Nikulin  writes:

>> I cannot find anything blocking the proposed change.
>
> I have not found anything valuable as well. So the only conflict is 
> named cell vs. named column.
> ...

I followed similar trace.

> So names after $ were used in the past, but only named fields are 
> currently supported, so it is not serious reason to disallow column names.

Agree.
Just need to make sure that we document this clearly in the manual.
Some parts of the manual are a ambiguous about column names vs. field
names.

3.5.1 References -> Named references only talks about column names, but
not field named.

3.5.5 Field and range formulas has

‘$NAME=’
 Named field, see *note Advanced features::.

only mentioning filed.

3.5.6 Column formulas says
The left-hand
side of a column formula can not be the name of column, it must be the
numeric column reference or ‘$>’.

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



Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

2023-07-22 Thread Max Nikulin

On 22/07/2023 14:25, Ihor Radchenko wrote:

Max Nikulin writes:


Perhaps git blame for the manual may give some hints. If the change is
really old then org.texi (removed at certain moment) should be inspected
as well.


This has been added very, very long time ago. org-table has undergone
through major transformations since that time.

I cannot find anything blocking the proposed change.


I have not found anything valuable as well. So the only conflict is 
named cell vs. named column.


The comment in the code was added in
d85ddfba0 2015-11-26 22:41:14 +0100 Nicolas Goaziou: org-table: Fix 
c651e150cc8fb230fca99dfff27caedfddced8ff


in response to
https://list.orgmode.org/20151126195059.gc13...@scotty.home/T/#u

that was a fix for
c651e150c 2015-11-12 23:12:18 +0100 Nicolas Goaziou: org-table: Fix 
`org-table-get-range' with column formulas


https://list.orgmode.org/cakzohg+2eu474+rcazkwjyk2vcj1p-9zvbykmqwdhta8waa...@mail.gmail.com/T/#u

I am not familiar with table code enough to track earlier changes.

There are were experiments with last row references as $LR12

dadc9a1af 2008-12-19 18:28:58 +0100 Carsten Dominik: Tables:  Implement 
last-row references.


later replaced by @>

https://list.orgmode.org/a8bc38be-fad6-4834-acd9-8c0d372b4...@gmail.com/T/#u
Carsten Dominik. Re: Table rows and ranges as LHS of formulas. Wed, 2 
Mar 2011 23:57:32 +0100


3dd474575 2011-03-08 14:49:53 +0100 Carsten Dominik: Tables:  Make @< 
and $< point to row/column 1 in a stable way


Note to the manual was added by
6761dcbbd 2009-02-12 07:12:38 +0100 Carsten Dominik: Minor fixes

The following commit

8237c9ae6 2011-03-01 09:05:56 +0100 Carsten Dominik: Implement table 
formulas that apply to field ranges, fix minor issues


added support of @L last row reference, $LR12 is mentioned as backward 
compatible way to specify a last row column.


So names after $ were used in the past, but only named fields are 
currently supported, so it is not serious reason to disallow column names.




Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

2023-07-22 Thread Max Nikulin

On 19/07/2023 09:36, Gavin Downard wrote:

+++ b/lisp/org-table.el
@@ -2253,8 +2253,7 @@ LOCATION is a buffer position, consider the formulas 
there."
((not (match-end 2)) m)
;; Is it a column reference?
((string-match-p "\\`\\$\\([0-9]+\\|[<>]+\\)\\'" m) m)
-   ;; Since named columns are not possible in
-   ;; LHS, assume this is a named field.
+   ;; This is either a named field or column.
(t (match-string 2 string)
(rhs (match-string 3 string)))
(push (cons lhs rhs) eq-alist)


Notice
   "Double definition `%s=' in TBLFM line, please fix by hand"

below. A bit more code is required to keep this sanity check for named 
columns.



@@ -2963,7 +2962,9 @@ existing formula for column %s"
  (t old-lhs)
  (if (string-match-p "\\`\\$[0-9]+\\'" lhs)
  (push (cons lhs rhs) eqlcol)
-   (push (cons lhs rhs) eqlfield
+(if-let ((named-column (assoc lhs org-table-column-names)))


`if-let' is not available in Emacs-26


+(push (cons (concat "$" (cdr named-column)) rhs) eqlcol)
+  (push (cons lhs rhs) eqlfield)
  (setq eqlcol (nreverse eqlcol))
  ;; Expand ranges in lhs of formulas
  (setq eqlfield (org-table-expand-lhs-ranges (nreverse eqlfield)))





Re: Is there a better (built-in) way to insert an org link with title as description?

2023-07-22 Thread Ihor Radchenko
Max Nikulin  writes:

> My idea is to handle dropping of text into Org buffers. Currently it 
> causes opening links in eww. I think, there are better options: convert 
> from html to Org using pandoc and insert text, `org-capture', 
> `org-store-link'. I have not tried to implement it. Currently I have 
> just a couple of hints in my notes: `dnd-protocol-alist' and 
> https://github.com/abo-abo/org-download/blob/master/org-download.el as 
> an example of code.

Supporting dnd will certainly be welcome.

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



Org Clive, a new Org-mode-based blog engine

2023-07-22 Thread Marcin Borkowski
Hi all,

you might be interested in looking at my latest (very small) project - a blog 
engine written on top of Org mode.  Yes, yet another one - but each of the 
existing solutions lacked something I needed.

Head on to GitLab (https://gitlab.com/mbork_mbork_pl/org-clive) or to my
blog post about it
(https://mbork.pl/2023-07-22_Org_Clive_-_a_new_Org-mode-based_blogging_engine)
or to Hacker News (https://news.ycombinator.com/item?id=36824652).

Best,

-- 
Marcin Borkowski
http://mbork.pl



[BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)]

2023-07-22 Thread Jens Schmidt

Tags: patch

`org-store-link' has a number of related issues when storing links from
article buffers related to nnvirtual, nnselect, or nnir groups.  I
describe them here in prose without providing a full repro case, which
would be somewhat difficult to set up.  Just let me know if you think
you need more information, I have the data available.

The most obvious symptom is this:

- Create an nnselect group and open an article from that.  In the
  article buffer, do M-x org-store-link RET, then paste the link with
  C-c C-l in some Org mode buffer.  The resulting link looks like

gnus:#e18xcfu-0004ht...@fencepost.gnu.org

  That is, it lacks the group name before the hash sign.  Correct would
  have been:

gnus:nnml+archive:test01#e18xcfu-0004ht...@fencepost.gnu.org

  Starting with Emacs 30, you even more obviously get an error:

Debugger entered--Lisp error: (wrong-type-argument 
number-or-marker-p nil)

  nnselect-article-group(nil)
  org-gnus-store-link()
  org-store-link(nil 1)
  funcall-interactively(org-store-link nil 1)
  call-interactively(org-store-link record nil)
  command-execute(org-store-link record)
  execute-extended-command(nil "org-store-link" nil)
  funcall-interactively(execute-extended-command nil 
"org-store-link" nil)

  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

Less obvious, occuring for nnvirtual groups:

- Create an nnvirtual group and open an article from that.  In the
  article buffer, do M-x org-store-link RET.  Observe the "current
  article arrow" in the fringe being set in the article header, even
  though that arrow should be used only in a summary buffer.

The root cause is that some of the Gnus functions used in
`org-gnus-store-link' must be called only in summary buffers, and not in
article buffers.  These are:

  gnus-summary-article-number
  nnselect-article-group

Not sure about these, but it is probably also better to call these in
summary buffers only:

  nnvirtual-map-article
  nnir-article-group

The remedy for these issues is simple: When calling above functions just
temporarily and unconditionally switch to the summary buffer with

  (with-current-buffer gnus-summary-buffer ...)

where buffer-local variable `gnus-summary-buffer' in an article buffer
points to the summary buffer where the articles comes from.  (And for
a summary buffer the variable points to the summary buffer itself.)

Finally, there is a related inefficiency when determining the article
header structure in function `org-gnus-store-link': Here the authors
indeed switch to the summary buffer when currently in the article
buffer, but using "user-land" interactive function
`gnus-article-show-summary' to do so where a simple

  (with-current-buffer gnus-summary-buffer ...)

would suffice.

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.24, cairo version 1.16.0)

 of 2023-07-20
Package: Org mode version 9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ 
/home/jschmidt/work/org-mode/lisp/)From e1bc9aefd4fd0080012c172d1c21c684a5b2fe51 Mon Sep 17 00:00:00 2001
From: farblos <43711228+farb...@users.noreply.github.com>
Date: Sat, 22 Jul 2023 10:30:19 +0200
Subject: [PATCH] ol-gnus.el: Fix issue when storing links from Gnus article
 buffers

* lisp/ol-gnus.el (org-gnus-store-link): Switch to
`gnus-summary-buffer' when calling functions that are intended to be
called only there.
---
 lisp/ol-gnus.el | 34 +++---
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/lisp/ol-gnus.el b/lisp/ol-gnus.el
index 7c07ce045..f0e04ce66 100644
--- a/lisp/ol-gnus.el
+++ b/lisp/ol-gnus.el
@@ -137,27 +137,23 @@ If `org-store-link' was called with a prefix arg the meaning of
  (let* ((group
 	 (pcase (gnus-find-method-for-group gnus-newsgroup-name)
 	   (`(nnvirtual . ,_)
-		(save-excursion
-		  (car (nnvirtual-map-article (gnus-summary-article-number)
+		(with-current-buffer gnus-summary-buffer
+		  (save-excursion
+		(car (nnvirtual-map-article (gnus-summary-article-number))
 	   (`(,(or `nnselect `nnir) . ,_)  ; nnir is for Emacs < 28.
-		(save-excursion
-		  (cond
-		   ((fboundp 'nnselect-article-group)
-		(nnselect-article-group (gnus-summary-article-number)))
-		   ((fboundp 'nnir-article-group)
-		(nnir-article-group (gnus-summary-article-number)))
-		   (t
-		(error "No article-group variant bound")
+		(with-current-buffer gnus-summary-buffer
+		  (save-excursion
+		(cond
+		 ((fboundp 'nnselect-article-group)
+		  (nnselect-article-group (gnus-summary-article-number)))
+		 ((fboundp 'nnir-article-group)
+		  (nnir-article-group (gnus-summary-article-number)))
+		 (t
+		  (error "No article-group variant bound"))
 	   (_ gnus-newsgroup-name)))
-	(header (if (eq major-mode 'gnus-article-mode)
-			;; When in an article, first move to summary
-			;; buffer, with 

Re: Is there a better (built-in) way to insert an org link with title as description?

2023-07-22 Thread Ihor Radchenko
Arthur Miller  writes:

>> (org-link-set-parameters "http" :insert-description #'your-function)
>> (org-link-set-parameters "https" :insert-description #'your-function)
>
> Thanks, after some thinkering I got it:
>
> ...
> (org-link-set-parameters "http" :insert-description #'org-desc-from-clipboard)
> (org-link-set-parameters "https" :insert-description 
> #'org-desc-from-clipboard)
> #+end_src
>
> And I can do it async too, *but*; this will affect all insertions of links,
> right?

Indeed. By design, `org-insert-link' is synchronous - it expects the
link and description to be available upon request.

> I am not sure if it is safe/possible always to access the internet or do
> it asynchronously, so I'll abandon the ship and revert to home-cooked one just
> for the precautios measures:

What you can do is (1) make url descriptions be something like ; (2) add an :after advice for `org-insert-link' that will
queue asynchronous url fetching; (3) replace 
with the fetched title upon finishing the request. If the request fails,
the description will remain .

Or you can run description retrieval independently, as a minor mode
that will search for  marks and try to fetch
them.

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



Re: [BUG] WORG example for ob-lilypond is no longer working as described (was: Moving some lisp/ob-*.el files to org-contrib - your advice?)

2023-07-22 Thread Ihor Radchenko
Jonathan Gregory  writes:

> On 21 Jul 2023, Ihor Radchenko wrote:
>
>> The png is still a full page on my side.
>
> That's not what I get. You're probably missing the paper settings:
>
> #+begin_src lilypond :exports none
> \version "2.20"
> \paper {
>   indent=0\mm
>   tagline=""
>   line-width=170\mm
>   oddFooterMarkup=##f
>   oddHeaderMarkup=##f
>   bookTitleMarkup=##f
>   scoreTitleMarkup=##f
> }
> #+end_src

I feel confused. Isn't you patch aiming for auto-sizing the resulting
page to fit the music fragment?

>> Also, I am getting
>>
>> Processing `/tmp/babel-xQweBZ/lilypond-WGdEvi'
>> Parsing...
>> /tmp/babel-xQweBZ/lilypond-WGdEvi:1: warning: no \version 
>> statement found, please add
>>
>> \version "2.24.0"
>>
>> which does not look necessary.
>
> What is not necessary? The warning is expected. Other than that 
> everything looks fine.

I guess I do not fully understand what your patch is trying to achieve.
I thought that the patch would make it not necessary to write some extra
boilerplate code, like \version or specifying the page size.

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



Re: [ANN] lisp/ob-tangle-sync.el

2023-07-22 Thread Ihor Radchenko
Mehmet Tekman  writes:

>> P.S. There going to be Emacs meetup this Saturday, July 22
>> (https://emacs-apac.gitlab.io/announcements/july-2023/). I plan to be
>> there and, if you need it, we can try to resolve difficulties in more
>> interactive way.
>
> I am currently travelling this weekend, otherwise I happily would
> attend so that this patch could speed forward. Next month maybe?

Another meetup is on July 26. https://emacs-berlin.org/
Or we can arrange a jitsi call.

>> Side note: You are re-implementing the already available ERT
>> features for failed test reporting. Instead of controlling
>> which tests failed manually, you should better follow the
>> example of all other tests and simply use a sequence of
>> `should'/`should-not' forms.
>
> Okay, I've re-written this to conform to the `should' macros.  I
> *really* wish these macros could be named so that I could debug
> failing statements better, but for now numbering them in the
> comments and using the `l' binding works well enough for
> debugging.

To name them, you can use separate ert-deftest statements.
Also, see the attached modified version of your diff - I made it so that
`should' failures immediately provide some clue about expected result
value, that can help to identify which of the should clauses fails.

> I have two tests that I've set to "should-not" pass for now, but
> once the correct merging behaviour has been implemented, I
> believe that I will change them to "should" pass statements:
>
> - 9. do-not-tangle-this-block
> - 12. tangle-file-with-spaces

The tests are indeed not passing on vanilla Org. I assume that you
tested them with your other patch applied.

diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index c8dbd44f4..de92cb90b 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -314,6 +314,147 @@ (ert-deftest test-ob/parse-header-args2 ()
 (org-babel-next-src-block)
 (should (= 14 (org-babel-execute-src-block)
 
+(defun test-ob/get-src-block-property (properties)
+  "Get plist of PROPERTIES and values for the first src block in buffer.
+PROPERTIES is a list of property keywords or a single keyword."
+  (org-with-wide-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block)
+   (org-set-regexps-and-options)
+   (let ((all-props (nth 2 (org-babel-get-src-block-info
+ (if (listp properties)
+ (apply #'nconc (mapcar (lambda (p) (list p (cdr (assoc p all-props properties))
+   (list properties (cdr (assoc properties all-props)))
+
+(ert-deftest test-ob/merge-params ()
+  "Test the output of merging multiple header parameters.  The
+expected output is given in the contents of the source code block
+in each test.  The desired test header parameters are given
+either as a symbol or a list in the `idtest-alist' variable.
+Multiple header parameters must be separated by a newline and
+exactly two spaces in the block contents."
+  (should ;; 1. inherit-document-header-args
+   (equal '(:tangle "/tmp/default_tangle.txt")
+  (org-test-with-temp-text
+  "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf
+#+end_src"
+(test-ob/get-src-block-property :tangle
+  (should  ;; 2. inherit-document-header-with-local-sync-action
+   (equal '(:tangle "/tmp/default_tangle.txt skip")
+  (org-test-with-temp-text
+  "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf :tangle skip
+#+end_src"
+(test-ob/get-src-block-property :tangle
+  (should ;; 3. override-document-header-with-local-tfile
+   (equal '(:tangle "randomfile sync")
+  (org-test-with-temp-text
+  "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf :tangle randomfile sync
+#+end_src"
+(test-ob/get-src-block-property :tangle
+  (should  ;; 4. override-document-and-parent-header-with-local-tfile-and-action
+   (equal '(:tangle "randomfile sync")
+  (org-test-with-temp-text
+  "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+:PROPERTIES:
+:header-args: :tangle \"newfile.txt\" import
+:END:
+** Two
+#+begin_src conf :tangle randomfile sync
+#+end_src"
+(test-ob/get-src-block-property :tangle
+  (should ;; 5. test-tangle-and-default-results-param-together
+   (equal '(:tangle "randomfile" :results "replace")
+  (org-test-with-temp-text
+  "\
+* One
+#+begin_src conf  :tangle randomfile
+#+end_src"
+(test-ob/get-src-block-property '(:tangle :results)
+  (should  ;; 6. inherit-document-tfile-take-only-last-local-sync-action
+   (equal '(:tangle "/tmp/default_tangle.txt export")
+  (org-test-with-temp-text
+  "\
+#+PROPERTY: header-args :tangle /tmp/default_tangle.txt
+* One
+#+begin_src conf  :tangle import export
+#+end_src"
+(test-ob/get-src-block-property :tangle
+  (should  ;; 7. 

Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

2023-07-22 Thread Ihor Radchenko
Max Nikulin  writes:

> Perhaps git blame for the manual may give some hints. If the change is 
> really old then org.texi (removed at certain moment) should be inspected 
> as well.

This has been added very, very long time ago. org-table has undergone
through major transformations since that time.

I cannot find anything blocking the proposed change.

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



Re: Documentation: Equal sign incorrectly listed as disallowed in plain links

2023-07-22 Thread Tom Alexander
Thanks for fixing all the documentation issues I submitted today!

On Sat, Jul 22, 2023, at 2:58 AM, Ihor Radchenko wrote:
> "Tom Alexander"  writes:
>
>> The documentation for plain links states that PATHPLAIN is:
>>
>>> A string containing non-whitespace non-bracket (()[]<>=) characters, 
>>> optionally containing parenthesis-wrapped non-whitespace non-bracket 
>>> substrings up to a depth of two. The string must end with either a 
>>> non-punctation non-whitespace character, a forwards slash, or a 
>>> parenthesis-wrapped substring.
>>
>> but if we create an org-mode document with the following test content:
>> ```
>> http://foo/bar=baz
>
> As you can see from the sentence, PATHPLAIN must be "non-whitespace"
> "non-bracket". "=" is just a messed up verbatim markup marker.
>
> Fixed, on master.
> https://git.sr.ht/~bzg/worg/commit/85ef10ed
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 



Re: Documentation: Equal sign incorrectly listed as disallowed in plain links

2023-07-22 Thread Ihor Radchenko
"Tom Alexander"  writes:

> The documentation for plain links states that PATHPLAIN is:
>
>> A string containing non-whitespace non-bracket (()[]<>=) characters, 
>> optionally containing parenthesis-wrapped non-whitespace non-bracket 
>> substrings up to a depth of two. The string must end with either a 
>> non-punctation non-whitespace character, a forwards slash, or a 
>> parenthesis-wrapped substring.
>
> but if we create an org-mode document with the following test content:
> ```
> http://foo/bar=baz

As you can see from the sentence, PATHPLAIN must be "non-whitespace"
"non-bracket". "=" is just a messed up verbatim markup marker.

Fixed, on master.
https://git.sr.ht/~bzg/worg/commit/85ef10ed

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



Re: Documentation: incorrect character name in line breaks

2023-07-22 Thread Ihor Radchenko
"Tom Alexander"  writes:

> The documentation for line breaks says that PRE is:
>
>> Anything but backspace (`\`).
>
> I suspect this is supposed to say "backslash" (ascii 92) not "backspace" 
> (ascii 8)
>
> Link to the documentation: 
> https://orgmode.org/worg/org-syntax.html#Line_Breaks

Fixed, on master.
https://git.sr.ht/~bzg/worg/commit/d032000b

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



Re: Documentation: Reference to BODY field that is not specified in the grammar

2023-07-22 Thread Ihor Radchenko
"Tom Alexander"  writes:

> The documentation for Inline Babel Calls mentions that opening and closing 
> square brackets must be balanced within BODY but the grammar above it only 
> defines NAME, ARGUMENTS, HEADER1, and HEADER2.
>
> Link to the documentation: 
> https://orgmode.org/worg/org-syntax.html#Inline_Babel_Calls

Fixed, on master.
https://git.sr.ht/~bzg/worg/commit/dc97c029

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



Re: Documentation: Reference to "KEYCITES" field that is not specified in grammar

2023-07-22 Thread Ihor Radchenko
"Tom Alexander"  writes:

> The documentation for Citations when specifying which syntactic elements have 
> spaces between them references a "KEYCITES" syntactic element that does not 
> appear anywhere else on the page.
>
> Link to the documentation issue: 
> https://orgmode.org/worg/org-syntax.html#Citations

Thanks for reporting!
Fixed, on master.
https://git.sr.ht/~bzg/worg/commit/9591b48f


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