In the time Emacs 22 is the current release, a typical new PC will come to
be around 20 GHz, and this slowness will not matter.
Actually, recent trends indicate that this is not true. We'll probably
see typical new PCs with 4-16 CPUs, each one running at 4-5GHz, but that
won't help Emacs
On Sun, Dec 10, 2006 at 04:39:03PM -0500, Stefan Monnier wrote:
In the time Emacs 22 is the current release, a typical new PC will come to
be around 20 GHz, and this slowness will not matter.
Actually, recent trends indicate that this is not true. We'll probably
see typical new PCs with
Stefan Monnier [EMAIL PROTECTED] writes:
The docstring doesn't mention anything about it. And really, when
defun-prompt-regexp is nil, then beginning-of-defun considers that defun
starts when there is a char with open-parenthesis syntax at the beginning of
a line. So if
The docstring doesn't mention anything about it. And really, when
defun-prompt-regexp is nil, then beginning-of-defun considers that defun
starts when there is a char with open-parenthesis syntax at the beginning of
a line. So if open-paren-in-column-0-is-defun-start is nil, it's hard to
BTW, in Elisp an open bracket in column zero of a string should not
confuse Emacs. Yet you highlight it with `font-lock-warning-face'.
Indeed, it *shouldn't*, but it does confuse Emacs, which is why it's
highlighted ;-(. We should fix it so it doesn't confuse Emacs any more (and
doesn't
[ Expanding on my previous message ]
Could we revert the change to beginning-of-defun instead?
It seems clearly incorrect for beginning-of-defun to ignore
open-paren-in-column-0-is-defun-start.
[ The change I'd like to revert only influences the case where
defun-prompt-regexp is nil so
I disagree in general. What I agree to is that programmers should avoid
putting things that look like defuns inside comments and strings.
Commented-out code may look like a defun.
I.e. in Lisp, an open-paren-in-col0 is indeed a bad idea. In C it's not
a problem (maybe an
I disagree in general. What I agree to is that programmers should avoid
putting things that look like defuns inside comments and strings.
Commented-out code may look like a defun.
Indeed, so programmers should be careful to comment out in a way that makes
it not look like a defun. That's
Richard Stallman [EMAIL PROTECTED] writes:
Could we set open-paren-in-column-0-is-defun-start to t for c mode?
If no one sees a better alternative, let's do that. But let's wait
a few days and see what else is suggested.
It seems that no better ideas are forthcoming, so I think we
Hi, Richard!
On Wed, Dec 06, 2006 at 11:59:26PM -0500, Richard Stallman wrote:
Could we set open-paren-in-column-0-is-defun-start to t for c mode?
This would nullify the fix for the bug reported by Martin a few weeks
ago, namely: Load syntax.c and immediately jump forward to a certain
Alan Mackenzie [EMAIL PROTECTED] writes:
I think I now agree with Martin R: opic0ids should become a fully user
settable option, and CC Mode should respect it. However, I think it
needs more than two values, t and nil; it should have three values,
definitely nil, definitely t and don't
Here's a tentative fix for the bug, not that well tested, but tested a
little bit:
2006-12-04 Alan Mackenzie [EMAIL PROTECTED]
* emacs-lisp/lisp.el (beginning-of-defun-raw): In the seeking a
non-nested open-paren case, check there are enough lists to move
over. Return the
martin rudalics [EMAIL PROTECTED] writes:
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.
I can second that. Working on xdisp.c has become awfully slow lately.
We definitely need to
[EMAIL PROTECTED] (Kim F. Storm) writes:
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.
I can second that. Working on xdisp.c has become awfully slow lately.
We definitely need to
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.
Where are documentation changes are needed for this?
___
emacs-pretest-bug mailing list
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
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.
Where are documentation changes are needed for this?
In the Elisp description of `beginning-of-defun' I presume. I'd explain
the following issues:
Evening, Martin!
Evening, Alan!
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.
No, I mean you
Could we set open-paren-in-column-0-is-defun-start to t for c mode?
If no one sees a better alternative, let's do that. But let's wait
a few days and see what else is suggested.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
(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
This change seems reasonable. Would you please install it?
But we still face the question of whether to make another change in
the way C mode finds defuns, for efficiency.
That is an important question, I think.
___
emacs-pretest-bug mailing list
For a few weeks now, I've had intermittent issues editing C++ code in
Emacs; I was hoping to find some minimal reproducible case, but have
been unable to do so.
The symptoms are that while editing a C++ source file (typically
happens when killing or yanking, but I think I've seen it happen
with
Tim Van Holder skrev:
For a few weeks now, I've had intermittent issues editing C++ code in
Emacs; I was hoping to find some minimal reproducible case, but have
been unable to do so.
The symptoms are that while editing a C++ source file (typically
happens when killing or yanking, but I think
I see this too a lot, even in plain C files. A backtrace when this
happen looks like this:
Debugger entered--Lisp error: (scan-error Containing expression ends
prematurely 107612 107612)
scan-lists(107699 -1 0)
forward-list(-1)
backward-list(1)
beginning-of-defun-raw(nil)
martin rudalics skrev:
I see this too a lot, even in plain C files. A backtrace when this
happen looks like this:
Debugger entered--Lisp error: (scan-error Containing expression ends
prematurely 107612 107612)
scan-lists(107699 -1 0)
forward-list(-1)
backward-list(1)
Hi everybody!
On Mon, 4 Dec 2006, martin rudalics wrote:
I see this too a lot, even in plain C files. A backtrace when this
happen looks like this:
Debugger entered--Lisp error: (scan-error Containing expression ends
prematurely 107612 107612)
scan-lists(107699 -1 0)
It's a consequence of the recent change to `beginning-of-defun-raw'.
Compare the threads font-locking and open parens in column 0 and
emacs hangs in jit-lock.
What sort of text causes this error in scan_lists?
We want to do something to prevent C mode from always scanning from
the
27 matches
Mail list logo
