[PATCH worg] Fix broken link

[Evgenii Klimov]

>From ed39640d75df231c8826191f2576fcfd6a5aa723 Mon Sep 17 00:00:00 2001
From: Evgenii Klimov 
Date: Sat, 15 Jul 2023 00:34:58 +0100
Subject: [PATCH] org-contrib/babel/languages/index.org: Fix broken link

---
 org-contrib/babel/languages/index.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/org-contrib/babel/languages/index.org b/org-contrib/babel/languages/index.org
index a72db778..0dc6f2f8 100644
--- a/org-contrib/babel/languages/index.org
+++ b/org-contrib/babel/languages/index.org
@@ -257,7 +257,7 @@ To fetch a copy of this file, please clone Worg:
 
 You should find =org-contrib/babel/ob-template.el=.
 
-Developers are encouraged to read the [[file:../../org-contribute.org][Org-mode contribution
+Developers are encouraged to read the [[file:../../../org-contribute.org][Org-mode contribution
 instructions]] in the hope that the language support can be added to the
 Org-mode core.
 
-- 
2.34.1

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Thomas S. Dye]

Evgenii Klimov  writes:


No Wayman  writes:

[...]
I, and others, have been surprised to find that the tangled 
file does
not have lexical binding enabled when :lexical blocks are 
tangled.


Am I correct that language-specific header arguments are not yet 
covered

in the manual?  I can't find any reference of "lexical" there.


Yes, I believe so.  Language-specific header arguments for many 
languages are documented at 
https://orgmode.org/worg/org-contrib/babel/languages/index.html. 
Several languages are not documented there; in these cases the 
documentation is typically in the source code.


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Evgenii Klimov]

No Wayman  writes:

[...]
> I, and others, have been surprised to find that the tangled file does
> not have lexical binding enabled when :lexical blocks are tangled.

Am I correct that language-specific header arguments are not yet covered
in the manual?  I can't find any reference of "lexical" there.

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[No Wayman]

From: Ihor Radchenko 
I am not sure if I like this approach.
I have 2 problems with the patch:



1. Previous users of :lexical header arg might be surprised.
   Though it is an OK breaking change since people who used 
   :lexical
   argument and expected it to be ignored in the tangled file 
   probably

   did something wrong.


Previous related discussion:

https://list.orgmode.org/87o89184h1@gmail.com/

I, and others, have been surprised to find that the tangled file 
does not have lexical binding enabled when :lexical blocks are 
tangled.

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

[Ihor Radchenko]

Jonathan Gregory  writes:

>> Looks like this on my side as well.
>
> Given the feedback, I went ahead and changed the lilypond.org 
> file:
>
> https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92

Thanks!
It would be even nicer if we allowed
https://packages.debian.org/buster/lilypond (2.19.81) or at least
https://packages.ubuntu.com/focal/lilypond (2.20.0).

I also checked what will happen with future versions, and it looks like
\version "2.24.1" actually means >=.

Fixed.

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

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> -#+begin_src org :exports none
> +#+begin_src lilypond :exports none
>
> That’s strange — what was the reason for using org as source before?

Could be just a typo.

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

[Dr. Arne Babenhauserheide]

Jonathan Gregory  writes:

> Given the feedback, I went ahead and changed the lilypond.org file:
>
> https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92

-#+begin_src org :exports none
+#+begin_src lilypond :exports none

That’s strange — what was the reason for using org as source before?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: Dates in headlines

[Max Nikulin]

On 03/02/2023 03:37, Ihor Radchenko wrote:

Max Nikulin writes:


May it happen that in some old Org version timestamps at the end of
headings were removed due by code intended to handle statistics cookie
[1/10]?


I do not see how.


