Carsten Dominik <carsten.domi...@gmail.com> writes: > Hi, > > Can we please first read Samuels post about extensible syntax? Before > we invent 20 other new syntaxes? > > http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10204
May I add this thread to the discussion as an example of another feature that was suggested as a possible use case for extensible syntax: http://thread.gmane.org/gmane.emacs.orgmode/24431 This is the feature I currently want most in org-mode: org mode blocks that behave exactly like org-mode blocks, except that their content in reality lies in a different file. This would allow org-mode to improve on its claim of inobtrusiveness: one could collaborate on a code project without the other people knowing you were using org-mode to manage your access points into the shared files. Also, I like the corollary, that a version control system will track the code content in separate files from the org content. A related idea is having links with both a start and an end point: following them would end up in a buffer to the specified region ("window links" if window wasn't already used for a different meaning). Any ideas welcome! (there are also ideas in that thread) Dan > Thanks! > > On Aug 10, 2010, at 8:14 AM, Christian Moe wrote: > >> Hi, >> >> >> >> >> - this would be extensible, e.g. >> >> >> >> [background[yellow] highlighted text] >> >> >> >> could export to the following html >> >> >> >> <span "style=background:yellow;">highlighted text</span> >> >> >> >> - this would avoid "{}"s >> >> >> >> - this would look more "org-like" than the pure latex solution >> >> >> >> the only issue with the above is that it may conflate a new / >> markup/ >> >> syntax with org-mode's existing /link/ syntax. >> >> >> >> Thoughts? -- Eric >> >> I'd like an extensible inline markup construct (not primarily for >> coloring). >> >> Would it make sense to hijack custom links for this purpose, and use >> existing bracketed link syntax rather than add a new syntax? >> >> For semantic tagging (my chief interest), one might e.g. define a >> class' link type and an HTML export handler to wrap the contents in >> <span class="kewyord"> tags. >> >> : [[class:animals][some text about animals]] >> >> As for color: If one is satisfied with getting colors on export, >> defining a `color' link type and appropriate export handlers will >> do. >> >> : [[color:red][some colored text]] >> >> If one also wants the text to appear in the right color within Org- >> mode, and does not want the pseudo-link markup to be underlined and >> look like links, it would require additional Org functionality (I >> think): User-defined custom faces for different link types. >> >>>>> What syntax to use... >>>> >>>> I've thought briefly about the following syntax >>>> >>>> [color[red] text to be colored red] >>> Nope, I am against this syntax. If we introduce a more general >>> syntax, >>> then it should be done in the way Samuel proposed. WHich means >>> we firs get a keyword indtroducing the piece, and then properties. >>> Like >>> $[style :color red the red text] >>> or >>> $[face :color :italic t red the red text] >>> Something like the $ before "[" also would seem critical to >>> disambiguate >>> from other uses of "[". >>> However, I am not too excited about extra syntax to get this kind >>> of thing. >>> Would not oppose it, but probably never use it. >>> - Carsten >> >> Those examples are not very readable IMO -- without a separator it's >> hard to see where the property values end and the marked up text >> begins. >> >> Yours, >> Christian > > - 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 _______________________________________________ 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
