Re: [O] new link parameters and link abbreviations

[Martin Carlé]

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
>> activated, no type is ever defined (it is done by a group in the
>> org-plain-link-re). The type is somewhat fundamental to the activation
>> function, as it is used to look up all the link properties, and hence
>> you get the default help (and all other properties too).
>>
>> I haven't thought of a simple fix though. It would involve adding the
>> abbreviations to the known link types, and some kind of lookup for when
>> the type in a link is not in org-link-parameters that resolves the type
>> to something in org-link-parameters. Since the abbreviations seem to
>> have quite flexible format, it isn't obvious how to do that robustly,
>> without changing the abbreviation syntax.
>
> I pushed a simple fix as 112463cbffb8bec7ec318c27d3b862e9ddcf76f3 that
> avoids extending `org-plain-link-re'. Link abbreviation is limited to
> bracket links whereas `org-link-parameters' helps defining plain links.
>
> Let me know if it isn't a sufficient solution.
>
>
> Regards,


-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] new link parameters and link abbreviations

[Martin Carlé]

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 (optionally) even been made
buffer-local, in order to safe typing efforts in different work context.

I wouldn't mind changing the abbreviation syntax, if necessary.

> It seems like you can probably build the abbreviation functionality into the 
> follow function
> right?

Don't really get what you mean by this.


On 2016-08-23 Tue 01:03, John Kitchin wrote:

> 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
> activated, no type is ever defined (it is done by a group in the
> org-plain-link-re). The type is somewhat fundamental to the activation
> function, as it is used to look up all the link properties, and hence
> you get the default help (and all other properties too).
>
> I haven't thought of a simple fix though. It would involve adding the
> abbreviations to the known link types, and some kind of lookup for when
> the type in a link is not in org-link-parameters that resolves the type
> to something in org-link-parameters. Since the abbreviations seem to
> have quite flexible format, it isn't obvious how to do that robustly,
> without changing the abbreviation syntax. 
>
> I would suggest just defining short links ;) It seems like you can
> probably build the abbreviation functionality into the follow function
> right?
>
>
> mc writes:
>
>> Yes, with pleasure:
>>
>> Let's put it the most simple way:
>>
>>
>> 1. Here is my new-link definition:
>>
>> #+begin_src emacs-lisp
>>   (org-link-set-parameters "new-link" :help-echo "show new-link's help echo")
>> #+end_src
>>
>> (it doesn't change matter, if there would be :follow or :store function etc.)
>>
>>
>> 2. the 'tooltip' shows my :help-echo string as expected.
>>
>> [[new-link:awesome]]
>>
>>
>> 3. Then I add the following abbreviation of the above link:
>>
>> #+begin_src emacs-lisp
>>   (setq org-link-abbrev-alist '(("nl" . "new-link::%s")))
>> #+end_src
>>
>>
>> 4. the 'tooltip' does not work but shows the default:
>>
>> [[nl:awesome]]
>>
>>
>> Hope that clarifies the issue.
>>
>>
>> Thanks once more for your sustained patience making link handling much
>> easier and more powerful!
>> mc
>>
>>
>>
>>> On 20 Aug 2016, at 17:17, John Kitchin  wrote:
>>> 
>>> that isn't a feature I have used too often. Could you post a small example 
>>> that illustrates the problem? Thanks,
>>> 
>>> John
>>> 
>>> ---
>>> Professor John Kitchin 
>>> Doherty Hall A207F
>>> Department of Chemical Engineering
>>> Carnegie Mellon University
>>> Pittsburgh, PA 15213
>>> 412-268-7803
>>> @johnkitchin
>>> http://kitchingroup.cheme.cmu.edu 
>>> 
>>> 
>>> On Fri, Aug 19, 2016 at 12:13 AM, mc >> > wrote:
>>> The new link parameters are fabulous!
>>> 
>>> Only the parameter ':help-echo' seems not to be respected, if a link is 
>>> used by an abbreviated form as defined by the 'org-link-abbrev-alist'.
>>> 
>>> Would be nice, if this could be fixed.
>>> 
>>> Anyway, thank you for this big step forward,
>>> mc
>>> 


-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] abbreviations of link-type "file"

[Martin Carlé]

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 suggestion. However, I like the application-link
feature for its convenience not being forced to duplicate quite some
code in the :follow and :store functions.

Best,
mc


Demonstrate parsing of an abbreviated link:


Define the link
#+begin_src emacs-lisp
  (org-link-set-parameters "file+my-lengthy-application-link"
 :help-echo "help-echo not showing, if mouse is on abbreviated link!")
#+end_src

#+RESULTS:


Set some abbreviations
#+begin_src emacs-lisp
  (setq org-link-abbrev-alist
'(
  ("_" . "file+my-lengthy-application-link:::%s")
  ("__" . "file+my-lengthy-application-link:%s")
  ))
