Re: ntemacs hangs when openning the attached file

[Stefan Monnier]

>> >     The current CVS header version hangs when openning the attached file.

>> No, it doesn't hang, it just takes a lot of time to visit this file.
>> I measured 61 seconds on a 3GHz machine.  This file has 86406 lines,
>> and uses some pretty non-standard formatting, such as this one:

> The problem was that c-neutralize-syntax-in-CPP was inefficiently coded.
> I've optimised it using essentially only Emacs primitives in the defun's
> main loop.  It now runs almost 2 orders of magnitude faster.

Sounds good.

> Eli, I'd appreciate it very much indeed if you could review this new
> code, please - earlier versions of it were peculiarly troublesome.

Don't know about Eli.  But here's some comments:

> +   ;; Note: SPEED _MATTERS_ IN THIS FUNCTION!!!
> +   ;; 
>     ;; This function might do invisible changes.
                             ^^
                            make

> +     (setq pps-position beg  pps-state nil)

It would be a lot more lispy to explicitly let-bind pps-position and
pps-state here, rather than declare them earlier without initializing
them and then initializing them here.

>       (while (and (< (point) end)
>               (search-forward-regexp c-anchored-cpp-prefix end t))
>         ;; If we've found a "#" inside a string/comment, ignore it.
> !       (setq pps-state
> !         (parse-partial-sexp pps-position (point) nil nil pps-state)
> !         pps-position (point))
> !       (unless (or (nth 3 pps-state) ; in a string?
> !               (nth 4 pps-state))    ; in a comment?
>       (setq mbeg+1 (point))
>       (c-end-of-macro)          ; Do we need to go forward 1 char here?  No!
> !     (c-neutralize-CPP-line mbeg+1 (point))
> !     (setq pps-state
> !           (parse-partial-sexp pps-position (point) nil nil pps-state)
> !           pps-position (point))))))

I have the impression that this second call to parse-partial-sexp
is unnecessary.


        Stefan