emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] custom emacs org-emphasis-alist breaks EXPORT, help ;-) ?


From: Eric Abrahamsen
Subject: Re: [O] custom emacs org-emphasis-alist breaks EXPORT, help ;-) ?
Date: Sat, 02 Nov 2013 18:15:05 +0800
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)

Xebar Saram <address@hidden> writes:

> Hi again all
>
> i have been using the before discussed font lock with great success
> over the past few weeks, thx alot for that tip!
>
> one short question i have from using it thourhgly is weather its
> possible to color specific words , IE not just text bound between
> symbols ( ie > !text! ) but rather lets say i always want to make the
> word server appear with blue FG. is this possible? currently i tried 
>
> (font-lock-add-keywords
>  'org-mode
> '(("\\(server[^server\n]+server\\)" (0 '(:foreground "#000000"
> :underline t :background "#FF9AEA" :weight ultra-bold) t))))

At some point you're definitely going to want to read up on regular
expressions!

But in the meantime yes, it's entirely (mostly) possible. A regular
expression is just a way of finding desired pieces of text in a larger
run of text. Think of the regexp as an instruction that starts: "Find
all pieces of text that are..."

All the special regexp characters are just a way of making the
instruction general (_any_ number, four of _any_ character, _anything_
that's not a "p").

In the most basic case, however, a regexp is simply the text you want to
find: "Find all pieces of text that are 'server'". In this case, that's
your regexp: "server".

The reason regexps are difficult, of course, is that they can't read
your mind, and will find things you didn't want, and not find things you
did want. So much of messing with regexps is telling them: _yes_ this
too, _no_ not that. In your case, you'd probably want to put word
boundaries around the regexp ("\b" on either side), and find both
capitalized and lowercase instances of the word. So your instruction
might be:

"Find all pieces of text that are 'server' or 'Server', but only as a
complete word."

Which would look like

"\\b[Ss]erver\\b"

Give that a shot. You're jumping into the middle of something fairly
complicated, so be patient and go slow!

E

> instead of the original
>
> (font-lock-add-keywords
>  'org-mode
> '(("\\(₆[^₆\n]+₆\\)" (0 '(:foreground "#000000" :underline t
> :background "#FF9AEA" :weight ultra-bold) t))))
>
>
> again i apologize for my regrex ignorance :)
>
> best
>
> Z
>
>
>
>
> On Sun, Oct 6, 2013 at 8:04 AM, Eric Abrahamsen <
> address@hidden> wrote:
>
>     Xebar Saram <address@hidden> writes:
>    
>     > thx again Eric
>     >
>     > i still have an issue with this when one of the symbols used to
>     start
>     > /end the highlight is used in a sentence, for example using
>     your
>     > code:
>     >
>     > (font-lock-add-keywords
>     >  'org-mode
>     >  '(("-1-\\([^-1-]+\\)-1-" (0 '(:weight ultra-bold :background "
>     #
>     > DDFFDD" :foreground "#000000") t))))
>     >
>     > if i write this:
>     >
>     > -1- this is a test of 1x1 to show higlight -1-
>     >
>     > it will kill the highlight, if i use the same text omitting the
>     '1'
>     > it works well, anyway around this issue? i thought it would
>     have
>     > matcehd -1- but it seems it matches also just 1 by itself
>     >
>     > best wishes and thx again
>    
>     Yup, the things inside the [^] construct, to _not_ be matched,
>     are
>     treated as a list of single characters. So you're saying
>     "anything
>     that's not a '1' or a '-'," but then you've got a '1' in the
>     middle of
>     the line. If you want the highlighting to include any character,
>     but not
>     span newlines, you could just use [^\n] instead.
>    
>     At this point you'll probably want to read the regular expression
>     part
>     of the manual:
>    
>     (elisp) Regular Expressions
>    
>     I think you mentioned you don't have a lot of programming
>     experience.
>     That's a bit unfortunate, since regexps aren't a great place to
>     start!
>     I'd recommend getting something that's "close enough", and not
>     going
>     down the rabbit hole of perfect. Then start at the top of the
>     introduction to elisp...
>    
>     Good luck,
>     Eric
>    
>    




reply via email to

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