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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

(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

Re: Invalid read syntax errors compiling orgmode from git repository

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

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

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

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

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

Re: Invalid read syntax errors compiling orgmode from git repository

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

Re: Invalid read syntax errors compiling orgmode from git repository

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

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

> 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

Invalid read syntax errors compiling orgmode from git repository

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,

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

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.

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

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

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

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

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

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

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

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

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

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

Re: [QUESTION] How to specific image size attributes under headline scope?

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

"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

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?

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:

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

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

Maintenance Request

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

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

Re: [PATCH] Fontification for inline src blocks

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

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

> 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

Re: [PATCH] Fontification for inline src blocks

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

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

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

Re: [PATCH] Fontification for inline src blocks

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

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

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

Re: [PATCH] Fontification for inline src blocks

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

Re: [PATCH] Fontification for inline src blocks

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

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

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

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/)]

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

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

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

Re: Supported Emacs version

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.

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

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

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

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

Re: Supported Emacs version

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