Re: [BUG] ox-md image captions

[Vladimir Alexiev]

I posted a Pandoc request: https://github.com/jgm/pandoc/issues/8752

On Wed, Apr 5, 2023 at 2:04 PM Ihor Radchenko  wrote:

> Morgan Willcock  writes:
>
> > If ox-md is trying to do the same thing as Markdown.pl then it doesn't
> > really make sense to compare it to CommonMark.
>
> Most likely, ox-md is following Markdown.pl simply because there was no
> better standard at the time ox-md was written.
>
> I now looked up a comparison between markdown flavours (see the attached)
> and I do not see why we should abandon following the original markdown.
> CommonMark and other markdown flavours usually extend things on top of
> the original implementation. So, following Markdown.pl should be the
> most universal option. We leave more specific exporters for advanced
> markdown flavours to external packages.
>
> > The only point am I trying to make is that both ox-md and Pandoc need to
> > deal in the same unambiguous specification in order to inter-operate.
> >
> > For Pandoc, the matching specification needs to be selected to ensure
> > that the correct one is used, but nothing based on Markdown.pl can be
> > unambiguous in this scenario because Markdown.pl has no unambiguous
> > specification.
>
> Indeed.
> I tried to make this point more clear in the attached patch for Org manual.
>
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [BUG] ox-md image captions

[Ihor Radchenko]

Max Nikulin  writes:

> My expectation is that Markdown
>
>  ![Alt text](/path/to/img.jpg "Optional title")
>
> is exported to HTML
>
>  
>
> If it is so then caption should not be exported as title and it is not 
> related to markdown extensions. Org caption should appear as text, it 
> should not require to hover image to see it as tooltip.

That will certainly be a breaking change to export #+caption and
ordinary text in markdown.
I do not feel that it is justified.

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

Re: [BUG] ox-md image captions

[Max Nikulin]

On 05/04/2023 20:05, Ihor Radchenko wrote:

MD has nothing to do with how Pandoc's "implicit_figures" extension
modifies MD->HTML export. The original MD spec only talks about image
description and image title being exported to "alt" and "title" HTML
attributes.


My expectation is that Markdown

![Alt text](/path/to/img.jpg "Optional title")

is exported to HTML



If it is so then caption should not be exported as title and it is not 
related to markdown extensions. Org caption should appear as text, it 
should not require to hover image to see it as tooltip.

Re: [PATCH] ANSI color on example blocks and fixed width elements

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> Attached is the patch.  Without this patch, ANSI escape sequences
> generated by the output of a source block will be left in the buffer
> without any fontification.  With this patch, the escaped text is nicely
> colored and escape sequences hidden using overlays.
>
> It works for Emacs versions which have the `PRESERVE-SEQUENCES` argument
> to the `ansi-color-apply-on-region` function.  It's a bit slow due to
> the use of overlays.  My implementation of this feature in Emacs-Jupyter
> supports older versions of Emacs without that argument, it relies on a
> custom version of that function though and uses text properties instead
> of overlays.
>
> Let me know what else could be done on my end to get this patch in.
> Thanks.

Thanks for the patch!

This is an interesting idea, but I am not sure if we want to use this
colouring by default. At least, it should be a minor mode. Probably
enabled by default. Because not every possible user may want to have the
escape sequences hidden away.

Further, your patch only allows fontifying ANSI sequences in fixed-width
elements, example blocks, export blocks, and src blocks without known
major mode that does the fontification. I doubt that fontifying ANSI
sequences in this specific subset of elements always makes sense -
example blocks are not always used as src block output; bash code blocks
may purposely contain escape sequences, but your patch will not handle
them; inline src block output is not covered at all.

Ideally, fontifying ANSI sequences should be fully controlled by users:
1. We may not want to touch src blocks by default, when
   `org-src-fontify-natively' is set to t. Only, maybe, provide an
   option. Or you may better publish a minor mode that does this for
   shell scripts.
2. We may allow all the ANSI sequences to be fontified in the whole
   buffer.
3. We may limit ANSI sequence fontification to results and only results.
   Or just certain types of results.

The easiest will be implementing fontification in the whole buffer,
early during fontification (and early in org-font-lock-keywords; see
org-font-lock-set-keywords-hook).

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

Re: [BUG] ox-md image captions

[Ihor Radchenko]

Max Nikulin  writes:

>> Upon further investigation, I have found that our base MD reference we
>> follow in ox-md is defining image syntax as the following:
>> 
>> ![Alt text](/path/to/img.jpg)
>> 
>> ![Alt text](/path/to/img.jpg "Optional title")
>> 
>> https://daringfireball.net/projects/markdown/syntax#img
>> 
>> Therefore, Org mode is doing everything right within the scope of MD
>> specification we follow. Pandoc does not.
>
> My reading of 
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#the_title_attribute
>  
> is that caption should not be exported as title. Alt text is more 
> "visible" than title, but perhaps caption should be exported as text 
> adjacent to image.

I will provide the linked text at the end of the message for future
reference.

For HTML, I agree that caption should ideally be exported as text adjacent
to image. That's what we actually do in `org-html--wrap-image'.

