refontifying links

refontifying links

[John Kitchin]

Hi,

I am trying to find a nice way to change the color of some links. So far
the only solution I have found is to create a new face, and use
highlight-regexp to do it.

I would prefer to just use font-lock to change the color of the link. so
far I have not found a way to do that.

I have found the org-activate-plain-links, and org-font-lock-keywords
and the org-font-lock-hook, but so far have not figured out how to
overwrite the org-link face.

I am kind of looking for a general approach to fontifying here, but the
specific problem I want to solve is to be able to write:

[[color:Orangered1][Some text I want colored]] and have it show in my
buffer in Orangered1.

Any thoughts?


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: refontifying links

[Aaron Ecay]

Hi John,

2015ko azaroak 25an, John Kitchin-ek idatzi zuen:
> 
> Hi,
> 
> I am trying to find a nice way to change the color of some links. So far
> the only solution I have found is to create a new face, and use
> highlight-regexp to do it.
> 
> I would prefer to just use font-lock to change the color of the link. so
> far I have not found a way to do that.
> 
> I have found the org-activate-plain-links, and org-font-lock-keywords
> and the org-font-lock-hook, but so far have not figured out how to
> overwrite the org-link face.
> 
> I am kind of looking for a general approach to fontifying here, but the
> specific problem I want to solve is to be able to write:
> 
> [[color:Orangered1][Some text I want colored]] and have it show in my
> buffer in Orangered1.
> 
> Any thoughts?

Links are currently defined by an open function and an export function.
It might be interesting if org added a third function to this set, a
fontification function.

OTOH we would have to consider if links are the best place to add this
functionality.  The work you have done on org-ref and other projects
(which I greatly admire!) (ab)uses links as an analogue of HTML’s span
element: a way to encapsulate and attach attributes to a
sub-paragraph-sized chunk of text whose semantics are somewhat
amorphous.  Your example here pushes that further, using the link for
pure formatting: it no longer “links” to anything at all (and thus
probably should not have an associated open function nor be click-active
in the buffer).

I think “Spans” are something org should support, but not by co-opting
links to do it.  We ought to either make new syntax, or change the name
of “links” to “spans” and say the former are a special case of the
latter (preserving backwards compatibility of existing documents to the
extent possible of course, but also doing our best to free ourselves of
link-specific implementation details like percent-escaping).

FWIW, HTH,
Aaron

PS I think if we had spans 2-3 years ago, then you would have used them
to implement org-ref, and that code would already be in core.  I think
the same would be true of annotations, for which we’ve recently had a
well-responded thread with several code contribtions, including from you
IIRC.  On the other hand I don’t think we want org to become like Latex,
where almost all documents require a complicated web of third-party
dependencies to “work” at all.  It’s a delicate balance...

-- 
Aaron Ecay

Re: refontifying links

[John Kitchin]

>
> Links are currently defined by an open function and an export function.
> It might be interesting if org added a third function to this set, a
> fontification function.
>
> OTOH we would have to consider if links are the best place to add this
> functionality.  The work you have done on org-ref and other projects
> (which I greatly admire!) (ab)uses links as an analogue of HTML’s span
> element: a way to encapsulate and attach attributes to a
> sub-paragraph-sized chunk of text whose semantics are somewhat
> amorphous.  Your example here pushes that further, using the link for
> pure formatting: it no longer “links” to anything at all (and thus
> probably should not have an associated open function nor be click-active
> in the buffer).

Thanks! I have had a lot fun stretching the intended uses of the mighty
link ;) you might click on it to change its color, or remove the link,
maybe all red text is glossary word that you can click on to get a
definition... I think there is a lot of potential advantage in changing
the color of a link. org-ref does already, to differentiate cite, ref
and label links, but the faces are static.

> I think “Spans” are something org should support, but not by co-opting
> links to do it.  We ought to either make new syntax, or change the name
> of “links” to “spans” and say the former are a special case of the
> latter (preserving backwards compatibility of existing documents to the
> extent possible of course, but also doing our best to free ourselves of
> link-specific implementation details like percent-escaping).

Spans sounds like a generalized link syntax to me. Something like here:
http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/

In the end I am not sure it makes much difference if we call it a link
or span. I have often wanted something different than a link, but that
was "linky", and still an org-element and more like the example above.
It would make a lot of things easier, like citations, annotations,
etc...

Wait till you see the (ab)use of the new citation syntax which looks
more like a span than anything else ;)

>
> FWIW, HTH,
> Aaron
>
> PS I think if we had spans 2-3 years ago, then you would have used them
> to implement org-ref, and that code would already be in core.  I think
> the same would be true of annotations, for which we’ve recently had a
> well-responded thread with several code contribtions, including from you
> IIRC.  On the other hand I don’t think we want org to become like Latex,
> where almost all documents require a complicated web of third-party
> dependencies to “work” at all.  It’s a delicate balance...

Agreed. The documents are still plain text in the end, and readable if
you do it right.


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu