Re: [PATCH] Re: worg patch: R usage of :colnames for :results

[Greg Minshall]

Bastien,

> Applied, thanks, but I removed the reference to X-Woof-Patch here.

thanks.  yes, makes sense -- i was hesitant to mention it, on a
"beginner" page.

cheers, Greg

Re: [PATCH] async process in R

[Bastien]

Hi Greg and Jeremie,

Greg Minshall  writes:

> if this is not already idiomatic for org mode, i'd vote to require the
> "yes" or "no".  just my 2 cents.

Agreed: even if a syntax is allowed, let's use the idiomatic form in
examples.

2 cts,

-- 
 Bastien

Bug: clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Jeff Trull]

:inherit-props seems to not consider global properties.

Testcase:

# Create a global property

#+PROPERTY: HOURLY_RATE 150

* Top 1
** Sub 1A
# here we should get the global property, but do not
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 12:25]--[2021-09-26 Sun 13:25] =>  1:00
   - I did some tasks
   :END:

** Sub 1B
* Top 2
  :PROPERTIES:
  :HOURLY_RATE: 110
  :END:
** Sub 2A
# successfully inherit from "Top 2"
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 21:26]--[2021-09-26 Sun 22:26] =>  1:00
   - I did some other tasks
   :END:

** Sub 2B
   :PROPERTIES:
   :HOURLY_RATE: 90
   :END:
# override Top 2
   :LOGBOOK:
   CLOCK: [2021-09-26 Sun 18:30]--[2021-09-26 Sun 19:00] =>  0:30
   - Attended a meeting
   :END:

#+BEGIN: clocktable :scope file :maxlevel 2 :properties ("HOURLY_RATE")
:inherit-props t
#+CAPTION: Clock summary at [2021-09-26 Sun 22:48]
| HOURLY_RATE | Headline |   Time |  |
|-+--++--|
| | *Total time* | *2:30* |  |
|-+--++--|
| | Top 1|   1:00 |  |
| | \_  Sub 1A   || 1:00 |
| 110 | Top 2|   1:30 |  |
| 110 | \_  Sub 2A   || 1:00 |
|  90 | \_  Sub 2B   || 0:30 |
#+END:

I expect that "Sub 1A" will show the global HOURLY_RATE of 150, but it is
empty.

Emacs  : GNU Emacs 27.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
2.24.32, cairo version 1.16.0)
 of 2020-09-01
Package: Org mode version 9.4.6 (9.4.6-12-gdcc3a8-elpa @
/home/jet/.config/emacs/elpa/org-20210823/)

