Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"

Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"

[Richard Stallman]

    It seems that about half the people who posted something about
    font-lock-support-mode are aware of jit-lock mode whereas
    the other half got stuck with lazy-lock mode. My guess is that people actively 
    tracking the latest CVS branch (and thus the pretest version)
    are well aware of jit-lock mode and the people who have not
    bothered with CVS version wrote about lazy-lock vs fast-lock and
    have not updated the web pages for some time.

What would people think of making font-lock-support-mode a no-op, and
creating some new variable people can use if they really want to use
something else instead of jit-lock?

Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"

[Stefan Monnier]

> What would people think of making font-lock-support-mode a no-op, and
> creating some new variable people can use if they really want to use
> something else instead of jit-lock?

They'd think "Damn, Richard!  What got into you?".
Seriously, I think we're wasting our time here: this problem does not
impact functionality.
AFAICT the OP's problem was the use of a separate package which enabled
lazy-lock.  That package is hence (minorl) broken and will be fixed soon
enough when people start reporting the problem.


        Stefan

Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"

[ishikawa]

Hi,


Stefan Monnier wrote:
>> What would people think of making font-lock-support-mode a no-op, and
>> creating some new variable people can use if they really want to use
>> something else instead of jit-lock?
> 
> They'd think "Damn, Richard!  What got into you?".
> Seriously, I think we're wasting our time here: this problem does not
> impact functionality.
> AFAICT the OP's problem was the use of a separate package which enabled
> lazy-lock.  That package is hence (minorl) broken and will be fixed soon
> enough when people start reporting the problem.
> 
> 
>         Stefan

The original reporter is here again. I agree.
Once enough people start to complain, the various widely used packages (and 
their methods of customization) would be fixed sooner or later.
I would rather have it sooner and thus a pointer to such changes would be
nice because having such material on-line, the package maintainers will fix such 
problems in a short time.
The information doesn't have to be in the manual page. A wiki or web page
accessible for such would-be trial users, among whom are package developers,
are just fine.

TIA.

Happy Hacking,
Chiaki Ishikawa

Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"

[Richard Stallman]

    > What would people think of making font-lock-support-mode a no-op, and
    > creating some new variable people can use if they really want to use
    > something else instead of jit-lock?

    They'd think "Damn, Richard!  What got into you?".
    Seriously, I think we're wasting our time here: this problem does not
    impact functionality.

I am skeptical of these statements.
Could you present reasons for them?

Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"

[Stefan Monnier]

>     They'd think "Damn, Richard!  What got into you?".
>     Seriously, I think we're wasting our time here: this problem does not
>     impact functionality.

> I am skeptical of these statements.
> Could you present reasons for them?

IIRC the "problem" was that Emacs warned the user that lazy-lock is obsolete
and that she can fix that via font-lock-support-mode.  That's no loss of
functionality: lazy-lock works just as well as ever, AFAIK.


        Stefan

Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"

[Richard Stallman]

    IIRC the "problem" was that Emacs warned the user that lazy-lock is obsolete
    and that she can fix that via font-lock-support-mode.

If that is true, I agree with you; I thought the problem was less
transparent.

Re: "Use font-lock-support-mode rather than calling lazy-lock-mode"

[ishikawa]

Stefan Monnier wrote:
>>     They'd think "Damn, Richard!  What got into you?".
>>     Seriously, I think we're wasting our time here: this problem does not
>>     impact functionality.
> 
>> I am skeptical of these statements.
>> Could you present reasons for them?
> 
> IIRC the "problem" was that Emacs warned the user that lazy-lock is obsolete
> and that she can fix that via font-lock-support-mode.  That's no loss of
> functionality: lazy-lock works just as well as ever, AFAIK.
> 

Hi,

The original reporter

The problem here was that I got a warning about lazy-lock being deprecated and
the code that printed the warning  contained "(sit-for 2)" and
the resulting behavior was not quite friendly since I could not figure out 
initially where lazy-lock was invoked until I traced the code to figure out where.

I am not sure if lazy-lock mode (supplied with 22.0.90)  works without showing 
this warning every now and then (electric-buffer mode certainly was not usable 
due to this warning message obscuring the intermediate output/input all the time.).
Basic functionality works maybe, but it was hardly usable to a testing luser.

Just my observation.

As for NOT putting the information into the info page, I concur given that
there is a NEWS entry and/or other pointers available on-line so that
the package mainteners have ample hints to fix his/her codes.
By the time, the release to the general public occurs, the kind of problems that 
I faced (in relation to somewhat obscure initialize code for VM) would disapper,
hopefully.


Chiaki Ishikawa