#+end_src

#+RESULTS:
: ((_ . file+my-lengthy-application-link:::%s) (__ . file+my-lengthy-application-link:%s))



* in-buffer links


the plain link: [[file+my-lengthy-application-link:::goto_in_buffer_target]]

=check :help-echo by mouse roll-over=

the abbreviated link: [[_:goto_in_buffer_target]]



* links with a relative path

to ~./someFile.org~


the plain link: [[file+my-lengthy-application-link:./someFile.org::goto_target]]

=check :help-echo by mouse roll-over=

the abbreviated link: [[__:./someFile.org::goto_target]]



* goto_in_buffer_target
a link target


* parse the links in this buffer
#+begin_src emacs-lisp :results verbatim
  (org-element-map (org-element-parse-buffer) 'link
(lambda (el)
  ;; (message "link: %s" (org-element-type el))
  (let* ((link (org-element-context el))
 (path (org-link-unescape (org-element-property :path link)))
 (option (org-element-property :search-option link)))
 (message "path: %s \noption: %s \n\n" path option)
 )))
#+end_src

#+RESULTS:
#+begin_example
("path:
option: goto_in_buffer_target

" "path:
option: goto_in_buffer_target

" "path: ./someFile.org
option: goto_target

" "path: ./someFile.org
option: goto_target

")
#+end_example
* goto_target
another link target


On 2016-08-21 Sun 09:32, Nicolas Goaziou wrote:

> Hello,
>
> mc  writes:
>
>> As we talk about link abbreviations, another issue might add some useful 
>> information:
>>
>> links of link-type "file" (e.g. "file+new-link"), if follow via an
>> abbreviation, is not parsed correctly:
>
> I suggest to avoid using so called "application" links, i.e.,
> type+application syntax as it may be ditched at some point. You can
> define a new link type instead, e.g., "newlink" or "applink".
>
> In any case, could you provide an ECM?
>
> Thank you.
>
> Regards,


-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] [bug] inserting footnotes via org-footnote-action command

[Martin Carlé]

On 2016-02-28 Sun 02:23, Nicolas Goaziou wrote:

> Hello,
>
> Martin Carlé <m...@aiguphonie.com> 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 restricted to subtrees.
>
> Not sure to understand this.

Never mind, I shall explain and release all the hack, if there is more time.

>
>> This extended export mechanism collects sections as marked by tags.
>> This is why, I need to tag the org-footnote-section as well.
>
> Why don't you also collect systematically the footnote section?

Because, tags are a general and convenient way of collecting sections
and I'like to avoid special where ever possible.


All in all, below are the tiny changes I was looking for,
marked in comments as 'hack'.


