all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* font-lock question
@ 2004-02-09 16:18 Javier Oviedo
  2004-02-09 18:12 ` Alan Mackenzie
  0 siblings, 1 reply; 10+ messages in thread
From: Javier Oviedo @ 2004-02-09 16:18 UTC (permalink / raw)


Hello all:

This will probably sound like a rather bizarre question but here goes...

Is there a way to fontify a buffer based on a different mode but still
retain all of the original/base modes attributes(expect for the face
attributes, of course)?

Example:  I have c-file open in emacs and the buffer is using c-mode. I'd
like to use the faces for emacs-lisp-mode(this just an example, so please
humor me) but keep every other attribute of the c-mode. Can this be done? Is
there some other way I could accomplish this? Perhaps using a minor mode and
it's faces but keeping the attributes of the major mode? I'm open to any and
all suggestions.

Thanks in advance!

-- 
Javier

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: font-lock question
  2004-02-09 16:18 font-lock question Javier Oviedo
@ 2004-02-09 18:12 ` Alan Mackenzie
  2004-02-09 20:50   ` Javier Oviedo
  0 siblings, 1 reply; 10+ messages in thread
From: Alan Mackenzie @ 2004-02-09 18:12 UTC (permalink / raw)


Javier Oviedo <email_joviedo@yahoo.com> wrote on Mon, 9 Feb 2004 11:18:00
-0500:
> Hello all:

> This will probably sound like a rather bizarre question but here goes...

Bizarre indeed!

> Is there a way to fontify a buffer based on a different mode but still
> retain all of the original/base modes attributes(expect for the face
> attributes, of course)?

Yes.  The answer is _always_ yes in Emacs.  :-)

> Example:  I have c-file open in emacs and the buffer is using c-mode.
> I'd like to use the faces for emacs-lisp-mode(this just an example, so
> please humor me) but keep every other attribute of the c-mode. Can this
> be done? Is there some other way I could accomplish this? Perhaps using
> a minor mode and it's faces but keeping the attributes of the major
> mode? I'm open to any and all suggestions.

How about something like this (not tested):

(defun jo-funny-font ()
  (font-lock-mode -1)
;; The next line is taken from lisp-mode-variables in lisp-mode.el
  (setq font-lock-defaults
        '((lisp-font-lock-keywords
           lisp-font-lock-keywords-1 lisp-font-lock-keywords-2)
          nil nil (("+-*/.<>=!?$%_&~^:" . "w")) beginning-of-defun
          (font-lock-mark-block-function . mark-defun)))
  (font-lock-mode 1))
(add-hook 'c-mode-hook 'jo-funny-font)

But why do you want to do this?

> Thanks in advance!

> Javier

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: font-lock question
  2004-02-09 18:12 ` Alan Mackenzie
