bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph

bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph

[Lennart Borgman]

Instead it should set the variable fill-paragraph.


In GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
 of 2009-06-30
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'

bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph

[Alan Mackenzie]

Hi, Lennart!

On Thu, Jul 30, 2009 at 07:47:32AM +0200, Lennart Borgman wrote:
> [c-mode sets M-q to c-fill-paragraph]
> Instead it should set the variable fill-paragraph.

It would be nice, wouldn't it?

Have you tried it, and does it work?  Does it always work?

I've just looked at fill-paragraph's source, and it looks like it's
broken.  If it's called interactively, transient mark mode is enabled,
the mark "is active", the region is non-zero length, and it's currently
a full moon, each paragraph in the region is filled by calling
fill-region, bypassing fill-paragraph-function.  Or maybe I've missed
something.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph

[Lennart Borgman]

On Thu, Jul 30, 2009 at 12:47 PM, Alan Mackenzie<acm@muc.de> wrote:
> Hi, Lennart!


Hi Alan, thanks for answering me. It makes my frustration a bit less ... ;-)


> On Thu, Jul 30, 2009 at 07:47:32AM +0200, Lennart Borgman wrote:
>> [c-mode sets M-q to c-fill-paragraph]
>> Instead it should set the variable fill-paragraph.
>
> It would be nice, wouldn't it?
>
> Have you tried it, and does it work?  Does it always work?


No, sigh, this is one of the desperate bug reports I send when I am
unable to get a "simple" thing to work in MuMaMo. I just gets confused
and gets things a bit wrong.

I realized after sending the bug report that you probably had some
good reason for doing it the way you do, as you confirm below. (But
that looks like a bug, but not the one I thought I found.)

The problem I am actually fighting is a bit different I believe.
c-fill-paragraph is a bit complicated so I am not sure. What I see
when I am testing is that c-fill-paragraph works in some MuMaMo chunks
(ie a chunk of the buffer with one major mode, other than in the
chunks before and after it) and not others, though in both cases the
major mode is php-mode. My guess so far is that it is because of a
(widen) somewhere inside c-fill-paragraph that makes a call to
something, perhaps to syntax-ppss or similar, come back with bad
information (since it is influenced by contents in other chunks).

What do you think about this guess?



> I've just looked at fill-paragraph's source, and it looks like it's
> broken.  If it's called interactively, transient mark mode is enabled,
> the mark "is active", the region is non-zero length, and it's currently
> a full moon, each paragraph in the region is filled by calling
> fill-region, bypassing fill-paragraph-function.  Or maybe I've missed
> something.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph

[Lennart Borgman]

On Thu, Jul 30, 2009 at 3:40 PM, Lennart
Borgman<lennart.borgman@gmail.com> wrote:

> The problem I am actually fighting is a bit different I believe.
> c-fill-paragraph is a bit complicated so I am not sure. What I see
> when I am testing is that c-fill-paragraph works in some MuMaMo chunks
> (ie a chunk of the buffer with one major mode, other than in the
> chunks before and after it) and not others, though in both cases the
> major mode is php-mode. My guess so far is that it is because of a
> (widen) somewhere inside c-fill-paragraph that makes a call to
> something, perhaps to syntax-ppss or similar, come back with bad
> information (since it is influenced by contents in other chunks).
>
> What do you think about this guess?

I tried to flet widen to ignore. That worked, but when trying to byte
compile I got:

  mumamo.el:6734:57:Error: Byte-compiling a redefinition of `widen'
will not work - use `labels' instead

But `labels' does a lexical binding, not a dynamic binding so that
obviously will not work. So now I don't know what to do...
defadvice...?

bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph

[Stefan Monnier]

> I've just looked at fill-paragraph's source, and it looks like it's
> broken.  If it's called interactively, transient mark mode is enabled,
> the mark "is active", the region is non-zero length, and it's currently
> a full moon, each paragraph in the region is filled by calling
> fill-region, bypassing fill-paragraph-function.  Or maybe I've missed
> something.

That's a long standing design bug, indeed.

I think fill.el needs to introduce fill-forward-paragraph-function and
some kind of fill-region-as-paragraph-function (and obsolete
fill-paragraph-function).

Patches welcome,


        Stefan

bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph

[Andrew Hyatt]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Jul 30, 2009 at 4:44 PM, Lennart
> Borgman<lennart.borgman@gmail.com> wrote:
>> On Thu, Jul 30, 2009 at 3:40 PM, Lennart
>> Borgman<lennart.borgman@gmail.com> wrote:
>>
>>> The problem I am actually fighting is a bit different I believe.
>>> c-fill-paragraph is a bit complicated so I am not sure. What I see
>>> when I am testing is that c-fill-paragraph works in some MuMaMo chunks
>>> (ie a chunk of the buffer with one major mode, other than in the
>>> chunks before and after it) and not others, though in both cases the
>>> major mode is php-mode. My guess so far is that it is because of a
>>> (widen) somewhere inside c-fill-paragraph that makes a call to
>>> something, perhaps to syntax-ppss or similar, come back with bad
>>> information (since it is influenced by contents in other chunks).
>>>
>>> What do you think about this guess?
>>
>> I tried to flet widen to ignore. That worked, but when trying to byte
>> compile I got:
>>
>>  mumamo.el:6734:57:Error: Byte-compiling a redefinition of `widen'
>> will not work - use `labels' instead
>>
>> But `labels' does a lexical binding, not a dynamic binding so that
>> obviously will not work. So now I don't know what to do...
>> defadvice...?
>
>
> I decided to use defadvice on `widen' (+ enable/disable) for the
> moment. It seems to work fine.
>
> However that c-fill-paragraph is bound to M-q is still a problem, I
> had to rebind that.
>
> I noticed some other problems:
>
> - The doc string for fill-paragraph-function does not say anything
> about the functions arguments.
> - The arguments to c-fill-paragraph is not the expected ones though it
> is used as fill-paragraph-function. (But it works - and I don't
> understand why at the moment...)
>
> Also the double role of c-fill-paragraph is perhaps a difficult design
> (it is used both for M-x and fill-paragraph-function).

This bug feels like a wishlist to me. I don't see a user-visible issue,
just (valid-seeming) design issues. The documentation does seem like a
potential bug, but I'd assume that any function defined in
fill-paragraph-function won't be called with any arguments, since they
aren't mentioned (and I'm not sure which arguments would make sense
anyway).

I'm going to mark this as wishlist, but feel free to disagree.