2:41 p.m.
First, why does XEmacs have its own, very different, version of font-lock?
Are our internals so incompatible that implementation of font-lock has to be
different? I'm not implying that that's not be the case; I'm simply curious
about the history over here.
My real issue is that FSF font-lock has a function called
font-lock-add-keywords that is missing from our implementation. There is a
comment in our implementation that says the following:
;;; FSF has here:
;; support for add-keywords, global-font-lock-mode and
;; font-lock-support-mode (unified support for various *-lock modes).
I'd really like to use this function and this comment does not quite do it
for me. Can anyone tell me why it's missing? Also, can anyone tell me how
to do the equivalent using XEmacs' font-lock? I'd like to (easily) add a new
C++ keyword to those that are already recognized for fontification.
Thanks!
--
Jake Colman -- XEmacs Tinkerer
3:04 p.m.
Jake Colman <jake.colman(a)xemacs.org> writes:
First, why does XEmacs have its own, very different, version of
font-lock?
This is, to me, a strange question. XEmacs has had font-lock from
*very* long ago (possibly before FSF), and until recently it was not
at all clear which version was "better". It's sort of like asking why
we have a different version of isearch or a different version of
`files.el'.
Even if we painstakingly imported the latest FSF version, who is to
guarantee that they won't change it as soon as they add another
feature to their internals? This has happened many times in the past,
and it's a losing game because their more recent version will always
be considered "latest and greatest". The "synching" process is in
fact so ardous that it's often easier to maintain a feature-by-feature
equivalent version.
Plus, synching forces us to only use the compatible API's, even where
our API's are better. Under so rigorous constraints it would be wiser
to just stop using XEmacs altogether.
I'd really like to use this function and this comment does not
quite
do it for me. Can anyone tell me why it's missing?
I assume that, so far, noone has needed it. Maybe it wouldn't be that
hard to add?
Jake Colman -- XEmacs Tinkerer
Go ahead and tinker! :-)
5:59 p.m.
>>>> "HN" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
HN> Jake Colman <jake.colman(a)xemacs.org> writes:
> First, why does XEmacs have its own, very different, version of
> font-lock?
HN> This is, to me, a strange question. XEmacs has had font-lock from
HN> *very* long ago (possibly before FSF), and until recently it was not
HN> at all clear which version was "better". It's sort of like asking
why
HN> we have a different version of isearch or a different version of
HN> `files.el'.
Ok, point taken. Thanks.
As I mention below I just realized that font-lock is actually part of core
and not done as packages. This should have made it clear to me that we need,
or want, a different (better) implementation. I assume we try to stay
feature-compatible with FSF so that anythng that they can do we can do too.
> I'd really like to use this function and this comment does
not quite
> do it for me. Can anyone tell me why it's missing?
HN> I assume that, so far, noone has needed it. Maybe it wouldn't be that
HN> hard to add?
> Jake Colman -- XEmacs Tinkerer
HN> Go ahead and tinker! :-)
Our implementarion is vastly different than FSF's. I cannot simply add the
missing function because it makes assumptions about how other functions
(i.e., font-lock-set-defaults) work. Our implementation of that function is
radically different so none of this can be simply ported from one version to
the other.
Having said all that, if I did decide to undertake the (non-trivial?) effort
to implement the font-lock-add-keywords function, what patch process would I
follow? font-lock is part of core, correct? This means that I'd have to
submit a patch to 21.5, have it approved, and then recommend it back for
21.4, correct?
--
Jake Colman -- XEmacs Tinkerer
9:10 p.m.
Jake Colman <jake.colman(a)xemacs.org> writes:
HN> Go ahead and tinker! :-)
Our implementarion is vastly different than FSF's. I cannot simply
add the missing function because it makes assumptions about how
other functions (i.e., font-lock-set-defaults) work. Our
implementation of that function is radically different so none of
this can be simply ported from one version to the other.
Well, that's why I said "tinker" rather than "copy and paste".
Having said all that, if I did decide to undertake the
(non-trivial?) effort to implement the font-lock-add-keywords
function, what patch process would I follow?
Mail the patch to xemacs-patches(a)xemacs.org. If the patch meets the
standards of quality (which I have no reason to believe it won't), it
will be accepted and applied to the CVS tree.
This means that I'd have to submit a patch to 21.5, have it
approved, and then recommend it back for 21.4, correct?
Given that it's a new feature, Vin will probably not accept it for
21.4. But you can still ask.
(Also note that there are differences between the font-lock in 21.5
and the one in 21.4.)
4:25 a.m.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
> I'd really like to use this function and this comment does
not
> quite do it for me. Can anyone tell me why it's missing?
Hrvoje> I assume that, so far, noone has needed it. Maybe it
Hrvoje> wouldn't be that hard to add?
It's a FAQ, and the people asking for it in most cases have already
taken the first couple of hacks at it and hit a wall. :-(
I had one person on the short list of people I'd like to have take a
look at the issue, but he got grabbed for national service ....
Welcome back, Hrvoje! ;-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:48 p.m.
Jake Colman wrote:
First, why does XEmacs have its own, very different, version of
font-lock?
Are our internals so incompatible that implementation of font-lock has to be
different? I'm not implying that that's not be the case; I'm simply curious
about the history over here.
My real issue is that FSF font-lock has a function called
font-lock-add-keywords that is missing from our implementation. There is a
comment in our implementation that says the following:
;;; FSF has here:
;; support for add-keywords, global-font-lock-mode and
;; font-lock-support-mode (unified support for various *-lock modes).
I'd really like to use this function and this comment does not quite do it
for me. Can anyone tell me why it's missing? Also, can anyone tell me how
to do the equivalent using XEmacs' font-lock? I'd like to (easily) add a new
C++ keyword to those that are already recognized for fontification.
Thanks!
Here is what you can try:
(defun my-c++-mode ()
(setq c++-font-lock-keywords
(append c++-font-lock-keywords
(list '(**ADD KEYWORD REGEX AS STRING HERE** **ADD AN INT HERE** **ADD
FONTLOCK FACE NAME HERE** t)))))
(add-hook 'c++-mode-hook 'my-c++-mode)
10:04 p.m.
>>>> "BS" == Bryan Shell
<bshell(a)civicnet.net> writes:
BS> Jake Colman wrote:
> First, why does XEmacs have its own, very different, version of
font-lock?
> Are our internals so incompatible that implementation of font-lock has to be
> different? I'm not implying that that's not be the case; I'm simply
curious
> about the history over here.
> My real issue is that FSF font-lock has a function called
> font-lock-add-keywords that is missing from our implementation. There is a
> comment in our implementation that says the following:
> ;;; FSF has here:
> ;; support for add-keywords, global-font-lock-mode and
> ;; font-lock-support-mode (unified support for various *-lock modes).
> I'd really like to use this function and this comment does not quite do it
> for me. Can anyone tell me why it's missing? Also, can anyone tell me how
> to do the equivalent using XEmacs' font-lock? I'd like to (easily) add a
new
> C++ keyword to those that are already recognized for fontification.
> Thanks!
>
BS> Here is what you can try:
BS> (defun my-c++-mode ()
BS> (setq c++-font-lock-keywords
BS> (append c++-font-lock-keywords
BS> (list '(**ADD KEYWORD REGEX AS STRING HERE** **ADD AN INT
BS> HERE** **ADD FONTLOCK FACE NAME HERE** t)))))
BS> (add-hook 'c++-mode-hook 'my-c++-mode)
Bryan,
I tried this:
(setq c++-font-lock-keywords
(append c++-font-lock-keywords
(list '(".*foreach.*" 1 font-lock-keyword-face t))))
but to no avail. I did check that in the c++-mode buffer, the
c++-font-lock-keywords variable has my setting but it still did not fontify.
Am I supposed to specify the regexp for my new keyword differently somehow?
Also, what is the final 't' used for in the list?
Thanks!
--
Jake Colman -- XEmacs Tinkerer
10:20 p.m.
>>>> "Jake" == Jake Colman
<jake.colman(a)xemacs.org> writes:
Jake> Bryan,
Jake> I tried this:
Jake> (setq c++-font-lock-keywords
Jake> (append c++-font-lock-keywords
Jake> (list '(".*foreach.*" 1 font-lock-keyword-face t))))
Jake> but to no avail. I did check that in the c++-mode buffer,
Jake> the c++-font-lock-keywords variable has my setting but it
Jake> still did not fontify. Am I supposed to specify the regexp
Jake> for my new keyword differently somehow? Also, what is the
Jake> final 't' used for in the list?
Hello Jake, see
`font-lock-keywords' (buffer: *Hyper Apropos*, mode: Hyper-Apropos)
The t you refer to is the OVERRIDE argument in above documentation:
FONT-LOCK-FORM :== MATCHER
| (MATCHER . MATCH)
| (MATCHER . FACE-FORM)
| (MATCHER . HIGHLIGHT)
| (MATCHER HIGHLIGHT ...)
| (eval . FORM)
MATCH-HIGHLIGHT :== (MATCH FACE-FORM OVERRIDE LAXMATCH)
OVERRIDE :== t - overwrite existing fontification
| 'keep - only parts not already fontified are
highlighted.
| 'prepend - merge faces, this fontification has
precedence over existing
| 'append - merge faces, existing fontification has
precedence over
this face.
Hope this helps,
Adrian
Jake> Thanks!
Jake> --
Jake> Jake Colman -- XEmacs Tinkerer
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
2:10 a.m.
On Tue, 18 Nov 2003, Jake Colman wrote:
BS> Here is what you can try:
BS> (defun my-c++-mode ()
BS> (setq c++-font-lock-keywords
BS> (append c++-font-lock-keywords
BS> (list '(**ADD KEYWORD REGEX AS STRING HERE** **ADD AN INT
BS> HERE** **ADD FONTLOCK FACE NAME HERE** t)))))
BS> (add-hook 'c++-mode-hook 'my-c++-mode)
Bryan,
I tried this:
(setq c++-font-lock-keywords
(append c++-font-lock-keywords
(list '(".*foreach.*" 1 font-lock-keyword-face t))))
You prompted me to fix my .el files, to not use the
font-lock-add-buffer-keywords I had aquired on the emacs wiki site,
I think I *might* have just found out what you are doing wrong:
Where you by chance getting a "fontifying blah.c... aborted.aborted."
message in the modeline?
Try putting brackets around the (1 font-lock-keyword-face t) list.
So I have now in one of mine:
(setq font-lock-keywords
(append font-lock-keywords
(list
'("\\<\\(d?a?\\(cos\\|sin\\|tan\\|tan\\|tan2\\)\\(deg\\)?\\|d?\\(sqrt\\|sqr\\|exp\\|abs\\|int\\|nint\\|min\\|max\\|sign\\|log\\|log10\\)\\)h?\\>"
(0 font-lock-math-face append)))))
)
Personally, I found the hyper-apropros font-lock-keywords documentation
not the easiest to understand :)
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
There are running jobs. Why don't you go chase them?
4:56 p.m.
>>>> "TC" == Tim Connors
<tconnors(a)astro.swin.edu.au> writes:
> I tried this:
>
> (setq c++-font-lock-keywords
> (append c++-font-lock-keywords
> (list '(".*foreach.*" 1 font-lock-keyword-face t))))
>
TC> Where you by chance getting a "fontifying blah.c... aborted.aborted."
TC> message in the modeline?
No. I get no error messages. The new kywork simply does not fontify.
TC> Try putting brackets around the (1 font-lock-keyword-face t) list.
TC> So I have now in one of mine:
TC> (setq font-lock-keywords
TC> (append font-lock-keywords
TC> (list
TC>
'("\\<\\(d?a?\\(cos\\|sin\\|tan\\|tan\\|tan2\\)\\(deg\\)?\\|d?\\(sqrt\\|sqr\\|exp\\|abs\\|int\\|nint\\|min\\|max\\|sign\\|log\\|log10\\)\\)h?\\>"
TC> (0 font-lock-math-face append)))))
TC> )
Looking again at how existing keywords (e.g., 'for', 'while') I tried the
following:
(setq c++-font-lock-keywords
(append c++-font-lock-keywords
(list '("\\<foreach\\>\\([^a-zA-Z0-9_$]\\|$\\)" 1
font-lock-keyword-face t))))
This still does not work.
--
Jake Colman -- XEmacs Tinkerer
4:54 p.m.
>>>> "Jake" == Jake Colman
<jake.colman(a)xemacs.org> writes:
Hi Jake,
this works for me:
(add-hook 'font-lock-mode-hook
'(lambda ()
(cond ((eq major-mode 'python-mode)
(set (make-local-variable 'font-lock-keywords)
python-font-lock-keywords))
((eq major-mode 'c++-mode)
(set (make-local-variable 'font-lock-keywords)
(append c++-font-lock-keywords
'(("\\<\\(foreach\\)\\>" (1 font-lock-keyword-face t)))))))))
I guess appending to c++-font-lock-keywords requires some
reinitialization for it to update 'font-lock-keywords in c++-mode.
I haven't spend the time to find that out, but the above seems to work
just as well.
Hope this helps,
Adrian
>>>> "TC" == Tim Connors
<tconnors(a)astro.swin.edu.au> writes:
>> I tried this:
>>
>> (setq c++-font-lock-keywords
>> (append c++-font-lock-keywords
>> (list '(".*foreach.*" 1 font-lock-keyword-face t))))
>>
TC> Where you by chance getting a "fontifying blah.c...
aborted.aborted."
TC> message in the modeline?
Jake> No. I get no error messages. The new kywork simply does not fontify.
TC> Try putting brackets around the (1 font-lock-keyword-face t) list.
TC> So I have now in one of mine:
TC> (setq font-lock-keywords
TC> (append font-lock-keywords
TC> (list
TC>
'("\\<\\(d?a?\\(cos\\|sin\\|tan\\|tan\\|tan2\\)\\(deg\\)?\\|d?\\(sqrt\\|sqr\\|exp\\|abs\\|int\\|nint\\|min\\|max\\|sign\\|log\\|log10\\)\\)h?\\>"
TC> (0 font-lock-math-face append)))))
TC> )
Jake> Looking again at how existing keywords (e.g., 'for', 'while')
I tried the
Jake> following:
Jake> (setq c++-font-lock-keywords
Jake> (append c++-font-lock-keywords
Jake> (list '("\\<foreach\\>\\([^a-zA-Z0-9_$]\\|$\\)" 1
font-lock-keyword-face t))))
Jake> This still does not work.
Jake> --
Jake> Jake Colman -- XEmacs Tinkerer
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
4:14 p.m.
>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
APA> this works for me:
APA> (add-hook 'font-lock-mode-hook
APA> '(lambda ()
APA> (cond ((eq major-mode 'python-mode)
APA> (set (make-local-variable 'font-lock-keywords)
APA> python-font-lock-keywords))
APA> ((eq major-mode 'c++-mode)
APA> (set (make-local-variable 'font-lock-keywords)
APA> (append c++-font-lock-keywords
APA> '(("\\<\\(foreach\\)\\>" (1 font-lock-keyword-face
t)))))))))
APA> I guess appending to c++-font-lock-keywords requires some
APA> reinitialization for it to update 'font-lock-keywords in c++-mode.
APA> I haven't spend the time to find that out, but the above seems to work
APA> just as well.
APA> Hope this helps,
Yup, it does! Thanks. If you ever do figure out why it has to be done this
way and not in a cc-mode hook, it would be great to know. Thanks again!
--
Jake Colman -- XEmacs Tinkerer
7469
days inactive
7475
days old
11 comments
6 participants
participants (6)
-
Adrian Aichner -
Bryan Shell -
Hrvoje Niksic -
Jake Colman -
Stephen J. Turnbull -
Tim Connors