Timothy writes:
> Hi Matt and Ihor,
> I must admit that with the new system, I don’t see much value in accepting a
> function: we now scale the previews based on a combination of the :scale
> parameter and their actual LaTeX display size.
Yep, we can close/cancel this patch. I had been using
Matt Huszagh writes:
> Another minor issue I've encountered. Using different delimiters results
> in images of slightly different sizes.
>
> For example, in a file containing:
>
> ```
> Using first delimiters: \(F=ma\).
>
> Using other delimiters: $F=ma$.
> ```
&g
Timothy,
Another minor issue I've encountered. Using different delimiters results
in images of slightly different sizes.
For example, in a file containing:
```
Using first delimiters: \(F=ma\).
Using other delimiters: $F=ma$.
```
The snippet with dollar sign delimiters is slightly larger than
Hi Timothy,
Thanks for your work on this.
I've run into an issue related to the change you made in
209e5f5f4047a34db27c3b5dff4077bb1da9ceed that makes org-latex-compile
asynchronous.
This breaks the org-babel-latex-pdf-svg-process functionality I
introduced in commit
Hi,
Bringing this back up. Ihor, I've added you to the thread directly
(hope that's ok).
Any thoughts? I have not yet updated it for the most recent changes to
main, but I can do that.
Matt
On Sun, Oct 10, 2021 at 9:40 PM Matt Huszagh wrote:
>
> Matt Huszagh writes:
>
> &g
Ihor Radchenko writes:
> Matt Huszagh writes:
>
>> These are nice ideas, and ones I hadn't considered. Thanks for the
>> suggestions! I'll think about it a bit and may modify the patch
>> accordingly.
>
> May I ask if you further considered changing the patch?
Hey
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
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
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
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
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
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
> 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
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
'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
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
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
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
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
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
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.
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
>
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
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
: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
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
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
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
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
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.
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
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
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
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
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
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
). 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]
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.
>
-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
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
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
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
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
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
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
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"
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.
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
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
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
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
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
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
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
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
"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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>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
, 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
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
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
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
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
Nvm, I found the issue.
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
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
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))
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
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
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.
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
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
"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
"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
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 &=
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
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
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
97 matches
Mail list logo
