bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19846: 25.0.50; Problem with auto-fill-mode and C mode


From: Alan Mackenzie
Subject: bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
Date: 14 Feb 2015 11:48:37 -0000
User-agent: tin/2.2.0-20131224 ("Lochindaal") (UNIX) (FreeBSD/8.4-RELEASE (amd64))

Hi, Martin.

In article <mailman.19768.1423766347.1147.bug-gnu-emacs@gnu.org> you wrote:
> With current trunk/master and emacs -Q evaluate the following form

> (add-hook
>  'c-mode-hook
>  '(lambda ()
>     (turn-on-auto-fill)
>     (set (make-local-variable 'fill-column) 72)))

> and visit ~/src/xterm.c.  Go to the end of that file, move a few lines
> backwards so that point is at the beginning of some non-empty line
> within the doc-string of `x-frame-normalize-before-maximize' (which is
> coded as a C comment).  Now keep the SPC key pressed.  Here Emacs
> consumes the entire available CPU and eventually redisplay gets stuck
> completely.  This used to work without problems in Emacs 24.3.

I don't see the difference between 24.3 and current master.  On both of
them, the behaviour is the same.  The spaces get inserted normally, up
to column 72, then the display freezes.  Some long while later (several
minutes), the display catches up again.  This is with point in column
~500.  (Both of my Emacs builds were with optimisation and without
debugging info.  Your build was without and with.)

A quick use of the profiler shows that forward-paragraph is taking ~87%
of the total CPU.  There'll be a reason for this.  I'll have a look at it.

> In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
>  of 2015-02-12 on MACHNO
> Repository revision: da726ad0c6177a3442a374a135f40a24945d362c
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> Configured using:
>  `configure --prefix=/c/emacs-git/trunk --enable-checking=yes
>  --enable-check-lisp-object-type=yes 'CFLAGS=-O0 -g3''

Incidentally, that doc string

  If this variable is t, Emacs asks the window manager to give the frame
  intermediately its normal size whenever changing from a full-height or
  full-width state to the fully maximized one and vice versa.

doesn't read well.  The "intermediately" in that position isn't English!
Perhaps something like the following would be better:

If this variable is t, Emacs first asks the window manager to give the
frame its normal size, and only then the final state, whenever changing
from a full-height or full-width state to the fully maximized one and vice
versa.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).






reply via email to

[Prev in Thread] Current Thread [Next in Thread]