Re: [BUG] Sourcehut Org project mailing list is confusingly pointing to our build failures list

2022-11-24 Thread Bastien
Hi Ihor,

Ihor Radchenko  writes:

> It looks like the mailing list associated with https://sr.ht/~bzg/org/
> is associated with https://lists.sr.ht/~bzg/org-build-failures.
> It is what I get when I click on "mailing list" tab.

Yes.  SourceHut only allows sr.ht projects to be associated with other
sr.ht resources, like repositories or mailing lists.

> I'd expect that tab to point to our main list instead.

I've edited the README in https://git.sr.ht/~bzg/org (displayed as the
default information page for the Org project) to mention the main Org
mailing list, the same way the "Repositories" heading mentions the
main Savannah Org repository first.  I hope it clarifies things a bit.

Thanks for bringing this up,

-- 
 Bastien



[BUG] Org project README at sourcehut links to admin page of Org mailing list

2022-11-24 Thread Ihor Radchenko
Hi,

I noticed that the link to Org mailing list is not right.

In the readme for https://sr.ht/~bzg/org/,

"Reports when tests fail are sent to the
[[https://lists.gnu.org/mailman/admindb/emacs-orgmode][Org-mode mailing
list]]."

admindb is not what we want here.

We probably need https://lists.gnu.org/mailman/listinfo/emacs-orgmode

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



Re: [BUG] Org project README at sourcehut links to admin page of Org mailing list

2022-11-24 Thread Bastien Guerry
Ihor Radchenko  writes:

> We probably need
> https://lists.gnu.org/mailman/listinfo/emacs-orgmode

Indeed, thanks for catching this, fixed.

-- 
 Bastien



Re: [PATCH] Fix clipped LaTeX fragments (not Babel)

2022-11-24 Thread Rudolf Adamkovič
Ihor Radchenko  writes:

> Maybe you can use full argument versions instead of short ones?

Good idea, Ihor!  Please see the two attached patches.  I re-attach the
first patch again because I reworded the first line of its commit
message to put more emphasis on the term "exact".

Rudy

>From b1be654ba28ceca60d0b12778d374db27e6eced5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Wed, 23 Nov 2022 23:03:37 +0100
Subject: [PATCH 1/2] org.el: Compute bounds exactly when converting LaTeX
 output to SVG

* lisp/org.el (org-preview-latex-process-alist): Call `dvisvgm' with
`-e' (`--exact-bbox') instead of `-b min' (`--bbox=min') to measure
the exact bounds around visual glyphs, as opposed to using font
metrics, to avoid clipping at the edges.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 64b33e597..2f473f54d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3243,7 +3243,7 @@ All available processes and theirs documents can be found in
  :image-output-type "svg"
  :image-size-adjust (1.7 . 1.5)
  :latex-compiler ("latex -interaction nonstopmode -output-directory %o %f")
