[PATCH] Prevent displayed images from being re-scaled

[Timothy]

Hello,

After my last patch providing support for proportional image width attributes
(e.g. 70% of the text width), I noticed that the results looked slightly off.
Investigating the code lead me to `create-image' which takes the liberty of
re-scaling images based on your default font size. As you might imagine, this
can be problematic when if you say determine that image should be 70% of the
text width, the text width is 1000px, and so the image should be 700px wide —
but upon being told to make the image 700 pixels wide `create-image' decides to
make it say 850 pixels wide. I personally found that images >~80% wide were
being made wider than the buffer, which isn’t good.

To make image width behave as expected, we can just specify `:scale 1' when
calling `create-image', and that will stop it from re-interpreting the `:width'
specification. See the patch attached.

All the best,
Timothy
>From 9c34dd6aba62d734f6ae9aecaffa76a0250bf495 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 29 Sep 2021 21:29:27 +0800
Subject: [PATCH] org: Don't change image size based on font size

* lisp/org.el (org--create-inline-image): When `create-image' is called
without the :scale parameter, the image size is expanded based on the
default font size (if it is larger than 10px).  When displaying images
with a specified width in Org buffers, either in pixels or proportional
to the text width, this width should not be modified according the to
font size.  Giving a :scale parameter of 1 prevents this font-size based
rescaling.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 2ec6566c0..0e7f926f0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16518,7 +16518,7 @@ (defun org--create-inline-image (file width)
 			 width
 			 'imagemagick)
 		remote?
-		:width width
+		:width width :scale 1
 
 (defun org-display-inline-images (&optional include-linked refresh beg end)
   "Display inline images.
-- 
2.33.0

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Timothy]

Hi  Jeremy,

> As an org user I would expect :tangle-mode 0660 to produce a file that
> has user rw, group rw, other nothing. Instead, what really happens
> currently is 0660 is treated as an integer which is actually
> 3140. This produces unexpected file permissions.

I agree that :tangle-mode could be more user-friendly. However, I think we can
go further. Currently, only (identity #o755 / 493) works, however I think it 
would be
good if it worked like chmod and accepted most of the following forms:
⁃ `#o755'
⁃ `755' (because people are used to this, as technically misleading as it may 
be,
  as long as we can tell “:tangle-mode 356” from “:tangle-mode (identity 
#o544)”)
⁃ `rw' (equivalent to a=rw, and so #o555)
⁃ `a=rw,u+x' (equivalent to #o755) [hardest to support, so maybe?]

And then I’d also be in favour of accepting
⁃ `rw-r--r--' (equivalent to #o544)

I think as long as it’s clear what’s intended, and it’s not some home-baked
non-standard format, or terribly annoying to support — why not?

All the best,
Timothy

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Timothy]

 writes:

> So you favour going the "full custom special parser". You're much more
> involved in Org, so I think your gut feeling counts more than mine here :)

Well, I'm not sure that my feeling is representative of experienced Org users,
my opinion basically boils down to:

>> I think as long as it’s clear what’s intended, and it’s not some home-baked
>> non-standard format, or terribly annoying to support — why not?

Rephrased: I think there are a few arguably "sensible" formats that a user could
reasonably assume, and if we can support most of them without introducing
ambiguity in parsing or interpretation (and I think we can), can't we make
everyone happy?

> `755' is the funniest one, since, strictly speaking it doesn't correspond
> to anything "out there" (note that the shell command `chmod' wants the
> leading zero, or, well, it will do surprising things if you don't
> provide it ;-)

Consider my suggestion amended to 0755 etc. :)

Anyway, as an example here's a code snippet that implements everything I've
mentioned.

#+begin_src emacs-lisp
(defvar org-tangle-default-mode #o544
  "The default mode for tangled files, as an integer.")

