Q: org-publish-project-alist and :exclude

2024-05-04 Thread David Masterson
In the Org Mode manual section 14.1.3, it says that ":exclude" takes a
regular expression of filenames to exclude from publishing but it
doesn't really explain what the regular expression format is (I assume
Elisp regex).  I have two Org files that I want to exclude:

* calendar-beorg.org
* init.org

So I have this form:

  :exclude "\(init\|calendar-beorg\).org"

but that doesn't seem to work as I get an ignorable error in processing
calendar-beorg.org (a known Beorg issue).

Is my regex wrong?

-- 
David Masterson



Re: Possible to set block switches "globally"?

2024-05-04 Thread Tom Gillespie
> I think that we can take names from the parser internals:

I had a similar thought immediately after I sent my previous email.

>  :number-lines
>  :preserve-indent
>  :retain-labels
>  :use-labels
>  :label-fmt

I thought that we might be able to combine :retain-labels
and :use-labels, but now I understand that :use-labels
is as opposed to line numbers. So think think that
using them as is is probably the best approach.

Defaults are effectively
:number-lines no
:preserve-indent (identity org-src-preserve-indentation)
:retain-labels yes
:use-labels yes
:label-fmt (or)



Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

2024-05-04 Thread Ihor Radchenko
Max Nikulin  writes:

> Another case:
>
> (org-babel-read "\"Newlines\"\n" t)
> "\"Newlines\"
> "

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

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



Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

2024-05-04 Thread Ihor Radchenko
Max Nikulin  writes:

> you added to tests, does not cause the error since the unbalanced 
> parenthesis is after first string. With the new regexp the error might 
> happen for
>
> (org-babel-read "\"Quoted closing quote:\\\"" t)
>
> but it is caught by `ignore-errors'.

I added this to the tests.

> Perhaps `save-match-data' may be dropped if `string-match-p' is used 
> instead of `string-match'. New code does not rely on match groups.

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

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



Re: Citations: strip braces {} in titles in bibliographies in basic style?

2024-05-04 Thread Ihor Radchenko
Ihor Radchenko  writes:

>> Should they be stripped?  I suggest they should.
> ...
> This is a more difficult problem actually, because Bibtex allows more
> than just curly braces - see https://www.bibtex.org/SpecialSymbols/ and
> https://www.bibtex.org/Format/.
>
> I tried to ask for bibtex.el to handle the accurate parsing in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57712, but it looks like
> it is not of interest upstream. So, we may have to implement a Bibtex
> entry parser according to the spec.
>
> Patches welcome!

Fixed, on main.
There is no formal Bibtex format reference, so approximate parsing has to do.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d2df9624c

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



Re: [BUG] tracker.orgmode.org does not track anything since March 8, 2024

2024-05-04 Thread Bastien Guerry
Ihor Radchenko  writes:

> Woof! does not seem to update the new emails any more.
> https://tracker.orgmode.org/?sorting-by=date page only contains emails
> back from March. No new bugs/requests/news are visible.

I restarted Woof, let's see if the dog is barking again.

-- 
 Bastien Guerry



Re: [PATCH] Add support for shortdoc link type

2024-05-04 Thread Bruno Cardoso

On 2024-05-04, 14:38 +0700, Max Nikulin  wrote:

> It is necessary to maintain backward compatibility for `ol-info'. I do 
> not know what kind of separator was added earlier: "::" or "#". I 
> suppose, for new link type, rules more close to file: links may be used, see
> (info "(org) Search Options")
> https://orgmode.org/manual/Search-Options.html
>
> That is why I suggested shortdoc:GROUP::#FUNCTION. This way 
> shrotdoc:GROUP::SEARCH_STRING is possible as well.

I see, thanks for pointing it out. I modified the regexp to match this pattern.

