when completion.el parses C files.

when completion.el parses C files.

[Michaël Cadilhac]

[-- Attachment #1.1.1: Type: text/plain, Size: 718 bytes --]

completion.el has a little bug with a C file that looks like that:
<<<<
#endif>>>>>

The point is that the file does not end with a newline character. So,
if you count rightly, there's no more than 5 characters after the #.

However, the C parse feature of completion.el supposes that this is
impossible and expects at least 6 chars after a #. This leads to
a misleading error :
Debugger entered--Lisp error: (wrong-type-argument stringp 59)

This  is  quite   unexpected.  This  (second)  bug  is   due  to  some
suppositions  on  the  error  caught  by  the  condition-case  of  the
function,  and the  «  error reporting  »  asked in  the  code is  not
reached.

I propose the following change:


[-- Attachment #1.1.2: completion.patch --]
[-- Type: text/x-patch, Size: 2372 bytes --]

Index: lisp/completion.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/completion.el,v
retrieving revision 1.57
diff -c -r1.57 completion.el
*** lisp/completion.el	6 Feb 2006 14:33:32 -0000	1.57
--- lisp/completion.el	7 Oct 2006 00:35:25 -0000
***************
*** 1895,1900 ****
--- 1895,1902 ----
                    (cond
                     ((= (preceding-char) ?#)
                      ;; preprocessor macro, see if it's one we handle
+ 		    (when (> (+ (point) 6) (point-max))
+ 		      (throw 'finish-add-completions t))
                      (setq string (buffer-substring (point) (+ (point) 6)))
                      (cond ((member string '("define" "ifdef "))
                             ;; skip forward over definition symbol
***************
*** 1944,1952 ****
                 (throw 'finish-add-completions t))
                (error
                 ;; Check for failure in scan-sexps
!                (if (or (string-equal (nth 1 e)
!                                      "Containing expression ends prematurely")
!                        (string-equal (nth 1 e) "Unbalanced parentheses"))
                     ;; unbalanced paren., keep going
                     ;;(ding)
                     (forward-line 1)
--- 1946,1955 ----
                 (throw 'finish-add-completions t))
                (error
                 ;; Check for failure in scan-sexps
!                (if (and e (stringp (nth 1 e))
! 			(or (string-equal (nth 1 e)
! 					  "Containing expression ends prematurely")
! 			    (string-equal (nth 1 e) "Unbalanced parentheses")))
                     ;; unbalanced paren., keep going
                     ;;(ding)
                     (forward-line 1)
Index: lisp/ChangeLog
===================================================================
RCS file: /sources/emacs/emacs/lisp/ChangeLog,v
retrieving revision 1.10166
diff -c -0 -r1.10166 ChangeLog
*** lisp/ChangeLog	6 Oct 2006 22:54:18 -0000	1.10166
--- lisp/ChangeLog	7 Oct 2006 00:35:28 -0000
***************
*** 0 ****
--- 1,6 ----
+ 2006-10-07  Michaël Cadilhac  <michael.cadilhac@lrde.org>
+ 
+ 	* completion.el (add-completions-from-c-buffer): Test if the
+ 	preprocessor macro can be 6 letters long.  Check if the error
+ 	caught is of the expected form.
+ 

[-- Attachment #1.1.3: Type: text/plain, Size: 391 bytes --]


-- 
/!\ My mail address changed, please update your files accordingly.
 |      Michaël `Micha' Cadilhac   |  «Tu aimeras ton prochain.»            |
 |         Epita/LRDE Promo 2007   |    D'abord, Dieu ou pas,               |
 |  http://michael.cadilhac.name   |       j'ai horreur qu'on me tutoie.    |
 `--  -   JID: micha@amessage.be --'           -- P. Desproges         -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: when completion.el parses C files.

[Stefan Monnier]

> This  is  quite   unexpected.  This  (second)  bug  is   due  to  some
> suppositions  on  the  error  caught  by  the  condition-case  of  the
> function,  and the  «  error reporting  »  asked in  the  code is  not
> reached.

Thanks, I installed a different patch,


        Stefan