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/)]

[Eric Abrahamsen]

Jens Schmidt  writes:

> Uh, I had technical issues and did not get all mails as I expected.
> Cobbling things together in one big reply now, with references and
> quotes hopelessly broken ... hope you can sort it out.
>
> Anyway, thanks to Eric for chiming in.
>
>> Ideally, it would be nice to have tests, though I have no clue how to
>> approach writing them.
>
> I have created a somewhat minimal Gnus setup to develop and test this
> patch on my development laptop, where I normally do not use Gnus.  It
> consists of a bunch of files and directories and a bit of configuration.
> I can follow up on this if you like, but preferably in a separate
> thread.

Someone mentioned gnus-mock in the other thread, which I made for
exactly these scenarios. It's a bit hairy making a Gnus installation
from nothing -- if you try it out and would like it to do something
different, I'd be interested in feedback.

>>> 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 [...].
>
> Not really.  The following executed in an article buffer:
>
>   (progn
>(kill-buffer gnus-summary-buffer)
>(gnus-article-show-summary))
>
> results in
>
>   Debugger entered--Lisp error:
>   (error "There is no summary buffer for this article buffer")
> signal(error ("There is no summary buffer for this article buffer"))
> error("There is no summary buffer for this article buffer")
> gnus-article-show-summary()
> [...]
>
> Which, OTOH, shows that I was wrong in one aspect: Gnus at least in some
> cases *does* give a reasonable error message when the summary buffer for
> an article buffer is gone.
>
>>> 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.
>>
>> I am not sure if it is safe.
>> There is
>> (save-window-excursion (gnus-summary-select-article))
>> which calls (set-buffer gnus-summary-buffer)
>
> I agree with Ihor here and would rather go for individual wraps into
> `with-current-buffer'.  As I have done in my patch already,
> incidentially.

Somehow I missed that this whole thread started with an actual patch!
Sorry, that should have been the subject of discussion the whole time. I
can help with applying it, once all issues are resolved.

Thanks,
Eric

[FR] Add an option to use ID links during tangling

[Evgenii Klimov]

Hi, I noticed that links created during tangling back to the original
Org file doesn't respect custom =org-id-link-to-org-use-id= option in
~org-babel-tangle--unbracketed-link~.

I see in the comment there the reason for that, but still would prefer
to use unique IDs in tangled files: the probability to overwrite wrong
source block under nonunique header overweights a side-effect of
creating new ID in Org file during tangling.

Can we do something with this?  Add another option or provide an even
eager value in =org-id-link-to-org-use-id=.

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]

On 27 Jul 2023, Ihor Radchenko wrote:


Jonathan Gregory  writes:

Ok. That fix has been already installed. 
https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92


To the extent of the lilypond.org file, yes, but only if the 
output is a PDF. My suggestion is to revert that commit and 
incorporate the changes into ob-lilypond.


Then, may you elaborate what purpose the changes are going to 
serve? Automatic page sizing? Automatic page settings?


Bug fix.

The purpose of the patch was to fix the problem described in 
https://masto.ai/@rfc1149/110674961710491363. I wasn't trying 
to introduce anything new.


If we want to add boilerplate code to ob-lilypond, it does sound 
like introducing something new. Again, I feel confused. Please, 
explain in more details what you want to archive in terms of 
functionality.


No, the patch is a bug fix. There are no changes for the user. 
Prior to the bug, we were able generate a "cropped" image when 
running:


#+begin_src lilypond :file myfile.pdf
\version "2.20"
\paper { tagline="" }
{
 c' e' g' e'
}
#+end_src

This is no longer the case, hence the patch.

No, the ob-lilypond patch is needed. It allows users to 
generate music fragments (as opposed to a full page) in basic 
mode using pdf, eps, and png.


May your please explain what is "basic mode".


Basic mode is explained in 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html. 
In summary:


With basic-mode you can embed LilyPond snippets into an Org-mode 
file, compile and export them using typical Org-mode commands 
(such as C-c C-e l p for PDF export). This is useful if you want 
to mix blocks of LilyPond-generated score with text, and perhaps 
other images to export to LaTeX, Docbook, PDF, or HTML.



And what about users who do want a full page?


In that case the user would use "arrange mode", which is also 
explained in the ob-doc-lilypond.html page. Try running the source 
block example above with arrange-mode enabled using M-x 
org-babel-lilypond-toggle-arrange-mode. To quote from that page:


With arrange-mode you can develop complete pieces of score whilst 
organizing sections of the piece using typical literate 
programming techniques. This allows you to assemble scores 
programatically by using tables to store information among other 
methods.


Noweb and babel references are not allowed in header args. And 
ob-emacs-lisp also does not support :prologue.


I see, so there's no built-in way to auto-insert a boilerplate 
without using the <<>> reference *inside* source blocks. Anyway, 
let's not worry about this for now.



--
Jonathan

Re: [PATCH] Please add support for dlangs packagemanager to ob-C.el - v3

[Ihor Radchenko]

Christian Köstlin  writes:

> After adding unit-tests (following in another patchset) I found a bug in my
> last patch.
> Sorry for the noise.

Sorry for the very late reply.

If you are still interested, may you please document the new header
argument in etc/ORG_NEWS and update
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html page?

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

Re: Minimal Gnus setup for test purposes

[Ihor Radchenko]

Kévin Le Gouguec  writes:

> Jens Schmidt  writes:
>
>> More notes:
>
> Don't know if this is well-suited to ol-gnus hacking, but the gnus-mock
> package on GNU ELPA might be of interest?  I have faint memories of
> using it once or twice to debug & fix Gnus problems.

Thanks! This looks interesting.

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

[TASK] Making org-src buffers sync with real files to allow LSP and other dev tools integration (was: [PATCH] LSP support in org-src buffers)

[Ihor Radchenko]

Ihor Radchenko  writes:

> In any case, João has a working solution. Once we get some actual patch
> that applies onto Org, we can start to improve it incrementally.

It has been a while since the last update in this thread.

If other people are interested to contribute, please feel free to do so
and ask any questions in the process.
I consider this feature important for Org and encourage contributions.
-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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/)]

[Ihor Radchenko]

Jens Schmidt  writes:

> I completed already an FSF copyright assignment for Emacs.  Does that
> count for org-mode as well or do I need to extend/repeat that somehow?

No, you don't need to do anything. Org mode is a part of Emacs.

Bastien, may your please check FSF records?

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

Re: Interest in an Org video meetup?

[Ihor Radchenko]

Russell Adams  writes:

>> We can make EmacsConf instance of BigBlueButton (BBB) available, as
>> well.  FWIW I had more success with BBB than Jitsi for larger
>> meetings.

This thread had no activity for a while.
Let me take the lead then.

I am now in UTC+3 zone and can host a meetup in the evening my time
(~6-10pm).

Say, early next month. Like Aug 9. (Alternative suggestions welcome; I
just randomly selected something no too far and no too close from now.)

I will need a BBB account though.

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

[Ihor Radchenko]

Gavin Downard  writes:

> (*): the issue with `org-table-formula-substitute-names' as it is, is
> that it will replace field names with the field /value/, not the field
> index. Hopefully modifying the function to replace field names with
> their indices won't break anything, so we can use the same function for
> both sides of the formula.

