font-lock-beginning-of-syntax-function semi-obsolete?

font-lock-beginning-of-syntax-function semi-obsolete?

[Lute Kamstra]

I'm updating lispref/modex.texi and noticed that the docstring of
font-lock-beginning-of-syntax-function says that it is semi-obsolete:

  *Non-nil means use this function to move back outside all constructs.
  When called with no args it should move point backward to a place which
  is not in a string or comment and not within any bracket-pairs (or else,
  a place such that any bracket-pairs outside it can be ignored for Emacs
  syntax analysis and fontification).

  If this is nil, the beginning of the buffer is used, which is
  always correct but tends to be slow.
  This is normally set via `font-lock-defaults'.
  This variable is semi-obsolete; we recommend setting
  `syntax-begin-function' instead.

So, how do you make Font Lock use the function in the variable
syntax-begin-function to move to top level?

Lute.

Re: font-lock-beginning-of-syntax-function semi-obsolete?

[Stefan Monnier]

> So, how do you make Font Lock use the function in the variable
> syntax-begin-function to move to top level?

I don't understand the question.  What have you tried?


        Stefan

Re: font-lock-beginning-of-syntax-function semi-obsolete?

[Lute Kamstra]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So, how do you make Font Lock use the function in the variable
>> syntax-begin-function to move to top level?
>
> I don't understand the question.  What have you tried?

>From what I understand, font-lock-beginning-of-syntax-function is
initialized from font-lock-defaults.  You can either specify nil or a
function name.  If you specify nil, Font Lock uses the beginning of
the buffer.  If you specify a function, Font Lock uses that function.
How do you make Font Lock use the function in the variable
syntax-begin-function?

Lute.

Re: font-lock-beginning-of-syntax-function semi-obsolete?

[Lute Kamstra]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> So, how do you make Font Lock use the function in the variable
>>> syntax-begin-function to move to top level?
>>
>> I don't understand the question.  What have you tried?
>
>> From what I understand, font-lock-beginning-of-syntax-function is
> initialized from font-lock-defaults.  You can either specify nil or a
> function name.  If you specify nil, Font Lock uses the beginning of
> the buffer.  If you specify a function, Font Lock uses that function.
> How do you make Font Lock use the function in the variable
> syntax-begin-function?

Can somebody confirm that this change is correct?

Lute.


Index: lisp/font-lock.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/font-lock.el,v
retrieving revision 1.256
diff -c -r1.256 font-lock.el
*** lisp/font-lock.el	19 May 2005 02:15:09 -0000	1.256
--- lisp/font-lock.el	20 May 2005 09:22:48 -0000
***************
*** 563,573 ****
  a place such that any bracket-pairs outside it can be ignored for Emacs
  syntax analysis and fontification).
  
! If this is nil, the beginning of the buffer is used, which is
! always correct but tends to be slow.
! This is normally set via `font-lock-defaults'.
! This variable is semi-obsolete; we recommend setting
! `syntax-begin-function' instead.")
  
  (defvar font-lock-mark-block-function nil
    "*Non-nil means use this function to mark a block of text.
--- 563,573 ----
  a place such that any bracket-pairs outside it can be ignored for Emacs
  syntax analysis and fontification).
  
! If this is nil, Font Lock uses `syntax-begin-function' to move back
! outside of any comment, string, or sexp.  This variable is semi-obsolete;
! we recommend setting `syntax-begin-function' instead.
! 
! This is normally set via `font-lock-defaults'.")
  
  (defvar font-lock-mark-block-function nil
    "*Non-nil means use this function to mark a block of text.

Re: font-lock-beginning-of-syntax-function semi-obsolete?

[Stefan Monnier]

> Can somebody confirm that this change is correct?

Confirmed,


        Stefan