- :image-converter ("dvisvgm %f -n -b min -c %S -o %O"))
+ :image-converter ("dvisvgm %f -n -e -c %S -o %O"))
 (imagemagick
  :programs ("latex" "convert")
  :description "pdf > png"
-- 
2.38.1

>From 34e3ecd3b23fae330574fe1cbcb3154b2fb8a2c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Thu, 24 Nov 2022 21:41:35 +0100
Subject: [PATCH 2/2] org.el: Use long option names when launching dvisvgm

* lisp/org.el (org-preview-latex-process-alist): Use long option names
when launching dvisvgm, optimizing for maintainability, instead of
brevity.  For example, use `--no-fonts' instead of `-n'.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 2f473f54d..472e87b9b 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3243,7 +3243,7 @@ All available processes and theirs documents can be found in
  :image-output-type "svg"
  :image-size-adjust (1.7 . 1.5)
  :latex-compiler ("latex -interaction nonstopmode -output-directory %o %f")
- :image-converter ("dvisvgm %f -n -e -c %S -o %O"))
+ :image-converter ("dvisvgm %f --no-fonts --exact-bbox --scale=%S --output=%O"))
 (imagemagick
  :programs ("latex" "convert")
  :description "pdf > png"
-- 
2.38.1

-- 
"I love deadlines.  I love the whooshing noise they make as they go by."
-- Douglas Adams, The Salmon of Doubt, 2002

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


Fix the confusing "result silenced" message

2022-11-24 Thread Rudolf Adamkovič
Hello smart folks!

With Org Babel, the user can make the results silent, or *silence* them,
with the `:results silent' header argument.  However, Org says "result
silenced" after executing source blocks with the `:results none' header
argument.  Every time I see that message, I have a "Wait, what?" moment.
The patch attached below fixes this incredibly confusing message.

Rudy

>From 6ffc06e9da723cf04e2c7471e35a46294742be3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Thu, 24 Nov 2022 22:10:29 +0100
Subject: [PATCH] ob-core: Fix the confusing "result silenced" message

* lisp/ob-core.el (org-babel-execute-src-block): Say "discarded"
instead of "silenced" after executing source blocks with `:results
none' to avoid confusion with `:results silent'.  Also, capitalize
correctly.
---
 lisp/ob-core.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 1259909a0..fb472a00a 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -850,7 +850,7 @@ guess will be made."
 		(when file
 		  (setq result-params (remove "file" result-params))
 	  (if (member "none" result-params)
-		  (message "result silenced")
+		  (message "Result discarded")
 	(org-babel-insert-result
 	 result result-params info new-hash lang
  (time-subtract (current-time) exec-start-time
-- 
2.38.1

-- 
"Mathematics takes us still further from what is human into the region
of absolute necessity, to which not only the actual world, but every
possible world, must conform."
-- Bertrand Russell, 1902

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


Re: Fwd: org-priority: allow customization of priority indicator

2022-11-24 Thread drlkf
Hi,

Apologies, I've been quite busy and I haven't had time to dive more into
this, but I have it written down somewhere and I'll make modifications
as soon as I am able. I'll reply here with a new patch when I'm done.

Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
>> Thanks for the patch!
>>
>> In general, we do not intend to support changing basic elements of Org
>> syntax. So, things like your _p may remain buggy because they clash with
>> underscore emphasis.
>> ...
>> More comments below.
>> ...
>
> [I am following this up as more than one month passed since the last
> activity in the thread]
>
> Have you had a chance to look into my comments?
> If you have any objections or issues with addressing them, feel free to
> reply.



signature.asc
Description: PGP signature


Re: [BUG] Sourcehut Org project mailing list is confusingly pointing to our build failures list

2022-11-24 Thread Ihor Radchenko
Bastien  writes:

>> It looks like the mailing list associated with https://sr.ht/~bzg/org/
>> is associated with https://lists.sr.ht/~bzg/org-build-failures.
>> It is what I get when I click on "mailing list" tab.
>
> Yes.  SourceHut only allows sr.ht projects to be associated with other
> sr.ht resources, like repositories or mailing lists.

May we ask them to change this?

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



Re: Images generated by R code blocks do not display

2022-11-24 Thread Ihor Radchenko
William Denton  writes:

> I refreshed the source just now, and it's at commit 183c66be97c:
>
> GNU Emacs 29.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo 
> version 1.16.0) of 2022-11-23
>
> I reran the convert image command, and the (clear-image-cache) problem is 
> still 
> there.  If you generate an image that's 300x300, then change the command so 
> it 
> makes a 500x500 image, and rerun the command, a 500x500 image appears right 
> away?  Or does after you C-c C-x C-v?  I have to run M-: (clear-image-cache) 
> and 
> then the image in the buffer updates to the larger one.

I tried again now, and I am able to reproduce.
This is very strange.

What I did is

1. cd /path/to/org/repo
2. git checkout main
3. make repro
4. M-: (require 'ob-shell)
5. Open the following org file

#+begin_src sh :results graphics file :file /tmp/colour.png
convert -size 300x300 xc:#002b36 /tmp/colour.png
#+end_src

6. Move point to the source block and C-c C-c yes
7. C-c C-x C-v
8. Observe the 300x300 image appearing
9. Edit the source code to 500x300
10. C-c C-c yes
11. Image disappears
12. C-c C-x C-v
13. Observe what appears to be the old 300x300 image
14. Move the cursor to the image
15. Observe the correct 500x300 appearing while the cursor is on it!!

Could you please confirm?

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



Re: [PATCH] Fix clipped LaTeX fragments (not Babel)

2022-11-24 Thread Ihor Radchenko
Rudolf Adamkovič  writes:

> Ihor Radchenko  writes:
>
>> Maybe you can use full argument versions instead of short ones?
>
> Good idea, Ihor!  Please see the two attached patches.  I re-attach the
> first patch again because I reworded the first line of its commit
> message to put more emphasis on the term "exact".

Thanks!
Applied onto main adding link to this thread into the commit message.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=52ebf6b45
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5337a49f3

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



Re: Fix the confusing "result silenced" message

2022-11-24 Thread Ihor Radchenko
Rudolf Adamkovič  writes:

> Hello smart folks!
>
> With Org Babel, the user can make the results silent, or *silence* them,
> with the `:results silent' header argument.  However, Org says "result
> silenced" after executing source blocks with the `:results none' header
> argument.  Every time I see that message, I have a "Wait, what?" moment.
> The patch attached below fixes this incredibly confusing message.
> ...
> (if (member "none" result-params)
> -   (message "result silenced")
> +   (message "Result discarded")

:results none are not discarded. Just not inserted and not displayed.
Otherwise, they can still be used, for example, during noweb expansion.

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



Re: Fwd: org-priority: allow customization of priority indicator

2022-11-24 Thread Ihor Radchenko
drlkf  writes:

> Apologies, I've been quite busy and I haven't had time to dive more into
> this, but I have it written down somewhere and I'll make modifications
> as soon as I am able. I'll reply here with a new patch when I'm done.

No problem. This email was not to push you. Rather just a reminder to
make sure that you did not forget about this thread.

Take your time.

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



Re: [BUG] Sourcehut Org project mailing list is confusingly pointing to our build failures list

2022-11-24 Thread Bastien
Hi Ihor,

Ihor Radchenko  writes:

> May we ask them to change this?

Yes, you can ask anything by sending an email to the sr.ht discussion
list: https://lists.sr.ht/~sircmpwn/sr.ht-discuss

If the request is to be able to list *any* mailing list in the mailing
list tab of a sr.ht project, I am not sure it is acceptable, though.

A sr.ht project is a place for sr.ht resources: repositories, mailing
lists, bug trackers.  Allowing a "foreign" mailing list to be listed
in the mailing lists tab would call for allowing foreign bug trackers
(and even foreign repositories) as the resources for a project, which
I think will be (rightfully) rejected as not consistent.

Also, I believe the current state of information is okay.

-- 
 Bastien



Re: Compiling a C++ source block

2022-11-24 Thread Ihor Radchenko
tbanelwebmin  writes:

> Good point Ihor!
> I will change that

I pushed my version of the change onto master.
https://git.sr.ht/~bzg/worg/commit/7a1e9671

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