A patch for `org-store-link' tests reminded me about this topic. The 
footnote on dates in heading title was added in response to


Links to datestamped headings broken? Thu, 24 Feb 2011 16:49:14 +1300
https://list.orgmode.org/86pqqi9jnp.wl%25sgu...@bayfield-high.school.nz/T/#u

3765304c8 2011-06-28 15:30:50 +0200 Bastien Guerry: doc/org.texi: 
footnote: don't put timestamps in headlines.


however removing of timestamps was dropped during migration to org-element:

a0be28eeb 2012-12-22 23:06:08 +0100 Bastien Guerry: org.el 
(org-make-org-heading-search-string): Rewrite using org-element.el


Cleaning up of statistics cookies, tags, comment and todo keywords were 
re-added, but timestamps are preserved since that commit.

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

[Jonathan Gregory]

Hi

On 13 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:


Can you check if adding:

\version "2.24.1"
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'tall-page-formats 'pdf)

to the version-and-paper block fixes the issue.


Yes, except that I have lilypond 2.24.0, which failed until I 
changed the version to fit my lilypond version.


Do you happen to know the minimal required version needed for 
your change to work? And do we need that \version line at all?



Also, I believe tagline = "" is now the only variable needed.


Looks like this on my side as well.


Given the feedback, I went ahead and changed the lilypond.org 
file:


https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92


--
Jonathan

Re: [BUG] org-store-link on document title

[Max Nikulin]

On 29/06/2023 22:54, Ihor Radchenko wrote:

Anthony Carrico writes:


On 6/29/23 09:20, Ihor Radchenko wrote:

Sure. And if it were a plain file link, there would be no reason to
assign TITLE as description. Because the link would be to a generic line
in file.


What? The title is the perfect description for the file!


That's because you expect Org to create a link to file.
But what Org does (by default) is a link to specific _line_ in file.


I find expectation to use the title property reasonable. Text search 
links are not created for lines after first heading. Current behavior is 
not documented and (if I understand it correctly) was introduced in


https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=12c09be3a
2020-02-19 18:03:53 +0100 Nicolas Goaziou: Refactor context part in file 
links


However there is a number of unit tests, so it was certainly an intended 
change.


So my vote is for [[file:document.org][title property]] when the 
document has at least on heading.

Re: [PATCH] testing: Delete duplicate tests

[Max Nikulin]

On 13/07/2023 02:22, Ilya Chernyshov wrote:

+++ b/testing/lisp/test-ol.el
@@ -301,14 +301,6 @@ Seehttps://github.com/yantar92/org/issues/4.;
 (let ((file (buffer-file-name)))
 (equal (format "[[file:%s::two]]" file file)
(org-store-link nil))
-  (should
-   (let ((org-stored-links nil)
-(org-context-in-file-links t))
- (org-test-with-temp-text-in-file "# two"
-   (fundamental-mode)
-   (let ((file (buffer-file-name)))
-(equal (format "[[file:%s::two]]" file file)
-   (org-store-link nil))


The test was added by

7a78eb1be 2020-03-26 22:57:16 +0100 Nicolas Goaziou: ol: Fix some corner 
cases when normalizing context in links


The intention may be to test "#two" besides "# two". Maybe somebody has 
a better guess what case related to the change is not covered.


The idea to find duplicated tests is bright. The code may be transformed 
in a dedicated unit test. I would not drop existing tests blindly though.

Re: [BUG] Error in data input and output format for org-columns--summary-estimate

[andrea]

   Howdy!

   Da "Ihor Radchenko" yanta...@posteo.net
   A and...@fedeli.eu
   Cc emacs-orgmode@gnu.org
   Data Fri, 14 Jul 2023 09:02:04 +
   Oggetto Re: [BUG] Error in data input and output format for 
org-columns--summary-estimate
   [ Adding Org ML back to CC. Please use "reply all" to reply on the
   mailing list ]

   "and...@fedeli.eu"  writes:

   > I do apologize, I noticed only now the patch content: the output
   > format of duration-from-minutes Is controlled by the
   > org-duration-format variable, so if the user wants results in
   > months (s)he can easily get It that way.

   `org-duration-format' is controlling many other aspects of formatting.
   Customizing, for example, agenda should probably not affect column views.
   AF: I think we need to univoquely clarify which unit is to be used in 
estimation. As shown below org documentation suggests time it to be used for 
that, from there it cames the idea to turn times into minutes for computation 
reason; maybe we may introduce a new format variable for estimation results 
reporting. I thought I might use org-duration-from-minutes for that, as it came 
very handy.
   > About possibile abuses, org documentation, to date, clearly tells
   > org estimate utilizes times.

   May you please elaborate?
   AF: Sure! Clause 8.5 of current (2023.Jul.14) org documentation, 
https://orgmode.org/manual/Effort-Estimates.html, refers to effort estimates 
giving examples that are all appearing to fall in time domain. In particular it 
refers to org-duration.el for format information. That, IMO, establish that 
efforts have to refer to org-duration units. Now, the *default* values of 
org-duration are *clearly* time measures. From there my assumption about the 
fact that I may use the org-duration-to-minutes and org-duration-from-minutes 
adapters.
   Clearly, you /may/ decide to completely redefine the org-duration basis, but 
