Inconsistency in font-lock

Inconsistency in font-lock

[Herbert Euler]

The doc-string of `font-lock-fontify-region-function' says it is

Function to use for fontifying a region.
It should take two args, the beginning and end of the region, and an 
optional
third arg VERBOSE.  If VERBOSE is non-nil, the function should print status
messages.  This is normally set via `font-lock-defaults'.

The default value comes with Emacs is `font-lock-default-fontify-region',
but the third argument of it is _not_ optional:

font-lock-default-fontify-region is a compiled Lisp function in 
`font-lock.el'.
(font-lock-default-fontify-region beg end loudly)

Regards,
Guanpeng Xu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Inconsistency in font-lock

[martin rudalics]

It's not nice.  We should write:

(defun font-lock-default-fontify-region (beg end &optional loudly)

Re: Inconsistency in font-lock

[Glenn Morris]

martin rudalics wrote:

> It's not nice.  We should write:
>
> (defun font-lock-default-fontify-region (beg end &optional loudly)

But the one time font-lock-fontify-region-function is actually called
(AFAICS; in font-lock.el), it's called with three arguments, so what's
the point in the 3rd one being optional? But your suggestion seems the
simplest.

I imagine anyone writing a font-lock-fontify-region-function function
can figure out what to do.

Re: Inconsistency in font-lock

[Stefan Monnier]

> It's not nice.  We should write:
> (defun font-lock-default-fontify-region (beg end &optional loudly)

I think we should fix the docstring instead and just say that the function
is called with 3 arguments.  How that function accepts them is irrelevant
(the function may have 4 optional arguments if the programmer feels like
it).


        Stefan

Re: Inconsistency in font-lock

[Herbert Euler]

> > It's not nice.  We should write:
> > (defun font-lock-default-fontify-region (beg end &optional loudly)
>
>I think we should fix the docstring instead and just say that the function
>is called with 3 arguments.  How that function accepts them is irrelevant
>(the function may have 4 optional arguments if the programmer feels like
>it).

Well, from the caller's point of view, the third argument is less
meaningful.  In my opinion,

    (funcall font-lock-fontify-region-function start end nil)

is a bit worse than

    (funcall font-lock-fontify-region-function start end)

since the third argument `nil' is a surprise here.  Only start and
end positions are necessary for operations on a region.

Regards,
Guanpeng Xu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Inconsistency in font-lock

[martin rudalics]

>>It's not nice.  We should write:
>>(defun font-lock-default-fontify-region (beg end &optional loudly)
> 
> 
> I think we should fix the docstring instead and just say that the function
> is called with 3 arguments.  How that function accepts them is irrelevant
> (the function may have 4 optional arguments if the programmer feels like
> it).

I have no strong opinion.  XEmacs has it optional ever since, IIRC.

Re: Inconsistency in font-lock

[Stefan Monnier]

>>> It's not nice.  We should write:
>>> (defun font-lock-default-fontify-region (beg end &optional loudly)
>> I think we should fix the docstring instead and just say that the function
>> is called with 3 arguments.  How that function accepts them is irrelevant
>> (the function may have 4 optional arguments if the programmer feels like
>> it).

> I have no strong opinion.  XEmacs has it optional ever since, IIRC.

Whether the function has it optional or not is not the issue.  The issue is
that the code calls it with 3 arguments, so we should just say so rather
than impose that the third be optional.
Check the docstring of other foo-function(s) variables and you'll see that's
how we normally document them:

   after-change-functions is a variable defined in `C source code'.
   Its value is nil
   
   
   Documentation:
   List of functions to call after each text change.
   Three arguments are passed to each function: the positions of
   the beginning and end of the range of changed text,
   and the length in bytes of the pre-change text replaced by that range.
   ...

The after-change-functions can of course decide to leave the 3rd argument
as optional.


        Stefan

Re: Inconsistency in font-lock

[Herbert Euler]

>Whether the function has it optional or not is not the issue.  The issue is
>that the code calls it with 3 arguments, so we should just say so rather
>than impose that the third be optional.

I wrote a package these days, and I called the function.  The code
is as in the previous message:

  (if font-lock-defaults
      (funcall font-lock-fontify-region-function start end nil))

Since the issue is the amount of arguments in codes that actually
call it, I think `nil' here is not necessary.  For fontifying a region,
only the start and end position of the region is needed, whether
the fontifying process is "loud" is not necessary.

On the other hand, Glenn refered that there is an invocation in
font-lock.el, there does be one.  Please take a look at it:

(defun font-lock-fontify-region (beg end &optional loudly)
  (font-lock-set-defaults)
  (funcall font-lock-fontify-region-function beg end loudly))

All of the functions and variables, `font-lock-fontify-region-function',
`font-lock-default-fontify-region', and `font-lock-fontify-regin',
should be in one form, for consistency.  If we say that
`font-lock-fontify-region-function' is a function that requires
three arguments at least, perhaps we should modify the definition
of `font-lock-fontify-region' as well.

Regards,
Guanpeng Xu

Btw, after reading the code, I think I should not use the code
above in the package I wrote these days, but the following:

  (font-lock-fontify-region start end)

And I have changed my code.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Inconsistency in font-lock

[Stefan Monnier]

> I wrote a package these days, and I called the function.  The code
> is as in the previous message:

>  (if font-lock-defaults
>      (funcall font-lock-fontify-region-function start end nil))

> Since the issue is the amount of arguments in codes that actually
> call it, I think `nil' here is not necessary.

Calling font-lock-fontify-region-function like that it a mistake.
You should call font-lock-fontify-region instead.  So the argument is moot.


        Stefan

Re: Inconsistency in font-lock

[martin rudalics]

> Whether the function has it optional or not is not the issue.  The issue is
> that the code calls it with 3 arguments, so we should just say so rather
> than impose that the third be optional.

OK with me.

> Check the docstring of other foo-function(s) variables and you'll see that's
> how we normally document them:
> 
>    after-change-functions is a variable defined in `C source code'.
>    Its value is nil
>    
>    
>    Documentation:
>    List of functions to call after each text change.
>    Three arguments are passed to each function: the positions of
>    the beginning and end of the range of changed text,
>    and the length in bytes of the pre-change text replaced by that range.
>    ...
> 
> The after-change-functions can of course decide to leave the 3rd argument
> as optional.

Sure.  Just loudly / verbose is quite hysterical nowadays.