GNU bug report logs - #49073
28.0.50; python-send-to-repl functions misbehave

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49073 in the body.
You can then email your comments to 49073 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: dalanicolai <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; python-send-to-repl functions misbehave
Date: Thu, 17 Jun 2021 16:53:02 +0200

This is a combined bug report for two unrelated but still somewhat
related bugs.

- The first bug is that when using `python-send-to-repl` functions, the
  input does not get printed in the REPL buffer.
- The second bug is that for various setups, even the output does not
  get printed properly.

The reason for this bug report, which might arguably have the best
description, is
the Spacemacs issue at
https://github.com/syl20bnr/spacemacs/issues/14845.

Start emacs with -Q flag. Open a python buffer/.py file.
Call `M-x run-python`
type e.g. 2+2
now send to REPL with `M-x python-shell-send-buffer/statement`

The input does not get printed in the REPL (as I would expect from
sending to REPL).  This could be intentionally, but I would say that at
least `python-shell-send-statement` should print also the input.

Then secondly, often, even the output does not get printed (when
not sending an explicit print statement).
This seems to occur when sending more then two lines (e.g. when using
`python-shell-send-buffer` in a buffer that
starts with an empty line and has 2+2 on the second line). So then the
'interactivity` of using the repl got totally lost.This is a combined
bug report for two unrelated but still somewhat related bugs.

- The first bug is that when using `python-send-to-repl` functions, the
input
  does not get printed in the REPL buffer. - The second bug is that for
various
  setups, even the output does not get printed properly.

The reason for this bug report is the Spacemacs issue at
https://github.com/syl20bnr/spacemacs/issues/14845.

To reproduce:

- Start emacs with -Q flag.
- Open a python buffer/.py file.
- Call `M-x run-python`
- type e.g. 2+2 and send to REPL with `M-x python-shell-send-
buffer/statement`

The INPUT does not get printed in the REPL (as I would expect from
sending to
REPL). This could be intentionally, but I would say that at least
`python-shell-send-statement` should print also the input.

Then secondly, often, even the output does not get printed (when
not sending an explicit print statement).
This seems to occur when sending more then two lines (e.g. when using
`python-shell-send-buffer` in a buffer that
starts with an empty line and has 2+2 on the second line). So then the
'interactivity` of using the REPL got totally lost.


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.25, cairo version 1.16.0)
 of 2021-02-18 built on daniel-fedora
Repository revision: 185121da6978553d538d37d6d0e67dc52e13311f
Repository branch: feature/native-comp
Windowing system distributor 'The X.Org Foundation', version
11.0.12011000
System Description: Fedora 34 (Workstation Edition)

Configured using:
 'configure --with-nativecomp'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(thingatpt compile cl-extra python tramp-sh tramp tramp-loaddefs
trampver tramp-integration files-x tramp-compat shell pcomplete
parse-time iso8601 ls-lisp format-spec comint ring ansi-color help-mode
pp shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core eieio-loaddefs
password-cache json map cl-macs text-property-search time-date subr-x
seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-
loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-
utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face pcase macroexp
files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process
nativecomp emacs)

Memory information:
((conses 16 100433 12328)
 (symbols 48 9063 1)
 (strings 32 27932 1704)
 (string-bytes 1 968685)
 (vectors 16 16800)
 (vector-slots 8 337783 21001)
 (floats 8 47 279)
 (intervals 56 252 0)
 (buffers 992 14))

Message #8 received at 49073 <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: dalanicolai <at> gmail.com
Cc: 49073 <at> debbugs.gnu.org
Subject: Re: bug#49073: 28.0.50; python-send-to-repl functions misbehave
Date: Sat, 28 Aug 2021 11:43:02 +0200

On Thu, 17 Jun 2021 at 16:53, dalanicolai <at> gmail.com wrote:

> This is a combined bug report for two unrelated but still somewhat
> related bugs.
>
> - The first bug is that when using `python-send-to-repl` functions, the
>   input does not get printed in the REPL buffer.
> - The second bug is that for various setups, even the output does not
>   get printed properly.
>

See the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49822#45
for a proposed solution to the second problem.

As to the first problem (not echoing the input): I think this would be
pretty hard to implement in a dumb terminal.  You could try running the
Python shell in a terminal emulator (term or vterm) and write a macro to
paste regions of text into it.  In any case, echoing the input also
seems to be a somewhat unconventional behavior.  I don't think I would
want that.

PS: By 'python-send-to-repl' I assume you mean the 'python-shell-send-*'
family of commands, or do you refer to some external package?

Message #11 received at 49073 <at> debbugs.gnu.org (full text, mbox):

From: dalanicolai <dalanicolai <at> gmail.com>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 49073 <at> debbugs.gnu.org
Subject: Re: bug#49073: 28.0.50; python-send-to-repl functions misbehave
Date: Sat, 28 Aug 2021 14:56:35 +0200

[Message part 1 (text/plain, inline)]

Thanks for the update! Unfortunately, I actually rarely code in python. It
was
just when I did for a moment, then I noticed this surprising behavior of the
'python-send-repl' functions (which turned out to be partly a Spacemacs
issue,
and partly fixed already through the extra flag for (not) sending the coding
cookie).

