* Wiki Support @ 2009-12-06 22:23 Marc 2009-12-09 17:38 ` OrgmodeWiki Support Wes Hardaker 0 siblings, 1 reply; 9+ messages in thread From: Marc @ 2009-12-06 22:23 UTC (permalink / raw) To: Emacs-orgmode Hi, I've seen that there is a generic export function (http://orgmode.org/worg/org-contrib/org-export-generic.php) that can be used to export org-mode to wiki style. If I got it right, this is not completly implemented (e.g. nested bullet lists are not supported). Are there plans to complete the export function? IMHO, this is a really good feature that might save a lot of time. Are there plans to do it vice versa, i.e. translate from wiki syntax to org-mode ? BR Marc ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: OrgmodeWiki Support 2009-12-06 22:23 Wiki Support Marc @ 2009-12-09 17:38 ` Wes Hardaker 2009-12-18 11:28 ` Adam Spiers 0 siblings, 1 reply; 9+ messages in thread From: Wes Hardaker @ 2009-12-09 17:38 UTC (permalink / raw) To: Marc; +Cc: Emacs-orgmode >>>>> On Sun, 6 Dec 2009 23:23:35 +0100, Marc <liste@barisch.com> said: M> If I got it right, this is not completly implemented (e.g. nested M> bullet lists are not supported). Are there plans to complete the M> export function? IMHO, this is a really good feature that might save M> a lot of time. I actually almost implemented bullet-parsing yesterday for org-export-generic, but in the end I was swamped with other things to do. So yes, I'd like to see it done. But no, it's not done currently... M> Are there plans to do it vice versa, i.e. translate from wiki syntax M> to org-mode ? That'd certainly be helpful as well. I don't know of anyone with plans though (maybes someone else does) -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: OrgmodeWiki Support 2009-12-09 17:38 ` OrgmodeWiki Support Wes Hardaker @ 2009-12-18 11:28 ` Adam Spiers 2009-12-18 12:15 ` Carsten Dominik 0 siblings, 1 reply; 9+ messages in thread From: Adam Spiers @ 2009-12-18 11:28 UTC (permalink / raw) To: emacs-orgmode On Wed, Dec 09, 2009 at 09:38:42AM -0800, Wes Hardaker wrote: > >>>>> On Sun, 6 Dec 2009 23:23:35 +0100, Marc <liste@barisch.com> said: > > M> If I got it right, this is not completly implemented (e.g. nested > M> bullet lists are not supported). Are there plans to complete the > M> export function? IMHO, this is a really good feature that might save > M> a lot of time. > > I actually almost implemented bullet-parsing yesterday for > org-export-generic, but in the end I was swamped with other things to > do. > > So yes, I'd like to see it done. But no, it's not done currently... > > M> Are there plans to do it vice versa, i.e. translate from wiki syntax > M> to org-mode ? > > That'd certainly be helpful as well. I don't know of anyone with plans > though (maybes someone else does) I would *love* to see auto-linking of WikiWords as a customisable option. I'm not sure if anyone's looked at supporting WikiWords yet. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: OrgmodeWiki Support 2009-12-18 11:28 ` Adam Spiers @ 2009-12-18 12:15 ` Carsten Dominik 2009-12-18 14:19 ` Adam Spiers 0 siblings, 1 reply; 9+ messages in thread From: Carsten Dominik @ 2009-12-18 12:15 UTC (permalink / raw) To: Adam Spiers; +Cc: emacs-orgmode On Dec 18, 2009, at 12:28 PM, Adam Spiers wrote: > On Wed, Dec 09, 2009 at 09:38:42AM -0800, Wes Hardaker wrote: >>>>>>> On Sun, 6 Dec 2009 23:23:35 +0100, Marc <liste@barisch.com> >>>>>>> said: >> >> M> If I got it right, this is not completly implemented (e.g. nested >> M> bullet lists are not supported). Are there plans to complete the >> M> export function? IMHO, this is a really good feature that might >> save >> M> a lot of time. >> >> I actually almost implemented bullet-parsing yesterday for >> org-export-generic, but in the end I was swamped with other things to >> do. >> >> So yes, I'd like to see it done. But no, it's not done currently... >> >> M> Are there plans to do it vice versa, i.e. translate from wiki >> syntax >> M> to org-mode ? >> >> That'd certainly be helpful as well. I don't know of anyone with >> plans >> though (maybes someone else does) > > I would *love* to see auto-linking of WikiWords as a customisable > option. I'm not sure if anyone's looked at supporting WikiWords yet. Where should the link go? To a file WikiWord.org? Or doing an etags search? > > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: OrgmodeWiki Support 2009-12-18 12:15 ` Carsten Dominik @ 2009-12-18 14:19 ` Adam Spiers 2009-12-18 15:59 ` Carsten Dominik 0 siblings, 1 reply; 9+ messages in thread From: Adam Spiers @ 2009-12-18 14:19 UTC (permalink / raw) To: emacs-orgmode On Fri, Dec 18, 2009 at 01:15:59PM +0100, Carsten Dominik wrote: > On Dec 18, 2009, at 12:28 PM, Adam Spiers wrote: > >I would *love* to see auto-linking of WikiWords as a customisable > >option. I'm not sure if anyone's looked at supporting WikiWords yet. > > Where should the link go? To a file WikiWord.org? Or doing an > etags search? To a file WikiWord.org would cater for the majority of my needs. Would be even cooler if you could specify a list of directories as a search path, where each directory was either absolute or relative to the current file! Maybe others could make use of an etags option too; I'm not sure. I guess you might then need a custom function to translate the WikiWord into a tag to lookup, since a lot of tags are not CamelCase. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: OrgmodeWiki Support 2009-12-18 14:19 ` Adam Spiers @ 2009-12-18 15:59 ` Carsten Dominik 2009-12-18 20:35 ` Paul Sexton 2009-12-20 15:48 ` Darlan Cavalcante Moreira 0 siblings, 2 replies; 9+ messages in thread From: Carsten Dominik @ 2009-12-18 15:59 UTC (permalink / raw) To: Adam Spiers; +Cc: emacs-orgmode On Dec 18, 2009, at 3:19 PM, Adam Spiers wrote: > On Fri, Dec 18, 2009 at 01:15:59PM +0100, Carsten Dominik wrote: >> On Dec 18, 2009, at 12:28 PM, Adam Spiers wrote: >>> I would *love* to see auto-linking of WikiWords as a customisable >>> option. I'm not sure if anyone's looked at supporting WikiWords >>> yet. >> >> Where should the link go? To a file WikiWord.org? Or doing an >> etags search? > > To a file WikiWord.org would cater for the majority of my needs. > Would be even cooler if you could specify a list of directories as a > search path, where each directory was either absolute or relative to > the current file! > > Maybe others could make use of an etags option too; I'm not sure. I > guess you might then need a custom function to translate the WikiWord > into a tag to lookup, since a lot of tags are not CamelCase. 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: OrgmodeWiki Support 2009-12-18 15:59 ` Carsten Dominik @ 2009-12-18 20:35 ` Paul Sexton 2009-12-24 8:01 ` Carsten Dominik 2009-12-20 15:48 ` Darlan Cavalcante Moreira 1 sibling, 1 reply; 9+ messages in thread From: Paul Sexton @ 2009-12-18 20:35 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: OrgmodeWiki Support 2009-12-18 20:35 ` Paul Sexton @ 2009-12-24 8:01 ` Carsten Dominik 0 siblings, 0 replies; 9+ messages in thread From: Carsten Dominik @ 2009-12-24 8:01 UTC (permalink / raw) To: Paul Sexton; +Cc: emacs-orgmode Hi Paul, On Dec 18, 2009, at 9:35 PM, Paul Sexton wrote: > 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. That is correct, because the default behavior not only searches for <<target>>, but also for plain text searches, and this may disrupt the workings of your code. Since all targets in the current file should also be in your tags file, I think they will be fond without any problem in the current file as well. So it is early enough to fall back to full text search by the time your ctags search has *not* returned a successful match. Or am I missing something here? > > 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. Well, all the normal link stuff like http: links and file: links is still does before calling the hook! > > 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. Exactly. So why does your org-ctags still need a patch? I am confused. > > 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. Indeed, this would be relatively hard to do efficiently. - but not impossible. - Carsten > > > > > > > > > > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode - Carsten ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: OrgmodeWiki Support 2009-12-18 15:59 ` Carsten Dominik 2009-12-18 20:35 ` Paul Sexton @ 2009-12-20 15:48 ` Darlan Cavalcante Moreira 1 sibling, 0 replies; 9+ messages in thread From: Darlan Cavalcante Moreira @ 2009-12-20 15:48 UTC (permalink / raw) To: Carsten Dominik; +Cc: emacs-orgmode One of the main reasons that made me move from planner to org after using planner mode for more than one year is exactly the "one file per day" approach that is used by planner. Don't get me wrong, planner-mode is very good but I think that the powerful outline capabilities of org-mode works better with my brain than several files. Today I use a remember template for notes that asks me for a title and puts the note in a notes.org file. Maybe a good approach for camel case words for org-mode could be similar to this. Suppose that camel case support is active in org-mode and the user tries to visit the link CamelCaseWord which does not exist yet. Org-mode could then create a headline in a wiki.org file like this ,---- | * CamelCaseWord | <<CamelCaseWord>> `---- and visit that file. This would allow the user to change the title if desired and the link would still be valid even from other files (using the proposed etags functionality). At last, in order to tell org-mode in which file (in this case wiki.org) and in which section the new headlines should be created the user could define a template similar to the remember templates (maybe it is even possible to use remember-mode for this with the already available functionality). - Darlan Cavalcante Moreira At Fri, 18 Dec 2009 16:59:22 +0100, Carsten Dominik <carsten.dominik@gmail.com> wrote: > > > On Dec 18, 2009, at 3:19 PM, Adam Spiers wrote: > > > On Fri, Dec 18, 2009 at 01:15:59PM +0100, Carsten Dominik wrote: > >> On Dec 18, 2009, at 12:28 PM, Adam Spiers wrote: > >>> I would *love* to see auto-linking of WikiWords as a customisable > >>> option. I'm not sure if anyone's looked at supporting WikiWords > >>> yet. > >> > >> Where should the link go? To a file WikiWord.org? Or doing an > >> etags search? > > > > To a file WikiWord.org would cater for the majority of my needs. > > Would be even cooler if you could specify a list of directories as a > > search path, where each directory was either absolute or relative to > > the current file! > > > > Maybe others could make use of an etags option too; I'm not sure. I > > guess you might then need a custom function to translate the WikiWord > > into a tag to lookup, since a lot of tags are not CamelCase. > > 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 > > > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-12-24 8:01 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2009-12-24 8:01 ` Carsten Dominik 2009-12-20 15:48 ` Darlan Cavalcante Moreira
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).