@ 2004-02-09 20:50   ` Javier Oviedo
  2004-02-10 13:49     ` Javier Oviedo
  2004-02-12 15:46     ` Kai Grossjohann
  0 siblings, 2 replies; 10+ messages in thread
From: Javier Oviedo @ 2004-02-09 20:50 UTC (permalink / raw)


 Hi Alex.

Actually, I implemented something very similar to this exact code. My
motivation is that the occur mode buffer does not display the matches in the
original buffers faces. I was just curious if I could hack something and
decided to implement this myself...though an obviously vicious hack(see
below). I decided to do this more for fun then anything else...I just wanted
to see if I could figure it out. (Kevin Rogers suggests that I should submit
a bug report.)

This little hack works when running occur on a emacs-lisp-mode buffer...I
was going to add highlighting using overlays next, assuming that I could
figure that out as well. :-)

(defvar joviedo-occur-font-lock-default nil)
(defadvice occur (after joviedo-occur last activate)
  (setq joviedo-occur-font-lock-default font-lock-defaults)
  (pop-to-buffer "*Occur*")
  (set (make-local-variable 'font-lock-defaults)
joviedo-occur-font-lock-default)
  (font-lock-mode nil)
  (font-lock-fontify-buffer)

;;;still need to add highlights using overlays.

  )


One issue, however, is that this does not work for a c-mode buffer. I get
some sort of strange error that I can't figure out. I thought the principle
was relatively sound but I guess not. The error in the *Message* is the
following:

Wrong type argument: stringp, nil
Error in post-command-hook: (wrong-type-argument stringp nil)

When I examine the value for font-lock-defaults(after my defadvice runs) I
see the following:

font-lock-defaults's value is
((c-font-lock-keywords c-font-lock-keywords-1 c-font-lock-keywords-2
c-font-lock-keywords-3)
 nil nil
 ((95 . "w")
  (36 . "w"))
 c-beginning-of-syntax
 (font-lock-mark-block-function . c-mark-function))


This is exactly what I get if I examine the value of font-lock-defaults
before ever running occur. For some reason, there is something wrong with
this value(list) but I can't figure it out.

Any thoughts?????? help???

-- 
Javier


"Alan Mackenzie" <none@example.invalid> wrote in message
news:thi80c.q5.ln@acm.acm...
> Javier Oviedo <email_joviedo@yahoo.com> wrote on Mon, 9 Feb 2004 11:18:00
> -0500:
> > Hello all:
>
> > This will probably sound like a rather bizarre question but here goes...
>
> Bizarre indeed!
>
> > Is there a way to fontify a buffer based on a different mode but still
> > retain all of the original/base modes attributes(expect for the face
> > attributes, of course)?
>
> Yes.  The answer is _always_ yes in Emacs.  :-)
>
> > Example:  I have c-file open in emacs and the buffer is using c-mode.
> > I'd like to use the faces for emacs-lisp-mode(this just an example, so
> > please humor me) but keep every other attribute of the c-mode. Can this
> > be done? Is there some other way I could accomplish this? Perhaps using
> > a minor mode and it's faces but keeping the attributes of the major
> > mode? I'm open to any and all suggestions.
>
> How about something like this (not tested):
>
> (defun jo-funny-font ()
>   (font-lock-mode -1)
> ;; The next line is taken from lisp-mode-variables in lisp-mode.el
>   (setq font-lock-defaults
>         '((lisp-font-lock-keywords
>            lisp-font-lock-keywords-1 lisp-font-lock-keywords-2)
>           nil nil (("+-*/.<>=!?$%_&~^:" . "w")) beginning-of-defun
>           (font-lock-mark-block-function . mark-defun)))
>   (font-lock-mode 1))
> (add-hook 'c-mode-hook 'jo-funny-font)
>
> But why do you want to do this?
>
> > Thanks in advance!
>
> > Javier
>
> -- 
> Alan Mackenzie (Munich, Germany)
> Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
> (like "aa"), remove half of them (leaving, say, "a").
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: font-lock question
  2004-02-09 20:50   ` Javier Oviedo
@ 2004-02-10 13:49     ` Javier Oviedo
  2004-02-12 15:46     ` Kai Grossjohann
  1 sibling, 0 replies; 10+ messages in thread
From: Javier Oviedo @ 2004-02-10 13:49 UTC (permalink / raw)


I meant Alan, not Alex. Sorry. :-)

-- 
Javier