that would mean to coherently propagate the information change everywhere 
somebody used org-duration-units which, even though LisP is a very flexible 
language, is NOT what I'd expect org-duration utilizer always foresaw to have 
to be flexible in terms of.
   > Similarly, I'd not spend too much code to check the format; i
   > understand the intent to preserve backward compatibility, bit if
   > that format adaptation mistake slipped forward to these days I
   > doubt that nice feature was used much so far...

   Yes, but it is easy to have a fallback, so why not.
   Because this way you persist in allowing a mistaken usage of that function. 
A number is a number but a duration is NOT just a number, and having something 
like (just for example) 10kg-0.5ton be taken as 10-0.5 is in my opinion NOT 
helpful to any user.
   The pcase matches either value pairs or single values, and 
org-duration-to-minutes can be charged to decide on what to do if values did 
not match the proper format (with the default assumption, I'd say, that simple 
integers are minutes).
   In facts org-duration-to-minutes already has a cond classical closing (t 
...) branch to deal with that case. I'd leave the rest as I suggested; maybe, 
if you --as maintainer hence exposed to the global amount of supports request 
and use cases-- see that as convenient, with a different output format adapter 
than the one I picked (org-duration-from-minutes without an extra format 
specification actual argument); already allowing a custom format adapter would 
introduce an extra flexibility knob BUT consider that org-duration-to-minutes 
does NOT do the same (it implicitly utilizes the org-duration-format content, 
and has hardcoded assumption on quantities being representing times, so there 
too you'd need to change something, if it was not just a matter of definining a 
different alternative to display result times).
   Cheers!
 Andrea.

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

[BUG] org-babel-result-to-file failed when buffer is narrowed [9.7 (9.7-??-f7aa8c1 @ c:/Users/yhht/.config/emacs/.local/straight/build-29.0.60/org/)]

[赵一宇]

Remember to cover the basics, that is, what you expected to happen and 

what in fact did happen. You don't know how to make a good report? See
 https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.

