unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph
@ 2009-07-30  5:47 Lennart Borgman
  2009-07-30 10:47 ` Alan Mackenzie
  0 siblings, 1 reply; 6+ messages in thread
From: Lennart Borgman @ 2009-07-30  5:47 UTC (permalink / raw)
  To: emacs-pretest-bug

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'





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph
  2009-07-30  5:47 bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph Lennart Borgman
@ 2009-07-30 10:47 ` Alan Mackenzie
  2009-07-30 13:40   ` Lennart Borgman
  2009-07-30 21:12   ` Stefan Monnier
  0 siblings, 2 replies; 6+ messages in thread
From: Alan Mackenzie @ 2009-07-30 10:47 UTC (permalink / raw)
  To: Lennart Borgman, 3972; +Cc: emacs-pretest-bug

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).





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph
  2009-07-30 10:47 ` Alan Mackenzie
@ 2009-07-30 13:40   ` Lennart Borgman
  2009-07-30 14:44     ` Lennart Borgman
  2009-07-30 21:12   ` Stefan Monnier
  1 sibling, 1 reply; 6+ messages in thread
From: Lennart Borgman @ 2009-07-30 13:40 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: 3972

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).
>





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph
  2009-07-30 13:40   ` Lennart Borgman
@ 2009-07-30 14:44     ` Lennart Borgman
       [not found]       ` <e01d8a50907301752r7b9cd343xa00d8244f6feace8@mail.gmail.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Lennart Borgman @ 2009-07-30 14:44 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: 3972

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...?





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph
  2009-07-30 10:47 ` Alan Mackenzie
  2009-07-30 13:40   ` Lennart Borgman
@ 2009-07-30 21:12   ` Stefan Monnier
  1 sibling, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2009-07-30 21:12 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: 3972

> 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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph
       [not found]       ` <e01d8a50907301752r7b9cd343xa00d8244f6feace8@mail.gmail.com>
@ 2016-02-12  4:17         ` Andrew Hyatt
  0 siblings, 0 replies; 6+ messages in thread
From: Andrew Hyatt @ 2016-02-12  4:17 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: Alan Mackenzie, 3972

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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-02-12  4:17 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-30  5:47 bug#3972: 23.1.50; c-mode sets M-q to c-fill-paragraph Lennart Borgman
2009-07-30 10:47 ` Alan Mackenzie
2009-07-30 13:40   ` Lennart Borgman
2009-07-30 14:44     ` Lennart Borgman
     [not found]       ` <e01d8a50907301752r7b9cd343xa00d8244f6feace8@mail.gmail.com>
2016-02-12  4:17         ` Andrew Hyatt
2009-07-30 21:12   ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).