"Javier Oviedo" <email_joviedo@yahoo.com> wrote in message
news:c08rqv$e5f$1@home.itg.ti.com...
> Hi Alex.
>
> Actually, I implemented something very similar to this exact code. My
> motivation is that the occur mode buffer does not display the matches in
the
> original buffers faces. I was just curious if I could hack something and
> decided to implement this myself...though an obviously vicious hack(see
> below). I decided to do this more for fun then anything else...I just
wanted
> to see if I could figure it out. (Kevin Rogers suggests that I should
submit
> a bug report.)
>
> This little hack works when running occur on a emacs-lisp-mode buffer...I
> was going to add highlighting using overlays next, assuming that I could
> figure that out as well. :-)
>
> (defvar joviedo-occur-font-lock-default nil)
> (defadvice occur (after joviedo-occur last activate)
>   (setq joviedo-occur-font-lock-default font-lock-defaults)
>   (pop-to-buffer "*Occur*")
>   (set (make-local-variable 'font-lock-defaults)
> joviedo-occur-font-lock-default)
>   (font-lock-mode nil)
>   (font-lock-fontify-buffer)
>
> ;;;still need to add highlights using overlays.
>
>   )
>
>
> One issue, however, is that this does not work for a c-mode buffer. I get
> some sort of strange error that I can't figure out. I thought the
principle
> was relatively sound but I guess not. The error in the *Message* is the
> following:
>
> Wrong type argument: stringp, nil
> Error in post-command-hook: (wrong-type-argument stringp nil)
>
> When I examine the value for font-lock-defaults(after my defadvice runs) I
> see the following:
>
> font-lock-defaults's value is
> ((c-font-lock-keywords c-font-lock-keywords-1 c-font-lock-keywords-2
> c-font-lock-keywords-3)
>  nil nil
>  ((95 . "w")
>   (36 . "w"))
>  c-beginning-of-syntax
>  (font-lock-mark-block-function . c-mark-function))
>
>
> This is exactly what I get if I examine the value of font-lock-defaults
> before ever running occur. For some reason, there is something wrong with
> this value(list) but I can't figure it out.
>
> Any thoughts?????? help???
>
> -- 
> Javier
>
>
> "Alan Mackenzie" <none@example.invalid> wrote in message
> news:thi80c.q5.ln@acm.acm...
> > Javier Oviedo <email_joviedo@yahoo.com> wrote on Mon, 9 Feb 2004
11:18:00
> > -0500:
> > > Hello all:
> >
> > > This will probably sound like a rather bizarre question but here
goes...
> >
> > Bizarre indeed!
> >
> > > Is there a way to fontify a buffer based on a different mode but still
> > > retain all of the original/base modes attributes(expect for the face
> > > attributes, of course)?
> >
> > Yes.  The answer is _always_ yes in Emacs.  :-)
> >
> > > Example:  I have c-file open in emacs and the buffer is using c-mode.
> > > I'd like to use the faces for emacs-lisp-mode(this just an example, so
> > > please humor me) but keep every other attribute of the c-mode. Can
this
> > > be done? Is there some other way I could accomplish this? Perhaps
using
> > > a minor mode and it's faces but keeping the attributes of the major
> > > mode? I'm open to any and all suggestions.
> >
> > How about something like this (not tested):
> >
> > (defun jo-funny-font ()
> >   (font-lock-mode -1)
> > ;; The next line is taken from lisp-mode-variables in lisp-mode.el
> >   (setq font-lock-defaults
> >         '((lisp-font-lock-keywords
> >            lisp-font-lock-keywords-1 lisp-font-lock-keywords-2)
> >           nil nil (("+-*/.<>=!?$%_&~^:" . "w")) beginning-of-defun
> >           (font-lock-mark-block-function . mark-defun)))
> >   (font-lock-mode 1))
> > (add-hook 'c-mode-hook 'jo-funny-font)
> >
> > But why do you want to do this?
> >
> > > Thanks in advance!
> >
> > > Javier
> >
> > -- 
> > Alan Mackenzie (Munich, Germany)
> > Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
> > (like "aa"), remove half of them (leaving, say, "a").
> >
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: font-lock question
  2004-02-09 20:50   ` Javier Oviedo
  2004-02-10 13:49     ` Javier Oviedo
@ 2004-02-12 15:46     ` Kai Grossjohann
  2004-02-12 18:47       ` Javier Oviedo
  1 sibling, 1 reply; 10+ messages in thread
From: Kai Grossjohann @ 2004-02-12 15:46 UTC (permalink / raw)


"Javier Oviedo" <email_joviedo@yahoo.com> writes:

> Actually, I implemented something very similar to this exact code. My
> motivation is that the occur mode buffer does not display the matches in the
> original buffers faces.

The solution here is to just copy the faces along with the text from
the original buffers to the occur buffer.

But don't let that stop you from the fun experiments ;-)

Kai

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: font-lock question
  2004-02-12 15:46     ` Kai Grossjohann
@ 2004-02-12 18:47       ` Javier Oviedo
  2004-02-14 18:47         ` Kai Grossjohann
  0 siblings, 1 reply; 10+ messages in thread
From: Javier Oviedo @ 2004-02-12 18:47 UTC (permalink / raw)


How do I do this?  Occur mode has already copied the line to the buffer for
me. It sounds like you are suggesting that I implement this copy myself but
I'm not sure how to override the occur copy nor how to copy the faces with
the text. Any hints...thoughts...suggestions? Thanks!

-- 
Javier


"Kai Grossjohann" <kai@emptydomain.de> wrote in message
news:87znbo9u7t.fsf@emptyhost.emptydomain.de...
> "Javier Oviedo" <email_joviedo@yahoo.com> writes:
>
> > Actually, I implemented something very similar to this exact code. My
> > motivation is that the occur mode buffer does not display the matches in
the
> > original buffers faces.
>
> The solution here is to just copy the faces along with the text from
> the original buffers to the occur buffer.
>
> But don't let that stop you from the fun experiments ;-)
>
> Kai

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: font-lock question
  2004-02-12 18:47       ` Javier Oviedo
