[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: text color + highlight

From: Dan Davison
Subject: [Orgmode] Re: text color + highlight
Date: Wed, 11 Aug 2010 02:48:17 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Carsten Dominik <address@hidden> 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:


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)


> 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.
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

reply via email to

[Prev in Thread] Current Thread [Next in Thread]