Nicolas Goaziou writes:
>> One funny thing I observed was that the following test fails, but only
>> when run via "make test", not from e.g. my "own" Emacs or emacs -q and
>> emacs -q -nw.
>
> I don't see any failing test.
When I use something like the attached patch, "make test" goes from
passi
Hi,
Nicolas Goaziou writes:
>> When running through "make test" (org-current-level) evaluate to one
>> (before expansion) even when narrowed (should be nil).
>
> Why? `org-current-level' ignores narrowing.
Perhaps something changed recently then. In the version I was testing
with,
(with-temp-
Hello,
Rasmus writes:
> Pushed. See general comments in the other mail.
Thank you.
> One funny thing I observed was that the following test fails, but only
> when run via "make test", not from e.g. my "own" Emacs or emacs -q and
> emacs -q -nw.
I don't see any failing test.
> When running t
Hi,
Nicolas Goaziou writes:
> You can push the patch once this is fixed.
Pushed. See general comments in the other mail.
One funny thing I observed was that the following test fails, but only
when run via "make test", not from e.g. my "own" Emacs or emacs -q and
emacs -q -nw.
(should
Hi,
Nicolas Goaziou writes:
> I think you can push once the issues above are fixed. Thank you for the
> work.
Pushed!
> However, this raises a question: why are we modifying definition at all?
> We are only interested in its new label, which we can get without
> modifying buffer (i.e. if defin
Hi,
Nicolas Goaziou writes:
> Rasmus writes:
>
* Foo
[1] foo
* Bar
Baz[1]
>>>
>>> I'm not sure to understand. Would you mind elaborating?
>>
>> If I have #+INCLUDE: "example-above.org::*Bar" then point-min of the
>> include area will be pushed forward by four since the
Rasmus writes:
>>> * Foo
>>> [1] foo
>>>
>>> * Bar
>>> Baz[1]
>>
>> I'm not sure to understand. Would you mind elaborating?
>
> If I have #+INCLUDE: "example-above.org::*Bar" then point-min of the
> include area will be pushed forward by four since the definition of [1] is
> changed to fn:1-1 or
Hi,
I fixed the nitpicks, but no major changes.
Nicolas Goaziou writes:
> Pleonasm.
>
> Note that the regexp can match even if not at a footnote reference [...]:
Fair enough.
> In a thousand years, scholars might debate over the secret meaning
> behind these symbols.
Let's hope so! In the m
Thanks for the update.
Rasmus writes:
> I see. I disagree that it's more since it's directly inside a loop over
> org-footnote-re. So if we are not at a footnote-{reference,definition}
> it's probably a bug in the regexp.
Pleonasm.
Note that the regexp can match even if not at a footnote ref
Hi,
Thanks again!
Nicolas Goaziou writes:
>> I did not know markers but they seem perfect in this case. The manual
>> mentions setting markers to nil after use. I guess it's not necessary
>> here since they are in a (let ⋯)?
>
> It is. Binding between the symbol and the marker disappears with
Rasmus writes:
> Thanks for the comments. I managed to make the patch less
> complicated.
Thanks. Another round of comments follows.
> I did not know markers but they seem perfect in this case. The manual
> mentions setting markers to nil after use. I guess it's not necessary
> here since th
Rasmus writes:
> That's a nice solution. Implemented in attached patch.
Thanks. Two minor comments follow.
> Should this be added to ORG-NEWS? Is a "feature" or a "bug-fix"?
Bug-fix I'd say. There was an attempt to do it (see MINLEVEL binding),
but it was incorrect.
> +;; Add :minlevel
Hi,
Thanks for the comments. I managed to make the patch less complicated.
Nicolas Goaziou writes:
>> + (let* ((lines (and lines (split-string lines "-")))
>> + (lbeg (and lines (string-to-number (car lines
>> + (lend (and lines (string-to-number (cadr lines)
>
> T
Nicolas Goaziou writes:
> I suggest to do it differently, then. We first process every include
> keyword in the document, but simply add a text property (e.g.
> `org-include-level') over them specifying
> [...]
> Include lines are not modified and this variable only applies to Org
> documents. W
Rasmus writes:
> Thanks for the comments. I've attached a new version.
Thanks.
> Nicolas Goaziou writes:
>> This is not necessary. Even if :minlevel is used on these include
>> keywords, its value is ignored when inserting contents of the file.
>
> It's not neural to the org export buffer, t
Hi,
Thanks for the comments. I've attached a new version.
Nicolas Goaziou writes:
>> The recognition regexp is still not great, but the idea of the regexp
>> is to only act on includes where there's no :minlevel already and no
>> plain words (most obviously src and example, but any block reall
Rasmus writes:
> Here's a new version of the second patch with tests.
Thanks. Some comments follow.
> The recognition regexp is still not great, but the idea of the regexp
> is to only act on includes where there's no :minlevel already and no
> plain words (most obviously src and example, but a
Rasmus writes:
> Thanks for the notes. Hopefully patch one if good now.
Thanks. Some comments follow.
> * ox.el (org-export--prepare-file-contents): Preserve footnotes
> when using the LINES argument. New optional argument FOOTNOTES.
> (org-export-expand-include-keyword): New optional argume
Rasmus writes:
>> AFAICT, there's no reason to include a rule about whitespace separating
>> anything. Just make sure that any INCLUDE keyword that doesn't have
>> a :minlevel property gets one set to 1+N, where N is the current level
>> (or 0 if at top level).
>>
>> Another option is to delay in
Hi,
Thanks for the notes. Hopefully patch one if good now. Patch two needs
tests, but I can write those if we agree to impose minlevel automatically.
Nicolas Goaziou writes:
> AFAICT, there's no reason to include a rule about whitespace separating
> anything. Just make sure that any INCLUDE k
Hello,
Rasmus writes:
> Attached is a patch that enables footnotes in INCLUDEd documents when
> using :lines and friends. It stores the footnotes in a hash-table
> initialized in `org-export-expand-include-keyword' and updated via
> `org-export--prepare-file-contents'. The footnotes are then i
Hi,
Attached is a patch that enables footnotes in INCLUDEd documents when
using :lines and friends. It stores the footnotes in a hash-table
initialized in `org-export-expand-include-keyword' and updated via
`org-export--prepare-file-contents'. The footnotes are then inserted when
all include key
Rasmus writes:
> I'm curious about the hash table. (info "(elisp) Hash Tables") says "For
> smaller tables (a few tens of elements) alists may still be faster [than
> hash tables]".
True, but then, both a small table and a small alist are very fast.
OTOH, hash tables scale better.
> For an Org
Nicolas Goaziou writes:
> Rasmus writes:
>
>> Nicolas Goaziou writes:
>
>>> I think required definitions should be extracted from the included file
>>> and inserted at the end of the source file, without any footnote
>>> section.
>>
>> The "hard" solution. I will look into it.
>
> It may not
Rasmus writes:
> Nicolas Goaziou writes:
>> I think required definitions should be extracted from the included file
>> and inserted at the end of the source file, without any footnote
>> section.
>
> The "hard" solution. I will look into it.
It may not be that hard, but it will require tests
Nicolas Goaziou writes:
> Rasmus writes:
>
>> Clearly the current situation is not satisfactory ("You can use :lines,
>> but only if no footnotes are present. . . IOW, :lines supports a subset
>> of Org syntax.").
>>
>> I prefer converting [fn:N] references to [fn::FOOTNOTE] (see my other
>> em
Rasmus writes:
> Clearly the current situation is not satisfactory ("You can use :lines,
> but only if no footnotes are present. . . IOW, :lines supports a subset
> of Org syntax.").
>
> I prefer converting [fn:N] references to [fn::FOOTNOTE] (see my other
> email). Any obvious downsides?
Yes:
Hi,
Nicolas Goaziou writes:
> First `org-footnote-section' could be nil, in which case there is no
> headline to look after.
Sure.
> Also, there may be multiple footnote sections in the included document,
> or even some footnote definitions inside and some outside the single
> section...
Mult
Hello,
Rasmus writes:
> When using LINES in `org-export--prepare-file-contents' the footnotes
> section is not preserved causing export to fail.
>
> Minimal example
>
> $> cat t{1,2}.org
> # this is t1.org
> * intro
> foo[fn:1]
> * sec2
> bar
> * Footnotes
>
> [fn:1] baz
>
>
> # this is t2.org
>
Rasmus writes:
> The attached patch fixes this by explicitly saving the footnote section
As per usual my first patch is dodgy. It occurred to me that Org can
handle several footnote sections (that's how #+INCLUDE supports footnotes,
I guess). The attached patch how supports export of t2.org in
30 matches
Mail list logo