@ 2004-02-14 18:47         ` Kai Grossjohann
  0 siblings, 0 replies; 10+ messages in thread
From: Kai Grossjohann @ 2004-02-14 18:47 UTC (permalink / raw)


"Javier Oviedo" <email_joviedo@yahoo.com> writes:

> How do I do this?

I was being obtuse.  This is not good.  Argh.  It is so easy to hide
one's own ignorance behind some mists of vagueness.

> Occur mode has already copied the line to the buffer for me. It
> sounds like you are suggesting that I implement this copy myself but
> I'm not sure how to override the occur copy nor how to copy the
> faces with the text. Any hints...thoughts...suggestions? Thanks!

"Normal" copies should preserve the text properties, I think.  So
maybe something in occur mode is overwriting them afterwards, or occur
mode uses buffer-substring-no-properties to strip them.

Or is a yank handler stripping them?  It's unlikely for yanking to
happen, though.

I *should* be looking at the source code myself :-|

Kai

^ permalink raw reply	[flat|nested] 10+ messages in thread

* font-lock question
@ 2008-07-15 12:19 Klaus Zeitler
  2008-07-24 15:11 ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Klaus Zeitler @ 2008-07-15 12:19 UTC (permalink / raw)
  To: emacs-devel

For many years I had the following statement in my .emacs file:

(defun show-tabs () "Show tabs with a slightly changed background"
  (font-lock-add-keywords nil '(("\t"  (0 'tab-face t))) t))
(add-hook 'font-lock-mode-hook 'show-tabs)

This has worked without any problems up to 22.1.
In version 22.2 and 23 I do have problems with syntax highlighting due
to these few lines above, e.g. when I try M-x list-faces-display
all colors are gone.

So here's my question. Did that only work by accident in older versions?
Maybe I have to change this code slightly for 22.2 and CVS version, but I
can't see what's wrong, when I look at the docu for font-lock-add-keywords.

Klaus

-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
Copy Protection:  A clever method of preventing incompetent pirates from
stealing software and legitimate customers from using it.




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: font-lock question
  2008-07-15 12:19 Klaus Zeitler
@ 2008-07-24 15:11 ` Stefan Monnier
  2008-07-25 13:33   ` Klaus Zeitler
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2008-07-24 15:11 UTC (permalink / raw)
  To: kzeitler; +Cc: emacs-devel

> For many years I had the following statement in my .emacs file:
> (defun show-tabs () "Show tabs with a slightly changed background"
>   (font-lock-add-keywords nil '(("\t"  (0 'tab-face t))) t))
> (add-hook 'font-lock-mode-hook 'show-tabs)

> This has worked without any problems up to 22.1.
> In version 22.2 and 23 I do have problems with syntax highlighting due
> to these few lines above, e.g. when I try M-x list-faces-display
> all colors are gone.

> So here's my question. Did that only work by accident in older versions?
> Maybe I have to change this code slightly for 22.2 and CVS version, but I
> can't see what's wrong, when I look at the docu for font-lock-add-keywords.

Yes, looks like a bug to me,


        Stefan




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: font-lock question
  2008-07-24 15:11 ` Stefan Monnier
@ 2008-07-25 13:33   ` Klaus Zeitler
  0 siblings, 0 replies; 10+ messages in thread
From: Klaus Zeitler @ 2008-07-25 13:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

>>>>> "Stefan" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
    Stefan> 
    >> So here's my question. Did that only work by accident in older versions?
    >> Maybe I have to change this code slightly for 22.2 and CVS version, but I
    >> can't see what's wrong, when I look at the docu for font-lock-add-keywords.
    Stefan> 
    Stefan> Yes, looks like a bug to me,

I'll file a bug report next week.

Klaus


-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
Never let your sense of morals prevent you from doing
what is right.         -- Salvor Hardin, "Foundation"




^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2008-07-25 13:33 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-09 16:18 font-lock question Javier Oviedo
2004-02-09 18:12 ` Alan Mackenzie
2004-02-09 20:50   ` Javier Oviedo
2004-02-10 13:49     ` Javier Oviedo
2004-02-12 15:46     ` Kai Grossjohann
2004-02-12 18:47       ` Javier Oviedo
2004-02-14 18:47         ` Kai Grossjohann
  -- strict thread matches above, loose matches on Subject: below --
2008-07-15 12:19 Klaus Zeitler
2008-07-24 15:11 ` Stefan Monnier
2008-07-25 13:33   ` Klaus Zeitler

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.