Great! I'd think that shall do.
Thank you for this fast fix!
On 2016-08-23 Tue 07:44, Nicolas Goaziou wrote:
> Hello,
>
> John Kitchin writes:
>
>> I can confirm this happens. I think it happens because the abbreviation
>> is not listed in org-plain-link-re, so when the bracket link is
>> activ
Thank you for this confirmation of the abbreviation issue.
> I would suggest just defining short links ;)
Well, there are limits to this approach e.g. file+mnl {mnl = myNewLink}.
Furthermore, link definitions then tend to become pretty cryptic :-(.
Optimally, the 'org-link-abbrev-alist' could (
Thank your for taking up this quick posting.
While writing up the attached 'Exemple Complet Minimal', the
parsing turned out to work well.
Now only the :help-echo, not being triggered by an abbreviated link,
remains still an issue as demonstrated by the ECM below.
I shall consider your suggesti
On 2016-02-28 Sun 02:23, Nicolas Goaziou wrote:
> Hello,
>
> Martin Carlé writes:
>
>> Well, I wrapped the exporter mechanism into some advice functions that
>> allow for many different exports from a single file in such a manner that
>> multiple exports are not r
tags.
This is why, I need to tag the org-footnote-section as well.
Best regards,
mc
On 2016-02-27 Sat 10:16, Nicolas Goaziou wrote:
> Hello,
>
> Martin Carlé writes:
>
>> Keeping the tags is actually crucial to my practice, since I run some
>> filters during export based
ed to check for tags assigned to the
org-footnote-section and then re-create them as well?
Including this feature would be tremendously helpful and shouldn't do
harm to anybody else.
Best,
mc
On 2016-02-26 Fri 23:53, Nicolas Goaziou wrote:
> Hello,
>
> Martin Carlé writes:
>
Hello,
the outline heading containing footnote definitions (as specified by
org-footnote-section) does not accept tags.
E.g. if you add a tag to this headline and then try to insert a footnote
via the org-footnote-action command, always a new headline without the
tag is created and the former foo
On 2015-11-04 Wed 14:14, Andreas Leha wrote:
> ,---
> | > I'd say it is a bug if the results from evaluation differ between
> | > manual evaluation and during export.
> | >
> | > And even if it is not explicitely contradictin
" "DONEs")
| ))
`-------
Maybe that's the reason why it couldn't be reprod
Hello,
sections or subtrees commented with org-comment-string in the headline
should not be tangled. This works fine.
However, if a tag defined in org-todo-keywords (other than TODO or DONE)
precedes the comment (as the official syntax has it), commenting is no
longer respected such that source-b
Indirect buffers are of immense help but I had the same issue.
Can confirm that the hack referring to spec instead to the
buffer-file-name and getting the buffer-base-buffer respectively, does
the trick.
Great!
On 2015-09-04 Fri 17:49, Kyle Meyer wrote:
> Rainer M Krug writes:
>
>> Hi
>>
>> it
Hello,
guess the commit c27c101f (08/16/2015 04:14 PM) with the title "org.el: Fix
`org-comment-string' fontification" has chosen a bit too harsh 'fixation'
method:
Since then, the 'org-special-keyword' face for 'COMMENT' is not applied to
heading of lower levels any more but only to the top o
notes only relevant to author
during writing phase. (Notes in drawers are fine, but cannot be linked
up, as far as I know.)
All best,
mc
On 2015-03-26 Thu 22:09, Nicolas Goaziou wrote:
> Hello,
>
> Martin Carlé writes:
>
>> Guess it's a bug that fuzzy links won't mat
Guess it's a bug that fuzzy links won't match a commented headline
whereas the other internal link types (custom_id and org ID) do.
Or is there a special purpose for this specific type of link regarding comments?
Just check the following example:
,
It appears that by commit 69700e1 [22.04.2014 13:09] a little bug
slipped into the codebase, sinc the org-special-keyword face is only
shown at the top level in the correct face, but then gets simply
overwritten by the respective sublevel face.
I guess, this is not intented and would be nice to h
Dear Bastien,
yes, I just checked it against the master branch, and how great,
the URL of org-links stays intact now!!!
So, that's solved. Yet, there is another minor issue, as any underscore
char '_' that is contained in the link description (not the URL part)
of an org-link is swallow up and wi
It appears that the markdown export process spoils URLs that conain the
char '=' by wrongly replacing it with '%3D'.
This happens with org-links [[url][some_text]], but not with plain URLs.
I took a quick look at the defun 'org-md-link' and could see that the org-link
URLs are already spoiled whe
17 matches
Mail list logo