Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

2024-04-29 Thread Jim Porter

On 4/29/2024 11:14 AM, Ihor Radchenko wrote:

Thanks!
I have a small comment on the docstring of
`forward-thing-provider-alist' - it refers to
`thing-at-point-provider-alist', but the provides here are called with
an argument N, unlike the providers in `thing-at-point-provider-alist'.


Fixed.

I've also added some helper functions for 'forward-thing' and 
'bounds-of-thing-at-point' when the "thing" is defined by a text 
property, and then used those helper functions for EWW and 
bug-reference-mode.


I've lightly tested this (and added a few automated regression tests), 
but there could be some bugs lurking in here...From ad8db930907cd760142fd6f035d97ce93ce8d850 Mon Sep 17 00:00:00 2001
From: Jim Porter 
Date: Sun, 28 Apr 2024 21:19:53 -0700
Subject: [PATCH] Allow defining custom providers for more "thingatpt"
 functions

* lisp/thingatpt.el (forward-thing-provider-alist)
(bounds-of-thing-at-point-provider-alist): New variables...
(forward-thing, bounds-of-thing-at-point): ... use them.
(text-property-search-forward, text-property-search-backward)
(prop-match-beginning, prop-match-end): Declare.
(forward-thing-for-text-property)
(bounds-of-thing-at-point-for-text-property): New functions.

* lisp/net/eww.el (eww--bounds-of-url-at-point, eww--forward-url): New
functions...
(eww-mode): ... use them.

* lisp/progmodes/bug-reference.el
(bug-reference--bounds-of-url-at-point, bug-reference--forward-url): New
functions...
(bug-reference--init): ... use them.

* test/lisp/thingatpt-tests.el (thing-at-point-providers)
(forward-thing-providers, bounds-of-thing-at-point-providers): New
tests.

* etc/NEWS: Announce this change.
---
 etc/NEWS| 21 +++---
 lisp/net/eww.el | 14 +++
 lisp/progmodes/bug-reference.el | 22 +-
 lisp/thingatpt.el   | 71 ++---
 test/lisp/thingatpt-tests.el| 36 +
 5 files changed, 153 insertions(+), 11 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 7efb4110bcd..394f75884c1 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1591,19 +1591,30 @@ of the currently existing keyboards macros using the 
new mode
 duplicating them, deleting them, and editing their counters, formats,
 and keys.
 
-** Miscellaneous
+** thingatpt.el
 
 ---
-*** Webjump now assumes URIs are HTTPS instead of HTTP.
-For links in 'webjump-sites' without an explicit URI scheme, it was
-previously assumed that they should be prefixed with "http://;.  Such
-URIs are now prefixed with "https://; instead.
+*** New variables and functions for providing custom thingatpt implementations.
+The new variables 'bounds-of-thing-at-point-provider-alist' and
+'forward-thing-provider-alist' now allow defining custom implementations
+of 'bounds-of-thing-at-point' and 'forward-thing', respectively.  In
+addition, "things" defined by a text property can use the new functions
+'bounds-of-thing-at-point-for-text-property' and
+'forward-thing-for-text-property' to help implement these providers.
 
 ---
 *** 'bug-reference-mode' now supports 'thing-at-point'.
 Now, calling '(thing-at-point 'url)' when point is on a bug reference
 will return the URL for that bug.
 
+** Miscellaneous
+
+---
+*** Webjump now assumes URIs are HTTPS instead of HTTP.
+For links in 'webjump-sites' without an explicit URI scheme, it was
+previously assumed that they should be prefixed with "http://;.  Such
+URIs are now prefixed with "https://; instead.
+
 +++
 *** New user option 'rcirc-log-time-format'
 This allows for rcirc logs to use a custom timestamp format, than the
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index 39ea964d47a..adabd8d8d8b 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -1321,6 +1321,12 @@ eww-mode
   (setq-local thing-at-point-provider-alist
   (append thing-at-point-provider-alist
   '((url . eww--url-at-point
+  (setq-local bounds-of-thing-at-point-provider-alist
+  (append bounds-of-thing-at-point-provider-alist
+  '((url . eww--bounds-of-url-at-point
+  (setq-local forward-thing-provider-alist
+  (append forward-thing-provider-alist
+  '((url . eww--forward-url
   (setq-local bookmark-make-record-function #'eww-bookmark-make-record)
   (buffer-disable-undo)
   (setq-local shr-url-transformer #'eww--transform-url)
@@ -1351,6 +1357,14 @@ eww--url-at-point
   "`thing-at-point' provider function."
   (get-text-property (point) 'shr-url))
 
+(defun eww--bounds-of-url-at-point ()
+  "`bounds-of-thing-at-point' provider function."
+  (bounds-of-thing-at-point-for-text-property 'shr-url))
+
+(defun eww--forward-url (n)
+  "`forward-thing' provider function."
+  (forward-thing-for-text-property 'shr-url n))
+
 ;;;###autoload
 (defun eww-browse-url (url  new-window)
   "Ask the EWW browser to load URL.
diff --git a/lisp/progmodes/bug-reference.el b/lisp/progmodes/bug-reference.el
index 977a3d72cb7..bfc22fb10d2 100644
--- 

Re: link can not be created in a line with another link.

2024-04-29 Thread Alexandros Prekates
On Mon, 29 Apr 2024 13:19:15 +
Ihor Radchenko  wrote:

> For you workflow, it may be more convenient to set
> `org-link-descriptive' to nil. Then, Org mode will not hide the path
> part of the links and you can edit the plain text as you wish without
> being distracted by Org mode trying to detect the markup as you type.
> 

If you mean :‘org-toggle-link-display’ or (setq org-descriptive-links
nil) that can indeed help to instert many links in the same line will
less headache . Thanks.

Alexandros



Re: [PATCH] ob-lua: Support all types and multiple values in results

2024-04-29 Thread Rudolf Adamkovič
Rudolf Adamkovič  writes:

> Definitely!  I am on it.

All right, how about the attached patch?

Rudy

>From 40270bc62f951cfd20916c17e2dfc52863d6b8e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Mon, 29 Apr 2024 21:42:04 +0200
Subject: [PATCH] ob-lua: Quote list-like strings, sort tables, and parse bare
 returns

* lisp/ob-lua.el (org-babel-lua-multiple-values-separator): Change the
default value from ", " to "|" to avoid '\\,' appearing in strings.
(org-babel-lua-wrapper-method): Improve 3 aspects: (1) Quote strings
with list-like content to prevent Org Babel from incorrectly guessing
their type, (2) sort pretty-printed non-sequential tables to make them
reproducible, and (3) handle implicit nils produced by 'return' used
with no arguments.
* testing/lisp/test-ob-lua.el (test-ob-lua/result/nil):
(test-ob-lua/result/nil/explicit):
(test-ob-lua/result/boolean):
(test-ob-lua/results/number/integer):
(test-ob-lua/results/number/integer/negative):
(test-ob-lua/results/number/integer/multiple):
(test-ob-lua/results/number/real):
(test-ob-lua/results/number/real/multiple):
(test-ob-lua/results/number/infinity):
(test-ob-lua/results/string/single-quotes):
(test-ob-lua/results/string/double-quotes):
(test-ob-lua/results/string/multiple):
(test-ob-lua/results/string/list-like):
(test-ob-lua/results/string/list-like/brackets):
(test-ob-lua/results/string/list-like/curlies):
(test-ob-lua/result/table):
(test-ob-lua/result/table/pretty-print):
(test-ob-lua/result/table/pretty-print/sorted):
(test-ob-lua/results/value-separator): New tests.
---
 lisp/ob-lua.el  |  41 --
 testing/lisp/test-ob-lua.el | 264 
 2 files changed, 266 insertions(+), 39 deletions(-)

diff --git a/lisp/ob-lua.el b/lisp/ob-lua.el
index 041abfabc..5a0fdb18b 100644
--- a/lisp/ob-lua.el
+++ b/lisp/ob-lua.el
@@ -81,7 +81,7 @@ This will typically be `lua-mode'."
   :package-version '(Org . "8.3")
   :type 'symbol)
 
-(defcustom org-babel-lua-multiple-values-separator ", "
+(defcustom org-babel-lua-multiple-values-separator "|"
   "Separate multiple values with this string."
   :group 'org-babel
   :package-version '(Org . "9.7")
@@ -261,26 +261,33 @@ function dump(it, indent)
if indent == nil then
   indent = ''
end
+
if type(it) == 'table' and %s then
-  local count = 0
-  for _ in pairs(it) do
- count = count + 1
-  end
   local result = ''
+
   if #indent ~= 0 then
  result = result .. '\\n'
   end
-  for key, value in pairs(it) do
+
+  local keys = {}
+  for key in pairs(it) do
+table.insert(keys, key)
+  end
+
+  table.sort(keys)
+
+  for index, key in pairs(keys) do
+ local value = it[key]
  result = result
 .. indent
 .. dump(key)
 .. ' = '
 .. dump(value, indent .. '  ')
- count = count - 1
- if count ~= 0 then
+ if index ~= #keys then
 result = result .. '\\n'
  end
   end
+
   return result
else
   return tostring(it)
@@ -288,11 +295,27 @@ function dump(it, indent)
 end
 
 function combine(...)
+  local quotes = '\"'
   local result = {}
+
   for index = 1, select('#', ...) do
 result[index] = dump(select(index, ...))
   end
-  return table.concat(result, '%s')
+
+  if #result == 0 then
+return dump(nil)
+  end
+
+  if #result == 1 then
+local value = result[1]
+if string.find(value, '[%%(%%[{]') == 1 then
+  return quotes .. value .. quotes
+else
+  return value
+end
+  end
+
+  return quotes .. table.concat(result, '%s') .. quotes
 end
 
 output = io.open('%s', 'w')
diff --git a/testing/lisp/test-ob-lua.el b/testing/lisp/test-ob-lua.el
index 0a60c68ca..775a5cf14 100644
--- a/testing/lisp/test-ob-lua.el
+++ b/testing/lisp/test-ob-lua.el
@@ -136,45 +136,249 @@ return x
 	(org-babel-next-src-block)
 	(org-babel-execute-src-block)
 
-(ert-deftest test-ob-lua/types ()
-  "Test returning different types."
+(ert-deftest test-ob-lua/result/nil ()
+  "Test returning nothing."
   (should
-   (equal "nil"
-  (org-test-with-temp-text "src_lua{return nil}"
-(org-babel-execute-src-block
+   (equal
+"src_lua{return} {{{results(=nil=)}}}"
+(org-test-with-temp-text "src_lua{return}"
+  (org-babel-execute-src-block)
+  (buffer-substring-no-properties (point-min)
+  (point-max))
+
+(ert-deftest test-ob-lua/result/nil/explicit ()
+  "Test returning nothing explicitly."
+  (should
+   (equal
+"src_lua{return nil} {{{results(=nil=)}}}"
+(org-test-with-temp-text "src_lua{return nil}"
+  (org-babel-execute-src-block)
+  (buffer-substring-no-properties (point-min)
+  (point-max))
+
+(ert-deftest test-ob-lua/result/boolean ()
+  "Test returning the boolean values true and false."
+  (should
+   

Re: [BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]

2024-04-29 Thread Ihor Radchenko
Björn Bidar  writes:

> On another related note are `org-add-note` also follow the same pattern as
> e.g. `org-src`? Maybe it should have something like `org-note-window-setup`
> similar to `org-src-window-setup`?

Now, it should respect display-buffer-alist.

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



Re: [BUG] Org-Agenda leaves frame around [9.7-pre (release_9.6.8-785-g72bbf8.dirty @ /home/bidar/.local/private/etc/emacs/lib/org/lisp/)]

2024-04-29 Thread Björn Bidar
Ihor Radchenko  writes:

> Björn Bidar  writes:
>
 E.g.:
 1. I capture a link using org-protocol
 2. Switch to the org-buffer
 3. C-c C-l
 4. RET  <- frame closes however links isn't inserted into the target 
 org-buffer 
>>>
>>> May you provide more details about how to reproduce?
>>
>> What do you miss after the initial details?
>

> In other words, I need detailed steps starting from emacs -Q, if possible.

Never mind the issue was caused by my own setup. I had a hook killing
the frame spawned by org-store-link which cause a race condition.

On another related note are `org-add-note` also follow the same pattern as
e.g. `org-src`? Maybe it should have something like `org-note-window-setup`
similar to `org-src-window-setup`?




Re: [PATCH] lisp/org.el: Obsolete `org-cached-entry-get' in favor of `org-entry-get'

2024-04-29 Thread Morgan Smith
Ihor Radchenko  writes:

>
>
> This function should yield speedups when matching special properties
> like "CLOCKSUM", "CLOCKSUM_T", "TIMESTAMP", or "TIMESTAMP_IA".
>
> For example, when the requested match tests these properties multiple
> times.
>
> We need a real-life justification, not a theoretical one.
>
> Canceled.

I agree with all your points and I'm sorry for sending noise.  However, I think
I actually found a real-life justification.

It turns out that by replacing `org-cached-entry-get' with
`org-entry-get' the performance of my `org-clock-sum' calls got much
better for my specific use case.  Due to benchmarking with my local
changes in place (sorry), I accidentally attributed this performance
increase to byte-compiling the return of `org-make-tags-matcher'.

These numbers are also with my `org-clock-sum' rewrite patch applied.
They are in a 3M file of almost exclusivly clocking data.  The filters I
use are "CATEGORY={blah}" for one clock table and "-ignore-ITEM={foo}"
for 9 others.  

org-cached-entry-get
1st run: 26.868990287
2nd run: 16.043983143

org-entry-get
1st run: 18.209056578
2nd run: 5.003186764



Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

2024-04-29 Thread Ihor Radchenko
Jim Porter  writes:

> Ihor, Eli: What do you think of the attached patch? I added variables to 
> let modes define custom providers for 'bounds-of-thing-at-point' and 
> 'forward-thing'. (Notably, I avoided adding vars for the 
> 'beginning-of-thing' and 'end-of-thing' functions, since those just call 
> 'bounds-of-thing-at-point' anyway.)
>
> If this looks like a reasonable way to go, I'll continue work on this 
> patch by adding entries to 'bounds-of-thing-at-point-provider-alist' and 
> 'forward-thing-provider-alist' in the appropriate places (i.e. wherever 
> we already add to 'thing-at-point-provider-alist', like in EWW).

Thanks!
I have a small comment on the docstring of
`forward-thing-provider-alist' - it refers to
`thing-at-point-provider-alist', but the provides here are called with
an argument N, unlike the providers in `thing-at-point-provider-alist'.

-- 
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-04-29 Thread Ihor Radchenko
João Pedro  writes:

> Is there a way to set =src= and =example= switches (as documented in
> "(org) Literal Examples"[0]) file- or heading-wide?

There is currently no way to do it.

> Ideally, I would be able to set those as a file properties like that, or
> per heading under the =:PROPERTIES:= drawer.

Yes. This is the plan.

Citing earlier syntax discussion in
https://list.orgmode.org/orgmode/877d08bkze.fsf@localhost/

> Can we drop switch support? This seems like a fairly good idea. The 
functionality can simply be shifted to
> ARGUMENTS with the well-established :key val forms.
> “For the love of all that is sane” — Tom G

-- 
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.el: Obsolete `org-cached-entry-get' in favor of `org-entry-get'

2024-04-29 Thread Ihor Radchenko
Morgan Smith  writes:

> * lisp/org.el (org-cached-entry-get): Rewrite in terms
> `org-entry-get'.  Obsolete in favor of `org-entry-get'.
> (org-make-tags-matcher): Replace uses of `org-cached-entry-get' with
> `org-entry-get'.
> ---
> Hello!
>
> All tests pass.
>
> All of the logic here already exists in `org-entry-get'.
>
> This function is mentioned in very few commits unlike its more popular 
> sibling.

This function should yield speedups when matching special properties
like "CLOCKSUM", "CLOCKSUM_T", "TIMESTAMP", or "TIMESTAMP_IA".

For example, when the requested match tests these properties multiple
times.

> I don't think we can justify the existence of this function but let me know if
> I'm wrong.
>
> The caching mechanism used here is likely to cause hard to diagnose issues.

If you encountered such issue, please let me know.
Otherwise, I do not see any reason to remove `org-cached-entry-get'.

We need a real-life justification, not a theoretical one.

Canceled.

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



[PATCH] org-ctags.el: Do not activate on load

2024-04-29 Thread Max Nikulin

On 29/04/2024 20:12, Ihor Radchenko wrote:

Max Nikulin writes:


Notice that new tests for org-ctags do not require user interactions.

[...]

Of course, the cause is the known side effect of loading org-ctags.

Maybe we can disable the tests until that bug is fixed.
Or, ideally, load org-ctags only when the relevant tests are running and
unload it after they finish.


Isn't it better to modify buggy org-ctags than to add various kludges to 
tests?
From 0d260a0f260afb0f407d00b6a53ed2121a240203 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Mon, 29 Apr 2024 21:34:13 +0700
Subject: [PATCH 1/2] org-ctags.el: Define unload function
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-ctags.el (org-ctags-unload-function): New function to cleanup
during `unload-feature' call.
(org-ctags--open-link-functions-list org-ctags-open-link-functions):
Define and use list of options available for `org-open-link-functions'.
(org-ctags--visit-tags-table): Give a name to remove the function from
`org-mode-hook' on library unload.

Prevent the following error after library unloading

Symbol’s function definition is void: org-ctags-find-tag
---
 lisp/org-ctags.el | 60 +++
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el
index 6431a2765..c6f7fc708 100644
--- a/lisp/org-ctags.el
+++ b/lisp/org-ctags.el
@@ -161,6 +161,20 @@ (defcustom org-ctags-path-to-ctags
   :version "24.1"
   :type 'file)
 
+(defconst org-ctags--open-link-functions-list
+  (list
+   #'org-ctags-find-tag
+   #'org-ctags-ask-rebuild-tags-file-then-find-tag
+   #'org-ctags-rebuild-tags-file-then-find-tag
+   #'org-ctags-ask-append-topic
+   #'org-ctags-append-topic
+   #'org-ctags-ask-visit-buffer-or-file
+   #'org-ctags-visit-buffer-or-file
+   #'org-ctags-fail-silently)
+  "Options for `org-open-link-functions'.
+Ensure that the user option and `unload-feature'
+use the same set of functions.")
+
 (defcustom org-ctags-open-link-functions
   '(org-ctags-find-tag
 org-ctags-ask-rebuild-tags-file-then-find-tag
@@ -168,14 +182,7 @@ (defcustom org-ctags-open-link-functions
   "List of functions to be prepended to ORG-OPEN-LINK-FUNCTIONS by ORG-CTAGS."
   :version "24.1"
   :type 'hook
-  :options '(org-ctags-find-tag
- org-ctags-ask-rebuild-tags-file-then-find-tag
- org-ctags-rebuild-tags-file-then-find-tag
- org-ctags-ask-append-topic
- org-ctags-append-topic
- org-ctags-ask-visit-buffer-or-file
- org-ctags-visit-buffer-or-file
- org-ctags-fail-silently))
+  :options org-ctags--open-link-functions-list)
 
 
 (defvar org-ctags-tag-list nil
@@ -191,18 +198,20 @@ (defcustom org-ctags-new-topic-template
   :type 'string)
 
 
-(add-hook 'org-mode-hook
-  (lambda ()
-(when (and org-ctags-enabled-p
-   (buffer-file-name))
-  ;; Make sure this file's directory is added to default
-  ;; directories in which to search for tags.
-  (let ((tags-filename
- (expand-file-name
-  (concat (file-name-directory (buffer-file-name))
-  "/TAGS"
-(when (file-exists-p tags-filename)
-  (visit-tags-table tags-filename))
+(defun org-ctags--visit-tags-table ()
+  "Load tags for current file.
+A function for `org-mode-hook."
+  (when (and org-ctags-enabled-p
+ (buffer-file-name))
+;; Make sure this file's directory is added to default
+;; directories in which to search for tags.
+(let ((tags-filename
+   (expand-file-name
+(concat (file-name-directory (buffer-file-name))
+"/TAGS"
+  (when (file-exists-p tags-filename)
+(visit-tags-table tags-filename)
+(add-hook 'org-mode-hook #'org-ctags--visit-tags-table)
 
 
 (advice-add 'visit-tags-table :after #'org--ctags-load-tag-list)
@@ -219,6 +228,17 @@ (defun org-ctags-enable ()
 (add-hook 'org-open-link-functions fn t)))
 
 
+(defun org-ctags-unload-function ()
+  "Disable `org-ctags' library.
+Called by `unload-feature'."
+  (put 'org-mode 'find-tag-default-function nil)
+  (advice-remove 'visit-tags-table #'org--ctags-load-tag-list)
+  (advice-remove 'xref-find-definitions
+ #'org--ctags-set-org-mark-before-finding-tag)
+  (dolist (fn org-ctags--open-link-functions-list)
+(remove-hook 'org-open-link-functions fn nil)))
+
+
 ;;; General utility functions.  ===
 ;; These work outside org-ctags mode.
 
-- 
2.39.2

From 5915811995f83fbfb89606bfa4f316d2b4521268 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Mon, 29 Apr 2024 23:28:29 +0700
Subject: [PATCH 2/2] org-ctags.el: Do not activate on load

* etc/ORG-NEWS: Announce the change breaking for `org-ctags' users and
provide 

Re: [PATCH] org-make-tags-matcher: Compile returned function

2024-04-29 Thread Ihor Radchenko
Morgan Smith  writes:

> This should result in a nice performance boost when the function is
> called repeatedly (as is often done).
>
> * lisp/org.el (org-make-tags-matcher): Evaluate returned function to
> compile it into a closure.
> ...
> I don't have any rigorous benchmarks but this does make things significantly
> faster.  This actually seems to have a bigger performance impact on
> `org-clock-sum' then my rewrite of `org-clock-sum' I submitted earlier does.
> Which is a little frustrating honestly.
>
> It does involve using the `eval' function which I know is a little taboo.
> Although in this case I don't believe it actually adds any danger.

I am able to reproduce a noticeable ~10% speedup.
Even better approach is byte-compiling the result. It yields ~20%
speedup.

I applied an alternative patch that byte-compiles the returned function.

Handled, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3e11b2eb8

-- 
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

2024-04-29 Thread João Pedro
Em segunda, 29/04/2024 às 09:43 (+02), Mehmet Tekman  
escreveu:

> The development is happening chaotically on my own repo
> (gitlab.com/mtekman/org-mode) across several incomplete branches.
>
> I've actually been working on it on and off for the last two weeks, but
> I've been facing some rebasing issues that I need to tackle first before
> I actually push anything to a branch that anyone can work on.
>
> Can you wait until Sunday for me to resolve this, and then we can
> discuss?

Yeah, of course!

Cheers,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)


Re: [PATCH] ob-lua: Support all types and multiple values in results

2024-04-29 Thread Rudolf Adamkovič
Ihor Radchenko  writes:

>> We need *better tests*, otherwise all this is kind of useless.
>>
>> I will hack on this some more...
>
> Will you be willing to provide some?

Definitely!  I am on it.

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
--- Thomas Alva Edison, 1932

Rudolf Adamkovič  [he/him]
Studenohorská 25, 84103 Bratislava, Slovakia, European Union



RE: help: org-mode menu presence mysteriously disappearing and reappearing when I navigate the document

2024-04-29 Thread Ihor Radchenko
"Cook, Malcolm"  writes:

> Indeed, I am delighted when polymode works in this fashion, as designed.   
> However, I am finding that the menu is changing when I navigate between org 
> headers, such as below when I hit a single down arrow to advance from "** 
> DONE publish help.md markdown as helptext in sidebar" to "** DONE remove 
> custom search builder".
> ...
> Thoughts?

Just that you may try to bisect the config.
https://github.com/Malabarba/elisp-bug-hunter can be helpful.

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



Re: [DISCUSSION] The meaning of :cmdline header argument across babel backends

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

> It is documented as
> " :cmdline  ... [arg_n]
>
> Use the :cmdline header arg to pass arguments to a shell command."
>
> However current implementation allows code injection through args, 
> including a trivial one
>
> #+header-arg: :results verbatim
> #+begin_src sh :cmdline 1 ; touch /tmp/not-an-arg
>printf '%s\n' "$@"
> #+end_src
>
> #+RESULTS:
> : 1
>
> "touch ..." *are not arguments of the script*. So users should be 
> careful to get documented behavior.

I do not see any way to address this concern without introducing feature
regression. So, let's keep things as they are and maybe document that
:cmdline ... is passed verbatim as shell command.

>> What might be done is introducing _two_ different header arguments - one
>> for interpreter switches, and another for script/program switches.
>> 
>> Say, :interpreter-cmdline and :script-cmdline.
>> Then, we can call the current :cmdline behaviour "dwim" and allow users
>> to be more explicit if necessary.
>
> It is too easy to confuse org-babel, so "dwim" works in simple cases 
> only. Independent header arguments make things more clear, I would 
> prefer :script-args. The question is whether they should be interpreted 
> by shell (flexibility and shooting feet) or more strict syntax `("hello 
> world" 1 a) should be used.

I like :script-args.
The counterpart should then be :interpreter-args?

The point of "dwim" is mostly to keep backwards-compatibility. We may
discourage :cmdline for non-trivial cases.

More strict syntax with '(   ...) is possible for the
new header arguments, not for the old :cmdline where the existing
backends may not be able to understand the list format.

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



Re: link can not be created in a line with another link.

2024-04-29 Thread Ihor Radchenko
Alexandros Prekates  writes:

> The same behavior happens with emacs -Q.
>
> Having <> and <> anchors somewhere in an org file
> in a line a have an internal link :
>
> bla [[foo]]
>
> If i add :
> [[boo]] bla [[foo]]  
> org will create the two links.
>
> But if i add:
> [[boo][  bla [[foo]]
> with the intention to type: [[boo][description]]  bla [[foo]]
> then what i will get is: a link to boo with description : bla [[foo

This is expected, as per Org mode's link syntax [[path][description]].

[[boo][  bla [[foo]]

is indeed a link with path "boo" and description spanning between [...]:
"  blah [[foo".

For you workflow, it may be more convenient to set
`org-link-descriptive' to nil. Then, Org mode will not hide the path
part of the links and you can edit the plain text as you wish without
being distracted by Org mode trying to detect the markup as you type.

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



Re: [PATCH] org-ctags.el: Protect shell specials in directory name

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

>> So, may you update the patch to make tests automated?
>
> Notice that new tests for org-ctags do not require user interactions. Try
>
>  make test BTEST_RE=test-org-ctags/

Sure, but that does not change the fact that make test is broken after
applying your patch.

Of course, the cause is the known side effect of loading org-ctags.

Maybe we can disable the tests until that bug is fixed.
Or, ideally, load org-ctags only when the relevant tests are running and
unload it after they finish.

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



Re: [BUG] oddity tangling src_blk with :var [9.7-pre (release_9.6.26-1368-g1ae978 @ /home/minshall/.emacs.d/straight/build/org/)]

2024-04-29 Thread Ihor Radchenko
Greg Minshall  writes:

>> This is because Org mode currently cannot distinguish between babel
>> backends that simply do not support variable assignments and babel
>> backends that are not loaded.
>
> currently, is it possible to see well enough what is going on to
> generate an error and abort the tangle?
>
> (off the top of my head i would think a `:var` in either of the
> situations you describe might be described as an error -- albeit a user
> error.)

Not necessarily.

Consider something like


#+property: header-args :var common_variable = "foo"

#+begin_src elisp
(message "variable is %S" common_variable)
#+end_src

#+RESULTS:
: variable is "foo"

#+begin_src python :result value
return f"variable is \"{common_variable}\""
#+end_src

#+RESULTS:
: variable is "foo"

Below, ob-dot does not implement variable assignments.
Throwing an error here would be unexpected.

#+begin_src dot :file foo.png
digraph G {
a -> b
}
#+end_src

#+RESULTS:
[[attachment:foo.png]]

We may, theoretically, only throw an error when the variable assignments
are not inherited, but that will create even more confusion - sometimes,
the error will be thrown, and sometimes not.

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



Re: link can not be created in a line with another link.

2024-04-29 Thread Alexandros Prekates
On Sun, 28 Apr 2024 12:40:44 +
Ihor Radchenko  wrote:

> Alexandros Prekates  writes:
> 
> > In  the example below i  underline to show that a link has been
> > created.
> >
> > Given that lines :
> >
> >  [[sysadmInstallSoftware a [[deb][deb package]]
> >  [[sysadmInstallSoftware adeb package 
> >   ---
> >  If i try to complete the left link with:
> >  [[sysadmInstallSoftware][Install]]
> > /\
> > |
> >  the moment i insert that left bracket i will
> > get: a [[deb][deb package
> >  
> >
> > If i try that into a line with no other links it will work ok.
> 
> Thanks for reporting, but I do not fully understand what you did.
> May you please explain step by step, starting from emacs -Q, what you
> did, what you saw, and what you expected to see?
> 
> Please list what exactly you input into the buffer, and which
> keys/commands you use.
> 

The same behavior happens with emacs -Q.

Having <> and <> anchors somewhere in an org file
in a line a have an internal link :

bla [[foo]]

If i add :
[[boo]] bla [[foo]]  
org will create the two links.

But if i add:
[[boo][  bla [[foo]]
with the intention to type: [[boo][description]]  bla [[foo]]
then what i will get is: a link to boo with description : bla [[foo

Alexandros .



Re: [BUG] ob-shell: internal representation of cmdline arguments the same

2024-04-29 Thread Ihor Radchenko
Matt  writes:

> #+begin_src bash :cmdline 1 2 3
> ...
> #+begin_src bash :cmdline "1 2 3" 
> ...
> It was stated that,
>
> #+begin_quote
> AFAICT, it's due to how headers are parsed by 
> 'org-babel-parse-header-arguments' using 'org-babel-read'. The cell "\"1 2 
> 3\"" (corresponding to :cmdline "1 2 3") is reduced through 'string-match' to 
> "1 2 3". The cell "1 2 3" (corresponding to :cmdline 1 2 3), on the other 
> hand, passes through. The result is that :cmdline "1 2 3" and :cmdline 1 2 3 
> become indistinguishable.
> #+end_quote

Yes, "1 2 3" and 1 2 3 are the same from the perspective of header arg
parser - on purpose.

The idea is to allow passing arbitrary Elisp objects are values

:header-argument #("fancy" 0 1 (invisible t))
:cmdline "string object"
:foo '(a b c)

To force quotes in the :cmdline one can do

#+begin_src bash :cmdline "\"1 2 3\"" 
echo "$1"
#+end_src

#+RESULTS:
: 1 2 3

Not a bug.
Canceled.

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



Re: [BUG] ob-shell: results missing leading quotes

2024-04-29 Thread Ihor Radchenko
Matt  writes:

> #+begin_src bash
> echo \"\"1\"\"
> #+end_src
>
> #+RESULTS:
> : 1""

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

The problem was auto-detection of table data - the algorithm used CSV
parser as a fallback and ""1"" is a very peculiar data from the point of
view of CSV spec.

I now changed the code to not try parsing CSV when a single-line data
does not contain commas.

The new behavior is

#+begin_src bash
echo \"\"1\"\"
#+end_src

#+RESULTS:
: 1

The nested "..." are stripped on purpose via `org-babel-string-read'.
Although this function dates back to R output processing and I do not
fully understand why stripping nested quotes is useful for all possible
babel backends. But that's a completely different story.

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



Re: [PATCH] org-ctags.el: Protect shell specials in directory name

2024-04-29 Thread Max Nikulin

On 29/04/2024 00:02, Ihor Radchenko wrote:

Max Nikulin writes:


Tests must be fully automated. We use make test in CI and things like
project-compile are non-interactive.


I do not mind. Requiring unexpected user interactions is a feature of
org-ctags.


So, may you update the patch to make tests automated?


Notice that new tests for org-ctags do not require user interactions. Try

make test BTEST_RE=test-org-ctags/




Re: [PATCH] updating org-plot.org on worg, was Re: Can we add PLOT to org-element-multiple-keywords?

2024-04-29 Thread Ihor Radchenko
Leo Butler  writes:

> From 4e262898feb349dad2f5b5afe8960c8e09723862 Mon Sep 17 00:00:00 2001
> From: Leo Butler 
> Date: Wed, 24 Apr 2024 12:57:58 -0500
> Subject: [PATCH] org-tutorials/org-plot.org: update documentation and examples

Thanks!
Applied, with minor amendments (I fixed Org repository link to point to
gnu website).
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=36a9f6f18

> Advice sought: The section, 3d grid plots, is tricky:
> example-{4,5,6}.png are not reprocible using the code in the file. I am
> not sure they can even be produced using org-plot and gnuplot as each
> exists now, without some drastic surgery. For example, to produce a
> facsimile of example-5.png, I need something like
>
> #+name: org-mode-figure.gnuplot
> #+header: :var table=org-plot-org-mode-table
> #+begin_src gnuplot :exports none :results none
> unset key
> set xrange [0:16]
> set yrange [0:13]
> plot table matrix with image title 'org mode'
> #+end_src
>
> where `org-plot-org-mode-table' is the un-named table that occurs after
> these figures. Of course, that does not exercise the features of
> org-plot that are intended.
>
> To produce something like example-{4,5}.png, I can do the following (set
> view 15,30 for example-4). But, this example seems like an excursion
> into gnuplot coding. And, again, I am not using "type:grid", despite the
> name of the section.

It indeed looks like we need to use "matrix" in the underlying scripts
and generally fix type:grid option.
CCing Timothy.

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



Re: [PATCH] Run latex more than once for LaTeX src block evaluation

2024-04-29 Thread Ihor Radchenko
Michael  writes:

>> ...
>> So, it makes sense for `org-babel-execute:latex' to override
>> `org-preview-latex-default-process' temporarily, to something 
>> actually
>> generating .png file.
>
> Sorry-- got sidetracked by something else. I see what you
> mean. OK, so the proposal is: change the ".png" branch in
> `org-babel-execute:latex' to override `org-preview-process-alist'
> with something that will:
>
>   - actually produce a PNG formatted file
>   - by default, run latex more than once, tho this could of
>   - course be customized

May you prepare a patch?

-- 
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

2024-04-29 Thread Mehmet Tekman


Hello!

João Pedro  writes:

> I'd like to ask if I could contribute to this. I have followed the
> discussion to a point, but would be more than happy to try and
> contribute to this so it gets merged for the next Org major version,

That's the plan, and I'll happily take any help I can get.

> It solves the major gripe I had with your original org-tangle-sync.el
> package, which is the ability to sync blocks that aren't whole files.

Yep, and the fix for that was really quite trivial. If I knew what I
know now about org source blocks, I would have rewritten that entire
library very differently.

> So, what still needs to be done and where is development happening (I
> assumed it was on the main Org-mode git repository, but I see no branch
> there)?

The development is happening chaotically on my own repo
(gitlab.com/mtekman/org-mode) across several incomplete branches.

I've actually been working on it on and off for the last two weeks, but
I've been facing some rebasing issues that I need to tackle first before
I actually push anything to a branch that anyone can work on.

Can you wait until Sunday for me to resolve this, and then we can
discuss?

Best,
Mehmet