unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lawrence Liu <smartlitchi@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Andrii Kolomoiets <andreyk.mad@gmail.com>, emacs-devel@gnu.org
Subject: Re: python: Let pdb tracking not kill buffers
Date: Mon, 7 Oct 2019 12:33:17 +0800	[thread overview]
Message-ID: <CANYRarBbodcARHcXKmvt2JR9Mi9DPB4EA2hqYUP3cwTfncXdsg@mail.gmail.com> (raw)
In-Reply-To: <83a7af66fo.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

Dear

I am a full time python developer and seems in my case mostly I am using
the way as below:

insert a

import pdb; pdb.set_trace();

in my code bass and trigger the break point from other place (mostly
browser) and wait for the break point been hit.

Thanks.

Eli Zaretskii <eliz@gnu.org>于2019年10月5日 周六14:41写道:

> > From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> > Date: Fri, 4 Oct 2019 23:32:09 +0300
> >
> > 1. echo "import pdb; pdb.set_trace()" > test.py
> > 2. emacs -Q
> > 3. M-x run-python
> > 4. M-x python-shell-send-file <RET> test.py <RET>
> >
> > Now there are two windows: one with pdb session and another one with
> > source code.
> > Now in pdb prompt: pass<RET>
> >
> > The source code buffer is killed because pdb tracking comint output
> > filter doesn't found file name in the output and decides that tracking
> > session is over.
> >
> > This behavior interferes with debug session. Moving frame up/down the
> > stack trace open new files but evaluating some code kill them when they
> > are still needed.
>
> Thanks.
>
> Aren't users supposed to use pdb via "M-x pdb" instead?  (I don't use
> this, and don't debug Python programs, so maybe my question makes no
> sense.)
>
> > Attached patch brings the following changes:
> >
> > - New variable `python-pdbtrack-kill-buffers' that make buffers killing
> >   optional;
> >
> > - Comint input filter which decides that the debug session is over;
> >
> > - Process sentinel to finish tracking when python process is killed.
> >
> > Please see attached patch. I certainly sure docstrings and naming are
> > not so good but they can be fine tuned later if the main idea will be
> > accepted.
>
> Besides the question I asked above, your patch is too large to be
> accepted without assigning copyright to the FSF.  Would you like to
> start the legal paperwork rolling, so that any contributions from you
> could be accepted without limitations?
>
> > +(defcustom python-pdbtrack-continue-command '("c" "cont" "continue")
> > +  "Pdb continue command."
> > +  :type 'list
> > +  :group 'python)
>
> Each new defcustom should have a :version tag.  Also, if they belong
> to the group of the current file, our convention is not to use :group,
> as that's redundant.
>
> In addition, please try making the doc strings explain how is the
> variable used and what is its effect, including (if applicable) the
> effect of special values, like nil etc.
>
> > +(defcustom python-pdbtrack-kill-buffers t
> > +  "Kill buffers when tracking is finished.
> > +Only buffers opened during tracking will be killed."
>
> The first sentence should be "If non-nil, kill buffers when tracking
> is finished."  (And that is somewhat unclear, because it isn't clear
> what it means "when tracking is finished".)
>
> --
Best Regards
Lawrence

[-- Attachment #2: Type: text/html, Size: 3984 bytes --]

  reply	other threads:[~2019-10-07  4:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 20:32 python: Let pdb tracking not kill buffers Andrii Kolomoiets
2019-10-05  6:40 ` Eli Zaretskii
2019-10-07  4:33   ` Lawrence Liu [this message]
2019-10-07 16:19     ` Eli Zaretskii
2019-10-07 16:26       ` Lawrence Liu
2019-10-07 12:28   ` Andrii Kolomoiets
2019-10-30 19:14     ` Andrii Kolomoiets
2019-11-01  9:35       ` Eli Zaretskii
2019-11-02 16:37         ` Andrii Kolomoiets
2019-11-02 17:29           ` Eli Zaretskii
2019-11-02 18:51             ` Andrii Kolomoiets
2019-11-07 16:57               ` Eli Zaretskii

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=CANYRarBbodcARHcXKmvt2JR9Mi9DPB4EA2hqYUP3cwTfncXdsg@mail.gmail.com \
    --to=smartlitchi@gmail.com \
    --cc=andreyk.mad@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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).