current state:
==
(setq
 org-duration-format 'h:mm
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-latex-listings t
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-export-global-macros '((LASTMONTH .
 "(eval (format-time-string \"%B %Y\"
(encode-time (decoded-time-add (decode-time) (make-decoded-time :month
-1)")
(NET30 .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (decoded-time-add (decode-time) (make-decoded-time :day
30)")
(LASTOFLASTMONTH .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (let ((d (decode-time))) (setf (decoded-time-day d) 1)
(decoded-time-add d (make-decoded-time :day -1))")
(FIRSTOFLASTMONTH .
 "(eval (format-time-string \"%m/%d/%Y\"
(encode-time (let ((d (decoded-time-add (decode-time) (make-decoded-time
:month -1 (setf (decoded-time-day d) 1) d")
)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-log-note-clock-out t
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-mode-hook '(#[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2]
 org-bullets-mode org-tempo-setup (lambda nil
(electric-indent-local-mode -1))
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append
local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-babel-load-languages '((emacs-lisp . t) (dot . t) (ditaa . t))
 org-export-backends '(ascii html icalendar latex md confluence re-reveal)
 org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-ditaa-jar-path "/usr/share/ditaa/ditaa.jar"
 org-structure-template-alist '(("n" . "notes") ("a" . "export ascii") ("c"
. "center")
("C" . "comment") ("e" . "example") ("E" .
"export")
("h" . "export html") ("l" . "export
latex") ("q" . "quote")
("s" . "src") ("v" . "verse"))
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-export-before-

Re: [PATCH] Re: worg patch: R usage of :colnames for :results

[Bastien]

Hi Greg,

Greg Minshall  writes:

> if a picture is worth a thousand words, what's a patch worth?  :)

A lot :)

Applied, thanks, but I removed the reference to X-Woof-Patch here.

Also, this contribute.org page is somewhat redundant with the one 
that serves as a reference for a long time on Worg, we shall think
on merging them -- I'll add this to my todo list.

Best,

-- 
 Bastien

[PATCH] Re: worg patch: R usage of :colnames for :results

[Greg Minshall]

Bastien,

> I'm not sure what you mean, can you elaborate?

if a picture is worth a thousand words, what's a patch worth?  :)

thanks for the pointer to the orgweb sources.

cheers, Greg

>From 2594db749de7ae5ec9400b4397b0ba21d9526c9b Mon Sep 17 00:00:00 2001
From: Greg Minshall 
Date: Mon, 27 Sep 2021 08:03:42 +0300
Subject: [PATCH] contribute.html: Suggest '[PATCH]' on Subject: line when
 submitting patches

contribute.org: Modify text.

Also pointer to X-Woof-Patch as an alternative.
---
 contribute.org | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/contribute.org b/contribute.org
index 41ef346..bad79e4 100644
--- a/contribute.org
+++ b/contribute.org
@@ -120,10 +120,13 @@ More formally,
 
 ** Sending patches
 
-Use ~git diff~ or ~git format-patch~ to generate the patch files and then
-include them in an email to [[mailto:emacs-orgmode@gnu.org][emacs-orgmode@gnu.org]] describing what
+Use ~git diff~ or ~git format-patch~ to generate the patch files and
+then include them in an email to [[mailto:emacs-orgmode@gnu.org][emacs-orgmode@gnu.org]] describing what
 you've done.  If you have configured git to use [[https://git-send-email.io/][send-email]], then you
-can use that.
+can use that.  If you are able to add the phrase =[PATCH]= to the
+beginning of the Subject: line of your e-mail, that will help to
+manage your submission.[fn:: Adding a [[https://github.com/bzg/woof]["X-Woof-Patch";]] header to your
+e-mail can also accomplish this.]
 
 If your mail has not appeared on [[https://list.orgmode.org/][the list]] after waiting at least 15
 minutes, it may have been flagged as spam by the robot email
-- 
2.32.0

Re: [PATCH] async process in R

[Greg Minshall]

hi, Jeremie,

> Many thanks for the feedback, assigning yes or no to async will work
> as expected.

thanks for the answer.

> I am not sure if it is a desirable feature or not.

if this is not already idiomatic for org mode, i'd vote to require the
"yes" or "no".  just my 2 cents.

cheers, Greg

Re: Empty headline titles unsupported: Bug?

[Tom Gillespie]

Hi Bastien,
I am strongly in favor of this change. It simplifies the grammar
significantly, and from my work on the laundry lexer and parser, I'm
99% certain that the current behavior is a bug that is the result of
gobbling the space after the stars in the headline. The correct
implementation peeks 1 char ahead for the space, and then starts
parsing again starting with the space. This is because tags MUST be
preceded by a space, so if you incorrectly gobble the space after the
stars then that space cannot be used as the start for tags. Best,
Tom

Re: [PATCH] ob-svgbob: New babel backend for SVGBob

[Bastien]

Hi Timothy,

> Thanks for taking a look at this. In light of your response I’m wondering 
> about
> the ob-* inclusion criteria. I recall when removal was being discussed the
> concerns being with ob-* libraries that were some combination of:
> ⁃ Too niche
> ⁃ Being actively maintained

I may be wrong, and perhaps many people are already using svgbob to
convert ASCII drawing to SVG, but I think it is too niche for being
part of Org core and Emacs core.

The questions I'd ask before including a Babel library in Org are*:

- Is the language supported in Emacs core?
- Is the language or tool widely used?

You don't need to score very high with *both* answer, but at least
one.  For example, ob-js.el qualifies because Javascript is supported
in Emacs and widely used.  ob-plantuml.el because, even though there
is no kind of "Emacs support", the tool is widely used.

I don't think svgbob is widely used enough (3K GitHub stars does not
say much about the real use).

There is no harm in not being included in Org, such useful libraries
can live in GNU or NonGNU ELPA and still reach their audience.

WDYT?

* Given these criteria, I'm inclined to add ob-stan.el to the list
  of Babel libary that should probably move outside of Org core.

-- 
 Bastien

Re: [PATCH] ob-svgbob: New babel backend for SVGBob

[Timothy]

Hi  Bastien,

> Not later than a few hours ago, I removed several ob-* files:
> 
>
> (ob-svgbob.el should not go in org-contrib, though, because the
> org-contrib repo is for unmaintained libraries.)
>
> I suggest you maintain ob-svgbob.el as a contributed library to
> GNU ELPA () to help people find it. See the
> instructions here:
>
> 

Thanks for taking a look at this. In light of your response I’m wondering about
the ob-* inclusion criteria. I recall when removal was being discussed the
concerns being with ob-* libraries that were some combination of:
⁃ Too niche
⁃ Being actively maintained

Which is why I thought SVGBob could be a good fit, as it’s a small useful
general-purpose tool that only takes ~50 lines of code for a library (and so I’d
be quite happy to maintain) and IMO fits in nicely with Org.

Would you mind elaborating a bit more on your thoughts on what makes an ob-*
library a good fit for Org or not?

All the best,
Timothy

Re: [PATCH] ob-svgbob: New babel backend for SVGBob

[Bastien]

Hi Steven,

thank you very much for proposing this addition!

While I personally love it (and find the svgbob-editor demo very
impressive), we are in the process of restricting the ob-* files
that we include in Org's core and in GNU Emacs.

Not later than a few hours ago, I removed several ob-* files:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=db67c7e9

(ob-svgbob.el should not go in org-contrib, though, because the
org-contrib repo is for unmaintained libraries.)

I suggest you maintain ob-svgbob.el as a contributed library to
GNU ELPA (https://elpa.gnu.org) to help people find it. See the
instructions here:

https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

How does that sound?

-- 
 Bastien

Re: [BUG] 502/slow response from new repo [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

[Bastien]

No Wayman  writes:

> That was after multiple attempts which resulted in 502 errors.

Yes, I've noticed the https://git.savannah.gnu.org website had some
issues today.  It seems to be stable now.

-- 
 Bastien

Re: [PATCH] Improve org-mouse support for checkboxes

[Bastien]

Jim Porter  writes:

> On 9/25/2021 10:58 PM, Bastien wrote:
>> I applied the patch adding the TINYCHANGE cookie, since the assignment
>> process isn't done yet.  Can you check with copyright-cl...@fsf.org if
>> it will be done anytime soon?
>
> I think I might be in the database as "James" though; that caused a
> similar hiccup when contributing to Emacs too.

Er, yes, that was it!  I've updated
https://orgmode.org/worg/org-contribute.html

Thanks,

-- 
 Bastien

Re: behavior of (org-insert-heading-respect-content)

[Victor A. Stoichita]

Le 18 Sep 2021, Marco Wahl  a écrit :
> Would be great if you could test the fix.

Hi Marco!

Sorry, I was unable to try it until today. I just did and It
works perfectly.

Thanks!

Victor

Re: worg patch: R usage of :colnames for :results

[Bastien]

Hi Greg,

Greg Minshall  writes:

> maybe some comments/links at https://orgmode.org/contribute.html ?  

I'm not sure what you mean, can you elaborate?

> i'm not sure where those sources live, or i'd X-Woof a [PATCH].  :)

The orgmode.org website is at https://git.sr.ht/~bzg/orgweb which you
can clone with ~$ git clone https://git.sr.ht/~bzg/orgweb

HTH,

-- 
 Bastien

Re: [PATCH] async process in R

[Jeremie Juste]

Hello Greg,
>
> i was surprised by =:async= standing alone, i.e., with no following
> "yes" or "no".  is that an org-mode "idiom"?  i.e., unadorned header
> arguments default to (some form of) "yes"?

Many thanks for the feedback, assigning yes or no to async will work as 
expected.

#+begin_src R :session *R* :results value :async yes :colnames yes
Sys.sleep(10)
as.list(1:5)
#+end_src

No async process in R

#+begin_src R :session *R* :results value :async no :colnames yes
Sys.sleep(10)
as.list(1:5)
#+end_src

:async without parameters will default to yes.

#+begin_src R :session *R* :results value :async :colnames yes
Sys.sleep(10)
as.list(1:5)
#+end_src

I am not sure if it is a desirable feature or not. 

Best regards,
Jeremie

Re: Org branches: master, main, and maint?

[Samuel Wales]

i have forgotten all my non-basic git, so i guess i am in for a bunch
of figuring out the automatic rebase of my stuff on top of upstream.

perhaps i can do a single git clone, do the rebase, and then change
branches to create the ohters.  but i presume this is a normal git
thing git clone to get rid of stuff lying around, deal with tags, and
deal with branches?

if there is documentation perhaps say that bugfix ~= stable?


On 9/26/21, Max Nikulin  wrote:
> On 26/09/2021 17:31, Bastien wrote:
>> Timothy writes:
>>
>>> I’ve just had a look at the branches, and I see that we currently
>>> have
>>>
>>>  master
>>>  main
>>>  maint
>>
>> You probably listed your local branch with "git branch -a" or by
>> checking your .git/config file.
>>
>> If you clone a fresh repo like this:
>>
>> ~$ git clone https://git.savannah.gnu.org/git/emacs/org-mode.git
>>
>> and fetch all the branches (git fetch --all) you should only see
>> the three branches mentioned above.
>
>  git fetch --prune
>
> might help to keep personal local branches but to remove non-existing
> remote ones if you changed URL of origin repository. I renamed old
> "origin" and added new one with savannah URL, so each repository has its
> own branch (That is why I may be a bit wrong concerning exact behavior
> of --prune in this case).
>
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: [PATCH] async process in R

[Greg Minshall]

Jeremie,

a question.  in

> #+begin_src R :session *R* :results value :async :colnames yes
> Sys.sleep(10)
> as.list(1:5)
> #+end_src

i was surprised by =:async= standing alone, i.e., with no following
"yes" or "no".  is that an org-mode "idiom"?  i.e., unadorned header
arguments default to (some form of) "yes"?

cheers, Greg

Re: [BUG] Conflict between org-emphasis and org-latex

[Juan Manuel Macías]

Hi Léo and Timothy,

Léo Ackermann writes:

> [...]
> I think that this bug has been introduced recently (I
> never noticed it before)

I don't know if I'm pointing in the right direction, or I am missing
something, but I would say that this is a problem (or consequence) of
`org-emphasis-regexp-components'. According to the docstring, it is a list
with five parts:

("-[:space:]('\"{"
"-[:space:].,:!?;'\")}\\["
"[:space:]"
"."  ;; <<
15)

where part 4, body-regexp, is: "A regexp like "." to match a body
character. Don’t use non-shy groups here, and don’t allow
newline here".

Therefore, the segment "} and {" is fontized here as emphasis

For a LaTeX fragment I think you can do:

(setq org-highlight-latex-and-related 'script)

According to the docstrip:

Non-nil means highlight LaTeX related syntax in the buffer.
When non-nil, the value should be a list containing any of the
following symbols:
  ‘native’   Highlight LaTeX snippets and environments natively.
  ‘latex’Highlight LaTeX snippets and environments.
  ‘script’   Highlight subscript and superscript.
  ‘entities’ Highlight entities.

Best regards,

Juan Manuel

Re: worg patch: R usage of :colnames for :results

[Greg Minshall]

Bastien,


> Applied againt worg, thanks!

thanks.

> You simply need to add [PATCH] to the subject of your email, it will
> be listed in https://updates.orgmode.org.  You can also manually add
> X-Woof-Patch: yes -- see https://github.com/bzg/woof for details.

maybe some comments/links at https://orgmode.org/contribute.html ?  i'm
not sure where those sources live, or i'd X-Woof a [PATCH].  :)

cheers, Greg

Re: [PATCH] Improve org-mouse support for checkboxes

[Jim Porter]

On 9/25/2021 10:58 PM, Bastien wrote:

I applied the patch adding the TINYCHANGE cookie, since the assignment
process isn't done yet.  Can you check with copyright-cl...@fsf.org if
it will be done anytime soon?


Hm, it should be done, since I received confirmation from the copyright 
clerk on the 15th. I think I might be in the database as "James" though; 
that caused a similar hiccup when contributing to Emacs too.

[PATCH] async process in R

[Jeremie Juste]

Hello,

I have integrated some of the ob-session-async package in ob-R.el
(finally). Most of the heavy lifting has been made by Jack.


So with the patch async evaluation is  expected to work out of the box
for :result value

#+begin_src R :session *R*  :results value :async :colnames yes
Sys.sleep(10)
as.list(1:5)
#+end_src

#+RESULTS:
| x |
|---|
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |

But for the time being result output produces the following output.

#+begin_src R :session *R*  :results output :async
Sys.sleep(1)
print(1:5)
#+end_src

#+RESULTS:
: > Sys.sleep(1)
: > print(1:5)
: [1] 1 2 3 4 5
: > 'ob_comint_async_R_end_53c0a42fed17cf78f5508e5293029430'


>From my understanding the async command of python does not suffer from
this issue. I'm not sure if the issue needs to be solve at the ob-R.el
or at the ob-core.el. I welcome any comments on this patch or any idea
to move it forward.

Best regards,
Jeremie

>From 51e1efb75e15fab348fd5a2c8b5fb5c1dbbf4d1c Mon Sep 17 00:00:00 2001
From: Jeremie Juste 
Date: Sun, 26 Sep 2021 18:25:23 +0200
Subject: [PATCH] lisp/ob-R: Async evaluation in R

* lisp/ob-R.el `ob-session-async-R-indicator': Add constant
representing a prefix R to identity session.
(ob-session-async-org-babel-R-evaluate-session):New
function to evaluate R src block
asynchrously.  (ob-session-async-R-value-callback): New function that
callback the result of the asynchronous evaluation.
(org-babel-R-evaluate): Add `async' parameter and call
ob-session-async-org-babel-R-evaluate-session if `async' parameter is
present.  (org-babel-execute:R): Call (org-babel-comint-use-async) to
check if async is among `params' and add async parameter to (org-babel-R-evaluate).

* testing/lisp/test-ob-R.el: Add 7 more tests for async evaluations,
also taken from ob-session-async package.

This is almost a carbon copy of the package of ob-session-async
of Jack Kamm. The original source code can be found
https://github.com/jackkamm/ob-session-async

Please refer to the following thread to trace back the discussion on
async evaluation in R.
https://list.orgmode.org/87eed9g9p6@gmail.com/
---
 lisp/ob-R.el  | 90 +++--
 testing/lisp/test-ob-R.el | 94 +++
 2 files changed, 181 insertions(+), 3 deletions(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 2d9073cee..299ccdf1d 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -158,6 +158,7 @@ This function is called by `org-babel-execute-src-block'."
   (save-excursion
 (let* ((result-params (cdr (assq :result-params params)))
 	   (result-type (cdr (assq :result-type params)))
+   (async (org-babel-comint-use-async params))
(session (org-babel-R-initiate-session
 		 (cdr (assq :session params)) params))
 	   (graphics-file (and (member "graphics" (assq :result-params params))
@@ -184,7 +185,8 @@ This function is called by `org-babel-execute-src-block'."
 		  (cdr (assq :colname-names params)) colnames-p))
 	 (or (equal "yes" rownames-p)
 		 (org-babel-pick-name
-		  (cdr (assq :rowname-names params)) rownames-p)
+		  (cdr (assq :rowname-names params)) rownames-p))
+ async)))
   (if graphics-file nil result
 
 (defun org-babel-prep-session:R (session params)
@@ -371,11 +373,14 @@ Has four %s escapes to be filled in:
 4. The name of the file to write to")
 
 (defun org-babel-R-evaluate
-  (session body result-type result-params column-names-p row-names-p)
+  (session body result-type result-params column-names-p row-names-p async)
   "Evaluate R code in BODY."
   (if session
+  (if async
+  (ob-session-async-org-babel-R-evaluate-session
+   session body result-type result-params column-names-p row-names-p)
   (org-babel-R-evaluate-session
-   session body result-type result-params column-names-p row-names-p)
+   session body result-type result-params column-names-p row-names-p))
 (org-babel-R-evaluate-external-process
  body result-type result-params column-names-p row-names-p)))
 
@@ -468,6 +473,85 @@ Insert hline if column names in output have been requested."
 	(error "Could not parse R result"))
 result))
 
+
+;;; async evaluation
+
+(defconst ob-session-async-R-indicator "'ob_comint_async_R_%s_%s'")
+
+(defun ob-session-async-org-babel-R-evaluate-session
+(session body result-type result-params column-names-p row-names-p)
+  "Asynchronously evaluate BODY in SESSION.
+Returns a placeholder string for insertion, to later be replaced
+by `org-babel-comint-async-filter'."
+  (org-babel-comint-async-register
+   session (current-buffer)
+   "^\\(?:[>.+] \\)*\\[1\\] \"ob_comint_async_R_\\(.+?\\)_\\(.+\\)\"$"
+   'org-babel-chomp
+   'ob-session-async-R-value-callback)
+  (cl-case result-type
+(value
+ (let ((tmp-file (org-babel-temp-file "R-")))
+   (with-temp-buffer
+ (insert
+  (org-babel-chomp body))
+ (let ((ess-local-process-name
+(process-name (

Re: [BUG] Conflict between org-emphasis and org-latex

[Timothy]

Hi  Léo,

> I’ll try to do so ;)
> Let you know,

That’s great to hear. Thanks in advance, even if it doesn’t work out the effort
is appreciated 🙂.

All the best,
Timothy

Re: [BUG] Conflict between org-emphasis and org-latex

[Léo Ackermann]

Hi,
I’ll try to do so ;) 

Let you know,
Leo

> Le 26 sept. 2021 à 19:01, Timothy  a écrit :
> 
> 
> Hi Léo,
> 
> You write:
>> Nevertheless, I think that this bug has been introduced recently (I never 
>> noticed it before) and has to be corrected properly (as this is a really 
>> basic use of
>> org-mode).
>> Unfortunately, I can barely understand elisp... so writing a patch is far 
>> away from what I can do :/
> 
> Do you think you might be able to identify a "good" commit and bisect
> the bug? That would be a tremendous help for solving it, and shouldn't
> require any elisp.
> 
> --
> Timothy

Re: [BUG] Conflict between org-emphasis and org-latex

[Timothy]

Hi Léo,

You write:
> Nevertheless, I think that this bug has been introduced recently (I never 
> noticed it before) and has to be corrected properly (as this is a really 
> basic use of
> org-mode).
> Unfortunately, I can barely understand elisp... so writing a patch is far 
> away from what I can do :/

Do you think you might be able to identify a "good" commit and bisect
the bug? That would be a tremendous help for solving it, and shouldn't
require any elisp.

--
Timothy

Re: [BUG] Conflict between org-emphasis and org-latex

[Léo Ackermann]

Hi Juan Manuel,

I agree that some tricks exist in order to prevent this behavior.
Nevertheless, I think that this bug has been introduced recently (I never
noticed it before) and has to be corrected properly (as this is a really
basic use of org-mode).
Unfortunately, I can barely understand elisp... so writing a patch is far
away from what I can do :/

Best,
Leo

Le dim. 26 sept. 2021 à 14:57, Juan Manuel Macías 
a écrit :

> Hi Léo,
>
> Léo Ackermann writes:
>
> > Hi!
> > I noticed that in org@888aaa97c0ce331097787333d0d712dd6e4d078f, the
> > following happens:
> > When writing `Consider $a^{*}$ and $b^{*}$` in an org-mode buffer, the
> > two stars match together, causing "and" to appear in bold case.
> >
> > Any idea to fix this unwanted behavior ?
>
> You can insert a zero width space character (U+200B), to prevent that
> segment is fontified as emphasis [see the Manual in the section `Escape
> Character']. It is enough with insert the character after one of the
> asterisks: M-x insert-char RET 200b RET. I also recommend that you look
> at this section on Timothy's blog `This Month in Org':
> https://blog.tecosaur.com/tmio/2021-05-31-async.html#easy-zero-width
>
> Best regards,
>
> Juan Manuel
>

[BUG] 502/slow response from new repo [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Experiencing 502 errors and delay when trying to clone the new 
development repo:


time git clone https://git.savannah.gnu.org/git/emacs/org-mode.git
Cloning into 'org-mode'...
remote: Counting objects: 129920, done.
remote: Compressing objects: 100% (28292/28292), done.
remote: Total 129920 (delta 101703), reused 129609 (delta 101488)
Receiving objects: 100% (129920/129920), 81.43 MiB | 10.35 MiB/s, 
done.

Resolving deltas: 100% (101703/101703), done.

real1m59.019s
user0m27.884s
sys 0m0.955s

That was after multiple attempts which resulted in 502 errors.

For comparison:
time git clone -b master git://git.sv.gnu.org/emacs.git
Cloning into 'emacs'...
remote: Counting objects: 950806, done.
remote: Compressing objects: 100% (167880/167880), done.
remote: Total 950806 (delta 782727), reused 949614 (delta 781638)
Receiving objects: 100% (950806/950806), 318.40 MiB | 31.17 MiB/s, 
done.

Resolving deltas: 100% (782727/782727), done.

real1m37.033s
user2m56.213s
sys 0m2.527s

Just a heads up.

[PATCH] ob-svgbob: New babel backend for SVGBob

[Steven vanZyl]

Hello everyone,

Attached is a patch adding Babel support for SVGBob [1] to Org-Mode.

SVGBob is a popular CLI tool for transforming freeform ASCII art
(like what you can make with artist-mode) into SVG vector images. Unlike dot it
does not have a text syntax and is not specifically intended for creating
graph diagrams. Examples can be seen here [1].


I consider it suitable for inclusion in Org-mode since it's a fairly small
patch which provides support for a fairly popular tool, and is in a niche
that's currently not covered by anything else, like ob-dot.

This patch was co-developed by Timothy/TEC (as reflected in the commit)
and he has volunteered to maintain it. I have also filled out the
FSF paperwork for copyright assignment.

Feedback and comments are greatly appreciated!

Thank you,
Steven vanZyl

[1]: https://ivanceras.github.io/svgbob-editor/


0001-ob-svgbob-Babel-support-for-SVGBob.patch
Description: Binary data

Re: worg patch: R usage of :colnames for :results

[Bastien]

Hi Greg,

Greg Minshall  writes:

> hi.  i occasionally need to look up how to get header lines on tables
> resulting from an evaluation of an R source block.  the answer is
> =:colnames yes=.  here's a patch that minimally documents that.

Applied againt worg, thanks!

> ps -- i have some vague memory i'm supposed to hack in a "woof" header.
> but, it's not mentioned on https://orgmode.org/contribute.html so i've
> lazily not.

You simply need to add [PATCH] to the subject of your email, it will
be listed in https://updates.orgmode.org.  You can also manually add
X-Woof-Patch: yes -- see https://github.com/bzg/woof for details.

HTH,

-- 
 Bastien

Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Emily Bourke]

Hi Bastien,

> Tomorrow for sure, and probably next week will be okay too.

Perfect, I’ll get back to you once I’ve taken a look tomorrow.

> To be clear, I hope we can release 9.5 soon to be able to make it
> included in the next Emacs 28.1 version.

Understood, thanks for the clarification.

Best wishes,
Emily

Re: shrink table in columnmode view (poor man's issue system)

[Uwe Brauer]

>>> "MW" == Marco Wahl  writes:

> Hi!
> Uwe Brauer  writes:
>> I use the following org file to organise my issues.
>> It works quite well, however I would like to have a shrink option
>> automatically in my columnview.

> Your suggestion looks quite useful to me.

>> Any idea how to achieve that?

> One possibility is to write your own dynamic block writer function.
> Find documentation at (info "(org) Dynamic Blocks") .

Aha, meanwhile I discovered that a dummy entry 

* Issues
   :PROPERTIES:
   :COLUMNS:  %50ITEM(Problem) %10Is(Issue Nr) %7TODO(Status) %26TAGS(Which) 
%17Date(Date) %7STATUS(Status){X/} 
   :ID:   Issues
   :END:

** <45>
   :PROPERTIES:
   :ID:  Issues 
   :Date:
   :STATUS:   
   :Is:  0 
   :END:


Also works well sort of.

However, your solution is soo much *better* and works like charms, thanks a lot!

@maintainers, why not include this functionality into org-mode (most
likely  ‘org-insert-dblock.el’.


Regards

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

worg patch: R usage of :colnames for :results

[Greg Minshall]

hi.  i occasionally need to look up how to get header lines on tables
resulting from an evaluation of an R source block.  the answer is
=:colnames yes=.  here's a patch that minimally documents that.

cheers, Greg

ps -- i have some vague memory i'm supposed to hack in a "woof" header.
but, it's not mentioned on https://orgmode.org/contribute.html so i've
lazily not.

>From e0978a33a70a885db9d3383621c6ccfa97e5519a Mon Sep 17 00:00:00 2001
From: Greg Minshall 
Date: Sun, 26 Sep 2021 17:50:01 +0300
Subject: [PATCH] Add mention of :colnames effect on :results

org-contrib/babel/languages/ob-doc-R.org: added paragraph about effect
of `:colnames' on output.
---
 org-contrib/babel/languages/ob-doc-R.org | 4 
 1 file changed, 4 insertions(+)

diff --git a/org-contrib/babel/languages/ob-doc-R.org b/org-contrib/babel/languages/ob-doc-R.org
index 79d79bf2..16ee2ba6 100644
--- a/org-contrib/babel/languages/ob-doc-R.org
+++ b/org-contrib/babel/languages/ob-doc-R.org
@@ -138,6 +138,10 @@ both 32bit and 64bit binaries. The above path points to the 32bit paths; for
 
 There are no R-specific /default/ header arguments.
 
+The =:colnames= header argument is used to specify that both *input*
+tables (via a =:var= header argument), and output tables (via
+=:results=) (should) have headers.
+
 If a =:file filename.ext= header argument is provided to an R source
 block, then the output from the source block will go to the named
 file. What that output is depends on the value of the =:results=
-- 
2.32.0

Re: ox-taskjuggler scenarios

[Bastien]

Hi,

Tim Cross  writes:

> My guess is that ox-taskjuggler.el is currently lacking an active
> maintainer. Bastien can probably clarify, but I would consider just
> modifying the code to add the missing functionality you need and posting
> some patches. 

ox-taskjuggler.el now lives in https://git.sr.ht/~bzg/org-contrib and
a maintainer is still needed, yet.

-- 
 Bastien

Re: [PATCH] org.el: Use org-contrib module instead of CONTRIB dir in docs

[Bastien]

Max Nikulin  writes:

> Another patch to avoid confusing of users in customization
> interface.

Applied, thanks a lot!

-- 
 Bastien

Re: [patch] priorities range reversed

[Bastien]

Hi Joe,

Joe Corneli via "General discussions about Org-mode."
 writes:

> In the case of numeric priorities [#1] [#9] and so on, there is a test
> that is reversed in org.el.  

See the docstring of `org-priority-highest':

  The highest priority of TODO items.
  
  A character like ?A, ?B, etc., or a numeric value like 1, 2, etc.
  
  The default is the character ?A, which is 65 as a numeric value.
  
  If you set ‘org-priority-highest’ to a numeric value inferior to
  65, Org assumes you want to use digits for the priority cookie.
  If you set it to >=65, Org assumes you want to use alphabetical
  characters.
  
  In both cases, the value of ‘org-priority-highest’ must be
  smaller than ‘org-priority-lowest’: for example, if "A" is the
  highest priority, it is smaller than the lowest "C" priority:
  65 < 67.

Are you sure the numeric value for `org-priority-highest' is smaller
than that of `org-priority-lowest'?

For numeric priorities, [#1] is always "higher" than [#2].

If I'm not wrong and if you think we can throw a more useful error
earlier to the useful, could you provide a patch for this?

Let me know if I'm missing something, thanks,

-- 
 Bastien

Re: [PATCH] extra space at the end of lines in source

[Greg Minshall]

Bastien,

> Applied, thanks!

thank *you*!

[PATCH] org.el: Use org-contrib module instead of CONTRIB dir in docs

[Max Nikulin]

On 07/07/2021 14:23, Michael Maurer wrote:

On Tue, 6 Jul 2021 at 08:07, Michael Maurer wrote:


(setq org-return-follows-link t)
(custom-set-variables
  '(org-modules (quote (org-wikinodes)))
  '(org-return-follows-link t))


Is this deprecated and no longer part of org? I searched the
org-folder for any file resembling wikinodes, but couldn't find
anything.


Another patch to avoid confusing of users in customization interface.
>From 97e1d7548c6b050bc11a452072fb1e0d9032ab23 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Sun, 26 Sep 2021 20:25:14 +0700
Subject: [PATCH] org.el: Use org-contrib module instead of CONTRIB dir in docs

* lisp/org.el (org-modules, org-export-backends): Update docstrings
since CONTRIB directory was transformed into a package in NonGNU ELPA.

Reported by Michael Maurer
https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00195.html
---
 lisp/org.el | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 5379bd297..5ff8990bd 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -689,12 +689,13 @@ defined in org-duration.el.")
 (defcustom org-modules '(ol-doi ol-w3m ol-bbdb ol-bibtex ol-docview ol-gnus ol-info ol-irc ol-mhe ol-rmail ol-eww)
   "Modules that should always be loaded together with org.el.
 
-If a description starts with , the file is not part of Emacs
-and loading it will require that you have downloaded and properly
-installed the Org mode distribution.
+If a description starts with , the file is not part of Emacs and Org mode,
+so loading it will require that you have properly installed org-contrib
+package from NonGNU Emacs Lisp Package Archive
+http://elpa.nongnu.org/nongnu/org-contrib.html
 
 You can also use this system to load external packages (i.e. neither Org
-core modules, nor modules from the CONTRIB directory).  Just add symbols
+core modules, nor org-contrib modules).  Just add symbols
 to the end of the list.  If the package is called org-xyz.el, then you need
 to add the symbol `xyz', and the package must have a call to:
 
@@ -768,9 +769,10 @@ For export specific modules, see also `org-export-backends'."
 (defcustom org-export-backends '(ascii html icalendar latex odt)
   "List of export back-ends that should be always available.
 
-If a description starts with , the file is not part of Emacs
-and loading it will require that you have downloaded and properly
-installed the Org mode distribution.
+If a description starts with , the file is not part of Emacs and Org mode,
+so loading it will require that you have properly installed org-contrib
+package from NonGNU Emacs Lisp Package Archive
+http://elpa.nongnu.org/nongnu/org-contrib.html
 
 Unlike to `org-modules', libraries in this list will not be
 loaded along with Org, but only once the export framework is
-- 
2.25.1

Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Bastien]

Hi Emily,

thanks for your quick feedback!

Emily Bourke  writes:

>> ... did you have time to take a closer look at this?
>
> I’m afraid I haven’t had any look at this since. However, I’ll have
> time tomorrow and later in the week to take a look – will that be
> early enough for the 9.5 release?

Tomorrow for sure, and probably next week will be okay too.

To be clear, I hope we can release 9.5 soon to be able to make it
included in the next Emacs 28.1 version.

Best,

-- 
 Bastien

Re: org-cite not mentioned in ORG-NEWS for 9.5

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> Emmanuel Charpentier (Cc'ed) wrote some nice documentation for this
> feature. He might want to chime in.

that'd be great - thanks in advance Emmanuel!

I'm adding Timothy to the loop: since he's a native english speaker 
and this documentation is a high priority, perhap he can start with
something in both etc/ORG-NEWS and doc/org-manual.org?

The documentation does not need to be exhaustive for Org 9.5, but
we need to have something the users can start with before we merge
Org 9.5 into Emacs master branch, hopefully releasing Org 9.5 with
Emacs 28.1.

Thanks everyone,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien Guerry]

Hi all,

Bastien  writes:

> Less code is less bug and less maintainance.  So I'm considering
> moving these files to the new (unmaintained) org-contrib repo at
> https://git.sr.ht/~bzg/org-contrib:
>
> - ob-abc.el --- Org Babel Functions for ABC
> - ob-asymptote.el --- Babel Functions for Asymptote
> - ob-coq.el --- Babel Functions for Coq
> - ob-ditaa.el --- Babel Functions for ditaa
> - ob-ebnf.el --- Babel Functions for EBNF
> - ob-hledger.el --- Babel Functions for hledger
> - ob-J.el --- Babel Functions for J
> - ob-ledger.el --- Babel Functions for Ledger
> - ob-lilypond.el --- Babel Functions for Lilypond
> - ob-mscgen.el --- Babel Functions for Mscgen
> - ob-picolisp.el --- Babel Functions for Picolisp
> - ob-vala.el --- Babel functions for Vala evaluation

I've made this move now, with the exceptions we discussed in this
thread.

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

Please report anything weird that might happen here.

-- 
 Bastien

Re: [BUG] Conflict between org-emphasis and org-latex

[Juan Manuel Macías]

Hi Léo,

Léo Ackermann writes:

> Hi!
> I noticed that in org@888aaa97c0ce331097787333d0d712dd6e4d078f, the
> following happens:
> When writing `Consider $a^{*}$ and $b^{*}$` in an org-mode buffer, the
> two stars match together, causing "and" to appear in bold case. 
>
> Any idea to fix this unwanted behavior ?

You can insert a zero width space character (U+200B), to prevent that
segment is fontified as emphasis [see the Manual in the section `Escape
Character']. It is enough with insert the character after one of the
asterisks: M-x insert-char RET 200b RET. I also recommend that you look
at this section on Timothy's blog `This Month in Org':
https://blog.tecosaur.com/tmio/2021-05-31-async.html#easy-zero-width

Best regards,

Juan Manuel 

Re: [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)

[Bastien]

Juan Manuel Macías  writes:

> I have consulted the log, and the patch was already applied by Nicololas
> in commit

Oops, sorry for the noise and thanks for confirming!

-- 
 Bastien

Re: [PATCH] Add faces to improve contextuality of agenda views

[Bastien]

Hi Protesilaos,

Protesilaos Stavrou  writes:

> Please find attached the entry for the ORG-NEWS.

Applied, thank you very much!

-- 
 Bastien

Re: [PATCH] Add faces to improve contextuality of agenda views

[Protesilaos Stavrou]

On 2021-09-26, 10:45 +0200, Bastien  wrote:

>> The attached patch defines and implements a few new faces for the
>> agenda.  
>
> Applied, thank you very much for the thorough explanations and the
> well-written patch and commit message.
>
> This deserves an entry in etc/ORG-NEWS for Org 9.5: would you be 
> willing to submit a patch for this?

Hello again Bastien!

Please find attached the entry for the ORG-NEWS.

All the best,
Protesilaos


-- 
Protesilaos Stavrou
https://protesilaos.com

>From ac96612c9e1313ef40fef042c4e79771776423bd Mon Sep 17 00:00:00 2001
Message-Id: 
From: Protesilaos Stavrou 
Date: Sun, 26 Sep 2021 15:27:31 +0300
Subject: [PATCH] Document new agenda faces in the ORG-NEWS

---
 etc/ORG-NEWS | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 80a8bc388..f3cebd836 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -168,6 +168,44 @@ When specifying a custom agenda bulk option, you can now also specify
 a function which collects the arguments to be used with each call to
 the custom function.
 
+*** New faces to improve the contextuality of Org agenda views
+
+Four new faces improve certain styles and offer more flexibility for
+some Org agenda views: ~org-agenda-date-weekend-today~,
+~org-imminent-deadline~, ~org-agenda-structure-secondary~,
+~org-agenda-structure-filter~.  They inherit from existing faces in
+order to remain backward-compatible.
+
+Quoting from [[https://list.orgmode.org/87lf7q7gpq@protesilaos.com/][this thread]]:
+
+#+begin_quote
++ The 'org-imminent-deadline' is useful to disambiguate generic
+  warnings from deadlines.  For example, a warning could be rendered
+  in a yellow colored text and have a bold weight, whereas a deadline
+  might be red and styled with italics.
+
++ The 'org-agenda-structure-filter' applies to all tag/term filters
+  in agenda views that search for keywords or patterns.  It is
+  designed to inherit from 'org-agenda-structure' in addition to the
+  'org-warning' face that was present before (and removes the
+  generic 'warning' face from one place).  This offers the benefit
+  of consistency, as, say, an increase in font height or a change in
+  font family in 'org-agenda-structure' will propagate to the filter
+  as well.  The whole header line thus looks part of a singular
+  design.
+
++ The 'org-agenda-structure-secondary' complements the above for those
+  same views where a description follows the header.  For instance, the
+  tags view provides information to "Press N r" to filter by a
+  numbered tag.  Themes/users may prefer to disambiguate this line
+  from the header above it, such as by using a less intense color or by
+  reducing its height relative to the 'org-agenda-structure'.
+
++ The 'org-agenda-date-weekend-today' provides the option to
+  differentiate the current date on a weekend from the current date on
+  weekdays.
+#+end_quote
+
 *** New option ~org-clock-ask-before-exiting~
 
 By default, a function is now added to ~kill-emacs-query-functions~
-- 
2.33.0

Re: behavior of (org-insert-heading-respect-content)

[Bastien]

Marco Wahl  writes:

> Bastien!
>
>> Marco Wahl  writes:
>>
>>> Would be great if you could test the fix.
>>
>> If you're confident with the fix, please go ahead and push the commit.
>
> This has been committed some days ago.  See
>
> 
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=069bcba529142bdb91647258924513f0fb0f3fa1

Okay, thanks for confirming!

-- 
 Bastien

[BUG] Conflict between org-emphasis and org-latex

[Léo Ackermann]

Hi!
I noticed that in org@888aaa97c0ce331097787333d0d712dd6e4d078f, the
following happens:
When writing `Consider $a^{*}$ and $b^{*}$` in an org-mode buffer, the two
stars match together, causing "and" to appear in bold case.

Any idea to fix this unwanted behavior ?

Thanks for making org-mode better every day!
Leo

Re: [PATCH]

[Timothy]

Hello again,

> I’ve prepared a patch which implements this logic

I've just noticed that I had (when x (if (floatp x) ..)) which is a bit
silly, so I've removed the unnecessary when. Here's the updated patch.

>From 2d8f151bb996e0159793b590baea50c530e3ed11 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 24 Sep 2021 01:39:31 +0800
Subject: [PATCH] org: Display proportional image widths

* lisp/org.el (org-display-inline-images): When the image width is given
as a float less than 2, interpret the value as that portion of the text
area width.  This works well with cases such as "#+attr_latex: :width
0.6\linewidth" as this will now be interpreted as 60% of the text area
width.  The upper bound is set to 2 not 1, as more than 100% of the text
width can be realistic, e.g. "1.2\linewidth" in LaTeX, but more than
200% seems unrealistic.
---
 lisp/org.el | 46 ++
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 66ca73d5e..1a1feda78 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16622,22 +16622,36 @@ (defun org-display-inline-images (&optional include-linked refresh beg end)
 			   (cond
 			((eq org-image-actual-width t) nil)
 			((listp org-image-actual-width)
-			 (or
-			  ;; First try to find a width among
-			  ;; attributes associated to the paragraph
-			  ;; containing link.
-			  (pcase (org-element-lineage link '(paragraph))
-(`nil nil)
-(p
- (let* ((case-fold-search t)
-	(end (org-element-property :post-affiliated p))
-	(re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
-   (when (org-with-point-at
-	 (org-element-property :begin p)
-	   (re-search-forward re end t))
- (string-to-number (match-string 1))
-			  ;; Otherwise, fall-back to provided number.
-			  (car org-image-actual-width)))
+ (let ((width
+(or
+ ;; First try to find a width among
+ ;; attributes associated to the paragraph
+ ;; containing link.
+ (pcase (org-element-lineage link '(paragraph))
+   (`nil nil)
+   (par (let* ((case-fold-search t)
+   (end (org-element-property :post-affiliated par))
+   (re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
+  (when (org-with-point-at
+(org-element-property :begin par)
+  (re-search-forward re end t))
+(string-to-number (match-string 1)))
+;; Otherwise, fall-back to provided number.
+(car org-image-actual-width
+ (if (and (floatp width) (<= 0 width 2.0))
+ ;; A float in [0,2] should be interpereted as this portion of
+ ;; the text width in the window.  This works well with cases like
+ ;; #+attr_latex: :width 0.X\{line,page,column,etc.}width,
+ ;; as the "0.X" is pulled out as a float.  We use 2 as the upper
+ ;; bound as cases such as 1.2\linewidth are feasible.
+ (round (* width
+   (window-pixel-width)
+   (/ (or (and (bound-and-true-p visual-fill-column-mode)
+   (or visual-fill-column-width auto-fill-function))
+  (when auto-fill-function fill-column)
+  (window-text-width))
+  (float (window-total-width)
+   width))
 			((numberp org-image-actual-width)
 			 org-image-actual-width)
 			(t nil)))
-- 
2.33.0

Re: behavior of (org-insert-heading-respect-content)

[Marco Wahl]

Bastien!

> Marco Wahl  writes:
>
>> Would be great if you could test the fix.
>
> If you're confident with the fix, please go ahead and push the commit.

This has been committed some days ago.  See


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

Re: [Worg] Proposing a few CSS changes

[Max Nikulin]

On 26/09/2021 02:51, Timothy wrote:


I’m a big fan of the shift to a fixed em-based max width. However, I’m not quite
sold on a few of the other changes, for instance the font change. While it does
vary, I must say than in particular I find the default serifed font of browsers
somewhat unattractive. Have you considered instead a sans-serif system font
stack? For example, this is what I used on the homepage:
┌
│ -apple-system, BlinkMacSystemFont, San Francisco, Helvetica Neue, Helvetica, 
Ubuntu, Roboto, Noto, Segoe UI, Arial, sans-serif;
└


Sorry if it is a false alarm, I do not have enough experience with CSS.

Since "Noto Serif" font exist, is just "Noto" enough to select namely 
"Noto Sans"?


Concerning "em" and "rem", I may be wrong, but Chromium on Linux may 
apply font settings from desktop theme to  element, while "rem" 
units are based on  element. So using rem for max-width and 
leaving font-size to user defaults may result in too narrow or too wide 
text column. Unsure if values like "larger" are more "portable" for 
font-size of header elements.


Modern browsers support light and dark themes. I can not suggest CSS 
snippets for that since I have never played with such selectors yet.


I do not know what is the proper balance of overriding of defaults. I 
consider default built-in styles as compatibility mode with old pages. 
That is why I do not think that relying on default styles only (even 
some users customize them) is a good idea. Absolute font size may be 
left as in user preferences.

Re: [PATCH]

[Timothy]

How on earth did I remember to start writing the subject, then switch to the
message, and forget to finish it... (sigh). Ooops.

--
Timothy

[PATCH]

[Timothy]

Hi Everyone,

I’ve recently been wondering why it is that for sensibly sized images in a
LaTeX-export-oriented document I need to do both:
┌
│ #+attr_org: :width 400
│ #+attr_latex: :width 0.4\linewidth
└

When in HTML, just
┌
│ #+attr_html: :width 400px
└
is fine.

This has lead me to have a look at `org-display-inline-images', and I’ve 
realised
that the `#+attr_latex' width of `0.4\linewidth' is actually picked up, and
interpreted as a width of `0.4' pixels. I think it would make much more sense 
for
fractional values between zero and one to be interpreted as that portion of the
text width in the buffer. On second thoughts, given that the document width can
be slightly larger than the text width, perhaps an upper bound just a bit higher
— say 2, could be better.

I’ve prepared a patch which implements this logic, by converting extracted
widths that are:
⁃ floats, and
⁃ within the range [0,2]
and sizes them as that proportion of the text width in the buffer, which is
determined by checking
1. `visual-fill-column-width', when that package is installed and the mode 
active
2. `fill-column', when auto fill is active
3. `(window-text-width)', if neither of the above two cases hold

Please let me know what you think 🙂.

All the best,
Timothy
>From bc8aa862f513946599efe4a9bb420e54c504ab3b Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 24 Sep 2021 01:39:31 +0800
Subject: [PATCH] org: Display proportional image widths

* lisp/org.el (org-display-inline-images): When the image width is given
as a float less than 2, interpret the value as that portion of the text
area width.  This works well with cases such as "#+attr_latex: :width
0.6\linewidth" as this will now be interpreted as 60% of the text area
width.  The upper bound is set to 2 not 1, as more than 100% of the text
width can be realistic, e.g. "1.2\linewidth" in LaTeX, but more than
200% seems unrealistic.
---
 lisp/org.el | 47 +++
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 66ca73d5e..ce2ac7404 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16622,22 +16622,37 @@ (defun org-display-inline-images (&optional include-linked refresh beg end)
 			   (cond
 			((eq org-image-actual-width t) nil)
 			((listp org-image-actual-width)
-			 (or
-			  ;; First try to find a width among
-			  ;; attributes associated to the paragraph
-			  ;; containing link.
-			  (pcase (org-element-lineage link '(paragraph))
-(`nil nil)
-(p
- (let* ((case-fold-search t)
-	(end (org-element-property :post-affiliated p))
-	(re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
-   (when (org-with-point-at
-	 (org-element-property :begin p)
-	   (re-search-forward re end t))
- (string-to-number (match-string 1))
-			  ;; Otherwise, fall-back to provided number.
-			  (car org-image-actual-width)))
+ (let ((width
+(or
+ ;; First try to find a width among
+ ;; attributes associated to the paragraph
+ ;; containing link.
+ (pcase (org-element-lineage link '(paragraph))
+   (`nil nil)
+   (par (let* ((case-fold-search t)
+   (end (org-element-property :post-affiliated par))
+   (re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)"))
+  (when (org-with-point-at
+(org-element-property :begin par)
+  (re-search-forward re end t))
+(string-to-number (match-string 1)))
+;; Otherwise, fall-back to provided number.
+(car org-image-actual-width
+   (when width
+ (if (and (floatp width) (<= 0 width 2.0))
+ ;; A float in [0,2] should be interpereted as this portion of
+ ;; the text width in the window.  This works well with cases like
+ ;; #+attr_latex: :width 0.X\{line,page,column,etc.}width,
+ ;; as the "0.X" is pulled out as a float.  We use 2 as the upper
+ ;; bound as cases such as 1.2\linewidth are feasible.
+ (round (* width
+   (window-pixel-width)
+   (/ (or (and (bound-and-true-p visual-fill-column-mo

Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Emily Bourke]

Hi Bastien,

Thanks for getting in touch!

> ... did you have time to take a closer look at this?

I’m afraid I haven’t had any look at this since. However, I’ll have time 
tomorrow and later in the week to take a look – will that be early enough for 
the 9.5 release?

Best wishes,
Emily

Re: Org branches: master, main, and maint?

[Max Nikulin]

On 26/09/2021 17:31, Bastien wrote:

Timothy writes:


I’ve just had a look at the branches, and I see that we currently
have

 master
 main
 maint


You probably listed your local branch with "git branch -a" or by
checking your .git/config file.

If you clone a fresh repo like this:

~$ git clone https://git.savannah.gnu.org/git/emacs/org-mode.git

and fetch all the branches (git fetch --all) you should only see
the three branches mentioned above.


git fetch --prune

might help to keep personal local branches but to remove non-existing 
remote ones if you changed URL of origin repository. I renamed old 
"origin" and added new one with savannah URL, so each repository has its 
own branch (That is why I may be a bit wrong concerning exact behavior 
of --prune in this case).

Re: [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)

[Juan Manuel Macías]

Hi Bastien, thank you for your message,

Bastien writes:

> I could not apply the patch in the bugfix or main branch.  Is it still
> relevant?  If the bug is still here, feel free to send an updated patch.

I have consulted the log, and the patch was already applied by Nicololas
in commit:

40a20136d * | | Prevent partial fontification when a link is displayed full

Best regards,

Juan Manuel 

Re: list re-numbering not working in odt export

[Bastien]

Hi Rob,

Rob Sargent  writes:

> It appears to me that explicitly setting list order number is not
> honoured by the odt export mechanism.  The following works on latex
> (list numbering starts at 7) but not on odt (list numbering starts at
> one though the [@7] is stripped from the output (as expect)):
>
> 1. [@7](/facilities/) The tangible compute infrastructure
> employed by SGSaaS is entirely ...
>
> I am using org version 9.1.9 and libre office version 6.4.7.2

What happens if you manually fix the list numbering *within* your Org
buffer before exporting it?

It works fine here, and ox-odt.el honors the in-buffer numbers.

I think it's fine to expect the buffer to be up to date before it is
exported.

Thanks,

-- 
 Bastien

Re: [PATCH] Bug: No highlighting after [9.4.6 (release_9.4.6-544-gc5573b @ /home/user/.emacs.d/straight/build/org/)]

[Bastien]

Hi Sébastien,

Sébastien Miquel  writes:

> Thanks for the report, I can confirm this bug with latest org.
>
> Here's a patch that fixes this.

Applied, thanks.

-- 
 Bastien

Re: Bug: Fontify error with markdown source block [9.4.4 (release_9.4.4 @ /usr/share/emacs/28.0.50/lisp/org/)]

[Bastien]

Timothy  writes:

>> After you send it here, you can push to bugfix and merge the bugfix
>> branch into main.
>
> I’ll do exactly this shortly.

Thanks!

-- 
 Bastien

Re: behavior of (org-insert-heading-respect-content)

[Bastien]

Hi Marco,

Marco Wahl  writes:

> Would be great if you could test the fix.

If you're confident with the fix, please go ahead and push the commit.

Thanks,

-- 
 Bastien

Re: Suggestions for improved suffix parsing in oc-biblatex

[Bastien]

Hi Denis,

Denis Maier  writes:

> I think the suffix parsing in oc-biblatex could be improved. 

Can you provide a patch for this?

-- 
 Bastien

Re: Bug: Fontify error with markdown source block [9.4.4 (release_9.4.4 @ /usr/share/emacs/28.0.50/lisp/org/)]

[Timothy]

Hi  Bastien,

> Okay - can you post the patch in this thread?

Ahh, I forgot to attach it didn’t I. You should find it attached to this 
message.

> After you send it here, you can push to bugfix and merge the bugfix
> branch into main.

I’ll do exactly this shortly.

> You can also add the X-Woof-Patch: applied header to your reply.

I fully intend to 😀. In fact, I’ve recently made this much easier for myself
().
In case this is of interest:


All the best,
Timothy
>From 0c3571097bda58d1ef0fd0554322a42ff7068a67 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 17 Sep 2021 17:23:58 +0800
Subject: [PATCH 1/6] org: Fix potential modified src match-data issue

* lisp/org.el (org-fontify-meta-lines-and-blocks-1): When this is run on
a src block, a "leaky" major mode called in
`org-src-font-lock-fontify-block' can modify the match data.
This is problematic, as the match data already set is important for
font-lock.  To protect ourselves from this behaviour, we can wrap
`org-src-font-lock-fontify-block' in `save-match-data' to ensure that
the match data for the src block is conserved.
---
 lisp/org.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 733dda429..64f82b5ee 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5330,7 +5330,8 @@ (defun org-fontify-meta-lines-and-blocks-1 (limit)
 	(org-remove-flyspell-overlays-in nl-before-endline end-of-endline)
 	(cond
 	 ((and lang (not (string= lang "")) org-src-fontify-natively)
-	  (org-src-font-lock-fontify-block lang block-start block-end)
+	  (save-match-data
+(org-src-font-lock-fontify-block lang block-start block-end))
 	  (add-text-properties bol-after-beginline block-end '(src-block t)))
 	 (quoting
 	  (add-text-properties
-- 
2.33.0

Re: Org branches: master, main, and maint?

[Timothy]

Hi  Bastien,

> You probably listed your local branch with “git branch -a” or by
> checking your .git/config file.
>
> If you clone a fresh repo like this:
>
> ~$ git clone 
>
> and fetch all the branches (git fetch –all) you should only see
> the three branches mentioned above.
>
> Also, you can now forget code.orgmode.org, I’ve prevented any
> push there.

Yep, I think this was some sort of git leftovers. I’ve done a fresh clone and
I’m now seeing about half as many `origin/*' branches, which I’d consider to be 
a
success. Thanks for clearing this up Bastien 🙂.

All the best,
Timothy

Re: [PATCH] Re: org-bibtex does not recognise @Comment

[Colin Baxter]

> Bastien   writes:

> Hi Ihor, Ihor Radchenko  writes:

>> Colin Baxter  writes:
>> 
>>> I've noticed that "org-bibtex-import-from-file" will not import
>>> from bib files which begin with the standard bibtex mode-line
>>> heading of
>>> 
>>> @Comment -*- mode: bibtex; -*-
>> 
>> Well. It will import the files. However, org-bibtex-write will
>> indeed fail. If I got it wrong, please provide more details.

> Applied, thanks!

> -- Bastien

Great! Thanks Bastien.

Re: [Worg] Proposing a few CSS changes

[Stefan Nobis]

Timothy  writes:

> I don’t think a completely spartan page is entirely sensible though.

Indeed! I did not want to argue for all or nothing. :)

But font and font size for big chunks of text are quite important and
individual choices. So the rest of the styling should try to be
flexible enough to support different user choices as good as possible.

BTW: I like your design for the Org homepage. My thoughts should only
be seen as a very light weight on Adams side when trying to balancing
the scale of the multitude of styling choices. :)

-- 
Until the next mail...,
Stefan.

Re: [wip-cite-new] Quick note about citation insertion

[Bastien]

Hi all,

I'm marking the upstream bug as closed - feel free to resubmit it if
I misread the thread.

Thanks,

-- 
 Bastien

Re: [PATCH] org-cite: Use citeproc-el to create CSL processor itemgetters

[Bastien]

Hi András,

András Simonyi  writes:

> this is the first item in a series of oc-csl patches which I've
> accumulated and am planning to send this week. (My first attempt to
> send a patch, so please be patient and forgiving :-) )

Thanks for your patch! I just applied it in the main branch.

-- 
 Bastien

Re: Org branches: master, main, and maint?

[Bastien]

Hi Timothy,

Timothy  writes:

> I’ve just had a look at the branches, and I see that we currently
> have
>
> master
> main
> maint

Nope, the official source repository contains 

- main : the development branch (aka the old "master")
- bugfix : the bugfix branch (aka the old "maint")
- km/from-master-emacs : the branch to help with Emacs sync

> My previous impression was that master was the main development
> branch, and maint was for testing (though I wasn’t 100% sure).
> However now there’s master, main, and maint I’m feeling a bit unsure
> of what exactly is going on.
>
> A clarification would be much appreciated 🙂.

You probably listed your local branch with "git branch -a" or by
checking your .git/config file.  

If you clone a fresh repo like this:

~$ git clone https://git.savannah.gnu.org/git/emacs/org-mode.git

and fetch all the branches (git fetch --all) you should only see
the three branches mentioned above.

Also, you can now forget code.orgmode.org, I've prevented any
push there.

HTH,

-- 
 Bastien

Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing

[Bastien]

Hi Emily,

sorry to bump an old thread...

Emily Bourke  writes:

> I'm afraid I haven't had a chance to look at this any further since
> my last email. I'll try to find some time this week.

... did you have time to take a closer look at this?

We are working on preparing Org 9.5, hopefully releasing it quite
soon, it would be great if we can apply and test your patch before
that.

Thanks a lot!

-- 
 Bastien

Org branches: master, main, and maint?

[Timothy]

Hello,

I’ve just had a look at the branches, and I see that we currently have
⁃ master
⁃ main
⁃ maint

My previous impression was that `master' was the main development branch, and
`maint' was for testing (though I wasn’t 100% sure). However now there’s 
`master',
`main', and `maint' I’m feeling a bit unsure of what exactly is going on.

A clarification would be much appreciated 🙂.

All the best,
Timothy

Re: Bug: Fontify error with markdown source block [9.4.4 (release_9.4.4 @ /usr/share/emacs/28.0.50/lisp/org/)]

[Bastien]

Hi Timothy,

Timothy  writes:

> I’ve just written a proper commit message for this, and in the
> process realised that I wasn’t actually dealing with this the best
> way — and so amended my fix to something I’m fairly happy with.

Okay - can you post the patch in this thread?

> I haven’t pushed to the bugfix branch before, should I immediately
> merge the change into master too, or just leave it in bugfix only?

After you send it here, you can push to bugfix and merge the bugfix
branch into main.

You can also add the X-Woof-Patch: applied header to your reply.

Thanks,

-- 
 Bastien

Re: Bug: Fontify error with markdown source block [9.4.4 (release_9.4.4 @ /usr/share/emacs/28.0.50/lisp/org/)]

[Timothy]

Hi  Bastien,

> Can you commit a proper patch to the bugfix branch, with a comment in
> the code explaining why this is a catch-all hack?

I’ve just written a proper commit message for this, and in the process realised
that I wasn’t actually dealing with this the best way — and so amended my fix
to something I’m fairly happy with. I haven’t pushed to the bugfix branch
before, should I immediately merge the change into master too, or just leave it
in bugfix only?

All the best,
Timothy

Re: shrink table in columnmode view (poor man's issue system)

[Marco Wahl]

Hi!

Uwe Brauer  writes:
> I use the following org file to organise my issues.
> It works quite well, however I would like to have a shrink option
> automatically in my columnview.

Your suggestion looks quite useful to me.

> Any idea how to achieve that?

One possibility is to write your own dynamic block writer function.
Find documentation at (info "(org) Dynamic Blocks") .

> File starts here:
>
> #+begin_src 
> #+STARTUP: shrink
>
> * Issues
>:PROPERTIES:
>:COLUMNS:  %50ITEM(Problem) %10Is(Issue Nr) %7TODO(Status) %26TAGS(Which) 
> %17Date(Date) %7STATUS(Status){X/} 
>:ID:   Issues
>:END:
>
> ** TODO Why is  \eqref{eq:section4-sh15}: not used in the proof of 
> proposition 5 (section 4)
>:PROPERTIES:
>:ID:   Issues
>:Date: <2021-09-25 sáb>
>:STATUS:   [ ]
>:Is:   9
>:END:
>
> The table is generated like this
> #+BEGIN: columnview  :hlines 2 :skip-empty-rows t :indent nil  :format 
> "%5ITEM(Problem) %5Is(Issue) %12TODO  %12Date %7Status(Status){X/}"
> | Problem 
>  | Issue | TODO | Date | Status |
> |--+---+--+--+|
> | Issues  
>  |   |  |  | [0/1]  |
> |--+---+--+--+|
> | Why is  \eqref{eq:section4-sh15}: not used in the proof of proposition 5 
> (section 4) | 9 | TODO | <2021-09-25 sáb> | [ ]|
> #+END:
>
>
> But I would like to have this
>
> #+BEGIN: columnview  :hlines 2 :skip-empty-rows t :indent nil  :format 
> "%5ITEM(Problem) %5Is(Issue) %12TODO  %12Date %7Status(Status){X/}"
> |<45>
> | Problem 
>  | Issue | TODO | Date | Status |
> |--+---+--+--+|
> | Issues  
>  |   |  |  | [0/1]  |
> |--+---+--+--+|
> | Why is  \eqref{eq:section4-sh15}: not used in the proof of proposition 5 
> (section 4) | 9 | TODO | <2021-09-25 sáb> | [ ]|
> #+END:
>
> #+end_src 

Concretely check out this proposition (tested with your example).  Have

(defun org-dblock-write:columnview2 (params)
  "Write the column view table.

Like org-dblock-write:columnview but write a line with shrink widths 
taken from the
column view format.

PARAMS is the same as in `org-dblock-write:columnview'."
  (insert (format "|%s|\n"
  (mapconcat
   (lambda (x) (concat "<" (number-to-string x) ">"))
   (mapcar (lambda (x) (nth 2 x)) 
(org-columns-compile-format
  (plist-get params 
:format)))
   "|")))
  (org-dblock-write:columnview params))

defined.  E.g. type C-x C-e after the last paren.

Then use "columnview2" instead of "columnview" and get

#+BEGIN: columnview2  :hlines 2 :skip-empty-rows t :indent nil  :format 
"%5ITEM(Problem) %5Is(Issue) %12TODO  %12Date %7Status(Status){X/}"
| <5>   
   | <5>   | <12> | <12> | <7>|
| Problem   
   | Issue | TODO | Date | Status |
|--+---+--+--+|
| Issues
   |   |  |  | [0/1]  |
|--+---+--+--+|
| Why is  \eqref{eq:section4-sh15}: not used in the proof of proposition 5 
(section 4) | 9 | TODO | <2021-09-25 sáb> | [ ]|
#+END:


HTH

BUG Visibility Cycling with inline tasks

[Michael Dauer]

Hi,

I resend my report with now hopefully all information to reproduce it
quickly.

Inline tasks are a great feature of org-mode, very useful to include tasks
in all sorts of documents without interfering with the document structure.

0. emacs -Q
1. Insert the below snippet into scratch buffer.
>>>
* Example
** heading 1
x
** heading 2
*** TODO Test access with provided credentials
x
*** END
** heading 3
*** TODO State "high value" targets
x
*** END
** heading 4
x

(org-mode)
(require 'org-inlinetask)
<<<

2. Execute each of the 2 elisp statements at the bottom (C-x C-e)
3. Cycle Example to show children
4. Cycle heading 2

This should show the issue: Parts of heading 3 are expanded too. This is
also true for the next to cycling steps. Then comes a correct full cycle
and the issue repeats.

This garbage shown from the next heading(s) can become huge in more complex
structures.

Org mode version 9.4.6 (9.4.6-gcf30f7

Please confirm the issue.

Regards,
Michael

Re: Bug: Fontify error with markdown source block [9.4.4 (release_9.4.4 @ /usr/share/emacs/28.0.50/lisp/org/)]

[Bastien]

Hi Timothy,

Timothy  writes:

> I’ve prepared a patch that serves as a catch-all for this type of issue, but 
> I’m
> not sure if this is the best approach. 

Can you commit a proper patch to the bugfix branch, with a comment in
the code explaining why this is a catch-all hack?

Also, if someone can report the bug upstream for markdown-mode, that
be great.

Thanks!

-- 
 Bastien

Re: [PATCH] ob-R output file with graphics parameter

[Bastien]

Hi Jeremie,

Jeremie Juste  writes:

> The patch is redundant in its present state. In it's present state,
> ob-R is better without it.

Thanks!  I'm marking it as "canceled" then.

-- 
 Bastien

Re: [PATCH] Rename headline to heading

[Bastien]

Hi André,

André A. Gomes  writes:

> As previously discussed, please find the patch below.

I agree this change is a welcome improvement: thanks a lot for working
on this patch.  I would like to suggest a step by step approach:

1. Updating occurrences in the documentation: manual, guide,
   docstrings, worg occurences, etc.

2. Updating Org internals without impacting users' configuration
   (i.e. update the functions and variables name, but don't update
   the "file+headline" config string.)

3. If the "file+headline" config string is the only part of a config
   that can be impacted by this change, support both the new and old
   strings for backward compatibility.

We don't need a transition period for the first two changes, and we
don't need one either for the third one if we implement the backward
compatible solution.  We need a transition period if we remove it, but
I'm not convinced removing it is really needed now.

What do you think?

-- 
 Bastien

Re: [Worg] Proposing a few CSS changes

[Timothy]

Hi  Stefan,


Stefan Nobis  writes:

> [*snip*]
> Therefore I support Adams wish to honor the configuration of users.

Thanks for chiming in Stefan, I’m coming around to the parts of the view you and
Adam seem to share. I’m now thinking that with the font, font size, and viewport
settings, that it would make sense for Worg to just use the Browser default.

I don’t think a completely spartan page is entirely sensible though. IMO it’s
probably worth doing more to create visual links to the rest of the Org site —
I think there’s value in maintaining broad consistent stylistic choices. It
gives a sense of cohesion to the site, and as much as I’m loath to say it, helps
with “brand identity”. I think we should be able to implement some tweaks along
these lines that don’t just steamroll user preferences, where they are set.

> The web should be more seen as a documentation system, not an
> installation of art.

Style should certainly not impede the accessibility of the pages, however even a
dry technical document has stylistic choices, and I don’t think we should shy
away from that.

That’s my 2c. Anyway, back to the specific changes proposed by Adam, my current
thoughts are:

• Yes to the font, font-size, margin, and padding changes
• Still a big fan of the 60em font width. I do think 60rem may be a tad
  more sensible, but it probably makes no difference
• Change the headings to Org dark green coloured instead of default/black
• In a similar vein, maybe the link styling from  could 
also
  be copied over?

All the best,
Timothy

Re: [PATCH] ob-R output file with graphics parameter

[Jeremie Juste]

Hello Bastien,

On Sunday, 26 Sep 2021 at 10:48, Bastien wrote:
> What is the status of this patch?  Should it be more tested?  If it is
> ready, feel free to apply it in the main branch.

The patch is redundant in its present state. In it's present state,
ob-R is better without it.

Thanks,
Jeremie

Re: [PATCH] Fixed lstset where language= wipes out previous definitions

[Bastien]

Hi Karl,

can you expand a bit more on why this patch would be useful?  Perhaps
by providing a reproducible use-case where the problem appears?

Thanks,

-- 
 Bastien

Re: [new patch] Re: [PATCH] make org-notify support for macOS desktop notification

[Bastien]

Hi,

stardiviner  writes:

> Here is the new patch which invokes notifications though Emacs
> built-in API `ns-do-applescript`.

Applied in the main branch, thanks.

-- 
 Bastien

Re: [PATCH] ob-R output file with graphics parameter

[Bastien]

Hi Jeremie,

Jeremie Juste  writes:

> With the following patch the link to graphics output is finally back on
> with R source code.

What is the status of this patch?  Should it be more tested?  If it is
ready, feel free to apply it in the main branch.

Thanks!

-- 
 Bastien

Re: Empty headline titles unsupported: Bug?

[Bastien]

Hi all,

Ihor Radchenko  writes:

> Yet, why not simply alter the headline parser a little bit to support
> empty titles + tag? Such headlines are used in some of the tests. See
> the attached patch.

I'm in favor of this change...

Nicolas Goaziou  writes:

> Because, as I wrote, this is ambiguous. You cannot distinguish the
> following two cases:
>
>   * :mytag:
>   * :myheadline:

... because I'm not convinced by the above example: I agree this is
syntactically ambiguous, but as a human I would understand that Org
would parse

  * :myheadline:

as [beginning of a headline + empty heading + tag].

> So, your patch would only move the problem elsewhere. 

Nicolas, do you strongly feel against this change?  Is moving the
problem elsewhere is creating more problems I might have overlooked?

> I suggest to not tag emptiness. 

I'd rather allow empty headlines with tags, this seems a useful way
of filtering/searching contents.

WDYT?

-- 
 Bastien

Re: [PATCH] Add faces to improve contextuality of agenda views

[Protesilaos Stavrou]

On 2021-09-26, 10:45 +0200, Bastien  wrote:

>> The attached patch defines and implements a few new faces for the
>> agenda.  
>
> Applied, thank you very much for the thorough explanations and the
> well-written patch and commit message.

Thank you, Bastien (for this and for maintaining Org in general)!

> This deserves an entry in etc/ORG-NEWS for Org 9.5: would you be 
> willing to submit a patch for this?

Yes, I will prepare one, though I am committed to a task right now and
will only be available again in ~3 hours.

-- 
Protesilaos Stavrou
https://protesilaos.com

Re: [PATCH] Add faces to improve contextuality of agenda views

[Bastien]

Hi Protesilaos,

> The attached patch defines and implements a few new faces for the
> agenda.  

Applied, thank you very much for the thorough explanations and the
well-written patch and commit message.

This deserves an entry in etc/ORG-NEWS for Org 9.5: would you be 
willing to submit a patch for this?

Thanks!

-- 
 Bastien

Re: bug#47885: [PATCH] org-table-import: Make it more smarter for interactive use

[Bastien]

Hi,

I lost track of the discussion in this thread.  

My understanding is that there is no agreement on what feature 
should be added to Org regarding "smarter interactive table import"
and a patch is not yet ready for the suggested feature.

I'm marking this as canceled on updates.orgmode.org but feel free
to correct me if needed.

Thanks,

-- 
 Bastien

Re: [Worg] Proposing a few CSS changes

[Stefan Nobis]

Adam Porter  writes:

> So I think it's very important to respect the user's settings,
> especially for long texts and documentation (i.e. not the "home page"
> parts of Web sites whose purpose is to present projects as a whole).

+1.

HTML pages are neither books nor PDFs nor advertising columns. I have
a LaTeX background and I like to tweak the micro-typography of my PDF
documents (and I find many documents out there quite ugly and hard to
read). Therefore I think I understand and kind of sympathize with
Timothoys point of view.

But the web is quite a different beast. User choices like
Window/viewport size, fonts (serif, non-serif, size,...) are way too
often ignored and even battled against. Sometimes I get the
impression, that every time a web designer gets informed about a new
way for users to override design decisions they try to block these
possibilities - and in most cases to the disadvantage of users.

Yes, today seldom people play with the font settings in their
browsers. But why? I think, because they see that these settings seem
to never really work. Even if you configure your browser to ignore
font settings from HTML/CSS and always use the browser settings, many
pages will be next to unreadable - the layout breaks down, if the
wrong fonts/sizes are used.

Therefore I support Adams wish to honor the configuration of users.
The web should be more seen as a documentation system, not an
installation of art.

-- 
Until the next mail...,
Stefan.

Re: babel default header args as functions

[Bastien]

Hi Matt,

Matt Huszagh  writes:

> Matt Huszagh  writes:
>
>> I've generated a patch for this. Please let me know your thoughts. I
>> believe this adds valuable flexibility to default header
>> arguments.
>
> I've added an additional fix that makes this work during export too.

Applied, thanks, and sorry again for the lng delay.

It deserves an entry in etc/ORG-NEWS for Org 9.5, would you be willing
to submit a patch for this?

Thanks,

-- 
 Bastien

Re: Moving some lisp/ob-*.el files to org-contrib - your advice?

[Bastien]

Allo Arne,

"Dr. Arne Babenhauserheide"  writes:

> Bastien  writes:
>
>> Less code is less bug and less maintainance.  So I'm considering
>> moving these files to the new (unmaintained) org-contrib repo at
>> https://git.sr.ht/~bzg/org-contrib:
>>
>> - ob-ditaa.el --- Babel Functions for ditaa
>
> This is well-established, and once I have my paperwork in place I would
> offer maintenance, because this is a major part of the lectures I write
> in org-mode.

Thanks again for offering your help.

Did you go through the copyright assignment process?  I can't see your
name in the FSF copyright file.

Let me know how it goes, and please CC me if you ping the FSF
copyright clerk at 

Thanks,

-- 
 Bastien

Re: [PATCH] org.el: use only link descriptions in indirect buffer names

[Bastien]

Hi Juan,

Juan Manuel Macías  writes:

> (new patch attached)

I see this patch has been applied, thanks to both of you.

I'm marking it as applied for updates.orgmode.org.

-- 
 Bastien

Re: org-collector.el does not deal with inherited properties well

[Bastien]

Vikas Rawal  writes:

> I can contribute by way
> of helping with documentation, if you need that for any part of org.

Yes, that's always helpful.  Thanks,

-- 
 Bastien

Re: [BUG] org-compile-prefix-format regexp change breaks eval forms [9.4.6 (9.4.6-gf72a65)]

[Bastien]

Ihor Radchenko  writes:

> Thanks for the suggestion! The patch is attached.

Applied, thanks.

-- 
 Bastien

Re: [PATCH] Re: Bug: `org-fill-paragraph' relies on M-q being bound to `fill-paragraph' [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/mwj/.emacs.d/elpa/org-20210809/)]

[Bastien]

Ihor Radchenko  writes:

> The attached is patch solving the "M-q" problem and making sure the
> org-fill-paragraph returns non-nil.

Applied, thanks!

-- 
 Bastien

Re: [PATCH] Re: [bug] Setting org-id-link-to-org-use-id to t creates IDs properties when tangling

[Bastien]

Ihor Radchenko  writes:

> The fix is attached.

Applied, thanks!

-- 
 Bastien

Re: org-collector.el does not deal with inherited properties well

[Vikas Rawal]

>
> By the way, org-collector.el is now part of org-contrib and in
> lack of a maintainer.
>
> If you feel like you can maintain it or can help looking for a
> maintainer, please go wild.

I am not a big user of org-collector.el. I was only trying it for an
exercise, which I have abandoned because of lack of much interest
among others in my research group.

In any case, I hardly know lisp, and would not be able to either fix
things or review code contributed by others. I can contribute by way
of helping with documentation, if you need that for any part of org.

Vikas

Re: [PATCH] Re: org-bibtex does not recognise @Comment

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> Colin Baxter  writes:
>
>> I've noticed that "org-bibtex-import-from-file" will not import from bib 
>> files
>> which begin with the standard bibtex mode-line heading of
>>
>> @Comment -*- mode: bibtex; -*-
>
> Well. It will import the files. However, org-bibtex-write will indeed
> fail. If I got it wrong, please provide more details.

Applied, thanks!

-- 
 Bastien

Re: Sad tweet

[Corwin Brust]

I screen capped this from a non-free tool I've been using because some
of us our lazy when we must be stubborn, and anyway, hth:

https://bru.st/i/Discord_RVagphlqok.png

On Sun, May 23, 2021 at 4:29 PM Ypo  wrote:
>
> I've read this:
>
> "Contributing to Emacs is so frustrating. It's not worth it for minor things 
> and if I cannot get some experience and confidence with minor things, then I 
> likely won't ever make major contributions."
> https://twitter.com/magit_emacs/status/1396536686570610697?s=19



-- 
Corwin
612-217-1742
612-695-4276 (signal)
cor...@bru.st