> Notice that `shortdoc-display-group' has optional FUNCTION argument.

Yes, I completely missed that. I updated the patch to use the optional function 
argument instead.

diff --git a/doc/org-manual.org b/doc/org-manual.org
index d66d95a22..61ee0c63d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -3372,6 +3372,10 @@ Here is the full set of built-in link types:
 
   Execute a shell command upon activation.
 
+- =shortdoc= ::
+
+Link to short documentation summary for a function group.  For more information, see [[info:emacs#Name Help][Help by Command or Variable Name]].
+
 
 For =file:= and =id:= links, you can additionally specify a line
 number, or a text search string, separated by =::=.  In Org files, you
@@ -3413,6 +3417,8 @@ options:
 | irc| =irc:/irc.com/#emacs/bob=  |
 | help   | =help:org-store-link=  |
 | info   | =info:org#External links=  |
+| shortdoc   | =shortdoc:text-properties= |
+|| =shortdoc:text-properties::#get-pos-property=  |
 | shell  | =shell:ls *.org=   |
 | elisp  | =elisp:(find-file "Elisp.org")= (Elisp form to evaluate)   |
 || =elisp:org-agenda= (interactive Elisp command) |
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 87ebed751..f90c59ed3 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1369,6 +1369,10 @@ place the entry in the ~Misc~ category if ~TEXINFO_DIR_CATEGORY~ is missing.
 =TEXINFO_DIR_TITLE= is renamed to =TEXINFO_DIR_NAME=.
 The old name is obsolete.
 
+*** =ol.el=: Support for =shortdoc= link type
+
+Add support for storing and inserting links to =shortdoc= groups.
+
 ** New functions and changes in function arguments
 *** New optional argument =UPDATE-HEADING= for ~org-bibtex-yank~
 
diff --git a/lisp/ol.el b/lisp/ol.el
index bc9682e4a..19ec7a32a 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1582,6 +1582,41 @@ PATH is a symbol name, as a string."
  :follow #'org-link--open-help
  :store #'org-link--store-help)
 
+ "shortdoc" link type
+(when (version< "27" emacs-version)
+  (defun org-link--open-shortdoc (path _)
+"Open a \"shortdoc\" type link.
+PATH is a group name or \"group::#function\"."
+(string-match "\\`\\([^#:]*\\)\\(::#?\\(.*\\)\\)?\\'" path)
+(let ((group (match-string 1 path))
+  (fn (match-string 3 path)))
+  (condition-case nil
+  (shortdoc-display-group group (intern-soft fn))
+(error (message "Unknown shortdoc group: %s" group)
+
+  (defun org-link--store-shortdoc ( _interactive?)
+"Store \"shortdoc\" type link."
+(when (eq major-mode 'shortdoc-mode)
+  (let* ((buffer (buffer-name))
+ (group (when (string-match "*Shortdoc \\(.*\\)\\*" buffer)
+  (match-string 1 buffer
+(if (and group (assoc (intern-soft group) shortdoc--groups))
+(org-link-store-props :type "shortdoc"
+  :link (format "shortdoc:%s" group)
+  :description nil)
+  (user-error "Unknown shortdoc group: %s" group)
+
+  (defun org-link--complete-shortdoc ()
+"Create a \"shortdoc\" link using completion."
+(concat "shortdoc:"
+(completing-read "Shortdoc summary for functions in: "
+ (mapcar #'car shortdoc--groups
+
+  (org-link-set-parameters "shortdoc"
+   :follow #'org-link--open-shortdoc
+   :store #'org-link--store-shortdoc
+   :complete #'org-link--complete-shortdoc))
+
  "http", "https", "mailto", "ftp", and "news" link types
 (dolist (scheme '("ftp" "http" "https" "mailto" "news"))
   (org-link-set-parameters scheme


Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

2024-05-04 Thread Max Nikulin

Max Nikulin writes:

Quotes are not stripped:


On 04/05/2024 18:51, Ihor Radchenko wrote:

Fixed, on main.


Another case:

(org-babel-read "\"Newlines\"\n" t)
"\"Newlines\"
"





Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

2024-05-04 Thread Max Nikulin

On 04/05/2024 18:51, Ihor Radchenko wrote:

Max Nikulin writes:

Quotes are not stripped:

(org-babel-read "\"abc\nsdf\"" t)
"\"abc
sdf\""


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


Thanks


(org-babel-read "(\n\"abc\"\n" t)

progn: End of file during parsing


I cannot reproduce. Still, I added a prophylactic measure to recover
from parsing errors.


(should (equal "\"foo\"(\"bar\"" (org-babel-read "\"foo\"(\"bar\"" 
inhibit)))


you added to tests, does not cause the error since the unbalanced 
parenthesis is after first string. With the new regexp the error might 
happen for


(org-babel-read "\"Quoted closing quote:\\\"" t)

but it is caught by `ignore-errors'.

Perhaps `save-match-data' may be dropped if `string-match-p' is used 
instead of `string-match'. New code does not rely on match groups.





[BUG] tracker.orgmode.org does not track anything since March 8, 2024 (was: Org site is down)

2024-05-04 Thread Ihor Radchenko
Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> A few reports showed up in the tracker since my previous email.
>> However, not all the reports.
>> ...

Woof! does not seem to update the new emails any more.
https://tracker.orgmode.org/?sorting-by=date page only contains emails
back from March. No new bugs/requests/news are visible.

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



Re: [PATCH] copy cell contents to kill-ring. WAS [FR]: thing-at-point 'org-table-cell

2024-05-04 Thread Ihor Radchenko
Pedro Andres Aranda Gutierrez  writes:

> I needed this function to copy contents from an org spreadsheet to a Web
> page and I see it may be useful to others. Take a look and if you find it
> useful, I'll add the changelog stuff.
> ...
> +(defun org-table-copy-cell-as-kill (verbose)
> +  "Copy the contents of the current cell to the kill buffer.
> +Print a message when verbose is not nil.
> +
> +hlines are not considered table cells"

Org mode already has a command that copies cell contents -
`org-table-copy-region'. That command has a problem though - it uses a
kludge with dynamic variable instead of copying to the kill ring.

I think that we can modify `org-table-copy-region' to copy to the kill
ring, adding text properties with cell info as metadata. Then,
`org-table-paste-rectangle' can check for these text properties instead
of relying upon `org-table-clip'.

Would you be willing to work on such refactoring?

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



Re: Possible to set block switches "globally"?

2024-05-04 Thread Ihor Radchenko
João Pedro  writes:

>> :number-lines (yes|no|continue) as João proposes
>> :indent   (preserve|align|???) not sure about naming
>> :labels  (link|keep|remove|remove-whitespace)
>> :label-format  regexp-string
>
> Yeah, as Ihor pointed out I did forget about -i, though I'm not really
> sure what that does.

I think that we can take names from the parser internals:

 :number-lines
 :preserve-indent
 :retain-labels
 :use-labels
 :label-fmt

:preserve-indent is a per-block setting of
`org-src-preserve-indentation' variable.

> I tried searching for where switches are parsed in the code, but
> couldn't find much. Could you provide me with some pointers and files I
> should be looking at?

`org-element-src-block-parser' and `org-element-example-block-parser'.

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



Re: can clocktable link to IDs?

2024-05-04 Thread Ihor Radchenko
Bill White  writes:

> When I create a clocktable, its entries are links to heading text: 
>
> [ [file:/path/to/meetings.org::*featureset meeting][featureset meeting] ] 
> ..
> Is there a way to convince the clocktable mechanism to link to a unique ID 
> (when it exists) rather than a possibly non-unique heading? 

No, unless you contribute a patch for this effect.
Such patch would be welcome ;)
See https://orgmode.org/worg/org-contribute.html

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



Re: [FR] Support headline as a function for file+headline target for org-capture-templates

2024-05-04 Thread Ihor Radchenko
Nafiz Islam  writes:

> So far I have written this code...
>
> (defun org-capture-expand-headline (headline)
>   "Expand functions, symbols and strings for HEADLINE.
>
>
> When HEADLINE is a function, call it.  When it is a form, evaluate
> it.  When it is a variable, return its value.  When it is a string,
> treat it as a headline title. When it is `t', select existing headline
> title or enter a new one.  In any other case, raise an error."

Let's not add "t" variant yet. It is going beyond what
`org-capture-expand-file' does.

>((functionp headline) (funcall headline
> headlines))

Let's not over-complicate things. Just (funcall headline) will do,
making sure that it is called in the right context - current buffer
being selected according to file part of the capture target.

> What I am concerned about is the amount of tests I might have to write or
> update for `org-capture'.
>
> testing/lisp/test-org-capture.el
> ...
> 144: `(("t" "Todo" entry (file+headline ,file2 "A")
> ...
> How do you think it should be tested if the headline can be 4 different
> types?

It is enough to make sure that basic entry type works correctly,
expanding the HEADLINE part of the template definition. Other tests you
listed are really not testing this; they are checking the logic of
inserting the right entry/item/table/etc.

Also, since we are adding more flexible HEADLINE expansion, may as well
allow functions for OLP in file+olp and file+olp+datetree.

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



Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

2024-05-04 Thread Ihor Radchenko
Max Nikulin  writes:

>> I do not see why we should limit things to single-line strings.
>
> Quotes are not stripped:
>
> (org-babel-read "\"abc\nsdf\"" t)
> "\"abc
> sdf\""

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

> (org-babel-read "(\n\"abc\"\n" t)
>
> progn: End of file during parsing

I cannot reproduce. Still, I added a prophylactic measure to recover
from parsing errors.

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



Re: [Q/Bug?] Comment for noweb reference comments content

2024-05-04 Thread Ihor Radchenko
João Pedro  writes:

> #+begin_src emacs-lisp :noweb yes :comments noweb :tangle /tmp/foo.el
> (progn
>   <>)
> #+end_src
>
> #+name: foo
> #+begin_src emacs-lisp
> (message "foo")
> #+end_src
> ...
> ;; [[file:...][No heading:1]]
> (progn
>   ;; [[file:...][foo]]
>   (message "foo")
>   ;; foo ends here)

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1523e21d8

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



Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

2024-05-04 Thread Max Nikulin

On 04/05/2024 15:03, Ihor Radchenko wrote:

Max Nikulin writes:

I have no idea if "other\n\"string\"\nlines" may be passed
`org-babel-read', but it is not discarded by the current regexp:

"^[[:space:]]*\"\\(.*\\)\"[[:space:]]*$"


I do not see why we should limit things to single-line strings.


Quotes are not stripped:

(org-babel-read "\"abc\nsdf\"" t)
"\"abc
sdf\""

(org-babel-read "(\n\"abc\"\n" t)

progn: End of file during parsing

My conclusion that the current regexp may give both false positives and 
false negatives. `read` errors are not handled, but likely it is a 
result of wrong guarding regexp.



1. read is faster


I would not argue since I have no benchmark. My expectation was that 
replace is mostly no-op, so original string is returned while using 
`read' requires some overhead for a temporary buffer.



2. read is less maintenance - we can rely upon robust implementation
provided by Emacs itself instead of doing something custom, with
potential bugs.






Re: org-agenda: setting face to an item by its tag/category/property

2024-05-04 Thread Ihor Radchenko
Ilya Chernyshov  writes:

> Is there a custom variable in org-agenda that allows to set a specific
> face (or just foreground/background) for items with specific
> property/tag/category?

No.



Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

2024-05-04 Thread Ihor Radchenko
Max Nikulin  writes:

>>> (org-babel-read "\"1\" 2 \"3\"" t)
>>> "1\\"
>> 
>> Fixed, on main.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2028bb15c
>
> I have no idea if "other\n\"string\"\nlines" may be passed 
> `org-babel-read', but it is not discarded by the current regexp:
>
> "^[[:space:]]*\"\\(.*\\)\"[[:space:]]*$"

I do not see why we should limit things to single-line strings.

> Is there a reason why it is necessary to call `read' twice on the same 
> content? From my point of view, result of first call may be returned.

Yes, it can. 

> Does `read' have other role than unescaping backslash-protected 
> characters? Likely it can be done by `replace-regexp-in-string', see the 
> attachment. ...

> +(defconst org-babel--quoted-string-regexp
> ...

1. read is faster
2. read is less maintenance - we can rely upon robust implementation
   provided by Emacs itself instead of doing something custom, with
   potential bugs.

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



Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

2024-05-04 Thread Max Nikulin

On 03/05/2024 19:06, Ihor Radchenko wrote:

Max Nikulin writes:


What I do not like in `org-babel-read' is false positive for escaped
quote when actually backslash is escaped:

(org-babel-read "\"1\" 2 \"3\"" t)
"1\\"


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


I have no idea if "other\n\"string\"\nlines" may be passed 
`org-babel-read', but it is not discarded by the current regexp:


"^[[:space:]]*\"\\(.*\\)\"[[:space:]]*$"

Is there a reason why it is necessary to call `read' twice on the same 
content? From my point of view, result of first call may be returned.


Does `read' have other role than unescaping backslash-protected 
characters? Likely it can be done by `replace-regexp-in-string', see the 
attachment. I have tried regexp on the following string:


   (let ((cases '(("" . nil)
   ("\"" . nil)
   ("\"\"" . t)
   ("\"\\\"" . nil)
   ("\"\"" . t)
   ("a" . nil)
   ("\"a\"" . t)
   ("\\\"a\\\"" . nil)
   ("\\\"a\"" . nil)
   ("\"a\\\"\"" . t)
   ("\"aa\\\"bb\"" . t)
   (" \"aa( bb\"" . tdiff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 470db9fe6..a44d27cba 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -3346,6 +3346,26 @@ (defun org-babel-script-escape (str  force)
 	  (t str
 (condition-case nil (org-babel-read escaped) (error escaped
 
+(defconst org-babel--quoted-string-regexp
+  (rx string-start
+  (zero-or-more (or space ?\n))
+  ?\"
+  (group
+   (zero-or-more
+;; Anything besides double quotes ended not with backslash.
+(zero-or-one (zero-or-more (not ?\"))
+		 (not (or ?\" ?\\)))
+;; Skip backslashes escaping themselves.
+	(zero-or-more "")
+;; Escaped quotes are allowed.
+	(zero-or-one "\\\"")))
+  ?\"
+  (zero-or-more (or space ?\n))
+  string-end)
+  "Regexp matching single string in double quotes.
+Group 1 is text inside quotes. String may be optionally padded with
+spaces. Backslashes quote other characters.")
+
 (defun org-babel-read (cell  inhibit-lisp-eval)
   "Convert the string value of CELL to a number if appropriate.
 Otherwise if CELL looks like Lisp (meaning it starts with a
@@ -3361,15 +3381,11 @@ (defun org-babel-read (cell  inhibit-lisp-eval)
  ;; FIXME: Arbitrary code evaluation.
 	 (eval (read cell) t))
 	((save-match-data
-   (and (string-match "^[[:space:]]*\"\\(.*\\)\"[[:space:]]*$" cell)
-;; CELL is a single string
-(with-temp-buffer
-  (insert cell)
-  (goto-char 1)
-  (read (current-buffer))
-  (skip-chars-forward "[:space:]")
-  (eobp
- (read cell))
+   (and (string-match org-babel--quoted-string-regexp cell)
+;; Unquote characters escaped by backslashes similar to `read'.
+(replace-regexp-in-string
+ "\\(?:\\(.\\)\\|\n\\)" "\\1"
+		 (match-string 1 cell) 'fixedcase nil
 	(t (org-no-properties cell
 
 (defun org-babel--string-to-number (string)


Re: [BUG] Attachments not resolved correctly from symlinked Org files

2024-05-04 Thread Ihor Radchenko
Karthik Chikmagalur  writes:

>> I can see the problem.
>> But what would you expect to happen if there was no attachment in the
>> original directory? Should the attachment be created relative to the
>> original file? To the symlink?
>
> I don't know.  I would expect the attachment to always be created
> relative to the original file, but other users might have the opposite
> expectation.

What about the approach we already use in
`org-attach-id-to-path-function-list' - check if an attachment directory
already exists, generated using any rule, and only if not, create a new?

Similarly, in `org-attach-dir', we can first check local attachment
directory and return it if it exists. Then, we check attachment
directory for the symlink source, and return it when it exists.
If none exists, create attachment locally or relative to the symlink
source, according to some customization. The default will be creating
locally, to follow the existing behavior.

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



Re: [PATCH] Add support for shortdoc link type

2024-05-04 Thread Max Nikulin

On 04/05/2024 04:41, Bruno Cardoso wrote:

On 2024-05-02, 17:41 +0700, Max Nikulin wrote:




[...]

I implemented the search option by borrowing the regexp from `ol-info':


It is necessary to maintain backward compatibility for `ol-info'. I do 
not know what kind of separator was added earlier: "::" or "#". I 
suppose, for new link type, rules more close to file: links may be used, see

(info "(org) Search Options")
https://orgmode.org/manual/Search-Options.html

That is why I suggested shortdoc:GROUP::#FUNCTION. This way 
shrotdoc:GROUP::SEARCH_STRING is possible as well.



   (shortdoc-display-group group)
   (when fn
 (re-search-forward (concat "^(" (string-remove-prefix "#" fn))
nil t)


Notice that `shortdoc-display-group' has optional FUNCTION argument.


 (beginning-of-line)))
   (error (message "Unknown shortdoc group: %s" group)

It works, but I'm not quite sure if this is the best approach.


I do not have strong opinion as well. Some points to consider:
- Unambiguous parsing of link target.
- Flexibility it respect to later improvements.




[PATCH] copy cell contents to kill-ring. WAS [FR]: thing-at-point 'org-table-cell

2024-05-04 Thread Pedro Andres Aranda Gutierrez
Hi,

I needed this function to copy contents from an org spreadsheet to a Web
page and I see it may be useful to others. Take a look and if you find it
useful, I'll add the changelog stuff.

Thanks for the guidance ;-)
Best, /PA

On Fri, 3 May 2024 at 21:50, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> >>> It would be great to have a thing-at-point handler that returns a cell
> in
> >>> and org table. The most simple use case is to have a table in an
> org-file
> >>> with data that you need to transfer to an online Web page. Being able
> to
> >>> (copy-as-kill ...) a cell's contents could speed up the whole
> process...
> >>
> >> May you please elaborate on how exactly `thing-at-point' will help
> copy-as-kill?
> > 
> > Hi Ihor, of course this was just an example. The thing-at-point would
> make it easier to write a copy-as-kill-cell function.
>
> Then, you can just use `org-element-context' and/or `org-element-at-point'.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
From 545f6e26ba4fa29fedbb38ccc26e6018774ae63e Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Sat, 4 May 2024 09:09:43 +0200
Subject: [PATCH] org-table: add copy cell contents to kill ring

---
 etc/ORG-NEWS  |  6 ++
 lisp/org-table.el | 22 ++
 2 files changed, 28 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 99dd8839c..b4cacb2ce 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1520,6 +1520,12 @@ optional argument =NEW-HEADING-CONTAINER= specifies where in the
 buffer it will be added.  If not specified, new headings are created
 at level 1 at the end of the accessible part of the buffer, as before.
 
+*** New interactive function ~org-table-copy-cell-as-kill~
+
+This function copies the contents of a table cell to the kill-ring as
+a string without properties. Prints the contents copied to the
+kill-ring if called with an argument.
+
 ** Miscellaneous
 *** =org-crypt.el= now applies initial visibility settings to decrypted entries
 
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 0c2dc27ed..f02ea9243 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -6425,6 +6425,28 @@ This function is generated by a call to the macro `org-define-lookup-function'."
 (org-define-lookup-function last)
 (org-define-lookup-function all)
 
+;;;###autoload
+(defun org-table-copy-cell-as-kill (verbose)
+  "Copy the contents of the current cell to the kill buffer.
+Print a message when verbose is not nil.
+
+hlines are not considered table cells"
+  (interactive "P")
+  ;; Check we are in a table cell that is not an hline
+  (unless (and (org-at-table-p)
+   (not (org-at-table-hline-p)))
+(error "Not on a table cell"))
+  ;; if so, get the cell contents
+  (let ((content (org-table-get nil nil)))
+(unless (and content
+ (length> content 0))
+  (error "Empty cell"))
+;; This is a non-empty cell, extract the string
+(let ((cell-val (substring-no-properties content)))
+  (when verbose
+(message "Copied `%s'" cell-val))
+  (kill-new cell-val
+
 (provide 'org-table)
 
 ;; Local variables:
-- 
2.34.1



Re: PATCH] Auto-complete PRINT_BIBLIOGRAPHY with a trailing colon

2024-05-04 Thread Ihor Radchenko
Pedro Andres Aranda Gutierrez  writes:

>> * lisp/org.el (org-options-keywords): Add a trailing colon to the
>> 'PRINT_BIBLIOGRAPHY' keyword to avoid unnecessary user confusion.
>
> Hi Rudolf,
>
> I don't see any confusion by not having a trailing colon in
> #+print_bibliography. Where would there be? (I'm asking, because I'm
> tutoring a couple novel users and it would be good to have an answer ready
> if they ask ;-) )

It is very simple. The patch simply removed inconsistency in completion.
Here is the previous value of `org-options-keywords':

("ARCHIVE:" "AUTHOR:" "BIBLIOGRAPHY:" "BIND:" "CATEGORY:"
 "CITE_EXPORT:" "COLUMNS:" "CREATOR:" "DATE:" "DESCRIPTION:"
 "DRAWERS:" "EMAIL:" "EXCLUDE_TAGS:" "FILETAGS:" "INCLUDE:" "INDEX:"
 "KEYWORDS:" "LANGUAGE:" "MACRO:" "OPTIONS:" "PROPERTY:"
 "PRINT_BIBLIOGRAPHY" "PRIORITIES:" "SELECT_TAGS:" "SEQ_TODO:"
 "SETUPFILE:" "STARTUP:" "TAGS:" "TITLE:" "TODO:" "TYP_TODO:"
 "SELECT_TAGS:" "EXCLUDE_TAGS:" "EXPORT_FILE_NAME:")

See how only PRINT_BIBLIOGRAPHY does not have a trailing
colon. Everything else will be completed with colon.
So, users who are accustomed to the completion adding colons can be
surprised when for PRINT_BIBLIOGRAPHY in particular the colon is not
added.

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