Hi Ori,
Ori writes:
> I'm not sure which repo this all lives in but I believe since
> information has been added to the paths, this should be easy. The
> other direction would be trickier and would need the old scheme.
>
> Wherever the current filename has capital letters after the first
>
I'm not sure which repo this all lives in but I believe since information
has been added to the paths, this should be easy. The other direction would
be trickier and would need the old scheme.
Wherever the current filename has capital letters after the first
character, make an alias using the
Hi Ori,
Ori Barbut writes:
> Not sure if this was intentional?
Yes -- old html manual pages where still around and I deleted them,
because they confused people.
> If so would it make sense to alias the old URLs for people who have
> linked to the manual over the years?
Yes, such aliases
It seems that sometime in the past week the capitalization scheme of URLs
generated for the online manual has changed. For example I see as
of 2020-02-02 per the cache on Bing, the following url worked:
https://orgmode.org/manual/Structure-of-code-blocks.html
The new URL is:
Only needs to be in the exported document, and doesn't necessarily need to
render that way within org. However, I'd like to avoid having to choose the
export form with custom markup in the org document. I often have documents,
or parts of docs, that are exported to both HTML and latex.
The
> On Feb 8, 2020, at 2:13 AM, Fraga, Eric wrote:
>
> On Friday, 7 Feb 2020 at 17:59, Steve Downey wrote:
>> I have a need to lay out source blocks side by side, in order to present
>> before and after changes to the source. If I could embed a block in a
>> table, that would do it.
>
> Do
Hi,
> -Original Message-
> From: Nicolas Goaziou
> Sent: den 7 februari 2020 15:28
> To: Gustav Wikström
> Cc: emacs-orgmode@gnu.org
> Subject: Re: attachment: link type export to HTML invalid attach dir
>
> > Hmm, maybe that is so.. Except raw-path is called path (not really an
> >
On Friday, 7 Feb 2020 at 17:59, Steve Downey wrote:
> I have a need to lay out source blocks side by side, in order to present
> before and after changes to the source. If I could embed a block in a
> table, that would do it.
Do you need this layout in org file itself or only in an exported
Excellent use of the :prologue and :epilogue header arguments!
--
: Professor Eric S Fraga; use plain text: http://useplaintext.email
: https://www.ucl.ac.uk/chemical-engineering/people/prof-eric-fraga
: PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
#+begin_quote alphapapa
I think you have a better case for changing this setting. However, I
think there is another consideration: the default settings do not put
blank lines between headings and their entry text, and without any
indentation, headings and entry text on varying levels tends to
#+begin_quote alphapapa
What would be useful would be if Emacs/Org could be configured to wrap
prose lines but not, e.g. tables and code blocks. I don't think such
functionality exists in Emacs now, but here's a new package that may be
relevant: https://github.com/luisgerhorst/virtual-auto-fill
Hello Jack,
Thanks for taking the time to reply.
> I think a more reliable implementation would be to avoid
> `org-babel-comint-with-output', and take the approach used in the
> ":results value" case, which reads the output from a temp file instead
> of directly from the shell.
I understand
Hello,
Matt Huszagh writes:
> 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
Hello,
Matt Huszagh writes:
> - (let ((file (and (member "file" result-params)
> -(cdr (assq :file params)
> + (let ((file (cdr (assq :file params
This patch is wrong, with it, :file parameter alone would imply file
result, which is not
14 matches
Mail list logo
