Hi Christian, Christian Moe <m...@christianmoe.com> writes:
> Hi, > > I'm sorry my point was buried in quoted text. I did read Samuel's > post. But my question was whether we couldn't *avoid inventing new > syntaxes*, by using the already existing link syntax with custom links > and export handlers (plus possibly some some new functionality to > user-customize the faces of different link types in Org-mode). > > e.g. > > : [[color:red][some text in red]] > : [[class:highlight][some highlighted text]] > > > It's already trivial to write one's own `color' and `class' custom > link types with export handlers to turn this into HTML such as: > > : <span style="color: red;">some text in red</span> > : <span class="highlight">some highlighted text</span> > Thanks for making this suggestion. This is a much better solution than creating a new syntax out of whole cloth, I should have known that Org would already have a working solution in place. Just for completeness I'm adding an example of a color handler which can be added to a users config to enable colorization of exported text to html and latex. --8<---------------cut here---------------start------------->8--- (org-add-link-type "color" nil (lambda (path desc format) (cond ((eq format 'html) (format "<span style=\"color:%s;\">%s</span>" path desc)) ((eq format 'latex) (format "{\\color{%s}%s}" path desc))))) --8<---------------cut here---------------end--------------->8--- it should be fairly straightforward to extend the above for background or class link types > > (where the latter example would be styled by CSS). > > Doing this in exported text requires *no changes* to Org-mode. It also > does not require finding one solution that fits everybody. > > If one wants Org text styled in these colors, highlights etc., I > suppose it would require changes in Org-mode: not just > user-customizable faces for different link types, as I wrote in the > previous message, but a function to define link faces on the fly from > the PATH part of the link. > I think in-buffer colorization is much less important than the export behavior. Cheers -- Eric > > > Christian > > Carsten Dominik wrote: >> 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 >> >> 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