This sounds reasonable, but please proceed with care.
If you can, please factor out the common parts into a separate helper
function that we can carefully test (first, without adding new
features).

What I have in mind is a preparatory "refactoring" patch that we will
later supply with new tests.

> Or, if you want to get really crazy, we can let fields and columns with
> the same name share a formula. :)
> ...
> But in all seriousness, that does seem like it could be useful. I guess
> on the rhs we could give each of those "shared names" the value of an array of
> that name's connected columns (or fields). But I think support for that should
> probably be added in a separate patch, since it's a bit separate from
> the main issue.

Yes, please move the discussion of "shared names" to a separate thread.

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

Jonathan Gregory  writes:

>> Ok. That fix has been already installed. 
>> https://git.sr.ht/~bzg/worg/commit/6f69d212f41bc372426dc9b4df286638fe8f2a92
>
> To the extent of the lilypond.org file, yes, but only if the 
> output is a PDF. My suggestion is to revert that commit and 
> incorporate the changes into ob-lilypond.

Then, may you elaborate what purpose the changes are going to serve?
Automatic page sizing? Automatic page settings?

> The purpose of the patch was to fix the problem described in 
> https://masto.ai/@rfc1149/110674961710491363. I wasn't trying to 
> introduce anything new.

If we want to add boilerplate code to ob-lilypond, it does sound like
introducing something new. Again, I feel confused. Please, explain in
more details what you want to archive in terms of functionality.

> No, the ob-lilypond patch is needed. It allows users to generate 
> music fragments (as opposed to a full page) in basic mode using 
> pdf, eps, and png.

May your please explain what is "basic mode".
And what about users who do want a full page?

>> There is :prologue standard header argument. However, it is 
>> currently not supported by ob-lilypond. (which is a bug)
>
> Can you show me how that's done in elisp? I would expect the last 
> block to output "foobar".
>
> #+begin_src elisp :noweb-ref test
> (setq x "foo" y "bar")
> #+end_src
>
> #+begin_src elisp :prologue <> :noweb yes
> (concat x y)
> #+end_src

Noweb and babel references are not allowed in header args.
And ob-emacs-lisp also does not support :prologue.

You can try

#+begin_src gnuplot :prologue set xrange [0:1]
plot x
#+end_src

or

#+begin_src gnuplot :prologue (format "set xrange [0:%d]" 11)
plot x
#+end_src

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

IDs below headline level (for paragraphs, lists, etc) (was: [PATCH] org-id: allow using parent's existing id in links to headlines)

[Ihor Radchenko]

Samuel Wales  writes:

> ...  but what if those smaller things
> could have ids without drawers?  id markers.  then changes in
> surrounding text would not break anything.

I recall similar idea raised in
https://list.orgmode.org/orgmode/cajniy+ovd0ncwzztpit5t7wvsblbgllxzmpub5tgq3gshsg...@mail.gmail.com/

But there was not much interest.

It was pointed that we already have link targets, although they are not
global. Making link targets global is doable.

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

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

[Arthur Miller]

Ihor Radchenko  writes:

> 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  be retrieved>; (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 .

Yes of course, placeholders could work. Another option is to use url as
a placeholder, so if the retrieval failed the url would still be visible
which is a bit more informative than some generic placholder.

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

True. I could also run an idle timer on my notes file and try to patch
all urls without descriptions. Would need to put something as a marker
into a desription for dead links, or just remove them, so they are not
fetched over and over again.

However, I am ok with doing it on the request only, when I actually
create a note :).

But if someone adds something similar to org, I'll gladly use it :).

Thanks and sorry the  late response. My memory is like a gold fish,
sometimes when GNUS remove a mail from my view I totally forget about
it.

/a