Max Nikulin writes:
>>> I think, it is better to avoid "is ignored" here.
>>
>> May you convert your suggestion into a patch?
>
> See the attachment.
> From 7bc9d909867bf2f99a77d5d1554cd41e4fc664ae Mon Sep 17 00:00:00 2001
> From: Max Nikulin
> Date: Thu, 9 May 2024 17:32:54 +0700
> Subject:
Max Nikulin writes:
> I ma afraid, the code is a bit fragile. Consider
>
> #+attr_html: :alt Image width test
> #+attr_beamer: :width \linewidth
> #+attr_latex: :width +.5\textwidth
> #+attr_md: :width 75%
> [[file:babelfish.png]]
>
> - It is really confusing that #+attr_html casts shadow on
On 08/05/2024 17:54, Ihor Radchenko wrote:
Max Nikulin writes:
#+attr_html: :alt Image width test
#+attr_beamer: :width \linewidth
#+attr_latex: :width +.5\textwidth
#+attr_md: :width 75%
[[file:babelfish.png]]
- I do not mind that just "\linewidth" is ignored.
- The case of "+.5" should
Max Nikulin writes:
>> 1. #+attr_org is prioritised
>
> I ma afraid, the code is a bit fragile. Consider
>
> #+attr_html: :alt Image width test
> #+attr_beamer: :width \linewidth
> #+attr_latex: :width +.5\textwidth
> #+attr_md: :width 75%
> [[file:babelfish.png]]
>
> - I do not mind that just
On 02/05/2024 23:28, Ihor Radchenko wrote:
1. #+attr_org is prioritised
I ma afraid, the code is a bit fragile. Consider
#+attr_html: :alt Image width test
#+attr_beamer: :width \linewidth
#+attr_latex: :width +.5\textwidth
#+attr_md: :width 75%
[[file:babelfish.png]]
- I do not mind that
> 1. #+attr_org is prioritised
> 2. Docstrings are updated
>
> Handled, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fede1c990
Just a note that we already prioritize #+attr_org when
aligning/centering images. So this change makes sense.
Karthik
Matt Huszagh writes:
>> Thanks for continuing with this. Moving forward, I think it would be best to:
>> ⁃ Make a patch just for prioritising `#+attr_org'
>> ⁃ Make a patch just improving the regex (before or after the `#+attr_org'
>> patch)
> ...
>> Lastly, a comment on your documentation
Timothy writes:
> Thanks for your thoughtful deliberation on this.
No worries, and thanks for continuing to engage with it.
>> The other consideration is if we take the first point as a given (that
>> org should use width directives for other backends), should it also
>> attempt to interpret
Hi Matt,
Thanks for your thoughtful deliberation on this.
> I think the essential disagreement is whether org should take an action if not
> explicitly told to do so. I think org should only perform some action if given
> a clear directive. In this context, I feel that org is guessing what the
Timothy writes:
> What would be a more sensible interpretation in your mind? The “true” value
> depends on the number of columns, and fetching that information seems a bit
> unreasonable. Since this isn’t just used if nothing else if given, I see a
> 120%
> interpretation as fairly reasonable.
On 29/11/2021 07:23, Matt Huszagh wrote:
Max Nikulin writes:
My current variant:
":\\(?:[^\n]*?[[:blank:]]\\)?:width[[:blank:]]+\\(\\S-+\\)"
The regexp should not match e.g.
#+attr_html: :alt something
:width 600
P.S. I would prefer to use the same parser as ox does.
I can probably
Hi Matt,
> I also still don’t really like the behavior
> here. I don’t think it makes sense to interpret a width as 120% if we
> have something like
>
> #+attr_latex: :width 1.2
What would be a more sensible interpretation in your mind? The “true” value
depends on the number of columns, and
Max Nikulin writes:
> I am confused. I can not figure out how to create the following as HTML
> export result:
>
>
>
> Attempt to add quotes leads to and does not prevent ":width" to
> become another attribute.
>
>#+attr_html: :alt An image without :width 600 attribute
>
On 25/11/2021 00:00, Max Nikulin wrote:
On 24/11/2021 22:59, Matt Huszagh wrote:
I am sorry that I confused you by my note concerning space before
:width. I am afraid, current variant means repeated ":"
+ (concat "^[ \t]*#\\+attr_"
+ backend
On 24/11/2021 22:59, Matt Huszagh wrote:
Better?
Certainly. I have not tested the patch though.
I am sorry that I confused you by my note concerning space before
:width. I am afraid, current variant means repeated ":"
+ (concat "^[ \t]*#\\+attr_"
+
Max Nikulin 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 ".*".
>
>> +
On 24/11/2021 08:57, Matt Huszagh wrote:
Max Nikulin writes:
I may be wrong, but it seems both the old and the new regexps match
#+attr_html : :width 50%
that is not a keyword due to a space before ":". The dot in the regexp
is too permissive.
I agree.
Despite ".*" includes ": "
Max Nikulin writes:
> I may be wrong, but it seems both the old and the new regexps match
>
> #+attr_html : :width 50%
>
> that is not a keyword due to a space before ":". The dot in the regexp
> is too permissive.
I agree.
> Despite ".*" includes ": " before ":width", I would prefer
On 23/11/2021 14:46, Matt Huszagh wrote:
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.
diff --git a/lisp/org.el b/lisp/org.el
index 308bb7d51..bf5d08e09 100644
--- a/lisp/org.el
+++
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
Hi Matt,
(sigh) well that’s silly. Thanks, I’ve just pushed that.
All the best,
Timothy
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:
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
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
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.
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
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
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
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
Timothy writes:
> Once again, thank you for the patch. The fact that the current regexp matches
> `#+attr_latex' and `#+attr_html' is in fact by design though*. This is
> because I
> consider it safe to assume that a `#+attr_*' which gives non-integer width
> between
> 0 and 2 can be safely
Hi Matt,
> A recent patch started computing the inline image width from any attr_
> line. This is incorrect, as it matches settings like attr_latex, or
> attr_html. We only want to look for settings specifically for the org
> buffer. This patch fixes that.
Once again, thank you for the patch.
Hi,
A recent patch started computing the inline image width from any attr_
line. This is incorrect, as it matches settings like attr_latex, or
attr_html. We only want to look for settings specifically for the org
buffer. This patch fixes that.
Thanks
Matt
>From
32 matches
Mail list logo
