From: "Thomas S. Dye" <tsd@tsdye.com>
To: mail@christianmoe.com
Cc: Org Mode <emacs-orgmode@gnu.org>,
Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: Unintended behavior? Links without description
Date: Fri, 31 Dec 2010 10:09:32 -1000 [thread overview]
Message-ID: <7EE2D870-2AC8-474A-BB36-38751035BF5E@tsdye.com> (raw)
In-Reply-To: <4D19BC26.8030904@christianmoe.com>
Aloha Christian,
I explored the possibility of bisecting but found two things: 1) with
my setup I can't run versions of Org-mode earlier than approximately
7.01h because of requirements for ob.el, and 2) the current behavior
has been around at least since last summer--Org-mode version 7.01trans
(release_7.01h.209.g2c33b) yields the same results as the current git
master.
All the best,
Tom
On Dec 28, 2010, at 12:29 AM, Christian Moe wrote:
> (sorry -- hit "send" too early by mistake in the previous mail)
>
> Hi,
>
> In pre-processing for export with org-export-normalize-links, links
> that lack a description part are given one, which consists of the
> full raw path of the link. In other words, link descriptions are
> never nil. This seems to conflict with the expectations of org-
> bbdb.el and custom links based on that example.
>
> The link [[bbdb:Carsten Dominik]], for instance, is exported to html
> and latex as follows:
>
> <i>bbdb:Carsten Dominik</i>
> \textit{bbdb:Carsten Dominik}.
>
> Org-bbdb.el is clearly prepared to be passed a desc that is nil, in
> which case it would use path instead:
>
> (defun org-bbdb-export (path desc format)
> "Create the export version of a BBDB link specified by PATH or DESC.
> If exporting to either HTML or LaTeX FORMAT the link will be
> italicized, in all other cases it is left unchanged."
> (cond
> ((eq format 'html) (format "<i>%s</i>" (or desc path)))
> ((eq format 'latex) (format "\\textit{%s}" (or desc path)))
> (t (or desc path))))
>
> However, desc is never nil, because a missing description part is
> replaced in export pre-processing by a string consisting of the link
> type, a colon, and the path. This takes place in the function org-
> export-normalize-links.
>
> This makes for unexpected behavior in custom links that some of us
> have defined. E.g., Thomas S. Dye's `cite' links (the thread `org-
> add-link-type'):
>
>> (org-add-link-type
>> "citet" 'ebib
>> (lambda (path desc format)
>> (cond
>> ((eq format 'latex)
>> (if (and desc)
>> (format "\\citet[%s]{%s}" desc path)
>> (format "\\citet{%s}" path))))))
>>
>> [[citet:green84:_settl_patter_studies_ocean]]
>>
>> yields this:
>>
>> \citet[citet:green84:_settl\_patter\_studies\_ocean]
>> {green84:_settl_patter_studies_ocean}
>
> Some of my links, more closely modeled on org-bbdb.el, have similar
> problems.
>
> I haven't done the bisection thing, but I suspect this is a fairly
> recent change.
>
> I think I've tracked down the problem, but I don't necessarily
> understand what org-export-normalize-links is supposed to do or what
> other behaviors depend on this, so I'm not going to submit a patch.
> If this is now the intended behavior, it will be no problem to
> rewrite the custom link export definitions to take account of it.
>
> Yours,
> Christian
>
>
>
next prev parent reply other threads:[~2010-12-31 20:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-28 10:29 Unintended behavior? Links without description Christian Moe
2010-12-31 20:09 ` Thomas S. Dye [this message]
2011-02-12 22:11 ` Bastien
2011-02-13 12:45 ` [PATCH] " Christian Moe
2011-02-15 4:38 ` Bastien
2011-02-13 12:49 ` Christian Moe
2011-02-15 4:39 ` Bastien
-- strict thread matches above, loose matches on Subject: below --
2010-12-28 10:11 Christian Moe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7EE2D870-2AC8-474A-BB36-38751035BF5E@tsdye.com \
--to=tsd@tsdye.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@christianmoe.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).