From: Paul Sexton <psexton@xnet.co.nz>
To: emacs-orgmode@gnu.org
Subject: Re: OrgmodeWiki Support
Date: Fri, 18 Dec 2009 20:35:40 +0000 (UTC) [thread overview]
Message-ID: <loom.20091218T211305-103@post.gmane.org> (raw)
In-Reply-To: B0021057-F22D-47F7-9262-A02076A54792@gmail.com
Carsten Dominik <carsten.dominik <at> gmail.com> writes:
[snip]
>
> I think it would be useful to discuss this proposal first in a broader
> sense.
> Let me try to make a start.
>
> A few days ago, Paul Sexton submitted his proposal for simple
> file-to-file links based on etags.
>
> He wanted to make [[sometext]] be a link to <<sometext>> where
> the target definition <<sometext>> can be in a different file.
> Furthermore, his proposal uses an external program to do the
> indexing of the tags, and following the links uses the etags
> code shipped with Emacs.
>
> Finally, Paul's proposal also contains a way to automatically
> create new topics when a link is called that does not yet have
> a target.
>
> Now we are talking about WikiWords, or CamelCase links. Here the
> idea is that any such mixed-case word automatically is treated as a
> link.
> Traditionally these links to a separate file with name given by the
> link text directly. But I suppose it could also got to a <<target>>
> somewhere in a file?
>
> For a couple of reasons it seems to me that it would be useful
> to look at these proposals together. For one thing, I am not
> a huge fan of the zillions of files that will be created when using
> the one-file-per-word approach. Since Org-mode is outline based, it
> seem to make a lot of sense to have many topics per file.
>
> One way to move into this direction would be to still use etags
> to index the possible targets, and then to turn specific words
> (like CamelCase words) directly into links without the need to
> surround them with [[...]].
>
> But of course, we could also have an implementation as Adam
> proposes it, with CamelCase words linking to files, and
> then [[target]] linking to targets.
>
> Can we discuss this for a bit?
>
> - Carsten
Hi Carsten,
In the other thread, you say you have implemented a hook whose function(s) are
run when attempting to open a link. From your description it sounds like the
hook is run FIRST, and org's default behaviour only happens if the hook
functions don't override it.
However, both the link-to-file-of-same-name proposal and my etags functionality
would be more easily implemented with a hook function that is called only when
org can't find a specific target for [[plain link]]. At the moment org defaults
to performing a full-text search for "plain link". Both the wikiwords and the
etags behaviours need to happen instead of that default behaviour, but neither
needs to override the rest of org's link-opening behaviour.
Re the WikiWords idea -- this could be done in 2 independent parts:
1. Option to tell org to interpret all CamelCase words as plain links (this
might be behaviour that some people want by itself)
2. Function, called when org can't find target for plain link, that tries to
open and visit a file with the same name as the link.
I think a hook to change the default behaviour of org when it can't find an
explicit target for a plain link is a very good idea and would probably lead to
other useful stuff. Personally I don't find the default behaviour of full-text
search to be useful.
Paul
P.S. My wishlist includes using a different colour to fontify links whose
targets don't exist (a la wikipedia with its undefined links in red). Can be
done, but not sure how to do it efficiently.
next prev parent reply other threads:[~2009-12-18 20:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-06 22:23 Wiki Support Marc
2009-12-09 17:38 ` OrgmodeWiki Support Wes Hardaker
2009-12-18 11:28 ` Adam Spiers
2009-12-18 12:15 ` Carsten Dominik
2009-12-18 14:19 ` Adam Spiers
2009-12-18 15:59 ` Carsten Dominik
2009-12-18 20:35 ` Paul Sexton [this message]
2009-12-24 8:01 ` Carsten Dominik
2009-12-20 15:48 ` Darlan Cavalcante Moreira
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=loom.20091218T211305-103@post.gmane.org \
--to=psexton@xnet.co.nz \
--cc=emacs-orgmode@gnu.org \
/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).