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

[Matt Huszagh]

Here are two patches that prioritize attr_org over other attr_
keywords. I believe this is what you had in mind Timothy. But let me
know if not.

The second patch (intended to be applied after the first) improves the
documentation. It describes behavior that wasn't previously documented
and removes redundant documentation between org-image-actual-width and
org-display-inline-image--width (now only in
org-image-actual-width). Please double check I got everything correct,
as I haven't used all this behavior myself.

Thanks
Matt

>From 22bbe7d651e1f27398597297c7c35ae4f3253773 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Mon, 22 Nov 2021 23:28:48 -0800
Subject: [PATCH 1/2] org.el: Prioritize attr_org when computing image width

	* lisp/org.el (org-display-inline-image--width): First look
	for attr_org: :width and then look for another attr_.* :width
	when that isn't specified.
---
 lisp/org.el | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 308bb7d51..bf5d08e09 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16853,13 +16853,20 @@ buffer boundaries with possible narrowing."
((listp org-image-actual-width)
 (let* ((case-fold-search t)
(par (org-element-lineage link '(paragraph)))
-   (attr-re "^[ \t]*#\\+attr_.*?: +.*?:width +\\(\\S-+\\)")
+   (attr-re (lambda (backend)
+  (concat "^[ \t]*#\\+attr_"
+  backend
+  ": +.*?:width +\\(\\S-+\\)")))
(par-end (org-element-property :post-affiliated par))
-   ;; Try to find an attribute providing a :width.
+   ;; If an attr_org provides a :width, use that. Otherwise,
+   ;; use the first attribute that provides it, if any.
(attr-width
 (when (and par (org-with-point-at
(org-element-property :begin par)
- (re-search-forward attr-re par-end t)))
+ (or (re-search-forward (funcall attr-re "org")
+par-end t)
+ (re-search-forward (funcall attr-re ".*?")
+par-end t
   (match-string 1)))
(width
 (cond
-- 
2.31.1

>From aff581922e8d8bf10f813cdb9bc8adf9c8632683 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Mon, 22 Nov 2021 23:30:11 -0800
Subject: [PATCH] org.el: Clarify documentation for computing image width

	* lisp/org.el (org-display-inline-image--width)
	(org-image-actual-width): Specify documentation for computing
	an inline image width in org-image-actual-width and remove the
	redundant documentation from org-display-inline-image--width.
---
 lisp/org.el | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index bf5d08e09..c8dc1815f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15529,10 +15529,29 @@ When set to a number in a list, try to get the width from any
 
 and fall back on that number if none is found.
 
-When set to nil, try to get the width from an #+ATTR.* keyword
-and fall back on the original width if none is found.
-
-When set to any other non-nil value, always use the image width.
+When set to nil, first try to get the width from #+ATTR_ORG.  If
+that is not found, use the first #+ATTR_.*:width specification.
+If that is also not found, fall back on the original image width.
+
+Finally, org is quite flexible in the width specifications it
+supports and intelligently interprets width specifications for
+other backends when rendering an image in an org buffer.  This
+behavior is described presently.
+
+1. A floating point value is interpreted as the percentage of the text
+   area that should be taken up by the image.
+2. A number followed by a percent sign is divided by 100 and then
+   interpreted as a floating point value.
+3. If a number is followed by other text, extract the number and
+   discard the remaining text.  That number is then interpreted as a
+   floating-point value.  For example,
+
+   #+ATTR_LATEX: :width 0.7\\linewidth
+
+   would be interpreted as 70% of the text width.
+4. If t is provided the original image width is used.  This is useful
+   when you want to specify a width for a backend, but still want to
+   use the original image width in the org buffer.
 
 This requires Emacs >= 24.1, built with imagemagick support."
   :group 'org-appearance
@@ -16838,16 +16857,7 @@ buffer boundaries with possible narrowing."
 (defvar visual-fill-column-width) ; Silence compiler warning
 (defun org-display-inline-image--width (link)
   "Determine the display width of the image LINK, in pixels.
-- When `org-image-actual-width' is t, the image's pixel width is used.
-- When `org-image-actual-width' is a number, that value will is used.
-- When 

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

[Matt Huszagh]

Timothy  writes:

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

Good point. I could see someone using this as an argument against
interpreting :width 3.0\columnwidth as :width 3.0, but I do see the
value in interpreting :width 0.8\linewidth as :width 0.8, so I don't
know.

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

Yeah I think that makes sense. Thanks for considering this anyway!

Matt

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

[Tim Cross]

Bastien  writes:

> Hi Ihor,
>
> Ihor Radchenko  writes:
>
>> The text is mostly clear. However, there is a slight confusion about
>> actual current Emacs version vs. planned Emacs version.
>
> I've rephrased it a bit to focus on "releases", not "versions":
>
>   We aim at keeping the latest stable version of Org compatible with
>   the *last three major releases of Emacs*.
>
>   For example, if the latest release of Emacs is 28.x, then you can
>   assume that the latest release of Org is compatible with Emacs 28.x,
>   27.x and 26.x, but not with Emacs 25.x.
>
>> Should we target "current" Emacs 28 for main? Should we target Emacs
>> version+1 as current on main all the time or maybe just when new
>> Emacs release branch is created, but not yet released? It is not
>> fully clear.
>
> These paragraphes on Worg try to explicit reasonable expectations 
> for users and are thus focusing on stable releases only.
>
> Expectactions for development versions are another story: I am in
> favor of not trying to commit to _any_ expectactions for Org's main.
>
> For example, I would not mind a feature on main that relies on a new
> feature in the Emacs development branch, as long as we manage to keep
> the promise that the next Org stable is usable with the older Emacs
> releases.

So what your saying is that if the current main branch relies on a
new feature in the current Emacs development branch, then org must also
have a compatibility function so that the feature works with at least
the last 2 released versions (possibly 3 since we don't know when the
new Emacs version will be released and we may need/want to release main
before the new Emacs version is released).


So basically, if you want to use a new feature in development Emacs, you
will also need to implement a compatibility version for the previous 2
or 3 Emacs versions. This probably sounds worse than it is in practice
because most of the time, once you have a compatibility implementation
for the previous version, it will likely work with the previous 2 or 3
versions. It further means that a new feature added into Emacs cannot be
used in org without a compatibility version until it has been in Emacs
for 3 versions. 

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: Why is an image width restricted to being between 0 and 200% of the text area

[Matt Huszagh]

Timothy  writes:

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

Thanks for the response Timothy.

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.

I guess we could make the upper limit customizable and default to
2.0. But, this is a bit confusing because it doesn't apply to the
original image width. I also think adding too many customizable
variables adds to complexity. I don't know. Thoughts? This also isn't a
feature I've ever needed... so I'm happy to concede and revisit it in
the future if I have a valid use case for it.

Matt

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

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

[Matt Huszagh]

Hi,

In org-display-inline-image--width we have the restriction that
percentages and floating point width specifications must be between 0
and 200% (or 0.0 and 2.0) of the text area. Reading the comments, it
sounds like this is done because you might specify something like
1.2\linewidth, but you wouldn't write something like 5.0\linewidth. I
guess that's fair, but I can't say with certainty that there is never
any valid reason to, e.g., specify that you want a width of 500% of the
text area. I'm also not sure that we should prevent people from using
5.0\linewidth, even if it is a bit odd. The intent is clear.

Maybe I'm missing a reason as to why this is done?

Best
Matt

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

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> The text is mostly clear. However, there is a slight confusion about
> actual current Emacs version vs. planned Emacs version.

I've rephrased it a bit to focus on "releases", not "versions":

  We aim at keeping the latest stable version of Org compatible with
  the *last three major releases of Emacs*.

  For example, if the latest release of Emacs is 28.x, then you can
  assume that the latest release of Org is compatible with Emacs 28.x,
  27.x and 26.x, but not with Emacs 25.x.

> Should we target "current" Emacs 28 for main? Should we target Emacs
> version+1 as current on main all the time or maybe just when new
> Emacs release branch is created, but not yet released? It is not
> fully clear.

These paragraphes on Worg try to explicit reasonable expectations 
for users and are thus focusing on stable releases only.

Expectactions for development versions are another story: I am in
favor of not trying to commit to _any_ expectactions for Org's main.

For example, I would not mind a feature on main that relies on a new
feature in the Emacs development branch, as long as we manage to keep
the promise that the next Org stable is usable with the older Emacs
releases.

-- 
 Bastien

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: [PATCH] Fix regex for determining image width from attribute

[Matt Huszagh]

Timothy  writes:

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

There is just one small residual error I could find. This patch fixes
it.

Matt

>From 3724b5bcadab6900367848dadcf470494b5b0d79 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Mon, 22 Nov 2021 21:36:03 -0800
Subject: [PATCH] org.el: Fix string-match-p function arguments

	* lisp/org.el (org-display-inline-image--width):
	string-match-p requires 2 arguments, but only one was given.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 736b743c7..308bb7d51 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16867,7 +16867,7 @@ buffer boundaries with possible narrowing."
  ((string= attr-width "t") nil)
  ;; Fallback to `org-image-actual-width' if no interprable width is given.
  ((or (null attr-width)
-  (string-match-p "\\`[^0-9]"))
+  (string-match-p "\\`[^0-9]" attr-width))
   (car org-image-actual-width))
  ;; Convert numeric widths to numbers, converting percentages.
  ((string-match-p "\\`[0-9.]+%" attr-width)
-- 
2.31.1

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: org-sort random

[Kyle Meyer]

(Please don't drop the list.)

Vikas Rawal writes:

> That is, just press RET?

I think that depends on the completion framework.  With the default
completion, yes, I think RET should do it.  With ivy, it's instead
ivy-immediate-done (C-M-j).  I'm not sure offhand about other
frameworks.

> If I do that, it just reverses the existing order. No randomisation
> happens.

Dunno.  Seems to work on my end (release_9.5.1-188-g27f26f782).

* h
** a
** b
** c
** d
** e
** f
** g
** h
** i
** j
** k
** l

With point on h and vanilla Emacs:

- C-c ^ f
- random
- RET

* h
** f
** e
** h
** i
** g
** j
** k
** b
** c
** d
** a
** l

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

[Kyle Meyer]

Matt Huszagh writes:

> Timothy  writes:
>
>> 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.
>
> Thanks Timothy. However, I think this change may have some issues. It
> seems that it unbalances parentheses. This also no longer sets width
> (so, e.g., (floatp width) won't work). Maybe attr-width was intended to
> be renamed to width? Are you seeing the same?

I'm not sure either, but this syntax error brings down the whole tree,
so I've pushed 27f26f782 to resolve it.  Timothy, please check my guess
at what the intended code was.

Re: [PATCH] ob-doc-shell.org (was [PATCH] ob-shell-test, test-ob-shell and introduction)

[Thomas S. Dye]

Aloha Matt,
Matt  writes:

 > Unfortunately, there is no ob-doc-shell.org at 
 > worg/org-contrib/babel/languages/.
 > 
 > There is an ob-doc-template.org in case you'd like to 
 > contribute 
 > ob-doc-shell.org :)


I created one, along with a sourcehut account. However, it looks 
like I need to be granted some permissions to write to the worg 
website. Is Bastien the contact for that? I've attached a patch 
in the mean time.


That's a good start.  Thanks!

Yes, contact Bastien directly off list with your sourcehut user 
name and he'll set you up to push directly to Worg.


Let me know if you have questions.

All the best,
Tom

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

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

[Kyle Meyer]

JG writes:

> commit 4514a324c86a408951a0553a390a01981d61c367 (HEAD -> main, origin/main, 
> origin/HEAD)
[...]
> In toplevel form:
> org-agenda.el:50:1: Error: Invalid read syntax: ")", 50, 14
> Compiling /home/etest/org-mode/lisp/org-archive.el...
[...]

Thanks for reporting.  The syntax error was introduced by the commit you
referenced and is fixed with 27f26f782.

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

[PATCH] ob-doc-shell.org (was [PATCH] ob-shell-test, test-ob-shell and introduction)

[Matt]

 > Unfortunately, there is no ob-doc-shell.org at 
 > worg/org-contrib/babel/languages/.
 > 
 > There is an ob-doc-template.org in case you'd like to contribute 
 > ob-doc-shell.org :)

I created one, along with a sourcehut account. However, it looks like I need to 
be granted some permissions to write to the worg website. Is Bastien the 
contact for that? I've attached a patch in the mean time.

0001-org-contrib-babel-languages-ob-doc-shell.org-Create-.patch
Description: Binary data

Invalid read syntax errors compiling orgmode from git repository

[JG]

Hi everyone, I was working to compile orgmode in a fresh Ubuntu 21.10 VM from
the git repository. My steps are this:

1. Clone and compile emacs from
https://git.savannah.gnu.org/git/emacs.git

The git log -1 line reads currently

commit 9ceb3070e34ad8a54184fd0deda477bf5ff77000 (HEAD -> master, origin/master, 
origin/HEAD)

2. Set this emacs as the one available in my path.

3. Clone and attempt to compile orgmode from
https://git.savannah.gnu.org/git/emacs/org-mode.git

The git -1 line reads currently

commit 4514a324c86a408951a0553a390a01981d61c367 (HEAD -> main, origin/main, 
origin/HEAD)

When running make in the orgmode directory it fails with the following
trace:

emacs  -Q -batch --eval '(setq vc-handled-backends nil org-startup-folded nil 
org-element-cache-persistent nil)'  \
  --eval '(add-to-list `load-path "../lisp")' \
  --eval '(load "../mk/org-fixup.el")'\
  --eval '(org-make-manuals)'
Loading /home/etest/org-mode/mk/org-fixup.el (source)...
Debugger entered--Lisp error: (invalid-read-syntax ")" 1 0)
  read(#)
  eval-buffer(# nil "/home/etest/org-mode/lisp/org.el" 
nil t)  ; Reading at buffer position 659072
  load-with-code-conversion("/home/etest/org-mode/lisp/org.el" 
"/home/etest/org-mode/lisp/org.el" nil t)
  require(org)
  eval-buffer(# nil 
"/home/etest/org-mode/lisp/org-element.el" nil t)  ; Reading at buffer position 
2546
  load-with-code-conversion("/home/etest/org-mode/lisp/org-element.el" 
"/home/etest/org-mode/lisp/org-element.el" nil t)
  require(org-element)
  eval-buffer(# nil "/home/etest/org-mode/lisp/ox.el" 
nil t)  ; Reading at buffer position 3143
  load-with-code-conversion("/home/etest/org-mode/lisp/ox.el" 
"/home/etest/org-mode/lisp/ox.el" nil t)
  require(ox)
  eval-buffer(# nil "/home/etest/org-mode/lisp/ox-texinfo.el" 
nil t)  ; Reading at buffer position 1089
  load-with-code-conversion("/home/etest/org-mode/lisp/ox-texinfo.el" 
"/home/etest/org-mode/lisp/ox-texinfo.el" nil t)
  require(ox-texinfo)
  org-make-manuals()
  eval((org-make-manuals) t)
  command-line-1(("--eval" "(setq vc-handled-backends nil org-startup-folded 
n..." "--eval" "(add-to-list `load-path \"../lisp\")" "--eval" "(load 
\"../mk/org-fixup.el\")" "--eval" "(org-make-manuals)"))
  command-line()
  normal-top-level()

make[1]: *** [Makefile:31: org.texi] Error 255
make[1]: Leaving directory '/home/etest/org-mode/doc'
make: *** [mk/targets.mk:127: info] Error 2

I have attached a text file of the full make run showing the same Error
invalid read syntax for a large number of other files.

make -C doc clean;  make -C lisp clean;
make[1]: Entering directory '/home/etest/org-mode/doc'
rm -f *.pdf *.html *.info *_letter.tex org-version.inc org-version.tex \
  *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.pg *.pgs *.toc \
  *.tp *.tps *.vr *.vrs *.log *.ps
make[1]: Leaving directory '/home/etest/org-mode/doc'
make[1]: Entering directory '/home/etest/org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc
rm -f *.elc
make[1]: Leaving directory '/home/etest/org-mode/lisp'
make -C lisp compile
make[1]: Entering directory '/home/etest/org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc
org-version: 9.5.1 (release_9.5.1-187-g4514a3)
Loading /home/etest/org-mode/lisp/org-compat.el (source)...
Loading /home/etest/org-mode/mk/org-fixup.el (source)...
org-loaddefs: 9.5.1 (release_9.5.1-187-g4514a3)
Loading /home/etest/org-mode/lisp/org-compat.el (source)...
Loading /home/etest/org-mode/mk/org-fixup.el (source)...
make compile-dirall
make[2]: Entering directory '/home/etest/org-mode/lisp'
 dirall 
Checking /home/etest/org-mode/lisp...
Compiling /home/etest/org-mode/lisp/ob-C.el...
Compiling /home/etest/org-mode/lisp/ob-R.el...
Compiling /home/etest/org-mode/lisp/ob-awk.el...
Compiling /home/etest/org-mode/lisp/ob-calc.el...
Compiling /home/etest/org-mode/lisp/ob-clojure.el...
Compiling /home/etest/org-mode/lisp/ob-comint.el...
Compiling /home/etest/org-mode/lisp/ob-core.el...
Compiling /home/etest/org-mode/lisp/ob-css.el...
Compiling /home/etest/org-mode/lisp/ob-ditaa.el...
Compiling /home/etest/org-mode/lisp/ob-dot.el...
Compiling /home/etest/org-mode/lisp/ob-emacs-lisp.el...
Compiling /home/etest/org-mode/lisp/ob-eshell.el...
Compiling /home/etest/org-mode/lisp/ob-eval.el...
Compiling /home/etest/org-mode/lisp/ob-exp.el...
Compiling /home/etest/org-mode/lisp/ob-forth.el...
Compiling /home/etest/org-mode/lisp/ob-fortran.el...
Compiling /home/etest/org-mode/lisp/ob-gnuplot.el...
Compiling /home/etest/org-mode/lisp/ob-groovy.el...
Compiling /home/etest/org-mode/lisp/ob-haskell.el...
Compiling /home/etest/org-mode/lisp/ob-java.el...
Compiling /home/etest/org-mode/lisp/ob-js.el...
Compiling /home/etest/org-mode/lisp/ob-julia.el...
Compiling /home/etest/org-mode/lisp/ob-latex.el...
Compiling 

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

[Matt Huszagh]

Timothy  writes:

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

Thanks Timothy. However, I think this change may have some issues. It
seems that it unbalances parentheses. This also no longer sets width
(so, e.g., (floatp width) won't work). Maybe attr-width was intended to
be renamed to width? Are you seeing the same?

I've got an implementation for prioritizing #+attr_org, but I want to
make sure your commit goes in the right way before I submit that.

Matt

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

[Thomas S. Dye]

Aloha Matt,

Matt  writes:


Hi,

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.


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.


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?


Thanks,
Matt


Unfortunately, there is no ob-doc-shell.org at 
worg/org-contrib/babel/languages/.


There is an ob-doc-template.org in case you'd like to contribute 
ob-doc-shell.org :)


All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

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

[Thomas S. Dye]

Timothy  writes:


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


FYI, the long link in my patch was taken from 
worg/org-contrib/babel/index.org.  Whoever put it there (my git 
foo isn't up to finding out who) might have suspected your 
experience.


Thanks for your work on this.

All the best,
Tom

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

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] 

Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> Commit messages are also important, especially years later. I updated
> the commit message in the attached new version of the patch.

Note I'm not saying commit messages are not important. I just won't
spend energy on the wording there.

>> Thinking about it a bit more, you might be right: we may slightly change
>> the closing part of the emphasis regexp, e.g.:
>>
>>   (seq
>>(not space)
>>(group ,mark)
>>(or (any space ?- ?')
>>(and (any ?. ?, ?\; ?: ?! ?? ?\" ?\) ?\} ?\\ ?\[) (or space line-end))
>>line-end))
>>
>> The logic behind this is that in regular text, we assume usual
>> punctuation rules apply.
>
> This will fail for "*Bold*?!" or "/Italics/!!!"

Of course. Any regexp will fail somehow.

> Also, is there any reason why we are not simply using punctuation
> character class instead of listing punctuation chars explicitly (and
> only for English)? What about "_你叫什么名字_？"
>
> Maybe just
>
> (seq
>  (not space)
>  (group ,mark)
>  (0+ (in punctuation))
>  (or space line-end))

Historically, Org only focused on ASCII. But it makes sense to extend
the allowed punctuation characters, indeed.

This is orthogonal to OP's issue, however.

>> My concern is that the more complicated is the rule, the more difficult
>> it is to predict. Also, we introduce new corner case, e.g.,
>>
>>   Woot! I just released Org *10*.0!
>>
>> So, I'm not totally convinced it is worth the trouble.
>
> I am not sure if "Org *10*.0" is a good general example. It is probably
> one of those cases when users want fine control over emphasis and must
> use zero width space.

This is simply the first example that crossed my mind. My point is that
changing the regexp substantially may not be rewarding, ultimately.

> +Sometimes, when marked text also contains the marker character itself,
> +the result may be unsettling.  For example,
> +
> +#+begin_example
> +/One may expect this whole sentence to be italicized, but the
> +following ~user/?variable~ contains =/= character, which effectively
> +stops emphasis there./
> +#+end_example
> +
> +You can use zero width space to help Org sorting out the ambiguity.
> +See [[*Escape Character]] for more details.

LGTM!

Regards,
-- 
Nicolas Goaziou

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

[Matt]

Hi,

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.

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.

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?

Thanks,
Matt

0001-ob-shell-test.org-Add-example-for-stdin.patch
Description: Binary data


0002-test-ob-shell.el-Add-tests-for-stdin-and-cmdline-hea.patch
Description: Binary data

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

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

Re: Dodgy Worg publishing?

[Thomas S. Dye]

Aloha all,

Timothy  writes:


Hi Bastien,


You can check the output of Worg publishing process here:




Ah cool, thanks for pointing that out.

The latest build contains a line showing that 
library-of-babel.org

does not export:



  “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


Thanks for looking into this and identifying a problem.

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.


Also, is there a reason to keep 
worg/org-contrib/babel/library-of-babel.org in addition to 
worg/library-of-babel.org?


All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

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

[Matt Huszagh]

Timothy  writes:

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

Yeah, I think it's ok. To be perfectly honest, I still don't love it,
but I understand now that my disagreement was with a decision made a
while ago (from a quick look at the commit history, 2012 or before), not
with the one you made recently.

In my opinion the most logical solution would be for the width to fall
back on specifically attr_org, not just any attr_ when
`org-image-actual-width' is nil. To clarify further, my main
disagreement is with the idea that setting attr_html (for example)
implies that one wants the same setting in the org buffer. But, it seems
that ship sailed a while ago and now this would be a breaking change.

So, given that, I concede and I think attr_org: :width t is an
acceptable compromise. Thanks for coming up with that!

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

Ok, thanks for clarifying.

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

Yeah, I agree this is wrong. I'd misunderstood the current behavior.

Matt

Maintenance Request

[Daniel Fleischer]

Hi all,

I would like to maintain the 'ox-latex.el' file. It's one of the many
files created by Nicolas but few of the files that are not maintained
(by him). I have a long experience (14) with latex and relatively long
experience with org->latex.

Best,

-- 

Daniel Fleischer

Re: [BUG?] Cache: org-scan-tags behaves differently on inlinetasks with and without cache

[Ihor Radchenko]

Anders Johansson  writes:

> I had considered to implement some kind of cache in my code, but now I
> get this "for free"! I originally didn't use org-scan-tags but some
> custom and "simpler" code for scanning, but I am glad I refactored to
> use org-scan-tags, because now I get this speedup without a single
> code change in orgqda.

You can achieve even better speedup if you directly use
org-element-cache-map with :next-re/:fail-re parameters. If you are
matching against specific tags, those tags can be used to create a
regexp to locate match candidates very quickly.

Beware that org-element-cache-map does not work without
org-element-use-cache set to t (it is, by default).

Best,
Ihor

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: [BUG?] Cache: org-scan-tags behaves differently on inlinetasks with and without cache

[Anders Johansson]

> Thanks for reporting! You encountered a bug in org-get-tags. It ignored
> inlinetasks in some cases. Fixed in 7a14d6035.

Thank you!
It works very well now, and indeed the counting and collection of
tagged extracts (done with org-scan-tags) is much quicker now with
cache enabled. I tested with some generated files, and it looks like
with caching (assuming an updated cache) the time scales linearly with
the number of headlines/inlinetasks to match versus some power
function (n^1.6) with the old buffer-scanning.

I had considered to implement some kind of cache in my code, but now I
get this "for free"! I originally didn't use org-scan-tags but some
custom and "simpler" code for scanning, but I am glad I refactored to
use org-scan-tags, because now I get this speedup without a single
code change in orgqda.

Best,
Anders

Re: [PATCH] Fontification for inline src blocks

[Ihor Radchenko]

Timothy  writes:

>> I have some comments. See below.
>
> Thanks for going through this, and for all your help previously.
> I appreciate it :)

Welcome.

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

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

>>> +(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.

Makes sense. 

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

Best,
Ihor

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

[Max Nikulin]

On 22/11/2021 02:51, Matt Huszagh wrote:


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.


Then it is necessary make all backends aware of such attributes and 
length interpretation.


For a while attr_org may be tried at first with fallback to any other 
attr_ that has :width parameter.

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 
 lisp/org-src.el   | 44 
 lisp/org.el   |  9 +
 3 files changed, 57 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)))
  

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

[Tim Cross]

Ihor Radchenko  writes:

> Bastien  writes:
>
>> 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?
>>
>> Let me know if you think the text on Worg should be clarified.
>
> The text is mostly clear. However, there is a slight confusion about
> actual current Emacs version vs. planned Emacs version.
>
> Emacs 28 is have not been officially released yet. So, the "current
> major version of Emacs" is 27 and we are theoretically committed to
> Emacs 27, 26, and 25. Both on main and bugfix.
>
> On the other hand, we do know that Org 9.5 (bugfix) is going to be
> packaged together with Emacs 28 when it is out. Also, we do not yet know
> the time when Emacs 28 is going to be released (it can be even, say, a
> year from now). Will it happen before Org 9.6 (main)? Maybe. Maybe not.
> And some people are already using main branch. Should we target
> "current" Emacs 28 for main? Should we target Emacs version+1 as current
> on main all the time or maybe just when new Emacs release branch is
> created, but not yet released? It is not fully clear.
>

I agree it can be confusing. My interpretation -

As org 9.5 has been released and the latest Emacs version is still 27.2,
then org 9.5 needs to support 27.x, 26.x and 25.x.

Provided Org 9.6 is not released *before* Emacs 29, then it only needs
to support 29,.x, 28.x and 27.x. However, if org 9.6 is released before
Emacs 29, it has to support 28.x, 27.x and 26.x.

Of course, we could also interpret things differently. For example, we
could tie the support to the version of Emacs current at the time of
release. i.e. if we release org 9.6 before Emacs 29.1, then it would
have to support 28.x, 27.x and 26.x even if org 9.6 is what is released
in Emacs 29.

The difference in release schedules will mean this is always a little
challenging IMO.

Re: [PATCH] Fontification for inline src blocks

[Ihor Radchenko]

Timothy  writes:

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

I have some comments. See below.

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

> +(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. 

> +(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?

> +(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?

> +(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?

> +(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.

Best,
Ihor

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] Fix window width when line numbers present

[Ihor Radchenko]

Bastien  writes:

> 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?
>
> Let me know if you think the text on Worg should be clarified.

The text is mostly clear. However, there is a slight confusion about
actual current Emacs version vs. planned Emacs version.

Emacs 28 is have not been officially released yet. So, the "current
major version of Emacs" is 27 and we are theoretically committed to
Emacs 27, 26, and 25. Both on main and bugfix.

On the other hand, we do know that Org 9.5 (bugfix) is going to be
packaged together with Emacs 28 when it is out. Also, we do not yet know
the time when Emacs 28 is going to be released (it can be even, say, a
year from now). Will it happen before Org 9.6 (main)? Maybe. Maybe not.
And some people are already using main branch. Should we target
"current" Emacs 28 for main? Should we target Emacs version+1 as current
on main all the time or maybe just when new Emacs release branch is
created, but not yet released? It is not fully clear.

Best,
Ihor

Re: [BUG] org-element--cache: Cache corruption [9.5, (release_9.5-255-g54da1d @, c:/Users/micha/AppData/Roaming/.emacs.d/org-new/org-mode/lisp/)]

[Ihor Radchenko]

Michael Powe  writes:

> Error message:
>
> "Warning (emacs): org-element--cache: Cache corruption detected in 
> emacs-config-prog-modes.org. Resetting.
>   The error was: (error "rx ‘**’ range error")
>   Backtrace:
> nil
>   Please report this to Org mode mailing list""
>
> Done.

Thanks! After 17d4b31a8, you should hopefully not see this error. I am
not 100% sure though. Please, followup on this thread if you keep seeing
the same rx range error after update to latest main.

Best,
Ihor

Re: [BUG?] Cache: org-scan-tags behaves differently on inlinetasks with and without cache

[Ihor Radchenko]

Anders Johansson  writes:

> Without cache, inlinetasks are matched, but with cache they are not.
>
> A minimal test file:
>
> #+BEGIN_ORG
> * Test heading :testtag:
> Contents
>
> * Another heading
>
> *** An inlinetask :testtag:
> #+END_ORG

Thanks for reporting! You encountered a bug in org-get-tags. It ignored
inlinetasks in some cases. Fixed in 7a14d6035.

Best,
Ihor

Re: Supported Emacs version

[Bastien]

Hi Timothy,

Timothy  writes:

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

well, this is always a trade-off: we try to stick to a "users' first*"
principle, while managing the burden for maintainers.  If suddenly the
burden of keeping this code is too heavy for maintainers and does not
really benefit the users, we might revise this decision.

> Thanks for discussing this a bit :)

Thanks for bringing this up!

* https://bzg.fr/en/the-software-maintainers-pledge :)

-- 
 Bastien

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

[BUG?] Cache: org-scan-tags behaves differently on inlinetasks with and without cache

[Anders Johansson]

Hi,
I use inlinetasks with tags extensively in my library for coding
qualitative research data
(https://gitlab.com/andersjohansson/orgqda/).

With the new org-element caching functionality (which hopefully can
provide substantial speedups for my case, thanks Ihor!) I have
stumbled on a difference in how inlinetasks are handled by
org-scan-tags.

Without cache, inlinetasks are matched, but with cache they are not.

A minimal test file:

#+BEGIN_ORG
* Test heading :testtag:
Contents

* Another heading

*** An inlinetask :testtag:
#+END_ORG

Executing this code in this file
#+BEGIN_SRC emacs-lisp
(let ((org-element-use-cache nil))
  (org-scan-tags
   (lambda () (buffer-substring-no-properties (point-at-bol) (point-at-eol)))
   (cdr (org-make-tags-matcher "testtag"))
   nil))
#+END_SRC

Yields: ("* Test heading :testtag:" "*** An inlinetask :testtag:")

That is, both the headline and inlinetask were matched

However:
#+BEGIN_SRC
(let ((org-element-use-cache t))
  (org-scan-tags
   (lambda () (buffer-substring-no-properties (point-at-bol) (point-at-eol)))
   (cdr (org-make-tags-matcher "testtag"))
   nil))
#+END_SRC

Yields: ("* Test heading :testtag:")
Only the headline was matched.

The difference is in org-scan-tags, where the code using cache always
retrieves tags for matching with org-get-tags, whereas the code
without cache takes tags from group 4 of the scanning regexp ("re").
It appears that org-get-tags doesn't fetch tags for inlinetasks, is
this really right? Otherwise, the small patch below gets me the right
behaviour (tags returned also for inlinetasks) for these tests.

Best,
Anders Johansson

---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 17b7ff597..98ff5dba7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11808,7 +11808,7 @@ (defun org-get-tags ( pos-or-element
local fontify)
  (org-before-first-heading-p))
   (unless (org-element-type pos-or-element) (org-back-to-heading t))
   (let ((ltags (if (org-element-type pos-or-element)
-   (org-element-property :tags
(org-element-lineage pos-or-element '(headline) t))
+   (org-element-property :tags
(org-element-lineage pos-or-element '(headline inlinetask) t))
  (org--get-local-tags fontify)))
 itags)
 (if (or local (not org-use-tag-inheritance)) ltags
--
2.34.0

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