On Friday, 6 Dec 2019 at 17:47, Arthur wrote:
> Since my last org update (today or yesterday I would say) I have been
> having an issue with exporting .pgf or .tikz file to LaTeX. The
> exporter always returns `nil`.
Your example works just fine for me with git up to date as of a few
minutes
On Friday, 6 Dec 2019 at 11:42, Matt Huszagh wrote:
> I'm experiencing incorrect and seemingly inconsistent behavior when nesting
> `\begin` `\end` environments inside `\(\)` or `$$`. For example, the
> following is valid latex code:
The identification of LaTeX fragments is somewhat fragile (in
Greetings.
I am (still) trying to figure out a SINGLE common setup/include file for
all settings for a large batch of files.
I found out recently that common #properties can be set in a setup file
(but not in an included file). However, now it seems that in a setup
file I can not include all
Hello,
Tom Gillespie writes:
> * Description
> Headlines are not ignored inside of blocks when the headline is not indented.
>
> * Affected versions
> 9.1.9, 9.3
>
> * Observed behavior
> Lines starting with any headline pattern =*=, =**= etc. are treated as
> headlines inside all block types.
Hello,
Arthur writes:
> Since my last org update (today or yesterday I would say) I have been
> having an issue with exporting .pgf or .tikz file to LaTeX. The
> exporter always returns `nil`.
>
> I attached a patch that can fix this. It is not thoroughly tested by my
> assumption is that the
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
As stated in the subject of this e-mail, the command MathematicaScript
became wolframscript in the newer versions of mathematica. To make
ob-mathematica.el work again with newer versions of mathematica simply
replace all occurences of MathematicaScript with wolframscript in that file.
An extra
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hello,
'Ihor Radchenko' writes:
> I have one scheduled item like the following:
>
> * test
> <2019-12-05 Thu 23:00-29:00>
>
> This kind of item fails to be parsed by agenda because of incorrect
> treatment of 23:00-29:00 time interval
What makes you think the time interval above is correct? I
[Resending without a link since your mail server classified my previous message
as spam]
> What makes you think the time interval above is correct? I would also
> expect an error from that time specification.
I also thought that it is incorrect (and posted a bug report since it is
what is
On Fri 06 Dec 2019, Nicolas Goaziou wrote:
> Hello,
>
> Andy Moreton writes:
>
>> This is still a regression.
>>
>> The old behaviour allowed display of fixed width columns, even if that
>> is wider than the content of cells in that column. This is useful for
>> display of several related tables
"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
On Sunday, 1 Dec 2019 at 19:57, Fraga, Eric wrote:
> I guess I'm making a feature request: to be able to use custom time
> display in column views. Would this be possible? (or, knowing me, it
> might already be possible so would somebody tell me how?)
I found some time today to explore and
On 12/3/19 1:03 AM, Justin Vallon wrote:
> Newbie org-mode user. Wondering about some odd recurrence behavior.
...
> My understanding of .+TERM is that the new scheduled time should be now
> + term. However, from this instance and testing with other terms, it
> seems to be "current date +
Hello,
Andy Moreton writes:
> That still does not match the old behaviour though, as the table still
> shows the `org-table-shrunk-column-indicator' overlay which is
> undesireable.
Why is it undesirable?
> Dynamic shrink/expand is a fine feature to add, but why was it done in a
> way that
> What makes you think the time interval above is correct? I would also
> expect an error from that time specification.
I also thought that it is incorrect (and posted a bug report since it is
what is produced by typing 11pm+6 in org-read-date).
However, I got a reply that 23:00-29:00 is a
After test-driving this patch for a bit, the main issue I foresee is
that this can potentially hang Emacs if loading a lot of images over a
slow SSH connection. This was also discussed in the previous thread from
2014.
I plan to mitigate this with an option to enable/disable/cache the
remote
Jarmo Hurri writes:
> Greetings.
>
> I am (still) trying to figure out a SINGLE common setup/include file for
> all settings for a large batch of files.
>
> I found out recently that common #properties can be set in a setup file
> (but not in an included file). However, now it seems that in a
Hello,
Sharon Kimble writes:
> On loading the most recent version of org-mode (yesterdays, being
> 2019-12-03) I am consistently getting this occurring in debugger.
>
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (void-function
Hello Nicolas!
Nicolas Goaziou writes:
> SETUPFILE and INCLUDE are orthogonal. There is no point in mixing
> them.
Ok. As a programmer I was hoping to mix them, because it would be
logical to have _one_ header file that defines all the common things for
a set of related files.
But perhaps I
"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
Greetings,
In my init file I have
(setq org-confirm-babel-evaluate nil)
File "A" is attached as an org file. I evaluate the source blocks (C-c
C-v s), the table is generated and then I export it to PDF. The source
blocks do not evaluate during export.
In file B I have
#+INCLUDE:
sometimes i will get long lines pasted in from someplace.
all in a long set of lines
like this
except with longer lines
then i make it into a list.
but i want each item of the list to be filled.
so i make a region and fill and the items do not get filled.
sometimes filladapt works, but not
Hi,
I reached a strange bug, I hope you can reproduce it too
I want to track changes on TODO and I have in the beginning of my buffer:
#+TODO: TODO(t!) PLANNED(p!) DOING(d!) VERIFY(v) EXPLAIN(e) | DONE(d!)
which means that TODO, PLANEED, DOING and DONE will have a report of
change in the same
On Sat 07 Dec 2019, Nicolas Goaziou wrote:
> Hello,
>
> Andy Moreton writes:
>
>> That still does not match the old behaviour though, as the table still
>> shows the `org-table-shrunk-column-indicator' overlay which is
>> undesireable.
>
> Why is it undesirable?
It also always shows the
Hi Nicolas,
Thanks for the reply and pointer to the docs. Given that the
headlines are working as expected, is there the possibility to
change how the syntax highlighting for source and example
blocks works so that it matches the behavior for the verse blocks?
Best,
Tom
On Sat, Dec 7, 2019
26 matches
Mail list logo
