Re: font-lock-defaults doesn't work??

[Tim X]

"Peter Tury" <tury.peter@gmail.com> writes:

> Hi,
>
> I am trying to create a new major mode from scratch. I found that
> syntax parsing doesn't work properly sometimes. Why? Am I missed
> something or this is a bug?
>

I suspect you have missed something. Many modes are doing what you are trying
to do and successfully, so its unlikely you have found a bug. However, it is
possible, especially since your using a devlopment code base (emacs 22)., but I
think unlikely. 

You are also re-inventing a wheel to some extent. Use define-derived-mode and
let emacs take care of some of the heavy lifting for you and build on work
already done! Also, see the example provided on the emacs wiki site.

,----[ C-h f define-derived-mode RET ]
| define-derived-mode is a Lisp macro in `derived.el'.
| (define-derived-mode CHILD PARENT NAME &optional DOCSTRING &rest BODY)
| 
| Create a new mode as a variant of an existing mode.
| 
| The arguments to this command are as follow:
| 
| CHILD:     the name of the command for the derived mode.
| PARENT:    the name of the command for the parent mode (e.g. `text-mode')
|            or nil if there is no parent.
| NAME:      a string which will appear in the status line (e.g. "Hypertext")
| DOCSTRING: an optional documentation string--if you do not supply one,
|            the function will attempt to invent something useful.
| BODY:      forms to execute just before running the
|            hooks for the new mode.  Do not use `interactive' here.
| 
| BODY can start with a bunch of keyword arguments.  The following keyword
|   arguments are currently understood:
| :group GROUP
|       Declare the customization group that corresponds to this mode.
|       The command `customize-mode' uses this.
| :syntax-table TABLE
|       Use TABLE instead of the default.
|       A nil value means to simply use the same syntax-table as the parent.
| :abbrev-table TABLE
|       Use TABLE instead of the default.
|       A nil value means to simply use the same abbrev-table as the parent.
| 
| Here is how you could define LaTeX-Thesis mode as a variant of LaTeX mode:
| 
|   (define-derived-mode LaTeX-thesis-mode LaTeX-mode "LaTeX-Thesis")
| 
| You could then make new key bindings for `LaTeX-thesis-mode-map'
| without changing regular LaTeX mode.  In this example, BODY is empty,
| and DOCSTRING is generated by default.
| 
| On a more complicated level, the following command uses `sgml-mode' as
| the parent, and then sets the variable `case-fold-search' to nil:
| 
|   (define-derived-mode article-mode sgml-mode "Article"
|     "Major mode for editing technical articles."
|     (setq case-fold-search nil))
| 
| Note that if the documentation string had been left out, it would have
| been generated automatically, with a reference to the keymap.
| 
| The new mode runs the hook constructed by the function
| `derived-mode-hook-name'.
| 
| See Info node `(elisp)Derived Modes' for more details.
| 
| [back]
`----



> Details:
>
> I have the following defun for start. If I remove the "secretly
> must-to-have parts" (see below) then M-: (syntax-ppss) returns lists
> as if it would parse a lisp buffer: characters in a line after `;'
> reported as in-comment chars, and real comments (= delimited by `/*'
> and `*/' doesn't recognized as comments. However, fontification works
> nicely -- most of the time, but not always: _sometimes_, if I put `;'
> inside a /*-comment and then delete this `;', then comment-color is
> removed... More interestingly once I got nil for the value of
> font-lock-syntax-table (queried via C-h v font-lock-syntax-table from
> the buffer where I activated this new mode via M-x t-mode
> previously)!?
>
> So it seems syntax parsing is wrong and fontification is
> indeterministic iff I set(??) font-lock-syntax-table via
> font-lock-defaults, but everything works well if I directly set it via
> set-syntax-table.
>
> Is this normal? Do you know the reason? Should I report it as a bug?
>
> (defun t-mode ()
>   "test major mode"
>   (interactive)
>
>   (kill-all-local-variables)
>   (setq major-mode (quote t-mode))
>   (setq mode-name "t-mode")
>
>   ;; secretly must-to-have parts -- start
>   (let ((t-syntax-table (make-syntax-table)))
>     (modify-syntax-entry ?/ ". 14" t-syntax-table)
>     (modify-syntax-entry ?* ". 23" t-syntax-table)
>     (set-syntax-table t-syntax-table))
>   ;; secretly must-to-have parts -- end
>
>   (set (make-local-variable 'font-lock-defaults)
>        '(nil nil t
>              ((?/ . ". 14")
>               (?* . ". 23"))))
>

from memory, I don't htink this bit is correct and you shouldn't need it. See
the example on the eamcs wiki. Comment font locking is driven by the comment
characters defined in the syntax table. You shouldn't need to also set them
explicitly in the font-lock stuff (at least, I've not needed to in the derived
modes I've been working on in the past). 


>   (run-mode-hooks 't-mode-hook))
>
> Note: emacs' help writes for font-lock-syntax-table: "this is normally
> set via `font-lock-defaults'", while elisp manual writes for
> make-syntax-table (in 35.3): "most major mode syntax tables are
> created in this way" -- however I would think that make-syntax-table
> is unusable if I set font-lock-syntax-table via font-lock-
> defaults...??
>

have a look at a fairly simple mode and see how they do the font-lock stuff. I
found sql.el quite useful (part of emacs). Again, look at the emacs wikki,
there is some really useful ifo there. I think you may be making things more
complicated than necessary. 

Tim

-- 
tcross (at) rapttech dot com dot au