Re: text color + highlight

[Dan Davison <davison@stats.ox.ac.uk>]

Carsten Dominik <carsten.dominik@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