However, we are talking about MD export.

MD has nothing to do with how Pandoc's "implicit_figures" extension
modifies MD->HTML export. The original MD spec only talks about image
description and image title being exported to "alt" and "title" HTML
attributes.

Currently, Org's image link description will be exported to MD's image
link description and Org's image caption will be exported to MD's image
title. Doing otherwise by default is not entirely consistent.

Of course, the current default will also ignore #+caption altogether
unless the image link has no description. So, we may, in theory, play
around with the default.

On the other hand, by keeping the current default we also keep the
option to combine description and caption if we ever consider altering
our inline image rules during export (`org-export-inline-image-p').

I am still inclined towards keeping the current default, as not every
possible MD export user is doing it to consequently convert the MD to
HTML using Pandoc also having the "implicit_figures" Pandoc's extension
enabled.

We may provide a toggle for this, however. If someone is bothered enough
and sends a patch. Maybe #+ATTR_MD: also option.



https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#the_title_attribute

The title attribute is not an acceptable substitute for the alt
attribute. Additionally, avoid duplicating the alt attribute's value
in a title attribute declared on the same image. Doing so may cause
some screen readers to announce the description twice, creating a
confusing experience.

The title attribute should also not be used as supplemental
captioning information to accompany an image's alt description. If
an image needs a caption, use the figure and figcaption elements.

The value of the title attribute is usually presented to the user as
a tooltip, which appears shortly after the cursor stops moving over
the image. While this can provide additional information to the
user, you should not assume that the user will ever see it: the user
may only have keyboard or touchscreen. If you have information
that's particularly important or valuable for the user, present it
inline using one of the methods mentioned above instead of using
title.

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

Re: [RFC] Limit inline image width by default (was: feature request: easy embedding of images)

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> See the tentative patch.

This looks fantastic!  +1 for using the Fill Column by default.

Rudy
-- 
"The introduction of suitable abstractions is our only mental aid to
organize and master complexity."
-- Edsger Wybe Dijkstra, 1930-2002

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

[PATCH] ANSI color on example blocks and fixed width elements

[Nathaniel Nicandro]

Hello,

Attached is the patch.  Without this patch, ANSI escape sequences
generated by the output of a source block will be left in the buffer
without any fontification.  With this patch, the escaped text is nicely
colored and escape sequences hidden using overlays.

It works for Emacs versions which have the `PRESERVE-SEQUENCES` argument
to the `ansi-color-apply-on-region` function.  It's a bit slow due to
the use of overlays.  My implementation of this feature in Emacs-Jupyter
supports older versions of Emacs without that argument, it relies on a
custom version of that function though and uses text properties instead
of overlays.

Let me know what else could be done on my end to get this patch in.
Thanks.

diff --git a/lisp/org.el b/lisp/org.el
index 4d12084..24617ad 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -81,6 +81,7 @@ (eval-when-compile (require 'gnus-sum))
 (require 'calendar)
 (require 'find-func)
 (require 'format-spec)
+(require 'ansi-color)
 
 (condition-case nil
 (load (concat (file-name-directory load-file-name)
@@ -5326,6 +5327,10 @@ (defsubst org-activate-links (limit)
 (defun org-activate-code (limit)
   (when (re-search-forward "^[ \t]*\\(:\\(?: .*\\|$\\)\n?\\)" limit t)
 (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
+(let ((ansi-color-apply-face-function
+   (lambda (beg end face)
+ (font-lock-prepend-text-property beg end 'face face
+  (ansi-color-apply-on-region (match-beginning 0) (match-end 0) t))
 (remove-text-properties (match-beginning 0) (match-end 0)
 			'(display t invisible t intangible t))
 t))
@@ -5421,7 +5426,12 @@ (defun org-fontify-meta-lines-and-blocks-1 (limit)
 			   (let ((face-name
   (intern (format "org-block-%s" lang
 			 (append (and (facep face-name) (list face-name))
- '(org-block)))
+ '(org-block))
+  (let ((ansi-color-apply-face-function
+ (lambda (beg end face)
+   (font-lock-prepend-text-property beg end 'face face
+(ansi-color-apply-on-region
+ bol-after-beginline beg-of-endline t)))
 	 ((not org-fontify-quote-and-verse-blocks))
 	 ((string= block-type "quote")
 	  (add-face-text-property


-- 
Nathaniel

Re: [BUG] ox-md image captions

[Max Nikulin]

On 04/04/2023 15:48, Ihor Radchenko wrote:

Ihor Radchenko writes:


I am inclined to change ![img](url "caption") to
![caption](url) for links without description (links with description do
not obey caption in org export).


Upon further investigation, I have found that our base MD reference we
follow in ox-md is defining image syntax as the following:

![Alt text](/path/to/img.jpg)

![Alt text](/path/to/img.jpg "Optional title")

https://daringfireball.net/projects/markdown/syntax#img

Therefore, Org mode is doing everything right within the scope of MD
specification we follow. Pandoc does not.


My reading of 
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#the_title_attribute 
is that caption should not be exported as title. Alt text is more 
"visible" than title, but perhaps caption should be exported as text 
adjacent to image.

Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el

[Max Nikulin]

Ihor, I am sorry, but I sent this message off-list at first.

On 04/04/2023 20:29, Ihor Radchenko wrote:


Sure. Anything Emacs devs can act on. If you can prove that the problem
is in Emacs source code, we can report it in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882 and let Emacs devs
fix things.


I do not expect any result that may be useful for Emacs dev. I hope, the 
code added to emacs-29 branch fixes the issue. Outcome may be helpful 
for choosing better variant of `org-assert-version' and for demystifying 
causes why you can not reproduce it in gentoo.



This looks like
https://orgmode.org/list/jwvsfkv5s7l.fsf-monnier+em...@gnu.org


I have not looked into make rules used in Emacs source tree, but I 
expect it is another issue. I do not like that elisp can not generate 
list of dependencies during compilation similar to "gcc -MD". Otherwise 
I do not see a way to implement incremental rebuild if stale .elc files 
are preferred to updated .el sources by `require'.



But Emacs >26 + package-install specifically arranges unloading the
older version of the library.


What changes are you writing about? I mean 
`package--reload-previously-loaded' 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882#71


9dfd945a2c2 2021-11-07 01:28:47 +0100 dickmao: Fix byte compilation of 
package built-ins


and I do not see similar changes even in Emacs-28.

Re: [BUG] ox-md image captions

[Ihor Radchenko]

Morgan Willcock  writes:

> If ox-md is trying to do the same thing as Markdown.pl then it doesn't
> really make sense to compare it to CommonMark.

Most likely, ox-md is following Markdown.pl simply because there was no
better standard at the time ox-md was written.

I now looked up a comparison between markdown flavours (see the attached)
and I do not see why we should abandon following the original markdown.
CommonMark and other markdown flavours usually extend things on top of
the original implementation. So, following Markdown.pl should be the
most universal option. We leave more specific exporters for advanced
markdown flavours to external packages.

> The only point am I trying to make is that both ox-md and Pandoc need to
> deal in the same unambiguous specification in order to inter-operate.
>
> For Pandoc, the matching specification needs to be selected to ensure
> that the correct one is used, but nothing based on Markdown.pl can be
> unambiguous in this scenario because Markdown.pl has no unambiguous
> specification.

Indeed.
I tried to make this point more clear in the attached patch for Org manual.



markdown_comparison.pdf
Description: Adobe PDF document
>From 17eaaa6d4cdd9964b6f7d4f96c8020a8a8eb07ec Mon Sep 17 00:00:00 2001
Message-Id: <17eaaa6d4cdd9964b6f7d4f96c8020a8a8eb07ec.1680692739.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 5 Apr 2023 13:04:44 +0200
Subject: [PATCH] org-manual.org: Clarify the ox-md uses the original markdown
 spec

* doc/org-manual.org (Markdown Export): Make it more clear that we are
using the original Markdown spec.  Link to Wikipedia article
describing different Markdown favours.
---
 doc/org-manual.org | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 80a259184..9736bb3b7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14313,10 +14313,16 @@ ** Markdown Export
 
 The Markdown export back-end, "md", converts an Org file to Markdown
 format, as defined at https://daringfireball.net/projects/markdown/.
+This is the original Markdown specification, developed by John Gruber
+and Aaron Swartz.
 
-Since it is built on top of the HTML back-end (see [[*HTML Export]]), it
-converts every Org construct not defined in Markdown syntax, such as
-tables, to HTML.
+Since "md" back-end is built on top of the HTML back-end (see [[*HTML
+Export]]), it converts every Org construct not defined in Markdown
+syntax, such as tables, to HTML.
+
+Do note that the original markdown syntax has differences with other
+commonly used Markdown flavors.  See
+https://en.wikipedia.org/wiki/Markdown for more details.
 
 *** Markdown export commands
 :PROPERTIES:
-- 
2.40.0


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

Re: [BUG] ox-md image captions

[Morgan Willcock]

Ihor Radchenko  writes:

> Please provide concrete examples where ox-md does not follow
> specification.
>
> The title/caption issue herein does not qualify.
> https://spec.commonmark.org/0.30/#images also defines
> ![foo](/url "title") with "title" being the title, as we currently use
> it in ox-md when exporting captions.

If ox-md is trying to do the same thing as Markdown.pl then it doesn't
really make sense to compare it to CommonMark.

The only point am I trying to make is that both ox-md and Pandoc need to
deal in the same unambiguous specification in order to inter-operate.

For Pandoc, the matching specification needs to be selected to ensure
that the correct one is used, but nothing based on Markdown.pl can be
unambiguous in this scenario because Markdown.pl has no unambiguous
specification.

-- 
Morgan Willcock

Re: [BUG] ox-md image captions

[Ihor Radchenko]

Morgan Willcock  writes:

>> https://daringfireball.net/projects/markdown/syntax#img
>>
>> Therefore, Org mode is doing everything right within the scope of MD
>> specification we follow. Pandoc does not.
>
> I don't think that Markdown has a single specification.

Indeed. And the one in daringfireball is what we historically follow
since >10 years ago, when ox-md has been implemented.

> Perhaps it is a bug that ox-md is not following a specification, and
> this would be fixed by using a specification and passing its test suite:

Please provide concrete examples where ox-md does not follow
specification.

The title/caption issue herein does not qualify.
https://spec.commonmark.org/0.30/#images also defines
![foo](/url "title") with "title" being the title, as we currently use
it in ox-md when exporting captions.

> https://commonmark.org/

I agree that using CommonMark.org as the source of truth will make more
sense, given that the original daringfireball.net is not precise.

It would be helpful if someone examines whether ox-md is consistent with
CommonMark.

> However, if ox-md is intentionally trying to match the behaviour of the
> original Markdown.pl, the Pandoc format that matches this is
> "markdown_strict" and not "markdown".
>
> i.e. Pandoc's "markdown" format is not the same format which is
> described at daringfireball.net:
>
> https://pandoc.org/MANUAL.html#pandocs-markdown

Indeed. ox-md is certainly not aiming to export to Pandoc's markdown
flavour.

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

Re: [BUG] ox-md image captions

[Morgan Willcock]

Ihor Radchenko  writes:

> Upon further investigation, I have found that our base MD reference we
> follow in ox-md is defining image syntax as the following:
>
> ![Alt text](/path/to/img.jpg)
>
> ![Alt text](/path/to/img.jpg "Optional title")
>
> https://daringfireball.net/projects/markdown/syntax#img
>
> Therefore, Org mode is doing everything right within the scope of MD
> specification we follow. Pandoc does not.

I don't think that Markdown has a single specification.

Perhaps it is a bug that ox-md is not following a specification, and
this would be fixed by using a specification and passing its test suite:

https://commonmark.org/

However, if ox-md is intentionally trying to match the behaviour of the
original Markdown.pl, the Pandoc format that matches this is
"markdown_strict" and not "markdown".

i.e. Pandoc's "markdown" format is not the same format which is
described at daringfireball.net:

https://pandoc.org/MANUAL.html#pandocs-markdown

-- 
Morgan Willcock

Re: [patch] give tables their own default placement in LaTeX export

[Ihor Radchenko]

Ihor Radchenko  writes:

> Eric S Fraga  writes:
>
>> attached is a small patch to give tables their own default placement in
>> LaTeX export.  Up to now, tables have used the default placement for
>> figures but figures and tables are very different creatures so it does
>> not make sense to have just one default for both.

Canceled.

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

Re: [PATCH] ox.el: Refactor variable org-html--id-attr-prefix, ox-html.el: Add support for the ID property to org-html--reference

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> Thanks for the patch!
>> See my comments below.
>
> Feraidoon, have you had a chance to look into my comments?

Applied, with amendments, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5e9953fa0

You are now listed as an Org contributor.
https://git.sr.ht/~bzg/worg/commit/fb807476

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

Re: [ISSUE] The Emacs display Org mode "scaled" inline images are blurred

[Ihor Radchenko]

stardiviner  writes:

> Here is the screenshot:
>
> [image: Screenshot 2023-04-05 at 15.02.08.png]
>
> It is caused by option `org-image-actual-width`. I set it to bellowing
> value:
> ```elisp
> (setq org-image-actual-width '(600 800 1000))
> ```
> When I set the option `org-image-actual-width` to `nil` the inline image is
> display in original size as bellowing screenshot:
> ...
> brew install emacs-plus@30 --with-imagemagick --with-json --with-dbus

Your Emacs is built with Imagemagick support. Thus, Org (and Emacs in
general) is using Imagemagick to scale images. Please check your
imagemagick settings. You can also try setting `imagemagick-types-inhibit'.

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