Maybe not now, but an elegant rewrite may enable changes to make Emacs
more powerful and better in the future.
I am not saying these are useless, I am saying that people focus too
much on making Emacs "more powerful", disregarding other kinds of
improvements that we need. Most of the TODO
Richard Stallman wrote:
This is not the part of Emacs that is important to improve.
Hackers tend to focus their attention on the parts of Emacs
that make it seem more elegant in programmers' terms,
but this doesn't make Emacs more powerful or a better editor.
Maybe not now, but an elegant rewrite m
Richard Stallman <[EMAIL PROTECTED]> writes:
> Below is a quick "proof-of-concept" patch for src/eval.c and
> lisp/emacs-lisp/debug.el to get a better idea of what I mean.
> As you can see, the change to eval.c isn't that big.
>
> The code is not unclean, but I don't think it is a real
Richard Stallman <[EMAIL PROTECTED]> writes:
> > does it have any real impact?
>
> It can be confusing for new users of the debugger: Hey, what's
> that doing in my function? Did I put that there?
>
> The user probably rembemers having set "debug on entry" for the
> function, and has
Below is a quick "proof-of-concept" patch for src/eval.c and
lisp/emacs-lisp/debug.el to get a better idea of what I mean. As you
can see, the change to eval.c isn't that big.
The code is not unclean, but I don't think it is a real problem
that the debug-on-entry code is visible. So
> does it have any real impact?
It can be confusing for new users of the debugger: Hey, what's that
doing in my function? Did I put that there?
The user probably rembemers having set "debug on entry" for the function,
and has just been reminded by entering the debugger, so that ought
Temporary setting debugger-jumping-flag
would solve the problem of stepping into the code of the debugger.
(I'll implement this fix.)
Thanks.
The debug-entry-code would still be
visible in the backtrace however.
That is not a problem. It might e
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> This gives a backtrace like this:
>
>> -- Buffer: *Backtrace* --
>> Debugger entered--entering a function:
>> * (lambda (var) (if (or inhibit-debug-on-entry debugger-jumping-flag) nil
>> (debug ...)) (list (quote setq) var (list ... var)))(x)
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> I see you implemented this. This makes debug-on-entry for macros a
>> lot better, of course. Thanks. But the problem I mentioned remains:
>> the debug-entry-code is visible.
> [...]
>> Debugger entered--entering a function:
>> * (lambda (var) (if (o
> This gives a backtrace like this:
> -- Buffer: *Backtrace* --
> Debugger entered--entering a function:
> * (lambda (var) (if (or inhibit-debug-on-entry debugger-jumping-flag) nil
> (debug ...)) (list (quote setq) var (list ... var)))(x)
> (inc x)
> (progn (setq x 0) (inc x))
> ev
Richard Stallman <[EMAIL PROTECTED]> writes:
>The only solution (within the current implementation) that I can
>think of, is to temporarily remove all debug-on-entry code while
>stepping with `d'.
>
> Would setting inhibit-debug-on-entry temporarily do the job?
inhibit-deb
The only solution (within the current implementation) that I can
think of, is to temporarily remove all debug-on-entry code while
stepping with `d'.
Would setting inhibit-debug-on-entry temporarily do the job?
I can think of two points in a macro to set a break for the
> I see you implemented this. This makes debug-on-entry for macros a
> lot better, of course. Thanks. But the problem I mentioned remains:
> the debug-entry-code is visible.
[...]
> Debugger entered--entering a function:
> * (lambda (var) (if (or inhibit-debug-on-entry debugger-jumping-flag) nil
Stefan Monnier <[EMAIL PROTECTED]> writes:
>>I can think of two points in a macro to set a break for the
>>debugger: just before macro expansion and just after it, right
>>before the evaluation of the resulting sexp. In both cases,
>>hiding the debug-on-entry code from the user of
drkm <[EMAIL PROTECTED]> writes:
> Really?-)
Ouch. That should have been:
unsigned debug_on_entry : 1;
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo
[EMAIL PROTECTED] (Kim F. Storm) writes:
> You could define a bit in the Lisp_Symbol, like this:
> struct Lisp_Symbol
> {
[...]
> unsigned debug_on_entry;
^^^
Really?-)
--drkm
___
Emacs-devel mailing list
Emacs-dev
Lute Kamstra <[EMAIL PROTECTED]> writes:
> When I was thinking about these three problems, it seemed to me that
> the easiest and simplest thing to do, is to move support for
> debug-on-entry into the C implementation of the Lisp interpreter. To
> mark a function for debug-on-entry, you could set
>I can think of two points in a macro to set a break for the
>debugger: just before macro expansion and just after it, right
>before the evaluation of the resulting sexp. In both cases, hiding
>the debug-on-entry code from the user of the debugger seems not
>possible.
To me "e
18 matches
Mail list logo
