Hello,
Currently, org does tag alignment by adding a number of spaces before
the tags. This becomes messy when one changes the window size and turns
off line truncation.
I came up with an experimental code utilising 'display text property and
font-lock to align tags dynamically, as you resize the
Nicolas Goaziou writes:
I don't understand what would be the best of HTML email in that
case. You're neither inlining any image, nor using any fancy
presentation. Yet, your email is twice as big as it could be.
HTML is often prettier :P it's also nice to get code blocks with
syntax highl
At the moment, I'm working around this by setting the width in "TeX points":
#+attr_latex: :width 224pt
The exported image becomes 224 points wide (roughly 8 cm), and the
embedded image is 224 pixels wide, which is okay.
2020-05-26 12:01 GMT+08:00, Vladimir Nikishkin :
> Hello, everyone
>
> My
Hello, everyone
My problem is the following:
Compare the following three pieces of org code:
#+attr_latex: :width 80px
[[file:figure-1-1-dot.png]]
#+attr_latex: :width 8cm
[[file:figure-1-1-dot.png]]
#+attr_latex: :width 80mm
[[file:figure-1-1-dot.png]]
They get exported into LaTeX as expect
Nick Daly writes:
> On Sat, May 23, 2020 at 7:02 PM Nick Daly wrote:
>> : "^\\*?[[:upper:]][\\._[:alnum:]]*\\(?:
>> \\*?[[:upper:]][\\._[:alnum:]]*\\)*\\( λ\\)?> "
>>
>> =comint-prompt-regexp='s variable documentation calls out much simpler
>> regexps
>>
>> : "^[^>]+\\(> \\)?"
>
> This simplified
Nick Daly writes:
> After a bit of tinkering, I realized there are two things going on
> here, only one of which I fully understand:
>
> 1. My core functional issue is that =comint-prompt-regexp= isn't set
>up to handle the "Prelude| " entries or the repeated prompts. The
>other patches I
I apologize that I got to this so late,
I tested it and it works, issue is fixed, with, I must say, nice and
systematic approach.
Thank you.
On Sat, May 16, 2020 at 8:44 PM Nicolas Goaziou wrote:
>
> Hello,
>
> Alois Janíček writes:
>
> > When attempting to generate clock-report using ":scope
>
Timothy writes:
> I have only a basic working understanding, but my impression was that
> in functioned as a 'best of both worlds' type thing.
I don't understand what would be the best of HTML email in that case.
You're neither inlining any image, nor using any fancy presentation.
Yet, your emai
Hi all,
When playing around with org-archive, I noticed that the function
org-archive-all-matches doesn't use org-archive-default-command but
calls org-archive-subtree directly. Is there any reason for this, or is
it simply a small bug/missing feature?
Warm regards,
Thomas Schaper
Bastien,
> thanks for reporting this. I've pushed a quick fix in master so that
> it now displays an error as the output and does not choke at the user
> as it did before.
thank you!
>From fc91322e9f8e47484767b66fb9f438d3326ccc08 Mon Sep 17 00:00:00 2001
From: TEC
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
new function, `org-edit-latex-fragment' which is hooked into
`org-edit-special', modifying `org-sr
Nicolas writes:
>> <#multipart type=alternative><#part type=text/plain>
>
> Please don't send HTML.
Appologies, I'm trying to use org-msg for emails, which should be off
for replying to plaintext, but I seem to have odd things happen now and
then ... as you have noticed.
So, I'm trying to kee
TEC writes:
> <#multipart type=alternative><#part type=text/plain>
Please don't send HTML.
> Inline LaTeX, and Environments are indeed different. I failed to consider that
> there may be additional complications if switching an inline environment to an
> environment. Quite frankly I’m not too s
No, I was not aware of it. Yet, if I understand the objective of the Emacs
ML and Debbugs, it is for, when you have a crash with emacs or, at least,
an error stack trace when evaluating some lisp code. This is different from
the intent here to define how to switch a thread started as a simple
conv
Hello,
Rafael writes:
> Consider the following example:
>
> #+begin_src org
> ,#+title: Test
>
> ,#+options: H:2
>
> ,* Section
> :PROPERTIES:
> :CUSTOM_ID: section
> :END:
>
> ,** Frame
>:PROPERTIES:
>:CUSTOM_ID: frame
>:END:
>
> ,*** Block
> :PROPERTIES:
> :CUSTOM_ID:
Nicolas Goaziou writes:
That would be undesirable. LaTeX fragments (inline type) and
LaTeX environments (block type) are different beasts. This is
clearly outside the scope of `org-edit-special' to move from one
type to the other.
Inline LaTeX, and Environments are indeed different. I fa
Nicolas Goaziou writes:
This is the following part, in `org-edit-footnote-reference':
Thanks. Sorry I'm having you repeat yourself.
Replacing "\n" with "", as above, is too strong BTW. It would be
better to replace it with " ". I'll fix the footnote-reference
part.
Sounds sensible.
S
TEC writes:
> This is what I thought. Might you have any suggestions on how
> I incorporate this logic? Something like `org-in-table-p' would be
> ideal :D
This is the following part, in `org-edit-footnote-reference':
--8<---cut here---start->8---
;; If footn
Hi David,
David Trudgett writes:
> The publishing functionality now appears to be working as it
> should.
Thanks for confirming!
--
Bastien
Nicolas Goaziou writes:
Just saying 'no' to new lines seems like a possible solution,
but long equations can often be deperate for newlines when it
comes to readability.
Saying no to new lines is only necessary in tables. Outside, we
only need to say no to blank lines.
This is what I
Hi Vladimir,
Vladimir Alexiev writes:
>> Org inserts lower-case #+begin* keywords as a default
>
> But org-babel-demarcate-block doesn't do that in the case of new
> block.
Indeed, I pushed a fix to master so that org-babel-demarcate-block
insert lower-case keywords, unless upper-case ones ar
TEC writes:
> Just saying 'no' to new lines seems like a possible solution, but long
> equations can often be deperate for newlines when it comes to
> readability.
Saying no to new lines is only necessary in tables. Outside, we only
need to say no to blank lines.
Note that you cannot preserve
TEC writes:
> Thinking about this a bit more, I think this may not actually be desirable
> behaviour.
>
> Why? I considered the case where I’ve been writing a growing inline equation
> \( \),
> realised it should be displayed as an equation instead with \[ \] and edited
> the
> LaTeX marks such
Nicolas Goaziou writes:
It seems you're mixing inline source blocks and LaTeX fragment.
You
modified the former, but not the latter.
Ooops, I'll fix that.
+ (lambda () ; trim content
+ (goto-char (point-min))
This is not needed. The function is always called at
`point-min'.
TEC writes:
> - (end (progn (goto-char (org-element-property :end datum))
> - (search-backward "}" (line-beginning-position) t
> + (end (org-with-point-at (org-element-property :end datum)
> + (skip-chars-backward " \t")
> +
Nicolas Goaziou writes:
I don’t think we need to worry about newlines,
We need to.
| some | table| | LaTeX | $1 + 1$ |
Oh dear, I haden't considered that. This is beginning to sound
complicated :sweat_smile:
Just saying 'no' to new lines seems like a possible solution, but
TEC writes:
> Nicolas Goaziou writes:
>> LaTeX fragments should not break paragraphs, or tables. So you need to
>> prevent inserting blank lines, or even newlines characters in the case
>> of tables.
>
> I don’t think we need to worry about newlines,
We need to.
| some | table|
| LaT
I've had another thought :)
Nicolas Goaziou writes:
The equivalent code will prevent a user from changing, deleting
the LaTeX markers, or writing past them : this is not the
purpose of the functionality.
That's most helpful, thanks :)
I'l have a look at that now, in the mean time here's w
One other quick comment
Nicolas Goaziou writes:
LaTeX fragments should not break paragraphs, or tables. So you
need to
prevent inserting blank lines, or even newlines characters in
the case
of tables.
I don't think we need to worry about newlines, particularly as
this only applies
to elem
Kyle Meyer writes:
> Vladimir Nikishkin writes:
>
> When you enter the export dispatch, you should see an "Export scope"
> option bound to C-s. That toggles between buffer and subtree export.
I think it also works to narrow the buffer to what you want to export.
Calling org-narrow-to-subtree an
>From 748c20d65df9cd0ae9f9f80c2bb5ee87aea101e4 Mon Sep 17 00:00:00 2001
From: TEC
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
new function, `org-edit-latex-fragment' which is hooked into
`org-edit-special', modifying `org-sr
TEC writes:
> I’m trying to work out what it is that should be happening with this. Looking
> at
> `org-edit-footnote-reference’, as you pointed me to, and
> `org-edit-inline-src’:
>From `org-edit-footnote-reference':
--8<---cut here---start->8---
(add-text-
Nicolas Goaziou writes:
You also need to put read-only property on fragment markers, and
remove any blank line as the final step. See
`org-edit-footnote-reference'.
I'm trying to work out what it is that should be happening with
this. Looking at `org-edit-footnote-reference', as you poin
these .org files to be hidden by default from results
>>> of "org-agenda" -> "s Search for keywords" by default.
>>>
>>> This is not the case, unfortunately.
>>
>> Can you be so kind as to test with latest Org from maint or master?
>
> Ea
> Org inserts lower-case #+begin* keywords as a default
But org-babel-demarcate-block doesn't do that in the case of new block.
Hello,
Roland Coeurjoly writes:
> Sorry, I was working on the emacs git repo, which seems to be a bit behind
> the org mode one.
> Please find patch attached.
I removed some spurious blank lines and applied your patch.
Thank you.
Regards,
--
Nicolas Goaziou
Hello,
TEC writes:
> I thought that too initially. The think is you actually want them in the LaTeX
> buffer so they get treated as mathematics instead of text.
Indeed!
Still, END is not correct, because it includes white space after the
object. So, you probably need something like:
(end (o
37 matches
Mail list logo