(defun org-interpret-file-mode (mode)
  (cond
   ((integerp mode) mode)
   ((not (stringp mode))
(user-error "File mode %S not recognised as a valid format." mode))
   ((string-match-p "^0[0-7][0-7][0-7]$" mode)
(string-to-number mode 8))
   ((string-match-p "^#o[0-7][0-7][0-7]$" mode)
(string-to-number (substring mode 2) 8))
   ((string-match-p 
"^[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\(,[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\)*$" 
mode)
(file-modes-symbolic-to-number mode 0))
   ((string-match-p "^[rwx-]\\{3\\}$" mode)
(file-modes-symbolic-to-number (concat "u=" mode) org-tangle-default-mode))
   ((string-match-p "^[rwx-]\\{9\\}$" mode)
(file-modes-symbolic-to-number (concat  "u=" (substring mode 0 3)
   ",g=" (substring mode 3 6)
       ",a=" (substring mode 6 9))
   org-tangle-default-mode))
   (t (user-error "File mode %S not recognised as a valid format." mode
#+end_src

--
Timothy

Re: Grabbing the link to a message on the archive

[Timothy]

#+OPTIONS: html-postamble:nil H:5 num:nil ^:{} toc:nil author:nil email:nil tex:dvipng d:nil
#+STARTUP: hidestars indent inlineimages
:PROPERTIES:
:reply-to: nil
:attachment: nil
:alternatives: (utf-8 org)
:END:

Hi Greg,

> i love the searching on list.orgmode.org, but i have this recurrent
> dream: that some day each e-mail message will come with a header listing
> the URL for that message on https://list.orgmode.org.  (though i also
> worry this might open us up to some sort of spam, or other, attack?)
>
> and, i'll add my thanks and congratulations on 9.5!
>
> cheers, Greg

If you use mu4e, the following may be of some interest:
#+begin_src elisp
(defun +mu4e-ml-message-link (msg)
  (cond
   ((string= "emacs-orgmode.gnu.org" (mu4e-message-field msg :mailing-list))
(message "Link %s copied to clipboard" (gui-select-text (format "https://list.orgmode.org/%s"; (mu4e-message-field msg :message-id)
   (t (user-error "Mailing list %s not supported" (mu4e-message-field msg :mailing-list)
(add-to-list 'mu4e-view-actions (cons "link to message ML" #'+mu4e-ml-message-link t))
#+end_src

I expect this could be adapted to other clients (notmuch, gnus, etc.)
without much trouble :)

#+begin_signature
All the best,\\
@@html:@@Timothy@@html:@@
#+end_signature

[PATCH] Don't fill displayed equations

[Timothy]

Hi All,

If a displayed equation (`\[ ... \]') starts on its own line, I don’t think it
should be filled into the rest of the text. I.e.,

┌
│ some nice text
│ \[
│   1+1=2
│ \]
│ more text.
└
should not become,
┌
│ some nice text \[ 1+1=3 \] more text.
└

While the above example may not look bad, with non-trivial equations
this can become quite messy.

As such, I have attached a patch which adds fill “cuts” around `\[' and
`\]', when `\[' occurs at the start of a line. This leaves the display equation
delimiters on their own line.

I think this motivation for this change is fairly clear, and so without feedback
I intend to push this in a few days, however I if anybody has comments on the 
way
I’m currently implementing this, I’d like to hear your thoughts.

All the best,
Timothy
>From d008ff3c2218e19bb501137715b05e06a0c511e3 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 1 Oct 2021 01:14:21 +0800
Subject: [PATCH] org: Don't fill displayed equations into text

* list/org.el (org-fill-element): If a displayed equation (\[ ... \])
starts on its own line, it should not be filled into the rest of the
text. I.e.,

some nice text
\[
  1+1=2
\]
more text.

should not become,

some nice text \[ 1+1=3 \] more text.

While the above example may not look bad, with non-trivial equations
this can become quite messy.
---
 lisp/org.el | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 405f0f0f9..daf1d91b4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19551,10 +19551,10 @@ (defun org-fill-element (&optional justify)
 			 (org-element-property :contents-end element
 	   ;; Do nothing if point is at an affiliated keyword.
 	   (if (< (line-end-position) beg) t
-	 ;; Fill paragraph, taking line breaks into account.
 	 (save-excursion
 	   (goto-char beg)
 	   (let ((cuts (list beg)))
+ ;; Cut fill on line breaks.
 		 (while (re-search-forward "[ \t]*\n" end t)
 		   (when (eq 'line-break
 			 (org-element-type
@@ -19562,6 +19562,16 @@ (defun org-fill-element (&optional justify)
 	  (org-element-context
 		 (push (point) cuts)))
 		 (dolist (c (delq end cuts))
+ ;; Cut fill on displayed equations.
+ (while (re-search-forward "^[ \t]*\\[" end t)
+   (let ((el (org-element-context)))
+ (when (eq 'latex-fragment (org-element-type el))
+   (setf cuts (append
+   (list (org-element-property :end el)
+ (- (org-element-property :end el) 2)
+ (+ (org-element-property :begin el) 2)
+ (org-element-property :begin el))
+   cuts)
 		   (fill-region-as-paragraph c end justify)
 		   (setq end c
 	 t)))
-- 
2.33.0

Re: [PATCH] Don't fill displayed equations

[Timothy]

The initial patch was just slightly off. Here's a correct version.

Timothy  writes:
> As such, I have attached a patch which adds fill “cuts” around `\[' and
> `\]', when `\[' occurs at the start of a line. This leaves the display 
> equation
> delimiters on their own line.

>From d6d2221a7a9bf5e3cf93265c13cb643bcfe46929 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 1 Oct 2021 01:14:21 +0800
Subject: [PATCH] org: Don't fill displayed equations into text

* list/org.el (org-fill-element): If a displayed equation (\[ ... \])
starts on its own line, it should not be filled into the rest of the
text. I.e.,

some nice text
\[
  1+1=2
\]
more text.

should not become,

some nice text \[ 1+1=3 \] more text.

While the above example may not look bad, with non-trivial equations
this can become quite messy.
---
 lisp/org.el | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 405f0f0f9..ff86a9dd0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19551,16 +19551,26 @@ (defun org-fill-element (&optional justify)
 			 (org-element-property :contents-end element
 	   ;; Do nothing if point is at an affiliated keyword.
 	   (if (< (line-end-position) beg) t
-	 ;; Fill paragraph, taking line breaks into account.
 	 (save-excursion
 	   (goto-char beg)
 	   (let ((cuts (list beg)))
+ ;; Cut fill on line breaks.
 		 (while (re-search-forward "[ \t]*\n" end t)
 		   (when (eq 'line-break
 			 (org-element-type
 			  (save-excursion (backward-char)
 	  (org-element-context
 		 (push (point) cuts)))
+ ;; Cut fill on displayed equations.
+ (while (re-search-forward "^[ \t]*\\[" end t)
+   (let ((el (org-element-context)))
+ (when (eq 'latex-fragment (org-element-type el))
+   (setf cuts (append
+   (list (org-element-property :end el)
+ (- (org-element-property :end el) 2)
+ (+ (org-element-property :begin el) 2)
+ (org-element-property :begin el))
+   cuts)
 		 (dolist (c (delq end cuts))
 		   (fill-region-as-paragraph c end justify)
 		   (setq end c
-- 
2.33.0

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Timothy]

Hi  Jeremy,

> I love it! Much better than my proposed patch.

I’m about to send a patch based on my snippet, so I’m marking this patch as 
cancelled.

All the best,
Timothy

[PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hello,

Currently, the only way to set a file mode when tangling seems to be 
:tangle-mode (identity #o755)

In a [prior thread], Jeremy proposed that :tangle-mode should convert octal
number strings to the required decimal form. I think we should go further, and
so have prepared the attached patch based on a snippet I shared in the thread.

To quote the docstring of the new function I’m introducing, this patch now
accepts the following :tangle-mode forms:
• an integer (returned without modification)
• “#o755” (elisp-style octal)
• “0755” (c style octal)
• “755” (chmod style octal)
• “rwxrw-r–” (ls style specification)
• “a=rw,u+x” (chmod style)
• “rwx” (interpreted as “u=rwx”)

Why be so permissive? I’d refer you to my reasoning in the prior thread:

I think there are a few arguably “sensible” formats that a user could reasonably
assume, and if we can support most of them without introducing ambiguity in
parsing or interpretation (and I think we can), can’t we make everyone happy?

All the best,
Timothy


[prior thread] 
<https://list.orgmode.org/20210928145448.245883-1-jer...@cowgar.com/>
>From 5087de0d70151c33d66eb13dda84d78a361d7053 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 1 Oct 2021 02:02:22 +0800
Subject: [PATCH] ob-tangle: Accept more :tangle-mode forms

* lisp/ob-tangle.el (org-babel-tangle): Accept many more forms for
:tangle-mode, including octal strings (#o755, 0755, 755), ls forms (rwx,
rw-r--r--), and chmod forms (a=rw,u+x).  The interpretation of the input
is now handled by the new function `org-babel-interpret-file-mode' which
references the new variable `org-babel-tangle-default-mode' when
considering relative mode forms.
---
 lisp/ob-tangle.el | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2dd1d031c..28a235429 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -140,6 +140,14 @@ (defcustom org-babel-process-comment-text 'org-remove-indentation
   :version "24.1"
   :type 'function)
 
+(defcustom org-babel-tangle-default-mode #o544
+  "The default mode used for tangled files, as an integer.
+The default value 356 correspands to the octal #o544, which is
+read-write permissions for the user, read-only for everyone else."
+  :group 'org-babel
+  :version "9.6"
+  :type 'integer)
+
 (defun org-babel-find-file-noselect-refresh (file)
   "Find file ensuring that the latest changes on disk are
 represented in the file."
@@ -255,7 +263,7 @@ (defun org-babel-tangle (&optional arg target-file lang-re)
 		(when she-bang
 			  (unless tangle-mode (setq tangle-mode #o755)))
 		(when tangle-mode
-			  (add-to-list 'modes tangle-mode))
+			  (add-to-list 'modes (org-babel-interpret-file-mode tangle-mode)))
 		;; Possibly create the parent directories for file.
 		(let ((m (funcall get-spec :mkdirp)))
 			  (and m fnd (not (string= m "no"))
@@ -298,6 +306,38 @@ (defun org-babel-tangle (&optional arg target-file lang-re)
 	   path-collector))
 	path-collector
 
+(defun org-babel-interpret-file-mode (mode)
+  "Determine the integer representation of a file MODE specification.
+The following forms are currently recognised:
+- an integer (returned without modification)
+- \"#o755\" (elisp-style octal)
+- \"0755\" (c style octal)
+- \"755\" (chmod style octal)
+- \"rwxrw-r--\" (ls style specification)
+- \"a=rw,u+x\" (chmod style) *
+- \"rwx\" (interpreted as \"u=rwx\") *
+
+* The interpretation of these forms relies on `file-modes-symbolic-to-number',
+  and uses `org-babel-tangle-default-mode' as the base mode."
+  (cond
+   ((integerp mode) mode)
+   ((not (stringp mode))
+(error "File mode %S not recognised as a valid format." mode))
+   ((string-match-p "^0?[0-7][0-7][0-7]$" mode)
+(string-to-number mode 8))
+   ((string-match-p "^#o[0-7][0-7][0-7]$" mode)
+(string-to-number (substring mode 2) 8))
+   ((string-match-p "^[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\(,[ugoa]*\\(?:[+-=][rwxXstugo]*\\)+\\)*$" mode)
+(file-modes-symbolic-to-number mode org-babel-tangle-default-mode))
+   ((string-match-p "^[rwx-]\\{3\\}$" mode)
+(file-modes-symbolic-to-number (concat "u=" mode) org-babel-tangle-default-mode))
+   ((string-match-p "^[rwx-]\\{9\\}$" mode)
+(file-modes-symbolic-to-number (concat  "u=" (substring mode 0 3)
+",g=" (substring mode 3 6)
+",a=" (substring mode 6 9))
+   0))
+   (t (error "File mode %S not recognised as a valid format." mode
+
 (defun org-babel-tangle-clean ()
   "Remove comments inserted by `org-babel-tangle'.
 Call this function inside of a source-code file generated by
-- 
2.33.0

Re: [PATCH] Don't fill displayed equations

[Timothy]

Nicolas Goaziou  writes:

> I strongly disagree with this. \[...\] is an inline element, not a block
> element. As such, it can be filled, and filling function should obey to
> the inner structure of the document.
>
> You can use a real block element here, e.g.,
> \begin{equation*}...\end{equation*}, which will not be filled.

Given that \[ ... \] is an alias for \begin{equation*} ...
\end{equation*} I don't see why it should be treated any differently
when filling.

--
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Nicolas Goaziou  writes:

>> Given that \[ ... \] is an alias for \begin{equation*} ...
>> \end{equation*}
>
> This is true in LaTeX, not in Org, obviously.

Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$,
and \begin{env} ... \end{env} and constructs in Org to be consistent
with LaTeX?

--
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Nicolas,

I think there are also some relevant points which I haven’t mentioned so far,
separate from my thoughts that since we’re using the LaTeX syntax we should be
consistent with how LaTeX treats this.

> As I wrote above, they do not belong to the same category of syntax.
> There’s no reason to special case 

I think we already do special-case `\[ ... \]' somewhat. When refer to inline
elements like bold, verbatim, italic, etc. they sit in the text. Semantically,
this doesn’t hold for `\[ ... \]' either. The semantically inline maths element 
is
`\( ... \)'. Considering other “inline” syntax elements, like bold, verbatim,
italic, etc. if you spread the delimiters across multiple lines that doesn’t
work. So I’d argue the ship has already sailed on treating `\[ ... \]' 
differently
to other inline elements.

If you’re wondering why I’m so opposed to the current behaviour, that is 
probably
best explained by a more realistic demo that what I have in the commit message.

┌
│ Since \(\cos\) is an even function, we can negate the numerator of the 
argument
│ without changing the result, giving
│ \[
│   \cos \left( \pi \frac{C_1-x}{2C_1+D} \right) \ , \quad C_1 = \frac{D}{2}.
│ \]
│ this will be positive over \(x \in (0,D)\), and so we can rewrite 
\(\tilde{y}\) as,
│ \[
│   \tilde{y}(x) = \frac{2D}{\pi} \log \cos \left( \pi \frac{\frac{D}{2}-x}{2D} 
\right) + C_2.
│ \]
│ Once again considering that \(y(0)=y(D)=0\), it is clear that
│ \[
│   C_2 = - \frac{2D}{\pi} \log \cos \left( \frac{\pi}{4} \right) = - 
\frac{2D}{\pi} \log 2^{-\frac{1}{2}} = \frac{D}{\pi} \log 2.
│ \]
│ The complete solution for \(\tilde{y}\) is hence,
│ \[
│   \tilde{y} = \frac{2D}{\pi} \log \cos \left( \pi \frac{D-2x}{4D} \right) + 
\frac{D}{\pi} \log 2.
│ \]
└
is currently filled to
┌
│ Since \(\cos\) is an even function, we can negate the numerator of the 
argument
│ without changing the result, giving \[ \cos \left( \pi \frac{C_1-x}{2C_1+D}
│ \right) \ , \quad C_1 = \frac{D}{2}. \] this will be positive over \(x \in 
(0,D)\),
│ and so we can rewrite \(\tilde{y}\) as, \[ \tilde{y}(x) = \frac{2D}{\pi} \log 
\cos \left( \pi
│ \frac{\frac{D}{2}-x}{2D} \right) + C_2. \] Once again considering that
│ \(y(0)=y(D)=0\), it is clear that \[ C_2 = - \frac{2D}{\pi} \log \cos \left(
│ \frac{\pi}{4} \right) = - \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = 
\frac{D}{\pi} \log 2.
│ \] The complete solution for \(\tilde{y}\) is hence, \[ \tilde{y} = 
\frac{2D}{\pi} \log \cos
│ \left( \pi \frac{D-2x}{4D} \right) + \frac{D}{\pi} \log 2. \]
└

Suffice to say, I find the second terrible to read compared to the first.
Furthermore, when using org-latex-preview, wrapped `\[ ... \]' blocks join 
lines,
resulting in lines that are displayed going off edge of the page after filling.

Basically, this leads to a worse experience when using Org in what I would think
to be a perfectly reasonably way.

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Tom,

Thanks for giving me your thoughts on this. I have a few thoughts in response :)

> I strongly oppose this patch. It adds far too much complexity to the
> org grammar. Representation of numbers is an extremely nasty part of
> nearly every language, and I suggest that org steer well clear of
> trying to formalize this.

I’m not quite sure I see your point here, as I don’t see how this affects the
grammar of Org at all. The :attribute value syntax is unaffected, this just
changes how a particular :attribute’s value is interpreted. Attribute specific
interpretation is normal, with “:file ~/hello” you expect `~' to be interpreted 
as
`$HOME', but were I to give “:session ~/hello” I would not expect `~' to be
expanded etc.

Similarly, with regard to the representation of numbers, I’m not sure that
applies here, as the value is still a string not a number, it’s just
interpreted. Arguably, we’re not even representing numbers here but representing
file permissions which are currently abstracted by a numerical representation.

> With an eye to future portability I suggest that no special cases be given to
> [snipped for later] tangle mode without very careful consideration.

Mmmm, we defiantly want to think about what options we allow for, but I don’t
think that precludes us from accepting more than one common permissions
representations.

> [the snip]: something as important for security as tangle mode

Thank you for considering potential security implications, this is something
that I didn’t consider when writing the patch, but if we allow for a confusing
format that could deceive people into tangling files in modes they didn’t
realise they were tangling to.

I think there are two relevant points here
⁃ If we only allow very widely-understood, standard representations, I think the
  risk of people misunderstanding a :tangle-mode value is acceptably low
⁃ If you consider things this way, since arbitrary lisp closures are currently
  permitted, one can already trivially create a much more misleading
  :tangle-mode value with the current code.

> Emacs lisp closures have clear semantics in Org and the number syntax is clear

See my earlier comments on the semantics being unaffected, and this not being a
number syntax.

> If users are concerned about the verbosity of (identity #o0600) they could go
> with the sorter (or #o0600).

Perhaps, but I personally find it easier to interpret “rwxr-xr–” for example
than “(or #o754)”, and I feel quite confident in guessing that
a. I’m not alone
b. Nobody that understands “#o754” will have difficult understanding “rwxr-xr–”

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Nicolas Goaziou  writes:

> Timothy  writes:
>
>> I think there are also some relevant points which I haven’t mentioned so far,
>> separate from my thoughts that since we’re using the LaTeX syntax we should 
>> be
>> consistent with how LaTeX treats this.
>
> I'm not convinced about this. I don't think it is even possible.

By this, I'm specifically thinking of the fact that \( ... \) is inline,
and \[ ... \] is a display equation. What's the point of Org having both
if they're treated the same in "org syntax", on top of the inconstancy
that creates with HTML, LaTeX exports etc. where it is once again
treated as a display equation? Perhaps the discussion should shift from
my specific patch to this general situation, but this behaviour feels
wrong to me.

>>> As I wrote above, they do not belong to the same category of syntax.
>>> There’s no reason to special case 
>>
>> I think we already do special-case `\[ ... \]' somewhat. When refer to inline
>> elements like bold, verbatim, italic, etc. they sit in the text. 
>> Semantically,
>> this doesn’t hold for `\[ ... \]' either. The semantically inline maths 
>> element is
>> `\( ... \)'. Considering other “inline” syntax elements, like bold, verbatim,
>> italic, etc. if you spread the delimiters across multiple lines that doesn’t
>> work. So I’d argue the ship has already sailed on treating `\[ ... \]' 
>> differently
>> to other inline elements.
>
> I'm not sure about what you mean. \[...\] is no different than, e.g.,
> verbatim. It's an inline element, with all that it implies.

Is it? I can't use verbatim like this:

=
some
verbatim
text
=

but I can do

\[
some
display
equation
\]

It seems to me that \[ ... \] is already treated differently from other
inline markup.

> Now, if you want to discuss changing syntax for \[...\] and make it
> a block element, you can of course do it to your heart's content (it has
> been discussed already in this ML and I don't have an opinion on the
> subject), but please don't make filling do bizarre things (not all Org
> users use LaTeX or even like LaTeXisms), just because LaTeX modes behave
> differently.

If that's the only way that Org could treat \[ ... \] differently from
\( ... \), I'd be strongly in favour of this.

>> If you’re wondering why I’m so opposed to the current behaviour, that is 
>> probably
>> best explained by a more realistic demo that what I have in the commit 
>> message.
>> [*snip*]
> In every case above, you can already use
> \begin{equation*}...\end{equation*}, so I don't see the point.

I prefer \[ ... \] over \begin{equation*}...\end{equation*} as it's much
more succinct, and helps reduce the "markup noise" in my documents. I
don't think this is an insignificant concern, brevity may not be
something I'm very good at in emails 😛 but is something I look for in
syntax.

> You already have all you need without breaking filling function for
> the rest of us.

I must admit, I don't see the downside here --- how does this break the
filling function for the rest of you? This only affects \[ ... \] blocks
that have already been put on their own line.

> I don't think it is a worse experience, unless you apply expectations
> from LaTeX to Org. It just doesn't work.

Why can't we apply LaTeX expectations to LaTeX elements in Org? Applying
LaTeX expectations to Org as a whole is clearly a silly idea, but Org
copies \[ .. \] from LaTeX and it is a LaTeX construct.

> Notwithstanding filling behaviour, \[...\] in Org is much more limited
> than \[...\] in LaTeX.

I'd be curious to hear how, as I personally haven't run into any
instances where \[ ... \] has behaved differently other than when an
environment starts on a new line in of a \[ ... \] block (which can
easily be fixed by putting something like \!\ at the start of the line).

> If you need to write or copy "advanced" LaTeX code, Org provides
> dedicated environments.

I don't want "advanced" LaTeX code, I just want my display equations to
be treated as display equations consistently 😂.

Anyway, thanks for engaging with this Nicolas. Even if my patch is a bad
idea, I hope that by the end of this conversation we may arrive at an
agreement on how \[ ... \] should be treated.

--
Timothy

Re: [orgweb] Making the git repo URL more visible

[Timothy]

Hi Adam,

> Just now I found myself needing to look up the URL of the Org git repo,
> and it seemed a bit harder than it ought to be.  It’d be nice if there
> were a prominent “source code” link on the front page, but I remembered
> that it was somewhere on the “Contribute” page, so I opened that.

> When it loaded, I still overlooked the URL to the git repo.  I was
> expecting to see some kind of “Source Code” header, or “git repo” link,
> but instead the link is “The Org Codebase”, and it’s not under a header
> or near any other text like “source code” or “git repo”, so it seems
> easy to overlook:

Thanks for bringing this up. I agree that it should be more prominent. My
instinctual response is to change the text, add an icon, and bump the font size
up. Perhaps make it a /button link/ like “Tools that work with Org” on the
homepage. I’d be tempted to put it on the homepage, but I’m also wary of
clutter, and I’m hoping that the use of the common Git branch icon may clue devs
into thinking that the repository is linked/given on that page.

Do you have any thoughts on that?

All the best,
Timothy

Re: Visibility cycling with inline tasks 2

[Timothy]

Just marking this as a patch for  :)

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Tom,

Thanks for going through the replies so far and refining your thoughts.

> *snip a whole bunch of comments*

I think I’m of the same mind as you that if we try to mentally separate Org the
markup format and Org the emacs mode, the format should not specify the
interpretation of the :tangle-mode value.

I think the best way to have it would be,
⁃ Org the format, :tangle-mode takes a value representing the file permissions
  the tangled file should have. Optional: here are some common examples that
  might be recognised
⁃ Org the emacs mode, :tangle-mode’s value is interpreted like so (…)

> That said, reducing the number of forms as Eric suggests would
> be a happy medium.

Indeed, I’ve basically supported every form I could think of. I’m currently
inclined to cut it down to:
• 755
• “rwxrw-r–” (`ls -l' style)
• chmod style with `org-babel-tangle-default-mode' and 
`file-modes-symbolic-to-number'

Maybe with (if anybody says they would like this)
• #o755 (elisp octal)
• 0755 (C octal)
• “rwx” = user perm, bit-or’d with `org-babel-tangle-default-mode' for the rest
  (i.e. `org-babel-tangle-default-mode', but not exceeding the user perm)

All the best,
Timothy

Re: [orgweb] Making the git repo URL more visible

[Timothy]

Hi Bastien,

> Done, let me know if it’s good enough.

Just 2c from me, I’d be tempted to have put that on the contribute page 
¯\_(ツ)_/¯.

All the best,
Timothy

Re: [orgweb] Making the git repo URL more visible

[Timothy]

Hi Adam,

> Maybe this is moot, since Bastien already added the link to the home
> page, but anyway…
>
> On the Contribute page, I’d be in favor of having some kind of
> heading, like “Source Code,” and listing the git URL in text for easy
> copying (i.e. not hiding the URL behind a descriptive link).  It’d
> also be good to have a clickable link to view the repo on Savannah.
>
> Also, on that page, while I’m glad to have Bastien’s sponsorship links
> there, the “GitHub” link with the GitHub icon might be expected to be
> a link to the git source code, because that’s a common way to link to
> a git repo on other projects’ sites.  So it might be good to put them
> under a heading, like “Sponsor Development”.

I think a “Source Code” header could make sense, with a link to the cgit page,
git clone line, and maybe a sentence or on Savannah for the unfamiliar. Perhaps
we could like to the org-contrib and website repos as well there?

All the best,
Timothy

Re: [Worg] Proposing a few CSS changes

[Timothy]

Hi Adam,

>From the last few messages in this thread, I think we’ve reached agreement on
the changes. Would you like to go ahead?

All the best,
Timothy

Re: [orgweb] Making the git repo URL more visible

[Timothy]

Hi Adam,

> Sounds good to me.

Thanks :) it’s nice to get a second opinion.

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi  Eric,

>> text
>> 1+1=3
>> text
>>
>> is a single paragraph in LaTeX.

> This is true and probably the most convincing argument in this debate.

I can’t help but think that this line of thinking is a bit of a trap, because
what LaTeX’s idea of a paragraph does not line up with Org’s. I think the more
pertinent consideration is that `\[ ... \]' changes LaTeX into vertical mode,
which does not allow for any other content on the ’line’ — which is far
closer to Org’s concept of a block element than an inline element.

Frankly, I think the issue is that the semantics of `\[ ... \]' simply don’t 
play
well with Org. Unfortunately, due to the Org/LaTeX difference I don’t see any
ideologically “pure” way we can have it in Org. The most idiomatic solution
would be to just remove support for `\[ ... \]' *. Otherwise, we have to treat
`\[ ... \]' specially in if we want ’sensible’ behaviour — as I mention in my
reply to Nicolas, we’re already parsing it differently to other inline markup…

All the best,
Timothy

* However, I am not advocating for this: There’s both the obvious comparability
  issue, but I also rather like using `\[ ... \]' myself.

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Nicolas,

> *snip lots of text*

Thanks for going through my points in detail. I think I understand your
perspective much better now. At this point though, I’m not really sure what to
make of `\[ ... \]', I now feel like it’s sitting in some sort of markup limbo
where it can’t be either fully LaTeX-y or fully Org-y. I still think it would be
good to improve this, but I no longer have such a firm idea that “modifying fill
is the way”.

All the best,
Timothy

Re: [Worg] Proposing a few CSS changes

[Timothy]

Hi Adam,

> Sure, I’ve just pushed these commits:

Great! I’ve just taken a peek and it’s a clear improvement in my eyes 🙂.

> Note that, after I made the other changes, the links scattered around
> the page clashed very badly with the nice “Org green” and black theme,
> so I adjusted them as well (as detailed in the commit message).  I tried
> using “Org green” for the link text, but it seemed too low-contrast, as
> well as a bit distracting while reading, so I opted to use colorize just
> the underlines, and to make the link text green when hovering.

I just had a look at this, and I tried a darkened green (#08402e). I think this
may be the best option.

> Note as well that I ended up using 48em for the content width due to the
> unicorn logo in the corner being covered up by wider content than that
> (in a half-1080p-width browser window, which seems like an important use
> case to consider).

We should probably update the “angry unicorn” to the logo on the homepage,
perhaps <https://orgmode.org/resources/img/org-mode-unicorn.svg> or a simplified
version.

> And I left the H1 header black rather than green, because it didn’t seem
> to stand out enough as the page heading when it was also green.

The contrast looks good to me 👍.

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Tom,

> The answer is that  can only occur inside paragraphs. The issues
> here are exactly the same as the issues for inline footnotes. Org gives
> us a bit more power, but not the full power because Org is Org, not
> Latex. Making  available outside of a paragraph would be a massive
> breaking change.
>
> In Timothy’s original example he is narrowly skirting the syntax to
> allow that all to remain a single paragraph, but stick in a newline
> anywhere and boom, no more paragraph, no more equation.

I don’t understand what you’re talking about here. You can already use `\[ ... 
\]'
outside a paragraph, e.g.

┌
│ blah blah blah
│ 
│ \[
│   not part of a paragraph
│ \]
│ 
│ blah blah blah
└

I also don’t see how footnotes are analogous, as footnotes are placed in the
middle of a line of text.

If you could explain your thoughts here a bit more, that would be appreciated.

> I guess one thing I’m missing/not understanding is when/why people
> want to use  instead of full #+begin_export latex block?

org-latex-preview :)

All the best,
Timothy

Re: org-latex-preview and latex export blocks

[Timothy]

Tom Gillespie  writes:

> But surely #+begin_export latex works with org-latex-preview? If not then
> that would be a feature request to org-latex-preview yes?

It might be possible, but I don’t think you can generally expect #+begin_export
latex blocks to be either previewable in isolation, or something one would want
to preview.

This separation is also useful for packages like org-fragtog, which auto-toggles
equations[1] previews on cursor entry/exit.

Basically, LaTeX export blocks and maths are (in my view) two different things,
even if both use LaTeX syntax.

All the best,
Timothy



Footnotes
─

[1] `\( ... \) =, =\[ ... \]', and `\begin{*math} ... \end{*math}' bits

Re: [PATCH] Prevent displayed images from being re-scaled

[Timothy]

Hi All,

I intend to push this in the next few days, assuming I don’t get any feedback.

All the best,
Timothy

Re: [PATCH] Prevent displayed images from being re-scaled

[Timothy]

Bastien  writes:

> Nitpick: I suggest shortening the ChangeLog part like this:
> *snip*
> The ChangeLog part should not be too verbose, you can add explanations
> after it.

Thanks Bastien, I’ll use that message when I push the commit 👍.

All the best,
Timothy

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Ihor Radchenko  writes:

> Let me bump this thread again and mark it as a patch ;)

Thanks for the bump. I'd like to get this working, but I don't know how best to
deal with the "prettification" of {{{results(=value=)}}}, which is the major 
blocker as I
see it.

Other than that, this all works fantastically as far as I can tell from a few
months of usage of my branch of Org 🙂.

--
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Ihor,

> What about making org-fill-element modular?  We may define separate fill
> functions for different elements and let the user override them
> individually if the user prefer so.  It may be implemented similar to
> export functionality with customisable formatters for different
> elements.

Thanks for that idea. Perhaps something along those lines may be the best
solution here. If we don’t want to make the whole function modular, perhaps we
could make a setting for this?

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Ihor Radchenko  writes:

> I personally would prefer modular function as a whole.  For my taste,
> Org code has too much of (case (variant 1) (variant 2) …)-style
> functions (i.e. org-todo, org-cycle, org-ctrl-c-ctrl-c, org-store-link,
> etc) and they are a pain to debug and advice for users. 

Mmmm, I’m with you on this in general. I also think the code base has far too
many monolithic “200 line” functions which are crying out to be split up.
Now if I could just clone myself once or twice… 😛

All the best,
Timothy

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Hi Ihor,

> What about separating the src_{nil} fontification into separate patch? I
> think that part raised no objections.

That sounds like a good idea to me. We may as well get that in.

> As for the results prettifications, I look at this and similar ideas as
> at Emacs themes.  It looks nice on your screenshot with your fonts and
> colours, but may not be good for other people.  Similar to org-bullets
> and co.

The behaviour makes me think of link prettification more than what Emacs themes
do. Hiding the text {{{results( with an overlay seems like something a
major/minor mode should be responsible for, not a theme.

> I can see how some people (I am among those people) want to reduce the
> markup noise beyond hiding emphasis markers.  However, some people
> prefer not to hide text in buffer under “bells and whistles”.

Indeed, and it’s good to have this option. This is why I also introduced a new
setting, `org-inline-src-prettify-results' (similarly named to
`org-pretty-entities').

> Maybe we can create some kind of “prettify-symbol themes” replacing different
> markup elements in bulk with nice symbols/svg (e.g. inline results, block
> headers/footers, uninteresting property drawers aka org-custom-properties,
> bullets, etc)? WDYT? Also, CCing Prot as it might be of interest for him.
> Best, Ihor

I think it could make sense for some prettification capabilities to be built
into Org well. Currently there are a few little things we have, but it seems to
be handled inconsistently and I think it could be nice to provide a more unified
approach. There are also things like
<https://github.com/awth13/org-appear/blob/master/org-appear.el> which I feel 
just
make a lot of sense with Org (you never have to guess if `point' is before or
after a markup character).

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Ihor,

> Then would you mind proposing a patch for org-fill-element in
> particular? At least, you seem to have a motivation for this particular
> function ;)

Perhaps in a few weeks, for now I’m a bit to busy for anything other than
“accidental” 😛 patches.

All the best,
Timothy

Re: Cannot clone org-mode's git repository

[Timothy]

Hi Colin,

> I get a strange error when I try to clone org-mode:

Interesting, I just tried `git clone git://git.sv.gnu.org/emacs/org-mode.git' 
and
that seemed fine.

All the best,
Timothy

Re: Inequalities in math blocks

[Timothy]

Hi Rudolf and Max,

>> Usually, it is sufficient simply to put spaces around these symbols to
>> cause the browser to avoid them, so
>> … when x < y we have …
>
> Though I am a bit surprised that Org did not replace characters to < and 
> >
> during export. Perhaps, it is possible to define a filter.

You’re going to be much better off if you just use LaTeX math delimiters, i.e. 
`\(
... \)'.

All the best,
Timothy

Re: ox-slimhtml

[Timothy]

Hi Amin,

> What do you (other folks also) think?

A while ago Nicolas forwarded me an email between him and Laszlo on this. Here
are my thoughts at the time addresses to Laszlo (which haven’t changed much 
since):

Nicolas  writes:
> IIUC, merge is only viable if “ox-slimhtml” is a drop-in replacement for
> “ox-html”. Otherwise, users will miss out many features. Of course, we
> could ship two competing HTML export back-ends, but I don’t think that’s
> a good idea either.
>
> So, it is meant for inclusion in Org proper, or as a GNU ELPA package?
> I don’t know. Maybe Timothy has a clearer view about it.

I believe I see your motivation in creating ox-slimhtml, as the current
ox-html includes much more than could be considered strictly necessary.

However, like Nicolas I am hesitant to put this straight into Org along
side ox-html. My personal view is that ideally ox-html would be equipped
with the relevant knobs and levers (metaphorically speaking) such that
one could obtain the same result as ox-slimhtml, the current result, or
something in-between. I’ve felt for some time that ox-html could benefit
from a bit more in-built flexibility without going down the path of
hooks, filters, and advice. This would certainly be more effort, so I
completely understand if this isn’t something you’d like to undertake.
In that case, I feel that this may be best suited as an ELPA package —
closely in reach for those who are looking for a slimmer ox-html.

All the best,
Timothy

Re: Org mode web site

[Timothy]

Hi Thomas,

> I’m seeing what looks like a spurious headline:   Elaboration + demo image
> ignore

Thanks, that is indeed spurious. “ignore” is the tag :ignore: but it seems like
the ox-extra that makes :ignore: work isn’t being loaded any more.

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi All,

Given the way the conversation has evolved I think it may be worth revisiting
another viewpoint to see if anybody has any nice ideas.

As things are, regardless of the complexities of parsing and inline vs.
block elements etc., just considering the user experience when running
org-fill on an example like the one below, the behaviour isn't /nice/.

Might there be some way we could allow for people who are used to LaTeX
and/or like \[ ... \] to have fill behaviour that leaves \[ ... \]
blocks alone? My original idea was changing how org-fill works for
everyone, the discussion has gone on to changing \[ ... \] to a block
element -- both of these seem to have rather significant issues.

Ihor came up with the idea of making org-fill something more
customisable by the user, so that someone could have this behaviour
without making Org behave un-idiomatically for everyone. I proposed
maybe just having a setting could be a halfway house between my original
patch and his idea.

Does anybody have any other thoughts?

> If you’re wondering why I’m so opposed to the current behaviour, that is 
> probably
> best explained by a more realistic demo that what I have in the commit 
> message.
>
> ┌
> │ Since \(\cos\) is an even function, we can negate the numerator of the 
> argument
> │ without changing the result, giving
> │ \[
> │   \cos \left( \pi \frac{C_1-x}{2C_1+D} \right) \ , \quad C_1 = \frac{D}{2}.
> │ \]
> │ this will be positive over \(x \in (0,D)\), and so we can rewrite 
> \(\tilde{y}\) as,
> │ \[
> │   \tilde{y}(x) = \frac{2D}{\pi} \log \cos \left( \pi 
> \frac{\frac{D}{2}-x}{2D} \right) + C_2.
> │ \]
> │ Once again considering that \(y(0)=y(D)=0\), it is clear that
> │ \[
> │   C_2 = - \frac{2D}{\pi} \log \cos \left( \frac{\pi}{4} \right) = - 
> \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = \frac{D}{\pi} \log 2.
> │ \]
> │ The complete solution for \(\tilde{y}\) is hence,
> │ \[
> │   \tilde{y} = \frac{2D}{\pi} \log \cos \left( \pi \frac{D-2x}{4D} \right) + 
> \frac{D}{\pi} \log 2.
> │ \]
> └
> is currently filled to
> ┌
> │ Since \(\cos\) is an even function, we can negate the numerator of the 
> argument
> │ without changing the result, giving \[ \cos \left( \pi \frac{C_1-x}{2C_1+D}
> │ \right) \ , \quad C_1 = \frac{D}{2}. \] this will be positive over \(x \in 
> (0,D)\),
> │ and so we can rewrite \(\tilde{y}\) as, \[ \tilde{y}(x) = \frac{2D}{\pi} 
> \log \cos \left( \pi
> │ \frac{\frac{D}{2}-x}{2D} \right) + C_2. \] Once again considering that
> │ \(y(0)=y(D)=0\), it is clear that \[ C_2 = - \frac{2D}{\pi} \log \cos \left(
> │ \frac{\pi}{4} \right) = - \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = 
> \frac{D}{\pi} \log 2.
> │ \] The complete solution for \(\tilde{y}\) is hence, \[ \tilde{y} = 
> \frac{2D}{\pi} \log \cos
> │ \left( \pi \frac{D-2x}{4D} \right) + \frac{D}{\pi} \log 2. \]
> └

--
Timothy

Re: New HTML exporter (was a feature request)

[Timothy]

Hi Tim,

> Probably what is needed is a new HTML exporter which is capable of doing
> what slimhtml does as the default, but includes the additional
> functionality already in the exporter which many people are using.

I think there may be some promise in the idea of rewriting (large parts of) the
current HTML exporter. The way that the web has changed over the last decade I
think we can now make some assumptions that can simplify things — for example
I think we could safely go HTML5-only.

Not something I have time to investigate now, but in a month or two (or
three 😛) I might take a look.

All the best,
Timothy

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Tom,

> From time to time I encounter random patterns that I don’t want to be
> reformatted during a fill operation. Maybe a custom variable like
> org-fill-paragraph-skip-regexp or similar that could be set by the user?
> For Timothy’s use case he would set it to the regexp provided in the
> original patch? Not sure how much of the implementation in the patch
> is dependent on that particular regexp, but a general solution that
> could even be set per org file might be a very useful new feature.

Hmmm, that’s an interesting idea. I suppose you could have something like a list
of cons cells where the car is a regexp matching the start of the “don’t touch”
region and the cdr a regexp matching the end.

All the best,
Timothy

Re: Org lint and named source blocks

[Timothy]

Hi Tom,

> The issue for me is that I don’t have the bandwidth to get started
> with a full tree sitter implementation, especially because it is going
> to need a custom scanner, and because you’re effectively on your
> own when it comes to reconstructing the output of the AST into the
> actual internal representation of an Org file. I also have no idea how
> to deal with nested parsers in tree sitter. I have some ideas about
> how it might be done, but nothing concrete (see the linked issue
> for more on that).

orgmode.nvim is developing a tree-sitter parser, perhaps a dialog with them
could be productive?

All the best,
Timothy

Bare oc-csl author variants?

[Timothy]

Hi All,

I was recently citing something and wanted to mention the author and so tried
[cite/a/b:@] and was surprised to see it didn’t work. Looking at oc-csl.el I see
that we only define the following author variants:
• `a/c'
• `a/f'
• `a/cf'

Is there any reason why we haven’t added `a/b', `a/bc', `a/bf', `a/bcf' ?
>From a quick test, this seems to work as expected:
┌
│ (`(,(or "author" "a") . ,variant)
│  (pcase variant
│((or "caps" "b") '(:mode author-only :suppress-affixes t))
│((or "caps" "c") '(:mode author-only :capitalize-first t))
│((or "full" "f") '(:mode author-only :ignore-et-al t))
│((or "bare-caps" "bc") '(:mode author-only :suppress-affixes t 
:capitalize-first t))
│((or "bare-full" "bf") '(:mode author-only :suppress-affixes t 
:ignore-et-al t))
│((or "caps-full" "cf") '(:mode author-only :capitalize-first t 
:ignore-et-al t))
│((or "bare-caps-full" "bcf") '(:mode author-only :suppress-affixes t 
:capitalize-first t :ignore-et-al t))
│(_ '(:mode author-only
└

All the best,
Timothy

Re: Inequalities in math blocks

[Timothy]

Hi  Rudolf,

>> You’re going to be much better off if you just use LaTeX math delimiters, 
>> i.e.
>> `...’.
>
> Interesting. It works, but I do not understand why! Do we consider 
> inequalities
> in $$ breaking HTML export expected behavior? Or, do we consider it a bug? I
> suppose there exists no formal specification, executable or not, to answer the
> question?

Just considering the general situation, $ is hard for Org because it needs to do
“double duty” as both a currency symbol in text, and math delimiters. This means
that it can’t be consistent with how LaTeX works. However, `\( ... \)' doesn’t 
and
so Org can be much more consistent with LaTeX here. Besides which `$ ... $' is a
TeX-ism and `\( ... \)' is the /proper/ way of doing inline maths in LaTeX, so
really you should be reaching for those anyway.

> I ask because if … breaks basic mathematics, I should either return
> back to LaTeX for any serious notes or replace every … with … in all my
> Org files to avoid accidental breakage of mathematics in the future. Thank 
> you!

I’d just use `\( ... \)' in future, and that way you’ll be fine in LaTeX and Org
🙂. You might be able to use `org-element-map' to robustly convert from $ … $=
to `\( ... \)'.

All the best,
Timothy

Re: Bare oc-csl author variants?

[Timothy]

Hi  Bruce,

>> Is there any reason why we haven’t added `a/b’, `a/bc’, `a/bf’, `a/bcf’ ?
>
> There is a reason, though it may not be the strongest.
>
> It’s just odd to have a name without any other citation marker. How
> would a reader know it’s a citation?

For context, I’m basically just using this as a way to insert the author’s name
without any chance of typos.

Some thing was introduced in Doe (2019), and some comments about it.
To demonstrate X, Doe considers … which allows Doe to ….

All the best,
Timothy

Re: Bare oc-csl author variants?

[Timothy]

Hi  All,

Sounds like the general attitude is “why not?”. So I’ve turned my snippet into a
patch and unless any concerns are raised in the next few days I’ll push it to
main.

All the best,
Timothy
>From 88f8bb7bc8726c20f3cdd4e8d47d1b487b1c2cd7 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 5 Oct 2021 22:36:13 +0800
Subject: [PATCH] oc-csl: Support bare author citations

* lisp/oc-csl.el (org-cite-csl--create-structure-params): Add support
for bare (b), bare-caps (bc), bare-full (bf), and bare-caps-full (bcf)
author citation styles.
---
 lisp/oc-csl.el | 4 
 1 file changed, 4 insertions(+)

diff --git a/lisp/oc-csl.el b/lisp/oc-csl.el
index 3d1388075..3d8f8ed03 100644
--- a/lisp/oc-csl.el
+++ b/lisp/oc-csl.el
@@ -300,9 +300,13 @@ (defun org-cite-csl--create-structure-params (citation info)
   ;; "author" style.
   (`(,(or "author" "a") . ,variant)
(pcase variant
+	 ((or "bare" "b") '(:mode author-only :suppress-affixes t))
 	 ((or "caps" "c") '(:mode author-only :capitalize-first t))
 	 ((or "full" "f") '(:mode author-only :ignore-et-al t))
+	 ((or "bare-caps" "bc") '(:mode author-only :suppress-affixes t :capitalize-first t))
+	 ((or "bare-full" "bf") '(:mode author-only :suppress-affixes t :ignore-et-al t))
 	 ((or "caps-full" "cf") '(:mode author-only :capitalize-first t :ignore-et-al t))
+	 ((or "bare-caps-full" "bcf") '(:mode author-only :suppress-affixes t :capitalize-first t :ignore-et-al t))
 	 (_ '(:mode author-only
   ;; "noauthor" style.
   (`(,(or "noauthor" "na") . ,variant)
-- 
2.33.0

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi  Everyone,

It feels like we’re near a patch that would be good to merge. I would very much
like to get feedback on what I proposed in my reply to Tom though (see below).

>> That said, reducing the number of forms as Eric suggests would
>> be a happy medium.
>
> Indeed, I’ve basically supported every form I could think of. I’m currently
> inclined to cut it down to:
> • 755
> • “rwxrw-r–” (`ls -l’ style)
> • chmod style with `org-babel-tangle-default-mode’ and 
> `file-modes-symbolic-to-number’
>
> Maybe with (if anybody says they would like this)
> • #o755 (elisp octal)
> • 0755 (C octal)
> • “rwx” = user perm, bit-or’d with `org-babel-tangle-default-mode’ for the 
> rest
>   (i.e. `org-babel-tangle-default-mode’, but not exceeding the user perm)

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi  Jeremy,

> I think this is a good idea and don’t see any problems (or other
> suggestions) with the proposed formats.
>
> The existing (identity #o0755) will still function, correct?
> i.e. backward compatibility.

It should yes. I’ll double check before I actually push the commit.

All the best,
Timothy

Re: Inequalities in math blocks

[Timothy]

Hi Greg,

> oof.  ... is the way to go.

I’m thinking we should perhaps update the docs to more strongly recommend `\( 
... \)'
over `$ ... $'. So that someone coming from say, Markdown + $-math or
(not-La)TeX doesn’t just go “cool, $ works, I’ll keep on using that”.

All the best,
Timothy

Re: Inequalities in math blocks

[Timothy]

Hi Rudolf,

> I do not understand. As Max pointed out, inequalities break HTML export in 
> and as well.
>
> Example:
>
> - a - b>a
>
> Org should rewrite < and > to < and > to avoid broken HTML, or as < and 
>  in general.

I think we’ve drifted a bit to the differences in processing (where the `\( ... 
\)'
vs `$ ... $' comments are most pertinent), but as you say for valid HTML < and >
should be rewritten. I don’t think I’ve seen an issue because MathJax seems to
take care of it, but it looks like MathJax is also fine with < and &rt;.

As the maintainer for ox-html, I’ll take a look at this. I am exceptionally busy
over the next few weeks though, so there may be a brief delay.

All the best,
Timothy

Useful package? Compat.el

[Timothy]

Hi,

I’ve recently come across an interesting looking library available on ELPA,
<https://git.sr.ht/~pkal/compat>. I’m thinking in future this could allow us to
both use newer features and also support older versions of Emacs, e.g.

Org 10.X is developed for Emacs 28.1 and newer, but supports Emacs 24.3 and
newer with compat.el.

Just tossing this out as an idea :)

All the best,
Timothy

Re: Useful package? Compat.el

[Timothy]

Hi Russel,

> Do you have any examples of where this could shorten code in Org?

I don’t have any examples on hand, but Org is already rolling some compat code
for old Emacs versions, and we’ve had issues where people have accidentally used
functions which are “too new” (but a few years old, and so nobody picked it up
till someone raised an issue). I can also personally recall times when I’ve had
to refactor code to make it uglier and more verbose to avoid using newer
functions. All of this is why I’m thinking this could be an interesting idea.

> I believe it’s a tall order to add a dependency, but if it eliminates
> large chunks of backward compatibility code then maybe that’s
> something to consider.

I think the way to do this would be as a “soft” dependency, i.e. not needed for
anyone running a recent version of Emacs, but needed if you want to use Org with
an old version of Emacs. Not sure how this would best be done, but if this were
to be useful, this is how I’d imagine it working.

All the best,
Timothy

Re: [PATCH] Rename headline to heading

[Timothy]

Hi André,

I haven’t gone through the patches you’ve sent, but it looks like you’ve put a
tremendous amount of effort into this! It’s fantastic to see. I think I can
speak for the Org community when I say thank you.

André A. Gomes  writes:

> Hi Bastien and All,
>
> This is a first attempt towards the goal.

All the best,
Timothy

Re: [BUG] Inline images cannot be displayed [9.5 (release_9.5-108-g93132c @ /tmp/org-mode/lisp/)]

[Timothy]

Hi Bhavin,

> Confirmed
>
> I was able to reproduce this with the latest main branch. It works fine with
> attributes like this:
>
> #+attr_org: :width 500px
>
> And the 9.5 tag does not have this bug, so I think this might be related to
> recent changes to image width. Adding Timothy to CC who worked on those
> changes.

Thanks for confirming and the CC, hopefully it’s not what I did 😅, but that’s
what the bugfix branch is for. I’ll try to have a look within the next week or 
so,
but I’m unfortunately busy over the next ~month so I can’t make any grantees.

All the best,
Timothy

Re: citeproc-style-parse: Symbol’s function definition is void: libxml-parse-xml-region

[Timothy]

Hi Joseph,

The function libxml-parse-xml-region has been around for a while, what version
of Emacs are you running?

All the best,
Timothy

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Timothy]

Hi  Carlos,

Just a minor point from me, this really should be a new thread IMO. While not
much may have happened with the IETF RFC, it’s still something on my mind that I
hope to get back to eventually.

All the best,
Timothy

Re: Bare oc-csl author variants?

[Timothy]

Pushed as 7111ee7c.

Re: [PATCH] Prevent displayed images from being re-scaled

[Timothy]

It’s been quite a few days, so I’ve just pushed this as 9dc08c9.

Re: Introducing Org-transclusion

[Timothy]

Hi Noboru,

> Org-transclusion is rather simple. It only requires Emacs 27.1 and Org 9.4.

It’s worth noting that currently Org’s minimum supported Emacs version is 25. Do
you use much from Emacs 26/27? There was mention of compat.el earlier though,
and if that goes somewhere this may not be an issue.

All the best,
Timothy

Re: Introducing Org-transclusion

[Timothy]

Hi Tim,

> WRT making this part of org-mode core, I’m not in favour. This is no
> reflection on the package, which I think is a great addition to the org
> ecosystem. My preference would be for this package to be an add-on
> package in either ELPA or non-GNU ELPA.
>
> My main reason for this is because I think we should be striving to make
> the core org packages as small and easily maintained as possible,
> containing the core functionality used by everyone. While this package
> has some very useful functionality, I feel it is functionality which
> will be used by a subset of users or by others only occasionally.
>
> If, at a later date, it turns out a majority of users use this package,
> we can review and if necessary/appropriate, bring the package into org core
> (assuming copyright is handed over to FSF).

Reading your thoughts on this package, I find myself of a similar mind. I think
org-transclusion is great, but it may be a bit hasty to add it as a “core” Org
feature at this stage. If it looks like a good idea later and/or we end up
developing an Org spec with a small core and tiers of features, I could see this
being included alongside less-essential features like `#+plot'.

All the best,
Timothy

Re: Subject: [PATCH] Fix DISPLAY error on exporting org with plantuml to html

[Timothy]

Hi Sun,

> [snipped patch description]
> Please help review the patch. Thanks.
> [2. text/x-patch; 
> 0001-Fix-DISPLAY-error-on-exporting-org-with-plantuml-to-.patch]...

Thanks for your patience. This looks quite straight-forward. I don't use
or have plantuml so I'm in a poor position to test.

However, I can use google, and it seems that -Djava.awt.headless=true
just uses Java for some graphics operations which are normally delegated
to the system graphics stack.

This seems rather safe to me, and so I'd be inclined to take your word
that this is a beneficial change and merge the patch.

All the best,
Timothy

Re: [BUG] org-mode binds C-c C-TAB, which seems illegal [9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)]

[Timothy]

I think that the two actions we may want to take here are:
1. Replace "C-TAB" with "C-" in the keybinding
2. Change the keybinding to something else that doesn't use control+tab
   for instance, "C-c M-TAB" seems to be available.

Which option seems preferable?

--
Timothy

Re: [PATCH] org-manual.org: org-cite additions

[Timothy]

Hi Bruce,

Thanks for this patch. I've had a read through and it all looks good to
me. I've just applied this with minor tweaks as 30dbfc6.

> This is a minor patch to address the most obvious missing pieces that
> have confused people.

--
Timothy

Re: [BUG] require org-macs at compile time [9.5 (9.5-g0a86ad @ /home/phil/.emacs.d/elpa/org-9.5/)]

[Timothy]

Hi Phil,

> The macro `org-dlet' is not expanded in file org-agenda.el at compile
> time when installing Org 9.5 from ELPA.

How does this issue manifest? I tried byte-compiling org-agenda.el and
didn't see any errors/warnings.

--
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi All,

This has just been pushed as described in fa97f9a39.
See some tests I performed before pushing below.

#+begin_src text :tangle-mode (identity #o345) :tangle t1.txt
this works
#+end_src

#+begin_src text :tangle-mode 433 :tangle t2.txt
this works
#+end_src

#+begin_src text :tangle-mode u+x :tangle t3.txt
this works
#+end_src

#+begin_src text :tangle-mode rw-r--r-- :tangle t4.txt
this works
#+end_src

#+begin_src text :tangle-mode hey :tangle t5.txt
invalid, error message given
#+end_src

--
Timothy

Re: [PATCH] ob-R async evaluation

[Timothy]

Hi Jeremie,

Sorry it's taken a while to get to this. I've just gone through your
patch and it looks quite reasonable. I also took the liberty of
fixing the indentation in a few spots and tweaking your commit message.

This has just been pushed as 58db28d.

> I'm attaching a patch that clean up a bit of non conventional coding
> practices (mainly because of my ignorance), in ob-R. These were
> initially generating warning during the compilation of org-mode.

By the way, just letting you know that your mail client declared your
.patch to be a PDF file 😛.
> [2. application/pdf; 0001-ob-R.el-Patch-4-async-evaluation.patch]...

--
Timothy

Re: [PATCH] Treat :tangle-mode as an octal value not integer

[Timothy]

Just removing this from updates.orgmode.org.

Re: [PATCH] org.el (org-display-inline-image--width): Small fix

[Timothy]

Just marking this patch as applied for updates.orgmode.org.

Nicolas Goaziou  writes:

> Hello,
>
> Sébastien Miquel  writes:
>
>> Subject: [PATCH] org.el (org-display-inline-image--width): Small fix
>
> I expounded the commit message and applied your patch. Thank you.
>
> Regards,

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi All,

I thought I’d checked for this, but I’ve just noticed that :tangle-mode 755
doesn’t actually work as expected. I assumed 755 would be passed as a string but
org-babel-parse-header-arguments actually turns it into an integer, just like
(identity #o755). Obviously 755 != #o755 and so this causes issues.

As it stands “755” works, but that isn’t great (most importantly, it’s easy to
confuse). Since it’s easier to add than remove things like this, we could just
get rid of this for now, but a convenient octal notation was a large chunk of
the motivation here IIRC.

We could also change the implementation to handle :tangle-mode o755, which will
make org-babel-parse-header-arguments parse the argument as a string.

I’m be keen to hear other people’s thoughts on this.

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Tom, Tim, Thomas, and Greg,

Thank you all for your thoughts. I’ll try to respond to all the main points
raised below.

First off, in case it wasn’t clear in my earlier email when I said “#o555 works”
or the like I was being lazy and really meaning “(identity #o555)” works.

The parsing of “555” to the integer 555 is done by
org-babel-parse-header-arguments, and so can’t really be changed. For a simple
octal notation our best bet is adding non-digit characters so it is left as a
string, e.g. “o555”.

┌
│ 1 -> (org-babel-parse-header-arguments ":tangle-mode 555" light)
│ 1 <- org-babel-parse-header-arguments: ((:tangle-mode . 555))
│ ==
│ 1 -> (org-babel-parse-header-arguments ":tangle-mode o555" light)
│ 1 <- org-babel-parse-header-arguments: ((:tangle-mode . "o555"))
└

So while I’d like it if we could easily apply Tom’s suggestion to “change the
radix for bare integers to 8 when reading that particular header”, I don’t think
that’s very feasible, unfortunately.

Giving errors when a base 10 value has been given by accident would be a nice
idea, but in practice isn’t easy as many base 10 values are valid octal values,
e.g. #o555 = 365. Likewise, I don’t think Tim’s suggestion of disallowing base
10 values is feasible.

Regarding the concern that “we are making a rod for our back by trying to make
this overly clever” and that the change makes it too complex — I disagree.
Having had this discussion earlier we’ve ended up with,
• a shorthand for octal
• ls-style
• chmod-style
I think this small collection of distinct and simple input methods isn’t overly
clever or complex, and feel that it strikes the right balance between too many
options and too little flexibility.

Octal is great, for those that are familiar with it. Likewise, chmod-style is
quite natural for those who are used to chmod. There’s little added complexity
to the Org code base as we simply pass this to the Emacs function
file-modes-symbolic-to-number. I think the ls-style is quite valuable for two
reasons. It’s well-established thanks to ls, and is particularly good for
understanding permissions at a glance. For reading Org files I think this is
advantageous compared to the other styles. I’m don’t find assertions that this
is non-typical or unpredictable well-founded. Each style/syntax is well-defined,
simple, distinct, and taken from very common/wide spread usage.

Tim suggested that invalid forms should cause tangling to fail, but I feel this
may be a bit much. Personally I’m inclined to either
• warn, and don’t touch the file permissions (this is what currently occurs)
• use a very conservative file permission (e.g. rw——-).

So, as I see it the main decision that needs to be made is how to handle the
octal shorthand, now that it’s clear that the original plan is flawed? I’m
thinking either “o555” or “#o555” would be a good improvement over “(identity
#o555), but am open to other suggestions.

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Thomas (& co.),

>> […] I’m thinking either “o555” or “#o555” would be a good improvement over
>> “(identity #o555), but am open to other suggestions.
>
> That’s reasonable. I’d even tend to disallow decimal. In usage, it’s too
> exotic and the potential for someone entering “just a number” expecting
> for it to be read as octal is too high. Is it worth the risk?

I’ve just pushed three commits that
1. Add “o555” as an octal shorthand
2. Perform a simple check that integer modes are valid*
3. Make the ls-style regex stricter

> Timothy, I really admire your patience, and your incredibly friendly way
> of doing things :)

Thanks. It helps that this list is fairly friendly to begin with :)

All the best,
Timothy

* For example, “:tangle-mode 755” will now produce the warning:
  “1363 is not a valid file mode octal. Did you give the decimal value 755 by
  mistake?”. Maybe it would be worth adding “if so try o755” or similar?

[Aside] Generating commit messages for Org

[Timothy]

Hi All,

A few hours ago I noticed that I’ve made a few very minor mistakes in some of my
recent commit messages for Org. Realistically I don’t think I’m going to stop
making occasional mistake any time soon, eve if they do become rarer. So, I’ve
whipped up a magit hook that looks at the diff and fills in a /correct/ skeleton
in the commit message buffer.

For example, here’s what I get if a queue a few of my currently unstaged changes
┌
│ * lisp/org.el (org-place-formula-image, org-format-latex):
│ 
│ * lisp/org-macs.el (org-compile-file, org-async-queue):
└

This currently works with elisp functions/variables/etc. and headings from
documentation files. I’m sure it has a few rough edges, but it’s looking
promising so far.

Maybe a few of you might also find it of interest?
<https://tecosaur.github.io/emacs-config/config.html#commit-message-templates>
(the relevant commit is 
<https://github.com/tecosaur/emacs-config/commit/d1e3042a>).

Another thought I’ve had is a commit lint function for flycheck to check some
extra things (two spaces after sentences, commit subject starting with a capital
letter, etc.), but I haven’t looked into that at all.

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Tim,

>> The parsing of “555” to the integer 555 is done by
>> org-babel-parse-header-arguments, and so can’t really be changed.
>
> I don't understand this. Why can't it be changed?

Well, it can't be changed without changing
org-babel-parse-header-arguments, which is quite a major change and I
suspect may be a breaking change.

Maybe it's fine? I just don't feel confident about this.

> When I said disable base 10 values, what I meant was generate an error
> if the value looks like it is base 10 i.e. does not have a leading o or
> #o. This makes it clear it has to be specified as an octal value and
> will alert users to this fact.

This is all well and good, but the point I'm making is that since due to
the current behaviour of org-babel-parse-header-arguments we can't
distinguish between :tangle-mode (identity #o555) and :tangle-mode 365
putting this idea /into practice/ doesn't look like it will be easy.

It's also worth noting that with regard to the recent changes that have
been made, this is not a new issue.

>> I think the ls-style is quite valuable for two reasons. It’s
>> well-established thanks to ls, and is particularly good for
>> understanding permissions at a glance.
>
> I would agree it is an established way to display the permissions
> associated with a filesystem object, but disagree it is a well
> established way to set such values - I know of no other tool which uses
> this format.

The driving motivation here is that while the tools which you mention do
not use this for setting permissions (e.g. chmod), they are only used
for /setting/ permissions. Since Org files aren't write-only, and
occasionally we go back and look at what we've written :P I think
allowing a format that is optimised for ease-of-reading instead of
ease-of-writing makes some sense. It is in this respect that I think
ls -l style is a good idea.

> It is also not the same as the ls -l display (no object
> type indicator). The ls -l also displays sticky bit, uid and gid. Does
> your format also support setting these values (something which can be
> done with the octal or symbolic formats) i.e. support s, S, t and T for
> the 'executable' bit for user/group?

Ah, I'm afraid that I'm not that up-together on sticky bits. I suspect
that it's not just the ls -l style that will need tweaking. I'll read up
on this in the next few days and update the ML.

> Personally, I prefer the symbolic form as it is shorter and clear. I
> find the ls -l form too easy to get wrong (especially with getting the
> number of '-' correct).

Isn't choice a great thing? :D In seriousness, this is exactly why I
think it's worth providing these options. At least thinking back to when
I started using Linux a few years ago I would have said the same thing
about the octal form, and was completely unfamiliar with chmod. I expect
different people to have different preferences with these three options,
but for one of them to be something most people are happy with.

>> Tim suggested that invalid forms should cause tangling to fail, but I feel 
>> this
>> may be a bit much. Personally I’m inclined to either
>> • warn, and don’t touch the file permissions (this is what currently occurs)
>> • use a very conservative file permission (e.g. rw——-).
>
> I'm unsure on this. My concern is people may not notice the warning and
> then be surprised later. Given the potential security issues, a later
> surprise is something to be avoided even if it is inconvenient. With
> respect to the default action to take, I would suggest we also need to
> look at the default umask setting for the user and if that is more
> restrictive, use that rather than some value like rw--- For all we
> know, the user has set a specific umask for a valid reason and will be
> surprised if emacs just ignores that to do what it wants (another
> surprise to be avoided).

> The user is not required to specify a mode. However, if they do and if
> we cannot interpret what they have specified without ambiguity, we
> should throw an error and cease processing. Making a guess as to what
> they intended in this situation is IMO a big mistake.

I don't see how using the default permissions is a potential security
risk? Could it surprise the user, yes, but that seems unavoidable when
the user is doing something invalid.

> My only preference for "#o" over just "o" prefix is to clearly signal to
> the user that it is an octal value and avoid the situation where you
> might glance a value and see the leading 'o' as a '0', missing the point
> it is an octal value not a decimal one. However, this seems like a low
> risk, so I'm happy either way.

Well, I've got "o" for now but that's not set in stone. With a lower
case "o" I feel the risk for confusion with "0" is quite low (besides
which a "0" prefix seems to be the C-style for octal anyway).

All the best,
Timothy

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi Greg,

> i’d push back, even here, on allowing decimal.  file modes are bit
> masks.  to me, offering a way to set a bit mask via a *decimal* value
> seems a mistake.

Just a quick note (see my long recent reply to Tim where I expand on this more),
but this isn’t new behaviour (isn’t actually affected by my recent changes) and
my concerns are with the viability of the necessary changes rather than whether
this would be good (we are of the same mind I think).

All the best,
Timothy

Re: [PATCH] org-src: Reset buffer-modified-p after fontifying

[Timothy]

Hi Clément,

I've just had a look at your patch, and it seems very reasonable to me.
Hence, I've just pushed it as ebd06c1 :)

> Hi all,
>
> * lisp/org-src.el (org-src-font-lock-fontify-block): Reset the
> modification flag of the temporary fontification buffer after
> fontifying.
>
> Without this some modes cause Emacs to prompt about unsaved buffers
> when exiting: `Save buffer *org-src-fontification:...-mode*?'
>
> (I'm seeing this with Proof General's coq-mode, specifically.)
>
> Clément.
>
> [2. text/x-patch; 
> 0001-org-src-Reset-buffer-modified-p-after-fontifying.patch]...

--
Timothy

Dodgy Worg publishing? (was: [patch] Fix link to Library of Babel)

[Timothy]

Hi Thomas,

Thanks for catching this problem. To me this looks more like a problem with the
worg publishing than an outdated link. I’ve cc’d Bastien as he’s much more
familiar with the Worg publish process than I am.

“Thomas S. Dye”  writes:

> The attached patch changes a 404 link to the working link used on Worg.

All the best,
Timothy

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Hi All,

Since the contentious component of my previous patches has been the
`{{{results()}}}' prettification, I’ve prepared an alternate version that I’m
hoping everybody will be fairly happy with (fingers crossed!) that tosses out
the results prettification for now.

I think Protesilaos’ comments on making some new faces deserve consideration,
but could easily be done subsequently, as I’m quite keen to get this merged for
now.

All the best,
Timothy
>From 53d2851e248c4f4e4076878a999cbf647b401578 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 13 Jul 2021 02:43:29 +0800
Subject: [PATCH] org-src: Implement native inline src fontification

* lisp/org-src.el (org-fontify-inline-src-blocks,
org-fontify-inline-src-blocks-1): Create a function to search the buffer
up to a limit for inline src blocks.  Light fontification is applied to
matched inline src blocks.  When `org-src-fontify-natively' is
set, `org-src-font-lock-fontify-block' is applied to the content.

* lisp/org.el (org-set-font-lock-defaults): Add
`org-fontify-inline-src-blocks' to `org-font-lock-extra-keywords', which
is locally bound inside `org-set-font-lock-defaults'.
(org-inline-src-fontify-max-length): Create a variable to limit the
maximum length of an inline-src block fontified, to protect from lag
spikes (e.g. when typing out src_lang{ and half of the buffer is
fontified).
---
 lisp/org-src.el | 46 ++
 lisp/org.el | 18 ++
 2 files changed, 64 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 51dde602d..c3a6a40bc 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -654,6 +654,52 @@ (defun org-src-font-lock-fontify-block (lang start end)
 	 '(font-lock-fontified t fontified t font-lock-multiline t))
 	(set-buffer-modified-p modified)
 
+(defun org-fontify-inline-src-blocks (limit)
+  "Try to apply `org-fontify-inline-src-blocks-1'."
+  (condition-case nil
+  (progn
+(org-fontify-inline-src-blocks-1 limit)
+(org-fontify-inline-src-results limit))
+(error (message "Org mode fontification error in %S at %d"
+(current-buffer)
+(line-number-at-pos)
+
+(defun org-fontify-inline-src-blocks-1 (limit)
+  "Fontify inline src_LANG blocks, from `point' up to LIMIT."
+  (let ((case-fold-search t)
+(initial-point (point)))
+(when (re-search-forward "\\_

Re: [PATCH] Accept more :tangle-mode specification forms

[Timothy]

Hi  Tim,

Thanks for the way in which you’ve responded to my comments. I appreciate the
effort you’ve gone to to explain your views as opposed to simply saying you
disagree with some of my current thoughts :)

Tim Cross  writes:

> My suggestion is simply to look at the value and if it is not a string, reject
> it outright. […] This is not a change in org-babel-parse-arguments,
> but rather a change in how we interpret those arguments.

Ah I see, I did not think you were suggesting this. I’m quite wary of this as it
would break all current `:tangle-mode (identity #oXYZ)' headers, which as I
understand it are /the/ way tangle-mode has been previously set.

Perhaps this is a good argument for deprecation? I think we’d need to give a
decently long transition period though (a few years).

> Allowing base 10 mode specifications is just a bad idea. The fact it has been
> permitted in the past is likely just an oversight rather than intentional
> behaviour.

I think we are of the same mind regarding base10 permissions specifications
being bad, but are niggling over what to do about this.

> Given the potential security issues involved
> here, I think we can legitimately obsolete such features (using
> acceptable change management approaches with suitable notification for
> users etc).

I’m certainly open to deprecation, though I’d like to hear from some of the
other “main Org people” (e.g. Bastien, Nicolas) before doing anything along
these lines. Perhaps this would be worth making a second thread for?

> I understand your motivation. I dispute your claim it is an established
> and common convention.

Ok, cool. Since we should have a while till the next Org release, nothing is set
in stone yet and hopefully this will give us time to see if the ls -l format is
fit for purpose or not. I think it will be, but correctness is of course more
important than niceness.

>> [sticky bits and the ls -l format]
>
> This is very difficult Timothy. I really do appreciate all the work you
> have done here and your patience, which makes what I’m going to say all
> the more difficult. My big concern here is that you don’t understand
> this area with sufficient depth of understanding to really appreciate
> some of the subtleties involved here. This makes me concerned that any
> implementation of a new way to specify mode settings may have some
> unexpected side effects or hidden issues which could be exploited in
> unexpected ways (worse case) or simply have unexpected bugs which result
> in mode settings which are not what the user intended. As someone who
> has used Unix since 1980 and Linux since 1995, I’ve experienced my share
> of issues relating to file modes and their interaction with different
> filesystems, NFS, different platforms, character sets, locales etc.
> Implementing a new approach as you are proposing is something I would be
> extremely wary about.
>
> If you do plan to go forward with this approach, please ensure you are
> very confident in your understanding of the sticky bit, setuid/setgid
> and associated interaction with execute etc.

Thanks for explaining your position thoroughly here. I don’t need any convincing
that a solid understanding is necessary for a good implementation. I had a quick
peek and estimated the time I’d need to properly come to terms with sticky bits 
—
hence my estimate of a few days before I look at implementing this.

> I suspect you do have the skills to implement correctly given sufficient
> time, testing and motivation. However, I am concerned your initial stab
> at this may be somewhat naive and requires more consideration. My main
> concern is that once you take all the subtleties into consideration, the
> complexity of your ls -l approach will exceed its utility and
> maintainability. I could also be completely wrong.

I’ll let you (/the ML) know when I’ve taken a look at stiky bits, and whether I
think I’m able to create something that works. My intuition is that if ls -l can
properly represent sticky bits (and my rudimentary understanding is that it can)
it should be fine for specifying them too. We’ll see.

> Choice is good. However, as I mentioned in a previous post, the problem
> with choice is complexity and the biggest source of security problems is
> complexity. Keep in mind that what you do now is something which will
> need to be maintained by others in the future. It needs to be clear,
> concise and as simple as possible (but of course, no simpler!).

I like to think that the current implementation is fairly short and clean. If I
can’t add sticky bits “nicely”, I’ll reconsider things.

> Consider this simple scenario. The tangled output is being written to a
> directory which requires specific permissions for security reasons -
> perhaps it is some type of ftp server where permissions will determine
> what can be s

Re: [PATCH] Fix window width when line numbers present

[Timothy]

Hi Matt,

> This is a very small patch that I believe fixes a previous, incorrect
> fix for computing the window text area when line numbers are
> present. The previous fix seemed to assume that
> display-line-numbers-width being nil meant that this means line numbers
> are not present. However, it can also mean (as described in the
> variable documentation) that the line number width is computed
> dynamically.

Thanks for this patch. I wasn’t aware of `line-number-display-width' when I 
wrote
that, but it looks like a better fit than my `(or ... 0)' statement. As such, 
I’ve
just applied your patch as cd3e138, tweaking the commit message to no longer go
over the maximum length :)

Looking at the docstring for `line-number-display-width', it seems that the
pixelwise mode may be more useful for our purposes, but that improvement can be
in a subsequent patch.

All the best,
Timothy

Re: [PATCH] Fix window width when line numbers present

[Timothy]

Oops, I forgot to mark this patch as applied for updates.orgmode.org.
Done in this message.

Re: [PATCH] Fix regex for determining image width from attribute

[Timothy]

Hi Matt,

> A recent patch started computing the inline image width from any attr_
> line. This is incorrect, as it matches settings like attr_latex, or
> attr_html. We only want to look for settings specifically for the org
> buffer. This patch fixes that.

Once again, thank you for the patch. The fact that the current regexp matches
`#+attr_latex' and `#+attr_html' is in fact by design though*. This is because I
consider it safe to assume that a `#+attr_*' which gives non-integer width 
between
0 and 2 can be safely assumed to be that proportion of the page width. e.g.
`#+attr_latex: :width 0.7\linewidth' or `#+attr_html: :width 70%'.
This way, a good guess can be made without having do have both an
`#+attr_latex/html' /and/ an `#+attr_org' line for the width. Should this 
assumption
be incorrect, a subsequent `#+attr_org' line will override the other `#+attr_*'.

Should there be edge-cases where this assumption doesn’t hold, I’d be interested
in patches that improves the logic here. As long as this holds more often than
not though, this should be a net positive for user experience as I see it.

Do please let me know if there are any good examples of unintended /
counter-intuitive behaviour you’re aware of.

All the best,
Timothy

* Well, it’s worked this way for a while, and I made a deliberate choice to keep
  this behaviour when expanding the width to recognise proportional values.

Re: [PATCH] Fix window width when line numbers present

[Timothy]

Nicolas Goaziou  writes:

> `line-number-display-width’ is Emacs 26+. So I guess it is unfortunately
> not acceptable on main branch.

Ooops, thanks for picking that up Nicolas. I see we actually have
┌
│ (if (fboundp 'line-number-display-width)
│ (defalias 'org-line-number-display-width 'line-number-display-width)
│   (defun org-line-number-display-width (&rest _) 0))
└
in org-compat.el, but I think that fallback definition could be improved — even
just `(or display-line-numbers-width 0)' would be better.

All the best,
Timothy

Re: [PATCH] Fix window width when line numbers present

[Timothy]

Hi Bastien,

> We can safely assume that Org 9.6 will be released after Emacs 28, so
> let’s use `line-number-display-width’ on main.

So I take this to mean that we will now assume that Org 9.6+ will target Emacs
29? This seems reasonable to me, but doesn’t quite accord with how I read
<https://orgmode.org/worg/org-maintenance.html#emacs-compatibility>.

All the best,
Timothy

Re: Dodgy Worg publishing?

[Timothy]

Hi Bastien,

> You can check the output of Worg publishing process here:
>
> <https://builds.sr.ht/~bzg/worg>

Ah cool, thanks for pointing that out.

> The latest build contains a line showing that library-of-babel.org
> does not export:
>
> <https://builds.sr.ht/~bzg/job/627192#task-install-784>
>
>   “Reference `fibs’ not found in this buffer”
>
> Can someone have a look at this and fix the ref?

I’ve just pushed b837a85 which just defines fibs using the content of the
example block. This may not be the best fix long-term, but should make it work.

All the best,
Timothy

Supported Emacs version (was: [PATCH] Fix window width when line numbers present)

[Timothy]

Hi Bastien,

> Our commitment is that the latest Org version is compatible with the
> last three stable versions of Emacs.
>
> So when Emacs 28 and Org 9.6 are both out, we guarantee that Org is
> compatible with Emacs 28, 27 and 26.
>
> Does that explain it better?

Thanks for clarifying. That’s perfectly clear, and re-reading the content of
<https://orgmode.org/worg/org-maintenance.html#emacs-compatibility> I think that
is too and I just must have read it strangely the first time??

On the topic of Emacs version compatibility, I’ve just taken a peek at
org-compat.el and notice that we still have code for Emacs < 24.4 compatibility.
I’m tempted to make some patches to remove all the Emacs < 26 compatibility code
if we no longer need it. What do you think?

All the best,
Timothy

Re: Supported Emacs version

[Timothy]

Hi  Bastien,

>> I’m tempted to make some patches to remove all the Emacs < 26
>> compatibility code if we no longer need it. What do you think?
>
> We should NOT remove this code: many people probably use/need it.
>
> Anything that helps keeping Org compatible with Emacs < 26 is
> still useful, the more compatible the better.
>
> If for some reason, some backward-compatibility code becomes too
> difficult to maintain then perhaps yes we can remove it, but not
> before.

Hmm, I’m not entirely sure what to think here. On one hand, I very much agree
with you that it’s better if Org is compatible with older versions just by
having a bit of extra code left in org-compat.el. However, if many bits of Org
use Emacs 24/25/26 functions that /aren’t/ covered in org-compat.el (as I think 
is
currently the case) that leads to bits of Org that are covered by org-compat.el
and bits that aren’t, and so I imagine this currently produces inconsistently
buggy behaviour in old versions of Emacs.

If this were just a question of fully supporting older Emacs versions at no
extra cost, I’d be inclined to respond as you have, but I think the problem we
really have is whether it’s better to provide /partial/ support for older 
versions
of Emacs? Personally I’m more inclined towards an all-or-nothing approach.

All the best,
Timothy

Re: Supported Emacs version

[Timothy]

Hi Bastien,

> Org is made of many areas and partial backward-compatibility can
> still be useful.  When people report compatibility problems with
> Emacs <26, we can guide them so that they enhance org-compat.el.
>
> It is not because we don’t promise compatibility for Emacs < 26
> that we should prevent backward-compatibility for Emacs < 26, and
> the all-or-nothing approach would actually prevent it.
>
> I hope this is convincing enough :)

It’s not the choice I’d make, but what matters more is that I now better
appreciate/understand the motivation for leaving those bit in.

Thanks for discussing this a bit :)

All the best,
Timothy

Re: [PATCH] Fix regex for determining image width from attribute

[Timothy]

Hi Matt,

> Unfortunately, I think this makes a valid use case
> impossible. Specifically, I like to be able to set an image width
> explicitly with #+attr_org (or some other attr_ for the corresponding
> export) and fall back to the actual image width when this isn’t
> specified. This includes the ability to use the actual image width in an
> org buffer, but an explicitly-set image width for export. For example,
> for my blog I often have attr_html set, but I want the image to use its
> actual width when displayed in org.

Thanks for explaining a use case! That’s most helpful.

> I don’t see how this is possible with the current implementation.But, it
> works naturally with the implementation I have in mind

Actually, it’s almost possible with the current implementation. Consider this
example:
┌
│ #+attr_org: :width t
│ #+attr_html: :width 20%
│ [[file:image.png]]
└

At the moment Org tries to interpret `t' as a number (and obviously fails),
however with a small tweak that I think would be very reasonable to make, this
would cause the behaviour you describe.

What do you think?

> (IIRC this is how it previously worked, but I could be mistaken).

You are mistaken. The previous implementation looked for `#+attr_*' too, but
didn’t recognise proportional values.

> Maybe a solution to accomplish all goals would be to add an #+attr_fallback
> (or attr_default, attr_any, attr_all, etc.) that is used for any backend
> unless a specific setting is made for that backend.

Hmmm, I’m not sure this is called for.

All the best,
Timothy

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Hi Everyone,

I think there’s room in the future to add more faces for this, but I it occurs
to me that the main complaint raised in this thread can be resolved by adding
one new face: `org-inline-src-block' (which inherits from `org-block') by 
default.

See attached for a patch which just adds this face. I feel like this might be
the final version of this patch so I’d appreciate thoughts on this.

All the best,
Timothy
>From 133b7a90853f7f9062bae40af2efc8fd22781125 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 13 Jul 2021 02:43:29 +0800
Subject: [PATCH] org-src: Implement native inline src fontification

* lisp/org-src.el (org-fontify-inline-src-blocks,
org-fontify-inline-src-blocks-1): Create a function to search the buffer
up to a limit for inline src blocks.  Light fontification is applied to
matched inline src blocks.  When `org-src-fontify-natively' is
set, `org-src-font-lock-fontify-block' is applied to the content.

* lisp/org.el (org-set-font-lock-defaults): Add
`org-fontify-inline-src-blocks' to `org-font-lock-extra-keywords', which
is locally bound inside `org-set-font-lock-defaults'.
(org-inline-src-fontify-max-length): Create a variable to limit the
maximum length of an inline-src block fontified, to protect from lag
spikes (e.g. when typing out src_lang{ and half of the buffer is
fontified).

* lisp/org-faces.el: Introduce a new face `org-inline-src-block' which
inherits from `org-block' by default.
---
 lisp/org-faces.el |  4 
 lisp/org-src.el   | 46 ++
 lisp/org.el   | 18 ++
 3 files changed, 68 insertions(+)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index b151045a9..272762789 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -459,6 +459,10 @@ (defface org-block-end-line '((t (:inherit org-block-begin-line)))
   "Face used for the line delimiting the end of source blocks."
   :group 'org-faces)
 
+(defface org-inline-src-block '((t (:inherit org-block)))
+  "Face used for inline source blocks as a whole."
+  :group 'org-faces)
+
 (defface org-verbatim '((t (:inherit (fixed-pitch shadow
   "Face for fixed-with text like code snippets."
   :group 'org-faces
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 51dde602d..f2aff1f43 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -654,6 +654,52 @@ (defun org-src-font-lock-fontify-block (lang start end)
 	 '(font-lock-fontified t fontified t font-lock-multiline t))
 	(set-buffer-modified-p modified)
 
+(defun org-fontify-inline-src-blocks (limit)
+  "Try to apply `org-fontify-inline-src-blocks-1'."
+  (condition-case nil
+  (progn
+(org-fontify-inline-src-blocks-1 limit)
+(org-fontify-inline-src-results limit))
+(error (message "Org mode fontification error in %S at %d"
+(current-buffer)
+(line-number-at-pos)
+
+(defun org-fontify-inline-src-blocks-1 (limit)
+  "Fontify inline src_LANG blocks, from `point' up to LIMIT."
+  (let ((case-fold-search t)
+(initial-point (point)))
+(while (re-search-forward "\\_

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Hi Ihor,

> I have some comments. See below.

Thanks for going through this, and for all your help previously.
I appreciate it :)

>> (org-inline-src-fontify-max-length): Create a variable to limit the
>> maximum length of an inline-src block fontified, to protect from lag
>> spikes (e.g. when typing out src_lang{ and half of the buffer is
>> fontified).
>
> I do not like this. Even with this variable, some part of buffer may be
> spuriously fontified. Maybe you just verify that you are at actual
> inline-src block by examining org-element-context?

The description may need updating, as that’s a tad inaccurate. That value
actually limits how far forwards a paired paren is searched for. There’s no
spurious fontification.

>> +(defun org-fontify-inline-src-blocks (limit)
>> +  “Try to apply `org-fontify-inline-src-blocks-1’.”
>> +  (condition-case nil
>> +  (progn
>> +(org-fontify-inline-src-blocks-1 limit)
>> +(org-fontify-inline-src-results limit))
>
> org-fontify-inline-src-results is not defined in this patch.

Ah. Thanks for catching this!

>> +(font-lock-append-text-property lang-beg lang-end ’face 
>> ’org-meta-line)
>> +(font-lock-append-text-property beg lang-beg ’face ’shadow)
>> +(font-lock-append-text-property beg lang-end ’face 
>> ’org-inline-src-block)
>
> Is there some special reason why you apply both ’shadow and
> ’org-inline-src-block? What about ’org-meta-line face? Maybe
> ’org-meta-line should not be hard-coded?

I think there’s an argument for more faces that can be made because of element
like this, but it comes down to the idea that in a `src_lang[options]{content}'
construct `src_' is effectively visual noise, particularly once fortification
occurs and it’s obvious that it’s inline code even without it. So, I find it
nicest if it’s faded, which `shadow' does. Also applying `org-inline-src-block'
allows for a consistent background colour across the whole construct.

>> +(setq pt (goto-char lang-end))
>> +;; `org-element–parse-paired-brackets’ doesn’t take a limit, so to
>> +;; prevent it searching the entire rest of the buffer we temporarily
>> +;; narrow the active region.
>> +(save-restriction
>> +  (narrow-to-region beg (min (point-max)
>> + limit
>> + (+ lang-end 
>> org-inline-src-fontify-max-length)))
>> +  (when (ignore-errors (org-element–parse-paired-brackets ?\[))
>> +(font-lock-append-text-property pt (point) ’face 
>> ’org-inline-src-block)
>> +(setq pt (point)))
>> +  (when (ignore-errors (org-element–parse-paired-brackets ?\{))
>
> It looks like you are repeating the job of org-element-context here. Why
> don’t you just get the proper object?

IIRC `org-element-context' doesn’t separate out the `src_', `lang', 
`[options]', and
`{content}' of an inline source code block (which we want).

>> +(remove-text-properties pt (point) ’(face nil))
>> +(font-lock-append-text-property pt (1+ pt) ’face ’(org-block 
>> shadow))
>
> Do you really intend to use ’org-block and ’shadow faces here? Not
> ’org-inline-src-block?

Ah, that was an oversight. Thanks for catching that, changed to
`(org-inline-src-block shadow)'.

>> +(defcustom org-inline-src-prettify-results t
>
> Looks like a stray defcustom. At least, it is not mentioned in the
> commit message and not used within the patch.

Removed.

> Best,
> Ihor

Thanks again! See an updated patch attached.

All the best,
Timothy
>From 08fff19eb6242339f9fe5549de0bc54520a3d603 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Tue, 13 Jul 2021 02:43:29 +0800
Subject: [PATCH] org-src: Implement native inline src fontification

* lisp/org-src.el (org-fontify-inline-src-blocks,
org-fontify-inline-src-blocks-1): Create a function to search the buffer
up to a limit for inline src blocks.  Light fontification is applied to
matched inline src blocks.  When `org-src-fontify-natively' is
set, `org-src-font-lock-fontify-block' is applied to the content.

* lisp/org.el (org-set-font-lock-defaults): Add
`org-fontify-inline-src-blocks' to `org-font-lock-extra-keywords', which
is locally bound inside `org-set-font-lock-defaults'.
(org-inline-src-fontify-max-length): Create a variable to limit the
maximum length of an inline-src block fontified, to protect from lag
spikes (e.g. when typing out src_lang{ and half of the buffer is
fontified).

* lisp/org-faces.el: Introduce a new face `org-inline-src-block' which
inherits from `org-block' by default.
---
 lisp/org-faces.el |  4 
 lis

Re: [PATCH] Fontification for inline src blocks

[Timothy]

Hi Ihor,

>>>> org-inline-src-fontify-max-length
>> The description may need updating, as that’s a tad inaccurate. That value
>> actually limits how far forwards a paired paren is searched for. There’s no
>> spurious fontification.
>
> I can see the purpose. However, it still looks like overcomplication.
> org-element-context takes care about this issue simply by narrowing to
> current element (inline src block is an object and hence must end within
> current element).

Well, one simple change we could do is just replace
org-inline-src-fontify-max-length with the addition of `(save-excursion
(search-forward "\n" limit nil) (point))' to the restriction.

>>> It looks like you are repeating the job of org-element-context here. Why
>>> don’t you just get the proper object?
>>
>> IIRC `org-element-context’ doesn’t separate out the `src_’, `lang’, 
>> `[options]’, and
>> `{content}’ of an inline source code block (which we want).
>
> Sounds like an omission in org-element-context. At least, the parser
> could return :contents-begin and :contents-end. Then, you would also not
> need to re-implement the parser.

Perhaps. However frankly I don’t think it would do that much to reduce the
complexity, and what’s in this patch seems to work fairly nicely.

All the best,
Timothy

Re: [PATCH] Fix regex for determining image width from attribute

[Timothy]

Hi Matt,

I’ve just pushed the change I described in 4514a32. This improves the
interpretation of :width attributes and makes a value of “t” work as discussed.
I have not prioritised #+attr_org for now, but that sounds like a change we
could make in the future.

All the best,
Timothy

Worg's library-of-babel.org (was: Dodgy Worg publishing?)

[Timothy]

"Thomas S. Dye"  writes:

> I checked this morning and I still get a 404 error when I follow the Worg link
> in section 16.12 of the Org mode manual at orgmode.org.

(sigh) I already fixed a 2nd issue, it looks like there's at least a
3rd...

--
Timothy

Re: [QUESTION] How to specific image size attributes under headline scope?

[Timothy]

Hi Christopher,

> I want to specify image size under headline properties. Is it possible to do
> this?

As I understand org.el, this is solely governed by
`org-display-inline-image--width', which only looks at `#+attr_*' keywords when
setting an image width.

All the best,
Timothy

Re: [PATCH] ob-shell-test, test-ob-shell and introduction

[Timothy]

Hi Matt,

> I’m interested in getting async into ob-shell.el. Since I’ve never contributed
>before, I figure it’d be good to start with a few easy tasks.

Fantastic! Great to hear from you, and I hope it goes well. Feel free to send
further emails for if you get stuck. If you intend to do more than just one or
two small tweaks (it sounds like you have bigger plans than that), you’ll need
what’s known as [FSF copyright assignment]. Have you done that yet?

> It looks to me like the stdin and cmdline header args aren’t documented 
> anywhere
> (at least I couldn’t find anything). To make sure I’m using them correctly
> before making a patch for the manual, here are some tests.

Great! I’m not overly familiar with these, so I’ll leave other people to take a
look at the tests you’ve written, but your approach sounds good. 👍

> Please let me know if things look okay. It wasn’t clear to me how to send 
> along
> a message with git send-email, so I formatted these patches and included them 
> as
> an attachment. Is that fine?

Patches attached to an email are perfectly fine here.
Thanks for getting in touch, and I hope to see you around 🙂.

All the best,
Timothy


[FSF copyright assignment] <https://orgmode.org/contribute.html#copyright>

Re: Invalid read syntax errors compiling orgmode from git repository

[Timothy]

Hi Kyle,

> Timothy, please look over my change to confirm that it matches the
> change you intended to make in 4514a324c.

I’ve just become aware that a paren slipped out of that commit. I’m currently
writing the commit message on a correction. Expect to see it pushed in a minute
or two :)

All the best,
Timothy

Re: Invalid read syntax errors compiling orgmode from git repository

[Timothy]

Hi Kyle,

>> Timothy, please look over my change to confirm that it matches the
>> change you intended to make in 4514a324c.
>
> I’ve just become aware that a paren slipped out of that commit. I’m currently
> writing the commit message on a correction. Expect to see it pushed in a 
> minute
> or two :)

Ooops, I missed the part where you said you pushed a commit. I discovered this
when I pulled before pushing and noticed that my commit disappeared because you
recently pushed one making exactly the same changes (character for character) 😅.

Thanks for taking care of this, and sorry for causing a bit of trouble by
letting it slip through.

All the best,
Timothy

Re: [PATCH] Fix regex for determining image width from attribute

[Timothy]

Hi Matt,

This issue and Kyle’s change were resolved in another thread, just FYI this is
fixed now. Thanks for mentioning it.

All the best,
Timothy

Re: [PATCH] Fix regex for determining image width from attribute

[Timothy]

Hi Matt,

(sigh) well that’s silly. Thanks, I’ve just pushed that.

All the best,
Timothy

Re: Why is an image width restricted to being between 0 and 200% of the text area

[Timothy]

Hi Matt,

> I’m also not sure that we should prevent people from using
> 5.0, even if it is a bit odd. The intent is clear.
>
> Maybe I’m missing a reason as to why this is done?

Just to be clear, this isn’t preventing people from setting image widths to say
`5.0\linewidth', it just prevents them from being previewed at 5x the buffer 
text
width as that seems a bit ridiculous. Happy to reconsider the [0,2] preview
restriction, but I don’t think ridiculously large in-buffer images make much
sense.

All the best,
Timothy

Re: Why is an image width restricted to being between 0 and 200% of the text area

[Timothy]

Hi Matt,

> I agree that requesting an image to be >2x the buffer text width is a
> strange request, and it’s not one I’ve ever tried to give. But, I think
> the salient point is that it’s a very clear request, and I think org
> should carry it out. I’m all in favor of org helping people not shoot
> themselves in the foot, but I don’t think it should prevent people from
> doing so, especially when they’re clear about their intentions. I also
> think this qualifies as a case where someone /might/ have a valid reason
> for doing this.

It occurred to me that large values would only really appear when occurring in a
narrower scope, e.g. in a multi-column document an image which is multiple
columns wide. Say,
┌
│ #+attr_latex: 3.0\columnwidth
└

However, I doubt that when previewing the image in Org one would want the
preview to be 3x the buffer text area width!

I suppose the exception would be say something like
┌
│ #+attr_org: :width 300%
└
Though I can’t imagine why you’d want that…

I think you don’t raise an unreasonable point, however I’m tempted to let this
sit till we hear from someone who actually runs into this as an issue.

All the best,
Timothy

Re: [Aside] Generating commit messages for Org

[Timothy]

Hi Robert,

> I suggest you look at `add-change-log-entry-other-window’ and/or
> `magit-generate-changelog’.

Thanks for the suggestions. I happen to have already had a peek, but thought it
would be easier to make something from scratch than integrate those to create
the experience I wanted.

All the best,
Timothy