About the first 'bug' (showing the input), I was considering the ipython
shell
where one can refer to previous input by its number. But I agree that for
send-to-repl functions printing the input is not a very useful addition.

Looking at the description of the patch, the new behavior looks preferable
to me
as it is generally nice to see some values when sending statements/code
during
interactive development.


On Sat, 28 Aug 2021 at 11:43, Augusto Stoffel <arstoffel <at> gmail.com> wrote:

> On Thu, 17 Jun 2021 at 16:53, dalanicolai <at> gmail.com wrote:
>
> > This is a combined bug report for two unrelated but still somewhat
> > related bugs.
> >
> > - The first bug is that when using `python-send-to-repl` functions, the
> >   input does not get printed in the REPL buffer.
> > - The second bug is that for various setups, even the output does not
> >   get printed properly.
> >
>
> See the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49822#45
> for a proposed solution to the second problem.
>
> As to the first problem (not echoing the input): I think this would be
> pretty hard to implement in a dumb terminal.  You could try running the
> Python shell in a terminal emulator (term or vterm) and write a macro to
> paste regions of text into it.  In any case, echoing the input also
> seems to be a somewhat unconventional behavior.  I don't think I would
> want that.
>
> PS: By 'python-send-to-repl' I assume you mean the 'python-shell-send-*'
> family of commands, or do you refer to some external package?
>

[Message part 2 (text/html, inline)]

Message #14 received at 49073 <at> debbugs.gnu.org (full text, mbox):

From: Ben Sturmfels <ben <at> sturm.com.au>
To: dalanicolai <at> gmail.com
Cc: 49073 <at> debbugs.gnu.org
Subject: Re: bug#49073: 28.0.50; python-send-to-repl functions misbehave
Date: Sat, 26 Feb 2022 10:23:38 +1100

On Thu, 17 Jun 2021, dalanicolai <at> gmail.com wrote:

> This is a combined bug report for two unrelated but still somewhat
> related bugs.
>
> - The first bug is that when using `python-send-to-repl` functions, the
>   input does not get printed in the REPL buffer.

This seems similar to bug#29592: 25.3; python does not print input or
output in the inferior process.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29592

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Ben Sturmfels via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 49073 <at> debbugs.gnu.org, dalanicolai <at> gmail.com,
 Ben Sturmfels <ben <at> sturm.com.au>
Subject: Re: bug#49073: 28.0.50; python-send-to-repl functions misbehave
Date: Sat, 26 Feb 2022 17:24:11 +0100

On Sat, 26 Feb 2022 at 10:23, Ben Sturmfels via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> wrote:

> On Thu, 17 Jun 2021, dalanicolai <at> gmail.com wrote:
>
>> This is a combined bug report for two unrelated but still somewhat
>> related bugs.
>>
>> - The first bug is that when using `python-send-to-repl` functions, the
>>   input does not get printed in the REPL buffer.

This is by design.  It's not too hard to copy the evaluated code to the
comint buffer, and I toyed a bit with it, eventually concluding that
it's not all that great of a feature.

As to the second point mentioned in the original message of this bug
(“for various setups, even the output does not get printed properly”), I
can't observe this, so a minimal recipe to reproduce would be
appreciated.

>
> This seems similar to bug#29592: 25.3; python does not print input or
> output in the inferior process.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29592

Message #23 received at 49073 <at> debbugs.gnu.org (full text, mbox):

From: Ben Sturmfels <ben <at> sturm.com.au>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 49073 <at> debbugs.gnu.org, dalanicolai <at> gmail.com
Subject: Re: bug#49073: 28.0.50; python-send-to-repl functions misbehave
Date: Mon, 28 Feb 2022 10:07:26 +1100

On Sat, 26 Feb 2022, Augusto Stoffel wrote:

> As to the second point mentioned in the original message of this bug
> (“for various setups, even the output does not get printed properly”), I
> can't observe this, so a minimal recipe to reproduce would be
> appreciated.

I believe this second point is the same as closed bug #29592. It's fixed
in 28.0.91 but wasn't fixed in 28.0.50.

Regards,
Ben

Message #26 received at 49073 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ben Sturmfels <ben <at> sturm.com.au>
Cc: 49073 <at> debbugs.gnu.org, dalanicolai <at> gmail.com,
 Augusto Stoffel <arstoffel <at> gmail.com>
Subject: Re: bug#49073: 28.0.50; python-send-to-repl functions misbehave
Date: Mon, 28 Feb 2022 10:10:08 +0100

Ben Sturmfels <ben <at> sturm.com.au> writes:

>> As to the second point mentioned in the original message of this bug
>> (“for various setups, even the output does not get printed properly”), I
>> can't observe this, so a minimal recipe to reproduce would be
>> appreciated.
>
> I believe this second point is the same as closed bug #29592. It's fixed
> in 28.0.91 but wasn't fixed in 28.0.50.

And skimming this bug report, it looks like the first point was fixed
earlier?  So I'm closing this bug report.  If I misunderstood, please
respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.