When I try to execute ob-block in a narrowed buffer, there seems to have
a error on org-babel-result-to-file, with msg "wrong argument type
stringp, nil"
As I look into this function:
(defun org-babel-result-to-file (result  description type)
  "Convert RESULT into an Org link with optional DESCRIPTION.
If the `default-directory' is different from the containing
file's directory then expand relative links.
   
If the optional TYPE is passed as `attachment' and the path is a
descendant of the DEFAULT-DIRECTORY, the generated link will be
specified as an an \"attachment:\" style link."
  (when (stringp result)
(let* ((result-file-name (expand-file-name result))
   (base-file-name (buffer-file-name (buffer-base-buffer)))
-2-> (base-directory (and buffer-file-name
(file-name-directory base-file-name)))
   (same-directory?
 (and base-file-name
  (not (string= (expand-file-name default-directory)
-1-> (expand-file-name
   base-directory)
the error line is marked as -1->
and the reason is at line marked as -2->, which "buffer-file-name" would
be nil when in narrowed buffer. I wonder if "buffer-file-name" should be
"base-file-name" here. Anyway, after that change, this issue go away.
Emacs : GNU Emacs 29.0.60 (build 1, x86_64-w64-mingw32)
 of 2023-03-11
Package: Org mode version 9.7 (9.7-??-f7aa8c1 @ 
c:/Users/yhht/.config/emacs/.local/straight/build-29.0.60/org/)




| |
赵一宇
|
|
zhy...@163.com
|

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Timothy]

Hi Ihor,

> 2. More importantly, we are adding ob-emacs-lisp-specific handling into
>generic ob-tangle.
>
> What about generalizing the idea and providing a way to set Emacs
> buffer-local variables in the tangled files?

Looking at this patch earlier, I had the same concern. I think it’s worth being
paranoid about a proliferation of overly-specialised ob-tangle arguments.

It occurs to me that this use case could also perhaps be satisfied by file-local
variables? If we presume that mixing tangling to lexically-bound and
non-lexically bound elisp files is a corner case we don’t care that much about,
a `org-babel-elisp-lexical' variable could be used to set the behaviour, and
modified using file-local variable forms as usual.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

[Ihor Radchenko]

Evgenii Klimov  writes:

> diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
> index a4725ae8c..c632c4814 100644
> --- a/etc/ORG-NEWS
> +++ b/etc/ORG-NEWS
> @@ -284,6 +284,13 @@ setting the ~STYLE~ property for each sub-task.
>  The change is breaking when ~org-use-property-inheritance~ is set to ~t~.
>  
>  ** New and changed options
> +*** =:lexical= header argument now influences tangled files
> +
> +When extracting an Elisp src block, the target's file
> +~lexical-binding~ variable is set according to the src block's
> +=:lexical= parameter.  If at least one block is set to lexical scope,
> +then the whole file will be with lexical scope.

I am not sure if I like this approach.
I have 2 problems with the patch:

1. Previous users of :lexical header arg might be surprised.
   Though it is an OK breaking change since people who used :lexical
   argument and expected it to be ignored in the tangled file probably
   did something wrong.
   
2. More importantly, we are adding ob-emacs-lisp-specific handling into
   generic ob-tangle.

What about generalizing the idea and providing a way to set Emacs
buffer-local variables in the tangled files?

Can be something like:

#+begin_src elisp :file-locals (lexical-binding t eval (line-number-mode))

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

Re: [BUG] Error in data input and output format for org-columns--summary-estimate

[Ihor Radchenko]

[ Adding Org ML back to CC. Please use "reply all" to reply on the
mailing list ]

"and...@fedeli.eu"  writes:

> I do apologize, I noticed only now the patch content: the output
> format of duration-from-minutes Is controlled by the
> org-duration-format variable, so if the user wants results in
> months (s)he can easily get It that way.

`org-duration-format' is controlling many other aspects of formatting.
Customizing, for example, agenda should probably not affect column views.
 
> About possibile abuses, org documentation, to date, clearly tells
> org estimate utilizes times.

May you please elaborate?
 
> Similarly, I'd not spend too much code to check the format; i
> understand the intent to preserve backward compatibility, bit if
> that format adaptation mistake slipped forward to these days I
> doubt that nice feature was used much so far...

Yes, but it is easy to have a fallback, so why not.

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

Re: [PATCH worg] ob-doc-python: Use ":results file link" for returning filenames

[Ihor Radchenko]

~jackkamm  writes:

> From: Jack Kamm 
>
> The correct usage for returng filenames as paths is to use the link
> header arg.  This updates the ob-doc-python examples to follow this
> convention now.  See also:
> https://list.orgmode.org/87ttu95xst.fsf@localhost/

Thanks!
Applied, onto master.
https://git.sr.ht/~bzg/worg/commit/97d13402

Do you have write access to WORG?

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

Re: [PATCH v2] ob-tangle.el: Blocks overwrite each other when grouping before tangling

[Ihor Radchenko]

Evgenii Klimov  writes:

> In this version I just updated the docstrings for the relevant
> functions, because prior to that it wasn't clear: does this "default
> export file for *all* source blocks" influence blocks with :tangle
> "yes"/FILENAME?

Thanks for the patch, but we need to be careful changing things in
ob-tangle. Not everything is well-documented there.

>  Optional argument TARGET-FILE can be used to specify a default
> -export file for all source blocks.
> +export file for all source blocks without :tangle header
> +argument.

This is confusing.
Is :tangle yes "without"?
What about inheritance?
What about default header args?
What if we have :tangle "/path/to/foo" and TARGET-FILE = "/path/to/foo"?
What if they are :tangle "./foo" and TARGET-FILE = "/full/path/to/foo"?
  
>  (defun org-babel-effective-tangled-filename (buffer-fn src-lang src-tfile)
> -  "Return effective tangled filename of a source-code block.
> +  "Return effective tangled absolute filename of a source-code block.

This will likely cause breakage.
There are two callers of `org-babel-effective-tangled-filename:
1. `org-babel-tangle-collect-blocks'
2. `org-babel-tangle-single-block'

`org-babel-tangle-single-block' passes (nth 1 result) as BUFFER-FN.
Its value is

(if org-babel-tangle-use-relative-file-links
(file-relative-name file)
  file)

So,

> +  (let* ((fnd (file-name-directory (buffer-file-name
> +(get-buffer buffer-fn

will fail when FILE contains file path.
And it does: (file (buffer-file-name (buffer-base-buffer)))

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