latex preview parallel processes

2019-11-03 Thread Matt Huszagh
Hello. I have an org document with many latex snippets for which I use the org latex preview facility. As the document has gotten bigger, any changes requiring a rebuild of all images (e.g. changing `org-format-latex-header') takes longer and longer to the point where it now takes me over an hour

Re: Removing horizontal space in latex fragments

2019-12-14 Thread Matt Huszagh
t; > is slightly less low-level. Appreciate the nitpick; your version is better! I've attached an updated patch. Best, Matt >From bdb93a13a43d90ad6e66449797111e836a67a219 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Thu, 5 Dec 2019 23:25:32 -0800 Subject: [PATCH] org.el: Remove l

Re: Issues with nested begin..end blocks in inline math environments

2019-12-14 Thread Matt Huszagh
I'm submitting this as a patch. I've used it on hundreds of latex fragments over the past week or so and haven't experienced any issues (which is expected since the change is small). >From a699b699ed4132839c39f1152868bb13364422c7 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sat, 14

Re: Issues with nested begin..end blocks in inline math environments

2019-12-07 Thread Matt Huszagh
"Fraga, Eric" writes: > The identification of LaTeX fragments is somewhat fragile (in my > experience). I would suggest you enclose complex LaTeX code fragments > within an #+begin_export latex ... #+end_export environment. > > Assuming your export target is LaTeX and/or PDF. Thanks for the

Removing horizontal space in latex fragments

2019-12-05 Thread Matt Huszagh
I've modified the behavior of `org-create-formula-image' so that `\definecolor' etc do not create unnecessary whitespace in the output PDF. Here's the relevant change: ``` ... ;; remove tex \par at end of line (if (string= (substring string -1 nil) "\n") (aset string

Re: Removing horizontal space in latex fragments

2019-12-06 Thread Matt Huszagh
is preferable. On Thu, Dec 5, 2019 at 2:24 PM Fraga, Eric wrote: > On Thursday, 5 Dec 2019 at 11:03, Matt Huszagh wrote: > > Is anyone else interested in this modification? Should I submit it as a > > patch? > > I think so. And I am not sure all those \n's are necessary. Wi

Issues with nested begin..end blocks in inline math environments

2019-12-06 Thread Matt Huszagh
I'm experiencing incorrect and seemingly inconsistent behavior when nesting `\begin` `\end` environments inside `\(\)` or `$$`. For example, the following is valid latex code: ``` \(\begin{aligned} b_n &= \frac{1}{\pi} \int_{0}^{\pi} x \sin{\left(nx\right)}dx \\ b_0 &= 0 \\ \int_{0}^{\pi} udv &=

Re: Issues with nested begin..end blocks in inline math environments

2019-12-07 Thread Matt Huszagh
"Fraga, Eric" writes: > The identification of LaTeX fragments is somewhat fragile (in my > experience). I would suggest you enclose complex LaTeX code fragments > within an #+begin_export latex ... #+end_export environment. > > Assuming your export target is LaTeX and/or PDF. Changing the

Re: Issues with nested begin..end blocks in inline math environments

2019-12-16 Thread Matt Huszagh
Nicolas Goaziou writes: > I don't think this patch is a good idea, as it mixes elements from > different types: LaTeX fragment (inline), and LaTeX environment (block). > For example, the regexp you modify is used as a paragraph separator, > which doesn't make sense for inline LaTeX. No worries.

preview src blocks that generate image files

2020-01-26 Thread Matt Huszagh
Hi, I'm considering adding the ability to display an image preview overlay of source blocks that generate an image file, much in the same way that latex fragments can be previewed. Is anyone else interested in this feature? Any general thoughts/feature requests? Matt

Re: latex fragments in html export

2020-02-05 Thread Matt Huszagh
Nvm, I found the issue.

latex fragments in html export

2020-02-05 Thread Matt Huszagh
Hello, Has anyone had success getting the html export to process latex fragments? It's leaving mine completely alone and I can't figure out why. Latex babel source blocks work fine. I've set (setq org-html-with-latex luasvgm) luasvgm is a process-alist element I defined. I went through ox-html

Re: babel latex headers and image generation commands

2020-02-04 Thread Matt Huszagh
Ok, here's an implementation that seems to be working pretty well so far. `org-latex-img-process` is the new customization. Most of the execute function is unaltered, but I've added the condition: ``` ((and (not imagemagick) (assoc extension org-latex-img-process))

Re: babel latex headers and image generation commands

2020-02-04 Thread Matt Huszagh
I've thought about this more and the solution I presented above isn't quite sufficient for me. I need something where I get complete control over what goes in the latex source block on a block-by-block basis. In other words, I don't want a user-configurable option like org-format-latex-header plus

babel latex headers and image generation commands

2020-02-03 Thread Matt Huszagh
I spent some time today trying to get latex babel source blocks to work for me and discovered that calling `org-babel-execute:latex` ignores the :headers header if the output file is a png without setting imagemagick to t. It's easy to see this in the source code: the conditions mentioned above

babel link bug

2020-02-07 Thread Matt Huszagh
The patch below fixes a bug with the behavior of link without file for babel source blocks. All explained in patch message, but let me know if any concerns. >From 25d363bbc3cd7122287364f25f9b5d653bcae232 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Fri, 7 Feb 2020 23:09:48 -0800 Subj

babel comma escape with :wrap

2020-02-07 Thread Matt Huszagh
There appears to be no way to disable the comma escape when using :wrap for a babel source block. I'm essentially trying to replicate this example from the manual #+NAME: attr_wrap #+BEGIN_SRC sh :var data="" :var width="\\textwidth" :results output echo "#+ATTR_LATEX: :width

babel default header args as functions

2020-02-07 Thread Matt Huszagh
I've added the ability in my own configuration to use lambda functions that evaluate to a string as babel default header arguments, instead of just the plain strings currently allowed. Would anyone else be interested in this feature? Shall I prepare a patch? There are a number of use cases for

Re: patch: add custom latex->html conversion command

2020-02-16 Thread Matt Huszagh
, 2020 at 4:06 PM Bastien wrote: > Hi Matt, > > Matt Huszagh writes: > > > The patch below allow's you to provide your own shell command the > > generates HTML from a latex fragment and places the output directly in > > the exported HTML file. > > Can you get

Re: patch: add custom latex->html conversion command

2020-02-16 Thread Matt Huszagh
Will do, thanks! On Sun, Feb 16, 2020 at 5:10 PM Bastien wrote: > Hi Matt, > > Matt Huszagh writes: > > > Thanks for the feedback. I've filled out the form you sent and sent it > > to the email listed. > > Thanks! It looks good. > > Let me know when you get

Re: patch: add custom latex->html conversion command

2020-02-16 Thread Matt Huszagh
>From 6b2495c8aef0b67fd00ad27a0056e79f42c23c06 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sun, 16 Feb 2020 16:52:02 -0800 Subject: [PATCH] add custom command option when converting latex fragments to html * lisp/org.el (org-latex-to-html-convert-command): Add custom command opt

patch: add custom latex->html conversion command

2020-02-15 Thread Matt Huszagh
iated! >From 056d23d9e5caa6fc22907014e0128519fcc84b6e Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sat, 15 Feb 2020 18:42:11 -0800 Subject: [PATCH] add custom command option when converting latex fragments to html This allows you to set a custom command `org-latex-to-html-convert-command' that will take as input a latex

Re: babel default header args as functions

2020-09-02 Thread Matt Huszagh
Matt Huszagh writes: > I've generated a patch for this. Please let me know your thoughts. I > believe this adds valuable flexibility to default header > arguments. I've added an additional fix that makes this work during export too. >From aec4e905d5d72f9a124adfde877835a783bd637b M

Re: [PATCH] babel latex headers and image generation commands

2020-09-02 Thread Matt Huszagh
Matt Huszagh writes: > Ok, I've finally gotten around to taking a crack at this. The patch is > attached. Basically, it allows a lot more control when converting a > latex source block into an svg image file. I've added a few changes to the patch that additionally allow custom the begi

Re: [PATCH] babel latex headers and image generation commands

2020-09-02 Thread Matt Huszagh
Matt Huszagh writes: > I've added a few changes to the patch that additionally allow custom the > begin and end document environments. The purpose here is to allow latex > code within the document environment that is ignored by the body > export. For instance, I can set th

Re: [PATCH] babel latex headers and image generation commands

2020-09-09 Thread Matt Huszagh
are some cases where dvisvgm may fail (see https://github.com/mgieseki/dvisvgm/issues/139) due to changes in ghostscript. Still, dvisvgm generally does a very good job with PDF inputs. Let me know your thoughts, I'd be happy to set the default to a dvisvgm command instead. Matt >From 1ff86f2267

Re: [PATCH] Omit file description when :file-desc has nil value

2020-09-09 Thread Matt Huszagh
Kyle Meyer writes: > I also don't find the current behavior particularly intuitive. (I'm > also not really a babel user, so my opinion probably shouldn't count for > much.) If we were adding it today, I think what you describe would be > better, but, as you mention, breakage also now also

Re: babel default header args as functions

2020-09-09 Thread Matt Huszagh
Bastien writes: > Also, if we integrate the change, `eval-default-headers' would be > better named `org-babel-eval-default-headers'. I've changed the function name to `org-babel-eval-headers'. The reason for dropping "default" is that this function is now used as part of

Re: babel default header args as functions

2020-09-09 Thread Matt Huszagh
ed when they are used as part of the final set of headers. >From 4a461a90ec4f3c5f9634b687a6685ea3ba74f168 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Fri, 28 Aug 2020 11:05:59 -0700 Subject: [PATCH] ob-core.el: Add ability to use closures as default header arguments * lisp/ob-core.el (org-babel-default-header-ar

Re: [PATCH] Omit file description when :file-desc has nil value

2020-09-15 Thread Matt Huszagh
> Kyle Meyer writes: > >> I also don't find the current behavior particularly intuitive. (I'm >> also not really a babel user, so my opinion probably shouldn't count for >> much.) If we were adding it today, I think what you describe would be >> better, but, as you mention, breakage also now

Re: basic org questions

2020-09-15 Thread Matt Huszagh
Emanuel Berg via "General discussions about Org-mode." writes: > 2) How do I have tables not appear centered > by default, but left-aligned? Do you mean the alignment of columns, or the table itself? You can control column alignment with ``, ``, ``, e.g., | title | description

Re: basic org questions

2020-09-15 Thread Matt Huszagh
Emanuel Berg via "General discussions about Org-mode." writes: > Heh...? What's strange with that? > > Anyway that's what I mean. I guess I'm just not sure what you mean. I was under the impression that tables were always left-aligned and table alignment in the manual refers to column alignment

Re: basic org questions

2020-09-15 Thread Matt Huszagh
Emanuel Berg writes: > Yeah, but in LaTeX being left aligned is not some > property of the table, everything is left-aligned, > and if you want it otherwise, you put between > \begin{center} and \end{center} ... That page also describes how to set float parameters, which the table can be

Re: basic org questions

2020-09-15 Thread Matt Huszagh
Emanuel Berg via "General discussions about Org-mode." writes: > Yes, after export to PDF, they are centered. they = > the whole table items. I think this link (https://orgmode.org/manual/Tables-in-LaTeX-export.html) is the relevant part of the documentation. I haven't used this though, so I

Re: [PATCH] Omit file description when :file-desc has nil value

2020-09-03 Thread Matt Huszagh
Matt Huszagh writes: > This patch omits a file description when :file-desc has a nil > value. I've modified the patch to yield the same effect when executing a source block. Matt >From 24d156e421973b5a97f1c797d48f1daa95348898 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Wed, 2

[PATCH] Omit file description when :file-desc has nil value

2020-09-03 Thread Matt Huszagh
quot; part of the link will be omitted. Full disclaimer: I wrote this section of the documentation as part of this patch: https://lists.gnu.org/archive/html/emacs-orgmode/2020-07/msg00320.html Thanks Matt >From edcfa85add6ac71a1e13b7731779ccf4a8e12868 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Dat

Re: babel default header args as functions

2020-10-14 Thread Matt Huszagh
rey-coyrehourcq writes: > I'm unfamilliar with patch by mail but i try to apply your patch to my melpa > local org 9.4 version used by doom emacs. > Patch hang on Hunk #3, i attach the .rej file. You might need to start from a different org commit. I believe 6a182b690f works. Otherwise, you

Re: [PATCH] Omit file description when :file-desc has nil value

2020-10-06 Thread Matt Huszagh
eparately (didn't post to the thread since the PDF is too large). Thanks Matt >From 7452f3e8315be63fa8ae160f6be00963bac898a7 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Tue, 29 Sep 2020 14:11:59 -0700 Subject: [PATCH] lisp/ob-core.el: Allow passing empty vector to :file-desc to omit

Re: babel default header args as functions

2020-10-14 Thread Matt Huszagh
rey-coyrehourcq writes: > I'm interested by this functionality, do you know if it was merged or i need > to apply patch locally ? Hi SR, This hasn't been merged yet. I believe it's ready, but we're just waiting on a maintainer to apply it upstream. If you're able to apply the patch locally

Re: babel default header args as functions

2020-08-28 Thread Matt Huszagh
Matt Huszagh writes: > I've added the ability in my own configuration to use lambda functions > that evaluate to a string as babel default header arguments, instead of > just the plain strings currently allowed. Would anyone else be > interested in this feature? Shall I pre

Re: babel latex headers and image generation commands

2020-08-29 Thread Matt Huszagh
invasive to these workflows, though it will break workflows in an easily recoverable way for anyone using htlatex for svg output. Anyway, I'd be curious to hear thoughts and I'd be interested to discuss options for further refactoring the latex execute function. Matt On Fri, Aug 28, 2020 at 11:10 PM

Re: [PATCH] Omit file description when :file-desc has nil value

2020-09-29 Thread Matt Huszagh
xplicitly. I think this behavior is clearer. Thanks, Matt >From 749fd5ade6b65f9d07e87b4af44ebb1afef2bee6 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Tue, 29 Sep 2020 14:11:59 -0700 Subject: [PATCH] list/ob-core.el: Allow passing empty vector to :file-desc to omit description * doc/org-man

Re: [PATCH] Omit file description when :file-desc has nil value

2020-09-24 Thread Matt Huszagh
Kyle Meyer writes: > But it's not a direct comparison against that use case and the use case > you want to support. The potential breakage of existing documents is a > big factor to go against. Yep, I agree. I think my phrasing could have just been better. I meant to include the breakage as a

Re: official orgmode parser

2020-09-16 Thread Matt Huszagh
"Gerry Agbobada" writes: > I'm currently toying with the idea of trying a tree-sitter parser for Org. > The very static nature of a shared object parser (knowing TODO keywords are > pretty dynamic for example) is a challenge I'm not sure to overcome ; to be > honest even without that I can't

Re: [PATCH] babel latex headers and image generation commands

2020-10-24 Thread Matt Huszagh
Bastien writes: > sorry for the delayed answer. No worries! > Can you provide a patch against etc/ORG-NEWS announce this? Attached. Let me know what you think. Matt >From 51fb3ef9843ae45884803142f150c5d2f4f4d4c9 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sat, 24 Oct 2020

Re: incorrect documentation for file-desc header argument?

2020-07-29 Thread Matt Huszagh
20a24b3416f8f8ba0892a8e47221 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Tue, 28 Jul 2020 22:10:12 -0700 Subject: [PATCH] org-manual.org: Modify file-desc header argument to match action --- doc/org-manual.org | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/org

incorrect documentation for file-desc header argument?

2020-07-28 Thread Matt Huszagh
Hello, The org info documentation states The ‘file-desc’ header argument defines the description (see *note Link Format::) for the link. If ‘file-desc’ has no value, Org uses the generated file name for both the “link” and “description” parts of the link. However, if I

Re: incorrect documentation for file-desc header argument?

2020-07-28 Thread Matt Huszagh
Matt Huszagh writes: > Hello, > > The org info documentation states > > The ‘file-desc’ header argument defines the description (see *note > Link Format::) for the link. If ‘file-desc’ has no value, Org uses > the generated file name for both the “link” an

Re: babel default header args as functions

2020-12-21 Thread Matt Huszagh
Bastien, Any chance you've had the time to look at this? I know how much time you put into org-mode, so no rush if you need more time! Let me know if there's anything I can do on my end. Thanks! Matt

Account for latex snippet width in fill paragraph

2021-02-08 Thread Matt Huszagh
Hello, I make extensive use of inline latex image snippets in my Org buffers. One thing that has annoyed me for a while is that `org-fill-paragraph' (unsurprisingly) uses the width of the underlying text when determining the characters which make up each line. Because the characters which make up

Re: Account for latex snippet width in fill paragraph

2021-02-09 Thread Matt Huszagh
Eric S Fraga writes: > I don't have this issue because I use visual-line-mode (together with > org-indent-mode) and text reflows automatically. Every paragraph is a > single "line" in the org file but is (soft) wrapped automatically at the > window edge. But this may not suit you, of course.

Customizing the agenda item format

2021-09-19 Thread Matt Huszagh
I'm attempting to create a custom agenda, but having a bit of trouble getting this to work in the way that I want. In particular, I'd like to be able to specify the display format for each item. Here's what I've got so far: (setq org-agenda-custom-commands '(("c" "Custom agenda view"

Re: Patch to align baseline of latex fragments and surrounding text

2021-10-10 Thread Matt Huszagh
Matt Huszagh writes: > I've created a patch to align the baseline of latex image fragments to > the surrounding text. The patch consists of several parts. First, it > adds a customizable variable that can be set to a user supplied function > to compute the value of :ascent passed to

Patch to align baseline of latex fragments and surrounding text

2021-10-10 Thread Matt Huszagh
an incorrect :ascent value. Let me know what you think! Best Matt >From 6c33fa1875cc169616d878b59054d50980f741f3 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sun, 10 Oct 2021 15:46:05 -0700 Subject: [PATCH] org--make-preview-overlay: Add ability to set vertical alignment of latex fragme

Re: Patch to allow adjusting latex fragment display scale factor

2021-10-10 Thread Matt Huszagh
Matt Huszagh writes: > I've created a patch to allow adjusting the scale factor used for inline > latex image fragments. This involves a customizable variable that can > either be set to a scale factor (defaults to 1.0) or a function that > evaluates to a scale factor. >

Patch to allow adjusting latex fragment display scale factor

2021-10-10 Thread Matt Huszagh
-adjust' (e.g., through `advice-add'). Feedback appreciated. Matt >From 8247947aa6141cde9c58205e0266f0e674226f95 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sun, 10 Oct 2021 21:20:31 -0700 Subject: [PATCH] org.el: Allow customizing overlay-put scale factor * lisp/org.el (org-latex-fragm

Re: babel default header args as functions

2021-09-28 Thread Matt Huszagh
Matt Huszagh writes: > I've tested it, and if you revert > 78783f4e47901255695031dae0efcbb301a40878 and apply the new patch, it > will apply with conflicts. Let me know if you run into any difficulties, > have any concerns, etc. That "with" should be "without"... Matt

Re: babel default header args as functions

2021-09-28 Thread Matt Huszagh
Bastien writes: > Applied, thanks, and sorry again for the lng delay. Thanks Bastien, and no worries about the delay. However, I hate to say it but I think you may have applied an old patch. The most recent patch is https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/txtzi_PffIaG1.txt

Re: babel default header args as functions

2021-09-28 Thread Matt Huszagh
Matt Huszagh writes: > Thanks Bastien, and no worries about the delay. However, I hate to say > it but I think you may have applied an old patch. The most recent patch > is > > https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/txtzi_PffIaG1.txt > > Let me know what I

Re: babel default header args as functions

2021-09-28 Thread Matt Huszagh
Timothy writes: > I just read your docs patch, and that’s lead to a quick question: does this > patch > support a header arg function in the form “(:file . > #’my-org-file-name-generator)”? Unfortunately it doesn't. It's been about a year since I wrote this patch, so I'm a bit hazy on some of

[PATCH] Fix caption format for custom latex src block

2021-12-29 Thread Matt Huszagh
'm not actually 100% confident that the patch is the optimal way to do this. The API wasn't totally clear to me in this case. Any advice here is appreciated. Matt From 5b0601d6d3b8034202c4b9b820c64a719e3129b9 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Wed, 29 Dec 2021 19:35:42 -0800 Subject: [PATCH] o

[PATCH] Remove additional newline at end of results block

2021-12-30 Thread Matt Huszagh
he simplest equation as : #+begin_src latex : \begin{equation} : 1 + 1 = 2, : \end{equation} : #+end_src : #+RESULTS: : #+begin_results : [[file:some/file.svg]] : #+end_results : and hope that no one is confused by this. ``` From 667ba67570361bad878c74afdebe068b7916a1bb Mon Sep 17 00:00:00 2001 From

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

2021-11-22 Thread Matt Huszagh
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 regex for determining image width from attribute

2021-11-22 Thread Matt Huszagh
2001 From: Matt Huszagh Date: Mon, 22 Nov 2021 21:36:03 -0800 Subject: [PATCH] org.el: Fix string-match-p function arguments * lisp/org.el (org-display-inline-image--width): string-match-p requires 2 arguments, but only one was given. --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1

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

2021-11-22 Thread Matt Huszagh
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

2021-11-22 Thread Matt Huszagh
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 regex for determining image width from attribute

2021-11-22 Thread Matt Huszagh
:00:00 2001 From: Matt Huszagh 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 specif

[PATCH] Fix window width when line numbers present

2021-11-21 Thread Matt Huszagh
mean (as described in the variable documentation) that the line number width is computed dynamically. Thanks Matt >From 5faaf45bf54c0cd3135b9c5a747c22797fe1d290 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sun, 21 Nov 2021 10:30:30 -0800 Subject: [PATCH] org.el: Fix inline image wi

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

2021-11-21 Thread Matt Huszagh
Bastien writes: > See https://orgmode.org/worg/org-maintenance.html#emacs-compatibility Ah, my mistake. Thanks for pointing me to that. So does this stay on some other branch until the Emacs official release is at 28? Matt

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

2021-11-21 Thread Matt Huszagh
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

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

2021-11-21 Thread Matt Huszagh
Nicolas Goaziou writes: > `line-number-display-width' is Emacs 26+. So I guess it is unfortunately > not acceptable on main branch. Does org-mode not require 26+ even though the Emacs official release is on 27? Matt

[PATCH] Fix regex for determining image width from attribute

2021-11-21 Thread Matt Huszagh
rom b9b8fb9b31dbb9145c2fe73af04eccd59f7a9973 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sun, 21 Nov 2021 11:02:37 -0800 Subject: [PATCH] lisp/org.el: Fix regex for determining image width from attribute * lisp/org.el (org-display-inline-image--width): The regex should only match attr_org, not any attr_. This would ma

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

2021-11-24 Thread Matt Huszagh
eywords > 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 >From 73f6d6d0c16d9b3312737463361cefe08b0

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

2021-11-28 Thread Matt Huszagh
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 >

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

2021-11-22 Thread Matt Huszagh
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

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

2021-11-22 Thread Matt Huszagh
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] Fix regex for determining image width from attribute

2021-11-23 Thread Matt Huszagh
udes ": " before ":width", I would prefer explicit > space before ":width". Currently we have a space before .*. Would you prefer it after? Anyway, I've also implemented this change. Let me know what you think. Matt >From 76a0c05cec8e449efd5cbffd8123338912815f17

[PATCH] Fix behavior of lambda default header arg vars

2021-10-27 Thread Matt Huszagh
). This patch fixes that. I've also added documentation explaining how to set multiple vars in the default header argument facility. Thanks, Matt >From 5f02fe4e896e6909fab18e8d90a7e14bdce9d5c4 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Wed, 27 Oct 2021 07:47:20 -0700 Subject: [PATCH]

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

2021-12-02 Thread Matt Huszagh
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

Re: Patch to align baseline of latex fragments and surrounding text

2021-12-02 Thread Matt Huszagh
Timothy, looping you in on this. I feel that maybe it would be useful to attach screenshots to show the improvement from this patch? Anyway, I've attached two images: one with the correct baseline alignment to surrounding text and the other with the current, incorrect, baseline alignment. I

Re: [PATCH] Fix behavior of lambda default header arg vars

2021-12-02 Thread Matt Huszagh
Matt Huszagh writes: > Hey Timothy, > > Any thoughts on this bug fix? > > Thanks > Matt Apologies, meant to include the org-mode mailing list in this too. Thanks Matt

Re: Patch to align baseline of latex fragments and surrounding text

2021-12-09 Thread Matt Huszagh
side the image file. In this case, standalone encodes this information in the viewbox of the SVG file. Thanks Matt >From 2640b24d2cce8e2b61101125c348db35800570ff Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Sun, 10 Oct 2021 15:46:05 -0700 Subject: [PATCH] org--make-preview-overlay: A

Re: [Patch] Align baseline of latex fragments and surrounding text

2021-12-10 Thread Matt Huszagh
Sébastien Miquel writes: > My mistake. For some reason, I had thought that > =\documentclass[preview]{standalone}= was used by default for LaTeX > previews. Setting it as described in your patch, it now works > properly, even with the default value of =dvisvgm=. No worries; glad you got it

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

2021-11-30 Thread Matt Huszagh
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.

Re: [PATCH] Fix behavior of lambda default header arg vars

2022-07-08 Thread Matt Huszagh
uild fake ancestor My mistake. Try these. Matt >From 6894d7b441fe975bc90177d85102c031cffe3c46 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Mon, 27 Jun 2022 20:41:02 -0700 Subject: [PATCH 1/2] ob-core.el: Fix behavior of lambda default header arg vars * lisp/ob-core.el: Permit multipl

Re: [PATCH] Remove additional newline at end of results block

2022-07-08 Thread Matt Huszagh
Ihor Radchenko writes: > Thanks for the patch! And sorry for the late reply. No worries for the delay - I know you have a lot of these. Thanks for the review. > Your explanation is quite confusing, but I think I managed to understand > what you referred to: > > -- > We can write the

Re: [PATCH] Fix caption format for custom latex src block

2022-07-08 Thread Matt Huszagh
Timothy writes: > As mentioned by Ihor, you’ll want to take a look at the curent version of > ox-latex, specifically `org-latex-src-block--custom' which now contains `(?c . > ,caption)'. You may want to consider modifying > `org-latex--caption/label-string' to > accept the form `(element info

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

2022-07-08 Thread Matt Huszagh
Juan Manuel Macías writes: > TL;DR: A list of use cases where using LuaTeX is more advantageous than > using pdfTeX > > > > Many times Org users who frequently need to export their documents to > LaTeX, but who do not have much LaTeX experience (or their knowledge of > the TeX

Re: [PATCH] Fix caption format for custom latex src block

2022-06-27 Thread Matt Huszagh
Ihor Radchenko writes: > I think that it will be better if you use > org-latex--caption/label-string instead. It will take care about short > captions as well. Changing this to (?c . ,caption-str) yields for the original example \caption{\caption{Perform inter-sample interpolation.} } I could

Re: [PATCH] Fix behavior of lambda default header arg vars

2022-06-27 Thread Matt Huszagh
Hi Ihor, Modifications made and split into two patches. Let me know if any remaining issues. Thanks Matt >From fdc6e103932c68b450c72d44d062b4746ec2202c Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Mon, 27 Jun 2022 20:41:02 -0700 Subject: [PATCH 1/2] ob-core.el: Fix behavior of lam

Re: [PATCH] Fix behavior of lambda default header arg vars

2022-06-05 Thread Matt Huszagh
> It would help if closure part and multi-variable part were split into > separate paragraphs. The closure part and muliple header argument part are already in separate paragraphs. The multiple header argument part, however, is incorporated into an introductory paragraph that very briefly