bug#10463: 24.0.92; c-literal-limits out of range

bug#10463: 24.0.92; c-literal-limits out of range

[martin rudalics]

For quite some time, when editing c-mode buffers I get errors which
typically look like:

Debugger entered--Lisp error: (args-out-of-range 170988 178401)
   parse-partial-sexp(170988 178401)
   c-literal-limits(nil nil t)
   c-indent-new-comment-line(t)
   default-indent-new-line(t)
   do-auto-fill()
   apply(do-auto-fill nil)
   c-mask-paragraph(nil t do-auto-fill)
   c-do-auto-fill()
   self-insert-command(1)
   call-interactively(self-insert-command nil nil)

At this time the buffer is visibly narrowed - the arguments of
`parse-partial-sexp' were apparently within (point-min) and (point-max)
of the widened buffer but the second argument was likely after the end
of the the narrowed buffer.

Moreover, the buffer was no more associated with the file I was trying
to edit, so reverting the buffer was impossible, undo information had
been discarded, killing the buffer was possible without asking.


In GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600)
  of 2012-01-08 on NESTOR
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt'

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: ENU
   value of $XMODIFIERS: nil
   locale-coding-system: cp1252
   default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
   shell-dirtrack-mode: t
   scroll-restore-mode: t
   regexp-lock-mode: t
   eldoc-header-mode: t
   show-paren-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   temp-buffer-resize-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
Loading paren...done
Loading vc-cvs...done
Loading vc-bzr...done
With .emacs from "2012-01-09 10:52:57 martin"

Load-path shadows:
None found.

Features:
(shadow gnus-util mail-extr message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
hippie-exp dabbrev emacsbug cus-edit wid-edit cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs vc-bzr
add-log speck elp cl local-tags windmove info-look find-func
elinfo-support elinfo texinfo info shell pcomplete comint ring vc-cvs
sidebar easymenu bookmark pp sort m&d scroll-restore regexp-lock
easy-mmode time-stamp eldoc help-fns find-dired dired regexp-opt
jka-compr paren cus-start cus-load avoid time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win
w32-vars tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer button
faces cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process multi-tty emacs)

bug#10463: 24.0.92; c-literal-limits out of range

[Stefan Monnier]

> Moreover, the buffer was no more associated with the file I was trying
> to edit, so reverting the buffer was impossible, undo information had
> been discarded, killing the buffer was possible without asking.

That's presumably because the code uses something like
with-silent-modifications.  I.e. it's not a problem (contrary to the
`args-out-of-range' error, obviously).


        Stefan

bug#10463: 24.0.92; c-literal-limits out of range

[martin rudalics]

 > That's presumably because the code uses something like
 > with-silent-modifications.  I.e. it's not a problem (contrary to the
 > `args-out-of-range' error, obviously).

My bad.  I didn't quit the backtrace buffer but tried to fix it manually
and lost my changes :-(

martin

bug#10463: 24.0.92; c-literal-limits out of range

[Alan Mackenzie]

On Mon, Jan 09, 2012 at 07:19:25PM +0100, martin rudalics wrote a bug
report:

Hi, Martin.

Please apply this patch, use C Mode for an infinite amount of time, then
report back and tell me the bug has disappeared.

Thanks!


*** orig/cc-engine.el	2012-01-09 20:27:51.000000000 +0000
--- cc-engine.el	2012-01-09 20:53:42.000000000 +0000
***************
*** 4225,4236 ****
  
  Note that this function might do hidden buffer changes.	 See the
  comment at the start of cc-engine.el for more info."
!   (let* ((safe-place (c-state-safe-place (point)))
! 	 (lit (c-state-pp-to-literal safe-place (point))))
!     (or (cadr lit)
! 	(and detect-cpp
! 	     (save-excursion (c-beginning-of-macro))
! 	     'pound))))
  
  (defun c-literal-limits (&optional lim near not-in-delimiter)
    "Return a cons of the beginning and end positions of the comment or
--- 4225,4238 ----
  
  Note that this function might do hidden buffer changes.	 See the
  comment at the start of cc-engine.el for more info."
!   (save-restriction
!     (widen
!      (let* ((safe-place (c-state-safe-place (point)))
! 	    (lit (c-state-pp-to-literal safe-place (point))))
!        (or (cadr lit)
! 	   (and detect-cpp
! 		(save-excursion (c-beginning-of-macro))
! 		'pound))))))
  
  (defun c-literal-limits (&optional lim near not-in-delimiter)
    "Return a cons of the beginning and end positions of the comment or
***************
*** 4250,4258 ****
    (save-excursion
      (let* ((pos (point))
  	   (lim (or lim (c-state-safe-place pos)))
! 	   (pp-to-lit (c-state-pp-to-literal lim pos))
  	   (state (car pp-to-lit))
- 	   (lit-type (cadr pp-to-lit))
  	   (lit-limits (car (cddr pp-to-lit))))
  
        (cond
--- 4252,4261 ----
    (save-excursion
      (let* ((pos (point))
  	   (lim (or lim (c-state-safe-place pos)))
! 	   (pp-to-lit (save-restriction
! 			(widen)
! 			(c-state-pp-to-literal lim pos)))
  	   (state (car pp-to-lit))
  	   (lit-limits (car (cddr pp-to-lit))))
  
        (cond

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#10463: 24.0.92; c-literal-limits out of range

[martin rudalics]

 > Please apply this patch, use C Mode for an infinite amount of time,

Editing with C Mode already takes an infinite amount of time ...

 > then
 > report back and tell me the bug has disappeared.

... so better not hold your breath ;-)

 > !     (widen
 > !      (let* ((safe-place (c-state-safe-place (point)))

My `widen' doesn't like any arguments.

Thanks, martin

bug#10463: 24.0.92; c-literal-limits out of range

[Stefan Monnier]

>> Please apply this patch, use C Mode for an infinite amount of time,
> Editing with C Mode already takes an infinite amount of time ...

But doing it with Emacs makes the time pass infinitely faster.


        Stefan

bug#10463: 24.0.92; c-literal-limits out of range

[Juanma Barranquero]

On Tue, Jan 10, 2012 at 21:04, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Editing with C Mode already takes an infinite amount of time ...
>
> But doing it with Emacs makes the time pass infinitely faster.

Yes, but do both infinites have the same cardinality...?

    Juanma

bug#10463: 24.0.92; c-literal-limits out of range

[martin rudalics]

> But doing it with Emacs makes the time pass infinitely faster.

In particular when it throws you out of its ranges.

martin

bug#10463: Bug #10463 fixed

[Alan Mackenzie]

Bug fixed in revision 106849.

-- 
Alan Mackenzie (Nuremberg, Germany).