Evening, Martin! On Wed, Dec 06, 2006 at 10:04:23AM +0100, martin rudalics wrote:
[ .... ] > Thanks for taking care of this. Please note: > 1. You don't widen the buffer before calling `syntax-ppss'. You mean I don't have to, and would get the same result without widening? I need to widen anyway, in case point is inside a comment/string and (point-min) is after the c/s's start. > 2. A construct built along > (foo > ) (bar) > with point at "bar" might derail font-lock (remember, > `c-beginning-of-defun-1' calls `beginning-of-defun', not > `beginning-of-defun-raw'). I think it's best to keep the discussion of beginning-of-defun and the CC Mode stuff separate. Once b-o-d works right, the question is then how CC Mode should use it. You discuss this below. > 3. All this is still awfully slow and expensive: Open a larger buffer > like xdisp.c, jump to its end, hit M-v a couple of times, and look at > CPU consumption. UURRRKkk!! That's not good! It took me ~6 seconds, and that's not even on my (deceased) 166 MHz box. That file is the best part of a megabyte, though. > 4. You could avoid the tedious `up-list' steps by using a variant of the > tentative fix I attached. (nth 9 ppss) is "Internal data for continuing the parsing". If we're going to be using that thing's car as "the least nested paren", why don't we give up the pretence of an "internal" variable and document it properly? I know it's used in some other places too, but it seems to be being economical with our integrity to use it ourselves whilst telling everybody else "it's internal stuff". Or has this been discussed already? Your patch is more compact than mine was, and makes scrolling in xdisp.c acceptably (to me) fast. In fact, that 6 seconds has been reduced to about half a second. So it gets my vote. (I've got a 1.2 GHz Athlon machine, by the way.) Just a small point, though: your patch doesn't handle the silly case (beginning-of-defun 0). I think this should mean "point doesn't move". Is it the `up-list' calls which slow my version down so much? > 5. Consider making `open-paren-in-column-0-is-defun-start' a real user > option in C mode. Let, for example, users decide whether they want to > respect GNU coding standards [ .... ]. I think I might agree with this, now. Or is your version of beginning-of-defun-raw fast enough so that this doesn't really matter? I think there are lots of programmers who hang braces which open defuns. I think Java hackers do it a lot. But we need to implement this in a way which doesn't repeat the unholy hassle we had with `require-final-newline'. I don't think there should be a variable `c-open-paren....-start" - the name's long enough already. ;-) Maybe CC Mode should make o-p-i-c-o-i-d-s local in each of its buffers. > This should also permit binding C-M-a / C-M-e to `c-beginning-of-defun' > / `c-end-of-defun' when `open-paren-in-column-0-is-defun-start' is nil. Indeed. > 6. In any case, the new behavior should be documented since it applies > whenever `open-paren-in-column-0-is-defun-start' is set to nil. What new behaviour? But Richard asked that. -- Alan Mackenzie (Ittersbach, Germany) _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