All best,
mc


  > ,
  > |   

  > | (defun org-footnote--clear-footnote-section ()

  > |   "Remove all footnote sections in buffer and create a new one.   

  > | New section is created at the end of the buffer, 
before any file  
  > | local variable definition.  Leave point within the 
new section."  
  > |   (when org-footnote-section  

  > | (goto-char (point-min))   

  > | (let ((regexp 

  > |(format org-complex-heading-regexp-format ;; "^\\*+ +%s[ 
\t]*$"
  > |(regexp-quote org-footnote-section)))  

  > |   tags) ;;; hack  

  > |   (while (re-search-forward regexp nil t) 

  > |   

  > | ;; ;;; hack   

  > | (save-match-data  

  > |   (save-excursion 

  > | (beginning-of-line 1) 

  > | (looking-at org-todo-line-tags-regexp)

  > | (when (match-beginning 4) 

  > |   (setq tags (concat " " (buffer-substring (match-beginning 
4) (match-end 4)))
  > |   

  > | (delete-region

  > |  (match-beginning 0)  

  > |  (progn (org-end-of-subtree t t)  

  > | (if (not (eobp)) (point)  

  > |   (org-footnote--goto-local-insertion-point)  

  > |   (skip-chars-forward " \t\n")

  > |   (if (eobp) (point) (line-beginning-position))   

  > |   (goto-char (point-max)) 

  > |   (org-footnote--goto-local-insertion-point)  

  > |   (when (and (cdr (assq 'heading org-blank-before-new-entry)) 

  > |  (zerop (save-excursion (org-back-over-empty-lines

  > | (insert "\n"))

  > |   ;; (insert "* " org-footnote-section "\n")  

  > |   (insert "* " org-footnote-section (or tags "") "\n") ;;; hack — the 
simple way  
  > | (when tags
   

Re: [O] [bug] inserting footnotes via org-footnote-action command

[Martin Carlé]

Thanks for inviting me to elaborate.

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 restricted to subtrees.

This extended export mechanism collects sections as marked by 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é <m...@aiguphonie.com> writes:
>
>> Keeping the tags is actually crucial to my practice, since I run some
>> filters during export based on tags.
>>
>> Couldn't the algorithm be adopted to check for tags assigned to the
>> org-footnote-section and then re-create them as well?
>
> Footnote section is special, so, in a sense, is a tag on its own.
> Besides, export process completely ignores this section. So, I'm not
> sure about what you want to achieve with tagging it. Would you want to
> elaborate a bit?
>
>
> Regards,


-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] [bug] inserting footnotes via org-footnote-action command

[Martin Carlé]

Thank you for the quick answer!

All right, deletion and recreation of the section is fine with me, as
long as the tags would be recreated as well.

Keeping the tags is actually crucial to my practice, since I run some
filters during export based on tags.

Couldn't the algorithm be adopted 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é <m...@aiguphonie.com> writes:
>
>> 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 footnote order gets spoiled.
>>
>> I would be nice, if this could be fixed, such that org-footnote-section
>> can have tags (or even to-do keywords, drawers, etc.).
>
> You shouldn't put anything else than footnotes in the footnotes section.
> It can be erased without notice, e.g., when sorting footnotes, and all
> information inside, besides footnotes, will be lost.
>
> See it as a reserved (optional) headline. Maybe the manual should be
> more explicit about it.
>
>
> Regards,


-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

[O] [bug] inserting footnotes via org-footnote-action command

[Martin Carlé]

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 footnote order gets spoiled.

I would be nice, if this could be fixed, such that org-footnote-section
can have tags (or even to-do keywords, drawers, etc.).

Thank you,
mc

-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] Org Babel resolution of `:var` value reference inconsistent

[Martin Carlé]

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 contradicting the manual [1] (which
> | > does not say anything about finding references), I'd prefer if
> | > references in COMMENT'ed sections are not found -- neither during export
> | > nor during evaluation.  This would be more inline with my intuition of
> | > COMMENT is equivalent to # (which is also suggested by the fact that
> | > COMMENT is described in the section on #).
> `---

I'd like to strongly support this view.

Regards,
mc

-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

[O] [BUG] COMMENT-ed sections are tangled, if preceded by an org-todo keyword

[Martin Carlé]

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-blocks in the section/subtree are tangled.

I think this cannot be intentional and is probably a bug.

Best regards,
mc


For example:

* TODO COMMENT this headline should not be tangled
#+begin_src emacs-lisp 
  (message "I am COMMENT-ed and thus I am not tangled - OK")
#+end_src

* WATCH COMMENT this headline should not be tangled
#+begin_src emacs-lisp 
  (message "I am COMMENT-ed but a I still tangled - FALSE")
#+end_src


-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] [BUG] COMMENT-ed sections are tangled, if preceded by an org-todo keyword

[Martin Carlé]

Thank you for looking into that issue!

I trace the git repo of org-mode (current commit is 50a18201).

My todo-keywords are not defined file-local but during emacs startup like this:


,---
| (setq org-todo-keywords
| '((sequence "TODO(t)" "|" "DONE(d)")
|   (sequence "DOIT(i!)" "FEEDBACK(e@/!)" "LINGER(l@/!)" "VERIFY(v!)" 
"|" "OVER(o!)" "DELEGATED(g@/!)")
|   (sequence "BUG(b!)" "ASK(a)" "REPORT(r)" "KNOWNCAUSE(k!)" 
"WATCH(w!)" "|" "STRANGE(s!)"  "FIXED(f@/!)") 
|   (sequence "|" "CANCELED(c@)")  
|   (sequence "THINKof(T)" "CHECK(K)" "OPTIMIZE(O)" "CONTINUE(C)" 
"REPEAT(R)" "MAYBE(M)" "|" "PERFECTED(P)")
|   (sequence "TODOs" "|" "DONEs") 
|   ))  
`-------

Maybe that's the reason why it couldn't be reproduced.
Or do I missed something while setting the var "org-todo-keywords"?

Best regards,
mc


On 2015-10-12T00:39:41+0300, spake thus:
> Hello,

> Martin Carlé <m...@aiguphonie.com> writes:

> > 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-blocks in the section/subtree are tangled.
> >
> > I think this cannot be intentional and is probably a bug.
> >
> > Best regards,
> > mc
> >
> >
> > For example:
> >
> > * TODO COMMENT this headline should not be tangled
> > #+begin_src emacs-lisp 
> >   (message "I am COMMENT-ed and thus I am not tangled - OK")
> > #+end_src
> >
> > * WATCH COMMENT this headline should not be tangled
> > #+begin_src emacs-lisp 
> >   (message "I am COMMENT-ed but a I still tangled - FALSE")
> > #+end_src

> I cannot reproduce the problem. Did you properly activate new TODO
> keyword, e.g., using C-c C-c on the #+TODO: WATCH line?

> Also, what is Org's version ?


> Regards,

> -- 
> Nicolas Goaziou


-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] Tangling from indirect buffer

[Martin Carlé]

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 seems that tangling from an indirect buffer does not work. Is this by
>> design or a bug?
>
> I don't think that's by design.
>
>> Would it be possible to make this possible?
>
> Does the below patch work for you?  If so, I can test it more thoroughly
> and send a proper patch.

-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

[O] org-comment-string fontification stopped working in sublevel headlines

[Martin Carlé]

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 one.

The minimal example below also demonstrates another possibly unintended 
fontification.
Bold and italic faces (or the other options of 
http://orgmode.org/org.html#Emphasis-and-monospace) are extended across lists 
which they probably should not.

The two issues, however, seem not directly related and I do not know when the 
second one was introduced.

,---
| * COMMENT Level 1 
| ** COMMENT Level 2
| *** TODO COMMENT Level 3  
| 1) load all *.el files
| 2) tangle all org-* files 
| * TODO COMMENT Level 4
| 1) load all /*.el files   
| 2) tangle all org-*/ files
`---

Best,
mc

-- 
Fetch my gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] [bug] fuzzy link not matching commented headlines

[Martin Carlé]

Great, thanks for the quick fix!

Well, besides exports there is also tangling. Still, thanks for the
warning. I am aware of the exports 'issue' but turned it into a feature
while automatically removing unresolvable internal links. As a result,
we get a nice private comment system for 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é m...@aiguphonie.com writes:

 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:

 ,--
 | * First headline   
   
 | 1. fuzzy link to [[Second headline]] -- ok 
   
 | 2. fuzzy link to commented [[Third headline]] -- fails 
   
 |
   
 | 3. custom_id link to commented [[#Fourth][Fourth headline]] -- ok  
   
 | 4. id link to commented [[id:D91E1EF3-2918-4F37-98EB-E2C92ACBE372][Fifth 
 headline]] -- ok
 |
   
 | * Second headline  
   
 |
   
 | * COMMENT Third headline   
   
 |
   
 | * COMMENT Fourth headline  
   
 | :PROPERTIES:   
   
 | :CUSTOM_ID: Fourth 
   
 | :END:  
   
 |
   
 | * Fifth headline   
   
 | :PROPERTIES:   
   
 | :ID:   D91E1EF3-2918-4F37-98EB-E2C92ACBE372
   
 | :END:  
   
 |
   
 `--

 Thank you. This should be fixed in
 22f732c2553cc8ab42e8465018042bf0f49b6f4f.

 However, this kind of link is sort of pointless, since it is bound to
 fail during export, as the targeted headline will be removed. As
 a consequence, this document cannot be exported, even though COMMENT
 keyword is only meaningful during export.


 Regards,

-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

[O] [bug] fuzzy link not matching commented headlines

[Martin Carlé]

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:

,--
| * First headline  
   
| 1. fuzzy link to [[Second headline]] -- ok
   
| 2. fuzzy link to commented [[Third headline]] -- fails
   
|   
   
| 3. custom_id link to commented [[#Fourth][Fourth headline]] -- ok 
   
| 4. id link to commented [[id:D91E1EF3-2918-4F37-98EB-E2C92ACBE372][Fifth 
headline]] -- ok
|   
   
| * Second headline 
   
|   
   
| * COMMENT Third headline  
   
|   
   
| * COMMENT Fourth headline 
   
| :PROPERTIES:  
   
| :CUSTOM_ID: Fourth
   
| :END: 
   
|   
   
| * Fifth headline  
   
| :PROPERTIES:  
   
| :ID:   D91E1EF3-2918-4F37-98EB-E2C92ACBE372   
   
| :END: 
   
|   
   
`--

-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F


smime.p7s
Description: S/MIME cryptographic signature

[O] org-special-keyword face not showing in sublevels anymore since commit 69700e1

[Martin Carlé]

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 have it fixed.

best,
mc

-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F



smime.p7s
Description: S/MIME cryptographic signature

Re: [O] [bug] [new exporter] [markdown] spoiled URL containing '=' if using http/s org-links

[Martin Carlé]

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 will not appear on the markdown side.


Moreover, seeing all these nice bug fixes that led to today's release,
let me come back to older and maybe somehow forgotten feature request:

http://lists.gnu.org/archive/html/emacs-orgmode/2010-03/msg00379.html

Can't we make these kind of intrusive target-markups-brackets been
hidden, at least optionally, and instead be fontified just similar as link are?
Or could there be posted some hint how to best hack this as a private solution?


Thank you and the list for answering,
mc

On 2014-06-13 Fri 13:43, Bastien b...@gnu.org wrote:
 Hi Martin,

 can you try Org latest version from git and says if this still happen?

 Thanks,

-- 
Fetch my gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 7E3CA33F



smime.p7s
Description: S/MIME cryptographic signature