Dear org-mode list,
It appears that multi-line links in org-mode will only work with if
they span no more than two lines:
http://comments.gmane.org/gmane.emacs.orgmode/19919
I was wondering if this hard-coded limit could be removed in future
versions, also given the fact that the syntax spec.
Hello Nicolas,
On Sun, 2014-07-06 at 09:23 +0200, Nicolas Goaziou wrote:
Tobias Getzner tobias.getz...@gmx.de writes:
On Wed, 2014-07-02 at 12:39 +0200, Tobias Getzner wrote:
One additional issue I’ve hit upon is that the link :path returned by
org-mode is also truncated after a newline
Nicolas, thank you for reply. Due to some health issues I’m only
responding now.
On So, 2014-07-06 at 21:28 +0200, Nicolas Goaziou wrote:
Tobias Getzner tobias.getz...@gmx.de writes:
If there is some strong reason for a hard-coded limit, would it be
possible to expose the limit as a user
Hello Nicolas,
On Sa, 2014-07-26 at 15:32 +0200, Nicolas Goaziou wrote:
In the long run, I'm pretty sure the project will benefit more if you
bring in your own, temporary, inexperience and start hacking from there.
I’ll definitely look into this once I get a hang of Elisp. When I
Hello,
When using LaTeX-based export targets that produce a .tex file as output
(export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
foo.tex modified; kill anyway?». Irrespective of whether I answer y/n,
no .tex file is produced, and «latexmk» fails with «no such file».
On Wed, 17 Sep 2014 08:27:21 +, Tobias Getzner wrote:
When using LaTeX-based export targets that produce a .tex file as output
(export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
foo.tex modified; kill anyway?». Irrespective of whether I answer y/n,
no .tex file
Hello,
I was looking into applying a custom font to certain org-mode faces, when
I noticed that no dedicated face seems to be set for verse and quote
blocks. Looking into org-faces.el, it looked (to non-Elisp-trained eyes)
like there are faces set-up for these blocks, but for some reason they
Hello,
I was wondering whether there exists some way of sharing literal code
(or, possibly, code results) between subsequent code blocks. E.g., I was
trying to create a document containing several tikz graphics, and I would
like to share a number of style definitions between these. When I only
On Thu, 18 Sep 2014 13:17:14 +, Tobias Getzner wrote:
Are there any convenient inline-expansion methods I might have
overlooked?
To illustrate, I was wondering if any of the following is feasible
somehow:
* Semantic expansion
#+name setup_fu
#+begin_src sh :results raw
echo 2
On Thu, 18 Sep 2014 15:01:37 +0100, Eric S Fraga wrote:
Are there any convenient inline-expansion methods I might have
overlooked?
Org src blocks can reference other src blocks. Note the :noweb yes
option and the use of
Nice! And I see I get «semantic» expansion when I add call syntax
Evaluating LaTeX source blocks had an issue where header options would be
ignored when exporting to SVG; this appears to have been addressed in
246df88. I have patched this commit into my 8.2.7c installation. While
the headers now seem to work, I’ve noticed that LaTeX still doesn’t like
the
Hello,
I have a strange problem when exporting the following file:
* heading 1
#+BEGIN_SRC sh :eval never
echo baz
#+END_SRC
* heading 2
#+BEGIN_SRC sh :exports results
echo quux
#+END_SRC
When I export this document, and point is on heading 1 when issuing the
«C-c C-e», the results of the
Hello Nicolas,
On Mo, 2014-09-22 at 17:29 +0200, Nicolas Goaziou wrote:
FWIW, I cannot reproduce it.
This was quite painful to isolate, but I’ve now identified a minimal
configuration which should trigger this bug.
──
;; BEGIN
On Wed, 17 Sep 2014 09:29:48 +, Tobias Getzner wrote:
On Wed, 17 Sep 2014 08:27:21 +, Tobias Getzner wrote:
When using LaTeX-based export targets that produce a .tex file as output
(export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
foo.tex modified; kill anyway
On Tue, 23 Sep 2014 10:22:45 +0200, Tobias Getzner wrote:
This was quite painful to isolate, but I’ve now identified a minimal
configuration which should trigger this bug.
──
;; BEGIN minimal.el
(add-to-list 'load-path (expand
When mark-up such as =monospace=, /italic/, etc. is preceded by a
non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or «no-break
space» (U+00A0), org-mode will not recognize the mark-up content
correctly; i. e., this content will fail to be syntax-highlighted, and
the mark-up syntax
Hello Aaron!
On Tue, 23 Sep 2014 13:03:06 -0400, Aaron Ecay wrote:
2014ko irailak 23an, Tobias Getzner-ek idatzi zuen:
When mark-up such as =monospace=, /italic/, etc. is preceded by a
non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or
«no-break space» (U+00A0), org-mode
Hi Aaron,
On Di, 2014-09-23 at 14:15 -0400, Aaron Ecay wrote:
org-emphasis-regexp-components is known to be a wart. You can search
for posts on the mailing list. Some people are trying to figure out how
to get rid of it. (You can search in particular for Nicolas Goaziou’s
posts...) Here’s
On Di, 2014-09-23 at 14:32 -0400, Aaron Ecay wrote:
I can reproduce this.
Babel uses yes-or-no-p to confirm evaluation of the code block on export.
yes-or-no-p is implemented in C whereas y-or-n-p is in elisp, so it must
be the case that the lisp code allows some hook to run, which
Hello Nicolas,
On So, 2014-09-28 at 23:50 +0200, Nicolas Goaziou wrote:
Hello,
Tobias Getzner tobias.getz...@gmx.de writes:
When using LaTeX-based export targets that produce a .tex file as output
(export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
foo.tex
Hello,
After updating to Emacs 24.4 and org-mode 20141020, I’ve noticed that
org-indent-mode now underindents item bodies when variable-pitch-mode is
used. I. e., in the following document, «lorem», «ipsum», and «etc.» will
fall successively short of the item’s respective indent level.
* first
Headline titles may be empty, in which case the respective match group
will be nil. This would throw an error when trying to regexp-replace
checkbox cookies.
TODO: Depending on preference, a place-holder string might be a better
choice (for user-display) rather than leaving the outline-path
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Tobias Getzner <tobias.getz...@gmx.de> writes:
>
>> Headline titles may be empty, in which case the respective match group
>> will be nil. This would throw an error when trying to regexp-replace
>> che
When using the current git HEAD, I’ve noticed that my agenda has become
rather messy. This is because I’m including the outline-path in agenda
entries, and it seems that the changes following aa78158 (possibly
66fbceb?) have changed the org-get-outline-path semantics.
The documentation says that
24 matches
Mail list logo
