unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Helmut Eller <eller.helmut@gmail.com>, 15101@debbugs.gnu.org
Subject: bug#15101: 24.3.50; debugger-eval-expression broken
Date: Thu, 15 Aug 2013 10:03:46 -0700 (PDT)	[thread overview]
Message-ID: <bf8fef2e-c06b-4e0e-a694-7a1682bd8033@default> (raw)
In-Reply-To: <jwvzjsiewtd.fsf-monnier+emacs@gnu.org>

> > In your judgment, can both the old `e' behavior and the new `e'
> > behavior be useful, at least for dynamically bound variables?
> 
> `e' while on the top line of the buffer gives you the old behavior
> (except it handles lexical vars if there were any when `debug' was
> called).

Yes, you said that.  This should be documented, of course, especially
since previously the cursor position was irrelevant for `e'.  So there
is at least a doc bug here, it seems.

You say that "this refinement can be useful for dynamically bound
variables" and is "indispensable" for lexically bound vars.

OK.  So just what is the usefulness?  What is a use case for `e' with
point not on the first line?  That too should be pointed out in the
doc - not obvious to me, at least.

And if it is NOT useful for someone to use `e' anywhere other than the
first line then why not have `e' act as if it were at bob?

Or if it is sometimes, but not typically, useful to use `e' other than
on the first line, how about a message letting an unaware user know that
the cursor is not on the first line and hence evaluation will not be in
the "context that called `debug'"?  That seems the least we could do
about this gotcha.

In sum, my concerns here are:

1. Is the non-first-line behavior of `e' really useful?  If not, maybe
   have the code work around it (always act as if on the first line).

2. Document the behavior (completely).  Describe the different use cases.

3. Consider a message informing the user that, because point is not
   on the first line, evaluation will not be done in the original context
   (and tell the user just what evaluation context will be used).

AFAICT, there is no mention of this in the doc yet.  I see that "lexical"
is mentioned only briefly in (elisp) `Edebug Eval' - and nothing about
this.  And it is not mentioned at all in the manual sections about the
standard, non-edebug debugger (i.e., command `debug').





  reply	other threads:[~2013-08-15 17:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-15 11:39 bug#15101: 24.3.50; debugger-eval-expression broken Helmut Eller
2013-08-15 14:45 ` Stefan Monnier
2013-08-15 15:06   ` Drew Adams
2013-08-15 16:37     ` Stefan Monnier
2013-08-15 17:03       ` Drew Adams [this message]
2013-08-15 17:16   ` Helmut Eller
2013-08-15 20:30     ` Stefan Monnier
2013-08-16  5:27       ` Helmut Eller
2013-08-16 16:14         ` Stefan Monnier
2013-08-16 17:03           ` Helmut Eller
2013-08-15 17:21   ` Stefan Monnier
2013-08-15 17:47     ` Drew Adams
2013-08-15 20:27       ` Stefan Monnier
2013-08-15 21:12         ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf8fef2e-c06b-4e0e-a694-7a1682bd8033@default \
    --to=drew.adams@oracle.com \
    --cc=15101@debbugs.gnu.org \
    --cc=eller.helmut@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).