From: Matt Huszagh <huszaghmatt@gmail.com>
To: Max Nikulin <manikulin@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [PATCH] Fix regex for determining image width from attribute
Date: Wed, 24 Nov 2021 07:59:20 -0800 [thread overview]
Message-ID: <87ee75pmsn.fsf@gmail.com> (raw)
In-Reply-To: <snljcb$1aa$1@ciao.gmane.io>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
Max Nikulin <manikulin@gmail.com> writes:
> This is related solely to docscring.
>
>> +that is not found, use the first #+ATTR_.*:width specification.
>
> I am unsure how to make this phrase more clear, maybe something like
> "use :width value from the first #+ATTR_,*" or even "#+ATTR_xxx" to
> avoid ".*".
>
>> + (re-search-forward (funcall attr-re "[a-z]*?")
>> + par-end t))))
>
> https://orgmode.org/worg/dev/org-syntax.html#Keywords
> has no requirement that it may be letter only. I expect it to be more
> coherent with
> http://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/org-element.el#n2387
> that uses "\\S-" non-space character.
Better?
Matt
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: attr_org.patch --]
[-- Type: text/x-patch, Size: 5140 bytes --]
From 73f6d6d0c16d9b3312737463361cefe08b01d35c Mon Sep 17 00:00:00 2001
From: Matt Huszagh <huszaghmatt@gmail.com>
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..3718d3118 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 "\\S-+?")
+ par-end t))))
(match-string 1)))
(width
(cond
--
2.31.1
From 76e92428716f2dcde0fbd281f71739c44a9be9d3 Mon Sep 17 00:00:00 2001
From: Matt Huszagh <huszaghmatt@gmail.com>
Date: Mon, 22 Nov 2021 23:30:11 -0800
Subject: [PATCH 2/2] 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 3718d3118..b050cb0dd 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_xxx :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 `org-image-actual-width' is nil or a list, the first :width attribute
- set (if it exists) is used to set the image width. A width of X% is
- divided by 100.
- If no :width attribute is given and `org-image-actual-width' is a list with
- a number as the car, then that number is used as the default value.
- If the value is a float between 0 and 2, it interpreted as that proportion
- of the text width in the buffer."
- ;; Apply `org-image-actual-width' specifications.
+See `org-image-actual-width' for how the image width is computed."
(cond
((eq org-image-actual-width t) nil)
((listp org-image-actual-width)
--
2.31.1
next prev parent reply other threads:[~2021-11-24 16:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-21 19:08 [PATCH] Fix regex for determining image width from attribute Matt Huszagh
2021-11-21 19:20 ` Timothy
2021-11-21 19:51 ` Matt Huszagh
2021-11-22 8:29 ` Timothy
2021-11-22 16:11 ` Matt Huszagh
2021-11-22 17:54 ` Timothy
2021-11-22 20:53 ` Matt Huszagh
2021-11-23 4:59 ` Kyle Meyer
2021-11-23 5:14 ` Timothy
2021-11-23 5:38 ` Matt Huszagh
2021-11-23 5:39 ` Timothy
2021-11-23 7:46 ` Matt Huszagh
2021-11-23 16:44 ` Max Nikulin
2021-11-24 1:57 ` Matt Huszagh
2021-11-24 14:48 ` Max Nikulin
2021-11-24 15:59 ` Matt Huszagh [this message]
2021-11-24 17:00 ` Max Nikulin
2021-11-25 16:43 ` Max Nikulin
2021-11-29 0:23 ` Matt Huszagh
2021-11-29 5:13 ` Timothy
2021-12-01 3:24 ` Matt Huszagh
2021-12-01 4:54 ` Timothy
2021-12-03 2:06 ` Matt Huszagh
2024-05-02 16:28 ` Ihor Radchenko
2024-05-07 4:59 ` Karthik Chikmagalur
2024-05-08 10:36 ` Max Nikulin
2024-05-08 10:54 ` Ihor Radchenko
2024-05-09 10:47 ` Max Nikulin
2024-05-13 12:42 ` Ihor Radchenko
2024-05-13 12:42 ` Ihor Radchenko
2021-11-29 12:15 ` Max Nikulin
2021-11-22 14:30 ` Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ee75pmsn.fsf@gmail.com \
--to=huszaghmatt@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).