From: Matt Huszagh <email@example.com> To: Timothy <firstname.lastname@example.org> Cc: , email@example.com Subject: Re: [PATCH] Fix regex for determining image width from attribute Date: Mon, 22 Nov 2021 23:46:07 -0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 533 bytes --] 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 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 1st patch --] [-- Type: text/x-patch, Size: 1870 bytes --] From 22bbe7d651e1f27398597297c7c35ae4f3253773 Mon Sep 17 00:00:00 2001 From: Matt Huszagh <firstname.lastname@example.org> 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 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: 2nd patch --] [-- Type: text/x-patch, Size: 3260 bytes --] From aff581922e8d8bf10f813cdb9bc8adf9c8632683 Mon Sep 17 00:00:00 2001 From: Matt Huszagh <email@example.com> 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 `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-23 7:46 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-21 19:08 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 [this message] 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 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 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] Fix regex for determining image width from attribute' \ /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
Code repositories for project(s) associated with this 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).