GNU logs - #32986, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output 
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Oct 2018 10:49:01 +0000
Resent-Message-ID: <handler.32986.B.153899571029234 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 32986 <at> debbugs.gnu.org
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 08 Oct 2018 11:48:01 +0100
Message-ID: <jjbh8hwpvdq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hello maintainers,

I've asked this in Emacs devel already:
https://lists.gnu.org/archive/html/emacs-devel/2018-10/msg00037.html. Someone
suggested I report it as a bug.  It happens Windows (machine of bug
report), but also on my Ubuntu virtual server.

I would expect while-no-input to break out of accept-process-output very
quickly after user keyboard input.  These expectations are met except
for some situations.  Here's some test code:

   (defmacro joaot/time (&rest body)
     `(let ((start (current-time)))
        (prog1
            (progn ,@body)
          (let ((msg (format "Took %s seconds and returned "
                             (format-time-string
                              "%S.%3N"
                              (time-subtract (current-time) start)))))
            (if current-prefix-arg
                (insert "; " msg)
              (message msg))))))

Now, after each of these, I'm pressing C-u C-x C-e SPC as fast as I can.
The second result is unexpected, all the others are fine. Moreover, it
varies from 0.7s to as much as 5s.  

    (joaot/time
     (while-no-input
       (while t (accept-process-output nil 0.05)))); Expected, took 00.201 seconds and returned t 
     
    (joaot/time
     (while-no-input
       (while t (accept-process-output nil 30)))); Took 02.694 seconds and returned t 
     
    (joaot/time
     (while (sit-for 30))); Took 00.126 seconds and returned nil 
     
    (joaot/time
     (while (sit-for 0.1))) ; Took 00.093 seconds and returned nil

I tried quickly pluggin GDB in at the right time, but I don't know if
I'm using the right GDB (using msys's which is pretty slow) and I
probably should be using an unoptimized Emacs.  Anyway, as a start this
is what "bt full" look like:

   (gdb) bt full
   #0  0x00007ffc97b0d8c1 in ntdll!DbgBreakPoint () from /c/WINDOWS/SYSTEM32/ntdll.dll
   No symbol table info available.
   #1  0x00007ffc97b39a0b in ntdll!DbgUiRemoteBreakin () from /c/WINDOWS/SYSTEM32/ntdll.dll
   No symbol table info available.
   #2  0x00007ffc952b3034 in KERNEL32!BaseThreadInitThunk ()
      from /c/WINDOWS/System32/KERNEL32.DLL
   No symbol table info available.
   #3  0x00007ffc97ae1461 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
   No symbol table info available.
   #4  0x0000000000000000 in ?? ()
   No symbol table info available.
   Backtrace stopped: previous frame inner to this frame (corrupt stack?)
   (gdb) xbacktrace
   Undefined command: "xbacktrace".  Try "help".

xbacktrace probably failed because of some Python error loading .gdbinit

In GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32)
 of 2018-10-02 built on GONDOMAR
Repository revision: dfbb207ff946792efebb31c0c59b8245c304544a
Windowing system distributor 'Microsoft Corp.', version 10.0.17134
System Description: Microsoft Windows 10 Pro (v10.0.1803.17134.286)

Recent messages:
joaot/time
Quit
Mark set
Quit
Mark set
Is this a siscog mail? (y or n) n
Quit [4 times]
Mark set [2 times]
Auto-saving...done
Type C-x 1 to delete the help window.
Quit [3 times]
Configured using:
 'configure --prefix=/c/emacs/emacs-26 --without-imagemagick
 --without-dbus'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS JSON LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: PTG
  locale-coding-system: cp1252

Major mode: Message

Minor modes in effect:
  gnus-message-citation-mode: t
  diff-auto-refine-mode: t
  savehist-mode: t
  winner-mode: t
  ido-everywhere: t
  electric-pair-mode: t
  delete-selection-mode: t
  global-auto-revert-mode: t
  show-paren-mode: t
  mml-mode: t
  company-quickhelp-mode: t
  company-quickhelp-local-mode: t
  global-aggressive-indent-mode: t
  shell-dirtrack-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-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
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
Error during checking
Features:
(shadow emacsbug darkroom face-remap gnus-dup flymake-cc
display-line-numbers autoload trace imenu ...)

Memory information:
((conses 16 944904 133288)
 (symbols 56 54804 49)
 (strings 32 196879 15626)
 (string-bytes 1 4881114)
 (vectors 16 98591)
 (vector-slots 8 2249333 86252)
 (floats 8 863 1865)
 (intervals 56 47943 2025)
 (buffers 992 132))

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Subject: bug#32986: Acknowledgement (27.0.50; unexpected delay in
 while-no-input + accept-process-output )
Message-ID: <handler.32986.B.153899571029234.ack <at> debbugs.gnu.org>
References: <jjbh8hwpvdq.fsf@HIDDEN>
X-Gnu-PR-Message: ack 32986
X-Gnu-PR-Package: emacs
Reply-To: 32986 <at> debbugs.gnu.org
Date: Mon, 08 Oct 2018 10:49:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 32986 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
32986: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D32986
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Oct 2018 15:07:01 +0000
Resent-Message-ID: <handler.32986.B32986.153901118915862 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Date: Mon, 08 Oct 2018 18:05:57 +0300
Message-Id: <83sh1gzdey.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <jjbh8hwpvdq.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Mon, 08 Oct 2018 11:48:01 +0100)
References: <jjbh8hwpvdq.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Jo�o T�vora <joaotavora@HIDDEN>
> Date: Mon, 08 Oct 2018 11:48:01 +0100
> 
> I would expect while-no-input to break out of accept-process-output very
> quickly after user keyboard input.  These expectations are met except
> for some situations.

I think your expectations are incorrect.  My expectations are that if
you call accept-process-output with a timeout of 30 sec, then
while-no-input will return after 30 sec plus a small delay.  It's just
that in order to see this in action, your experiment must be done in a
"clean room", and that is not easy.

First, one basic fact: accept-process-output calls
wait_reading_process_output in a way that instructs it not to wait for
keyboard input, you can see that clearly in the code (read_kbd is
passed as zero).  This means that wait_reading_process_output will
call pselect with the timeout of 30 sec (in your case), and will wait
that long before it returns (unless there's a subprocess that gives us
some stuff).  So why would you expect while-no-input that calls
accept-process-output with that timeout to return earlier?

Maybe you expect while-no-input to interrupt the pselect call when you
press SPC?  But that's not how keyboard input works in Emacs.  In some
configurations (e.g., GUI frame on X), keyboard input indeed delivers
a signal to Emacs, but the signal handler just sets a flag and
returns, it doesn't jump out of the pselect call.  It is then the job
of the running Lisp code to check whether keyboard input is available,
and act accordingly: set the quit-flag, and then test that flag soon
enough to return from while-no-input.  But since the "running Lisp
code" is in this case stuck in the pselect call, it cannot do anything
before pselect returns, right?

Now to the "clean room" part: the reason why you don't always see this
30-sec delay is because there are several factors that "contaminate"
the picture:

  . timers -- these cause us to reduce the timeout until the
    expiration time of the next timer, so pselect returns earlier than
    after 30 sec
  . the first time wait_reading_process_output is called, it almost
    immediately checks for available keyboard input, before it calls
    pselect

Therefore, to see the 30-sec delay, you need:

  . stop all timers, which in "emacs -Q" means:
    . disable blink-cursor-mode
    . disable global-eldoc-mode
    . disable font-lock-mode
    . cancel the undo--auto-bindary-timer (I did that via list-timers)
  . type "C-u C-x C-e", wait for a few seconds, and only then type SPC

If I do all of the above, I see 30 sec plus a small delay every time I
run your 2nd test.

> I tried quickly pluggin GDB in at the right time, but I don't know if
> I'm using the right GDB (using msys's which is pretty slow) and I
> probably should be using an unoptimized Emacs.  Anyway, as a start this
> is what "bt full" look like:
> 
>    (gdb) bt full
>    #0  0x00007ffc97b0d8c1 in ntdll!DbgBreakPoint () from /c/WINDOWS/SYSTEM32/ntdll.dll
>    No symbol table info available.
>    #1  0x00007ffc97b39a0b in ntdll!DbgUiRemoteBreakin () from /c/WINDOWS/SYSTEM32/ntdll.dll
>    No symbol table info available.
>    #2  0x00007ffc952b3034 in KERNEL32!BaseThreadInitThunk ()
>       from /c/WINDOWS/System32/KERNEL32.DLL
>    No symbol table info available.
>    #3  0x00007ffc97ae1461 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
>    No symbol table info available.
>    #4  0x0000000000000000 in ?? ()

On Windows, when you attach a debugger to a program, the OS creates a
special thread in the debuggee, and that is the thread whose backtrace
you see here.  That thread is never an interesting one, so the first
thing you need to do after attaching is switch to the Lisp thread, by
typing "thread 1" at the GDB prompt.  Then the backtrace will make
much more sense.

>    Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>    (gdb) xbacktrace
>    Undefined command: "xbacktrace".  Try "help".
> 
> xbacktrace probably failed because of some Python error loading .gdbinit

No, it says "Undefined command", which means it doesn't know what
xbacktrace is.  You probably didn't start GDB from the Emacs's src
directory, so it didn't read the .gdbinit file which defines that
command.  You can do that manually by typing the command

  (gdb) source /path/to/emacs/src/.gdbinit

(This last part is not specific to Widnows.)

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Oct 2018 20:07:02 +0000
Resent-Message-ID: <handler.32986.B32986.153902919319132 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
In-Reply-To: <83sh1gzdey.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 8 Oct 2018 21:06:12 +0100
Message-ID: <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000e5bcdf0577bd2766"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--000000000000e5bcdf0577bd2766
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Eli,

I will fully read and process your thorough reply later tonight or
tomorrow, but in the meantime let me just restate, or clarify in case it
wasn't clear, that I expect the 30s, 15s and 0.1s case to break equally as
quickly, namely as quick as I can type the first input.

And indeed that's what happens on Linux and Mac OSX, but not on Windows.
If your reply already addresses this apparent discrepancy, then I apologize
for my premature clarification in advance.

Thanks,
Jo=C3=A3o



On Mon, Oct 8, 2018, 16:06 Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> > Date: Mon, 08 Oct 2018 11:48:01 +0100
> >
> > I would expect while-no-input to break out of accept-process-output ver=
y
> > quickly after user keyboard input.  These expectations are met except
> > for some situations.
>
> I think your expectations are incorrect.  My expectations are that if
> you call accept-process-output with a timeout of 30 sec, then
> while-no-input will return after 30 sec plus a small delay.  It's just
> that in order to see this in action, your experiment must be done in a
> "clean room", and that is not easy.
>
> First, one basic fact: accept-process-output calls
> wait_reading_process_output in a way that instructs it not to wait for
> keyboard input, you can see that clearly in the code (read_kbd is
> passed as zero).  This means that wait_reading_process_output will
> call pselect with the timeout of 30 sec (in your case), and will wait
> that long before it returns (unless there's a subprocess that gives us
> some stuff).  So why would you expect while-no-input that calls
> accept-process-output with that timeout to return earlier?
>
> Maybe you expect while-no-input to interrupt the pselect call when you
> press SPC?  But that's not how keyboard input works in Emacs.  In some
> configurations (e.g., GUI frame on X), keyboard input indeed delivers
> a signal to Emacs, but the signal handler just sets a flag and
> returns, it doesn't jump out of the pselect call.  It is then the job
> of the running Lisp code to check whether keyboard input is available,
> and act accordingly: set the quit-flag, and then test that flag soon
> enough to return from while-no-input.  But since the "running Lisp
> code" is in this case stuck in the pselect call, it cannot do anything
> before pselect returns, right?
>
> Now to the "clean room" part: the reason why you don't always see this
> 30-sec delay is because there are several factors that "contaminate"
> the picture:
>
>   . timers -- these cause us to reduce the timeout until the
>     expiration time of the next timer, so pselect returns earlier than
>     after 30 sec
>   . the first time wait_reading_process_output is called, it almost
>     immediately checks for available keyboard input, before it calls
>     pselect
>
> Therefore, to see the 30-sec delay, you need:
>
>   . stop all timers, which in "emacs -Q" means:
>     . disable blink-cursor-mode
>     . disable global-eldoc-mode
>     . disable font-lock-mode
>     . cancel the undo--auto-bindary-timer (I did that via list-timers)
>   . type "C-u C-x C-e", wait for a few seconds, and only then type SPC
>
> If I do all of the above, I see 30 sec plus a small delay every time I
> run your 2nd test.
>
> > I tried quickly pluggin GDB in at the right time, but I don't know if
> > I'm using the right GDB (using msys's which is pretty slow) and I
> > probably should be using an unoptimized Emacs.  Anyway, as a start this
> > is what "bt full" look like:
> >
> >    (gdb) bt full
> >    #0  0x00007ffc97b0d8c1 in ntdll!DbgBreakPoint () from
> /c/WINDOWS/SYSTEM32/ntdll.dll
> >    No symbol table info available.
> >    #1  0x00007ffc97b39a0b in ntdll!DbgUiRemoteBreakin () from
> /c/WINDOWS/SYSTEM32/ntdll.dll
> >    No symbol table info available.
> >    #2  0x00007ffc952b3034 in KERNEL32!BaseThreadInitThunk ()
> >       from /c/WINDOWS/System32/KERNEL32.DLL
> >    No symbol table info available.
> >    #3  0x00007ffc97ae1461 in ntdll!RtlUserThreadStart () from
> /c/WINDOWS/SYSTEM32/ntdll.dll
> >    No symbol table info available.
> >    #4  0x0000000000000000 in ?? ()
>
> On Windows, when you attach a debugger to a program, the OS creates a
> special thread in the debuggee, and that is the thread whose backtrace
> you see here.  That thread is never an interesting one, so the first
> thing you need to do after attaching is switch to the Lisp thread, by
> typing "thread 1" at the GDB prompt.  Then the backtrace will make
> much more sense.
>
> >    Backtrace stopped: previous frame inner to this frame (corrupt stack=
?)
> >    (gdb) xbacktrace
> >    Undefined command: "xbacktrace".  Try "help".
> >
> > xbacktrace probably failed because of some Python error loading .gdbini=
t
>
> No, it says "Undefined command", which means it doesn't know what
> xbacktrace is.  You probably didn't start GDB from the Emacs's src
> directory, so it didn't read the .gdbinit file which defines that
> command.  You can do that manually by typing the command
>
>   (gdb) source /path/to/emacs/src/.gdbinit
>
> (This last part is not specific to Widnows.)
>

--000000000000e5bcdf0577bd2766
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hello Eli,<div dir=3D"auto"><br></div><div dir=3D"auto">I=
 will fully read and process your thorough reply later tonight or tomorrow,=
 but in the meantime let me just restate, or clarify in case it wasn&#39;t =
clear, that I expect the 30s, 15s and 0.1s case to break equally as quickly=
, namely as quick as I can type the first input.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">And indeed that&#39;s what happens on Linux and Ma=
c OSX, but not on Windows.=C2=A0 If your reply already addresses this appar=
ent discrepancy, then I apologize for my premature clarification in advance=
.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Thanks,</div><div dir=
=3D"auto">Jo=C3=A3o</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 8, =
2018, 16:06 Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; From: Jo=C3=A3o=
 T=C3=A1vora &lt;<a href=3D"mailto:joaotavora@HIDDEN" target=3D"_blank" =
rel=3D"noreferrer">joaotavora@HIDDEN</a>&gt;<br>
&gt; Date: Mon, 08 Oct 2018 11:48:01 +0100<br>
&gt; <br>
&gt; I would expect while-no-input to break out of accept-process-output ve=
ry<br>
&gt; quickly after user keyboard input.=C2=A0 These expectations are met ex=
cept<br>
&gt; for some situations.<br>
<br>
I think your expectations are incorrect.=C2=A0 My expectations are that if<=
br>
you call accept-process-output with a timeout of 30 sec, then<br>
while-no-input will return after 30 sec plus a small delay.=C2=A0 It&#39;s =
just<br>
that in order to see this in action, your experiment must be done in a<br>
&quot;clean room&quot;, and that is not easy.<br>
<br>
First, one basic fact: accept-process-output calls<br>
wait_reading_process_output in a way that instructs it not to wait for<br>
keyboard input, you can see that clearly in the code (read_kbd is<br>
passed as zero).=C2=A0 This means that wait_reading_process_output will<br>
call pselect with the timeout of 30 sec (in your case), and will wait<br>
that long before it returns (unless there&#39;s a subprocess that gives us<=
br>
some stuff).=C2=A0 So why would you expect while-no-input that calls<br>
accept-process-output with that timeout to return earlier?<br>
<br>
Maybe you expect while-no-input to interrupt the pselect call when you<br>
press SPC?=C2=A0 But that&#39;s not how keyboard input works in Emacs.=C2=
=A0 In some<br>
configurations (e.g., GUI frame on X), keyboard input indeed delivers<br>
a signal to Emacs, but the signal handler just sets a flag and<br>
returns, it doesn&#39;t jump out of the pselect call.=C2=A0 It is then the =
job<br>
of the running Lisp code to check whether keyboard input is available,<br>
and act accordingly: set the quit-flag, and then test that flag soon<br>
enough to return from while-no-input.=C2=A0 But since the &quot;running Lis=
p<br>
code&quot; is in this case stuck in the pselect call, it cannot do anything=
<br>
before pselect returns, right?<br>
<br>
Now to the &quot;clean room&quot; part: the reason why you don&#39;t always=
 see this<br>
30-sec delay is because there are several factors that &quot;contaminate&qu=
ot;<br>
the picture:<br>
<br>
=C2=A0 . timers -- these cause us to reduce the timeout until the<br>
=C2=A0 =C2=A0 expiration time of the next timer, so pselect returns earlier=
 than<br>
=C2=A0 =C2=A0 after 30 sec<br>
=C2=A0 . the first time wait_reading_process_output is called, it almost<br=
>
=C2=A0 =C2=A0 immediately checks for available keyboard input, before it ca=
lls<br>
=C2=A0 =C2=A0 pselect<br>
<br>
Therefore, to see the 30-sec delay, you need:<br>
<br>
=C2=A0 . stop all timers, which in &quot;emacs -Q&quot; means:<br>
=C2=A0 =C2=A0 . disable blink-cursor-mode<br>
=C2=A0 =C2=A0 . disable global-eldoc-mode<br>
=C2=A0 =C2=A0 . disable font-lock-mode<br>
=C2=A0 =C2=A0 . cancel the undo--auto-bindary-timer (I did that via list-ti=
mers)<br>
=C2=A0 . type &quot;C-u C-x C-e&quot;, wait for a few seconds, and only the=
n type SPC<br>
<br>
If I do all of the above, I see 30 sec plus a small delay every time I<br>
run your 2nd test.<br>
<br>
&gt; I tried quickly pluggin GDB in at the right time, but I don&#39;t know=
 if<br>
&gt; I&#39;m using the right GDB (using msys&#39;s which is pretty slow) an=
d I<br>
&gt; probably should be using an unoptimized Emacs.=C2=A0 Anyway, as a star=
t this<br>
&gt; is what &quot;bt full&quot; look like:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 (gdb) bt full<br>
&gt;=C2=A0 =C2=A0 #0=C2=A0 0x00007ffc97b0d8c1 in ntdll!DbgBreakPoint () fro=
m /c/WINDOWS/SYSTEM32/ntdll.dll<br>
&gt;=C2=A0 =C2=A0 No symbol table info available.<br>
&gt;=C2=A0 =C2=A0 #1=C2=A0 0x00007ffc97b39a0b in ntdll!DbgUiRemoteBreakin (=
) from /c/WINDOWS/SYSTEM32/ntdll.dll<br>
&gt;=C2=A0 =C2=A0 No symbol table info available.<br>
&gt;=C2=A0 =C2=A0 #2=C2=A0 0x00007ffc952b3034 in KERNEL32!BaseThreadInitThu=
nk ()<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0from /c/WINDOWS/System32/KERNEL32.DLL<br>
&gt;=C2=A0 =C2=A0 No symbol table info available.<br>
&gt;=C2=A0 =C2=A0 #3=C2=A0 0x00007ffc97ae1461 in ntdll!RtlUserThreadStart (=
) from /c/WINDOWS/SYSTEM32/ntdll.dll<br>
&gt;=C2=A0 =C2=A0 No symbol table info available.<br>
&gt;=C2=A0 =C2=A0 #4=C2=A0 0x0000000000000000 in ?? ()<br>
<br>
On Windows, when you attach a debugger to a program, the OS creates a<br>
special thread in the debuggee, and that is the thread whose backtrace<br>
you see here.=C2=A0 That thread is never an interesting one, so the first<b=
r>
thing you need to do after attaching is switch to the Lisp thread, by<br>
typing &quot;thread 1&quot; at the GDB prompt.=C2=A0 Then the backtrace wil=
l make<br>
much more sense.<br>
<br>
&gt;=C2=A0 =C2=A0 Backtrace stopped: previous frame inner to this frame (co=
rrupt stack?)<br>
&gt;=C2=A0 =C2=A0 (gdb) xbacktrace<br>
&gt;=C2=A0 =C2=A0 Undefined command: &quot;xbacktrace&quot;.=C2=A0 Try &quo=
t;help&quot;.<br>
&gt; <br>
&gt; xbacktrace probably failed because of some Python error loading .gdbin=
it<br>
<br>
No, it says &quot;Undefined command&quot;, which means it doesn&#39;t know =
what<br>
xbacktrace is.=C2=A0 You probably didn&#39;t start GDB from the Emacs&#39;s=
 src<br>
directory, so it didn&#39;t read the .gdbinit file which defines that<br>
command.=C2=A0 You can do that manually by typing the command<br>
<br>
=C2=A0 (gdb) source /path/to/emacs/src/.gdbinit<br>
<br>
(This last part is not specific to Widnows.)<br>
</blockquote></div>

--000000000000e5bcdf0577bd2766--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Oct 2018 20:26:01 +0000
Resent-Message-ID: <handler.32986.B32986.153903034521153 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.153903034521153
          (code B ref 32986); Mon, 08 Oct 2018 20:26:01 +0000
Received: (at 32986) by debbugs.gnu.org; 8 Oct 2018 20:25:45 +0000
Received: from localhost ([127.0.0.1]:40835 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1g9c65-0005V6-L2
	for submit <at> debbugs.gnu.org; Mon, 08 Oct 2018 16:25:45 -0400
Received: from eggs.gnu.org ([208.118.235.92]:60571)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1g9c63-0005Ut-TI
 for 32986 <at> debbugs.gnu.org; Mon, 08 Oct 2018 16:25:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1g9c5t-0003Vf-Pi
 for 32986 <at> debbugs.gnu.org; Mon, 08 Oct 2018 16:25:38 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44414)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1g9c5o-0003TJ-7p; Mon, 08 Oct 2018 16:25:30 -0400
Received: from [176.228.60.248] (port=4845 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1g9c5g-0004a3-Ij; Mon, 08 Oct 2018 16:25:23 -0400
Date: Mon, 08 Oct 2018 23:25:14 +0300
Message-Id: <83in2cyymt.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Mon, 8 Oct 2018 21:06:12
 +0100)
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: João Távora <joaotavora@HIDDEN>
> Date: Mon, 8 Oct 2018 21:06:12 +0100
> Cc: 32986 <at> debbugs.gnu.org
> 
> I will fully read and process your thorough reply later tonight or tomorrow, but in the meantime let me just
> restate, or clarify in case it wasn't clear, that I expect the 30s, 15s and 0.1s case to break equally as quickly,
> namely as quick as I can type the first input.
> 
> And indeed that's what happens on Linux and Mac OSX, but not on Windows.  If your reply already addresses
> this apparent discrepancy, then I apologize for my premature clarification in advance.

I didn't investigate the difference in behavior between Windows and
GNU/Linux, because I see similar behavior on both systems if I
neutralize all the "contaminating" factors which I described.  It is
possible that it's easier to get the 30-sec delay on Windows because
keyboard input works without signals there, and uses messaging between
2 threads running within the Emacs process.

In any case, my point is that your expectation for immediate return is
incorrect, and I tried to explain why.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Oct 2018 20:41:01 +0000
Resent-Message-ID: <handler.32986.B32986.153903121422672 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.153903121422672
          (code B ref 32986); Mon, 08 Oct 2018 20:41:01 +0000
Received: (at 32986) by debbugs.gnu.org; 8 Oct 2018 20:40:14 +0000
Received: from localhost ([127.0.0.1]:40852 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1g9cK5-0005tb-RG
	for submit <at> debbugs.gnu.org; Mon, 08 Oct 2018 16:40:14 -0400
Received: from mail-qt1-f176.google.com ([209.85.160.176]:44892)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1g9cK4-0005tL-5J
 for 32986 <at> debbugs.gnu.org; Mon, 08 Oct 2018 16:40:12 -0400
Received: by mail-qt1-f176.google.com with SMTP id c56-v6so22392388qtd.11
 for <32986 <at> debbugs.gnu.org>; Mon, 08 Oct 2018 13:40:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=NvlPDyOThVtr8XOmXjOGRltJOQ7WX6fHnPwOZ9/lr2k=;
 b=c5EviOjhytBD4oLLsl8BWiM8iuv/92ftHDncdeGthdTijySSrM1E122d/fBPFvkc4T
 wni0w0yIu6DQKHlEbJpwINV+ZoBI5achy9mF5CN8n46EklitYUJ4jS+YIlRTIzs17RHm
 ftgD6WevasXxEDJE6A8hC5iXgfMPAtdMvzQjYF8Xn5UF/PgtZlH09Um6CU4gJ6sZf0Nv
 2/LUvaFNPI3G61RgnE/Njlv39VTPzqIn+W2aXgmEAen7zP0mQULAzdhGNBYMLQCneu31
 woKbI3KLIveJPq7pRxA0yQcESWozdlHbtu0b/MEchNxiDcDlhsk0YPmCZYLdW93uNSoq
 kZgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=NvlPDyOThVtr8XOmXjOGRltJOQ7WX6fHnPwOZ9/lr2k=;
 b=BS54Z6LjD22z3vud4sX+VAJzYkcs6gG/+jRRwZele/aBGPJDv5ki03RmA75BuGfZ5+
 snU2XOGs+krzmKkzqZpoV/sXjsdDhiEfpAV/THoi/9o/gqAPxFdxzajUQvb91SxFx7md
 7e58TTstR35symCrkPQ57AqVxJWCURUs+JVL+EhvNlyK/Bsv/Sm4nQlfP1vvtMSr5UDz
 ewBDpm08Us5klb42d/C7Z8Je6tMccf/JNDL4ualQu+RChFq7OCJEzIwqmYxBZxpiI7Gs
 EAliClwDlW/g8vvS+cZ2BmIAZ6mQXqK4tQL08tdSY35MSLvELWc4NMlaZBcXd0911SR7
 o6GQ==
X-Gm-Message-State: ABuFfogqc11ZUGsjZscLW+O3MdxeTD4wao34/AhmzBnbLk6LxzMpHuk3
 4r14iGyO6zKiSZwFJlH8RAnTY3mvIIUl+sTwBD8=
X-Google-Smtp-Source: ACcGV62Dtx4rwc0wcecEt/+Hssu0vYF538gUSegr5IaJip4bZ8fQldoz2Q2NgOkldsAOH2w6YIBEW04aCDfTuAz0fg8=
X-Received: by 2002:ac8:435b:: with SMTP id
 a27-v6mr20142040qtn.295.1539031206521; 
 Mon, 08 Oct 2018 13:40:06 -0700 (PDT)
MIME-Version: 1.0
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
In-Reply-To: <83in2cyymt.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 8 Oct 2018 21:39:53 +0100
Message-ID: <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000005cef5d0577bda0c0"
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

--0000000000005cef5d0577bda0c0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for the clarification. I have now read the original explanation,
and it makes sense.  Ultimately, I think the sit-for is the right approach
for my wait-for-any-process-or-input problem.  Am I right to assume  it's
not affected by your explanation, and that I can expect immediate return
there?

If so, there's some unfortunate combination of factors that cause a
hard-to-reproduce hang in Emacs, at least in the packages where I use it.
But that's a matter for a future issue...

Thanks,
Jo=C3=A3o

On Mon, Oct 8, 2018, 21:25 Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> > Date: Mon, 8 Oct 2018 21:06:12 +0100
> > Cc: 32986 <at> debbugs.gnu.org
> >
> > I will fully read and process your thorough reply later tonight or
> tomorrow, but in the meantime let me just
> > restate, or clarify in case it wasn't clear, that I expect the 30s, 15s
> and 0.1s case to break equally as quickly,
> > namely as quick as I can type the first input.
> >
> > And indeed that's what happens on Linux and Mac OSX, but not on
> Windows.  If your reply already addresses
> > this apparent discrepancy, then I apologize for my premature
> clarification in advance.
>
> I didn't investigate the difference in behavior between Windows and
> GNU/Linux, because I see similar behavior on both systems if I
> neutralize all the "contaminating" factors which I described.  It is
> possible that it's easier to get the 30-sec delay on Windows because
> keyboard input works without signals there, and uses messaging between
> 2 threads running within the Emacs process.
>
> In any case, my point is that your expectation for immediate return is
> incorrect, and I tried to explain why.
>

--0000000000005cef5d0577bda0c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Thank you for the clarification. I have now read the orig=
inal explanation, and it makes sense.=C2=A0 Ultimately, I think the sit-for=
 is the right approach for my wait-for-any-process-or-input problem.=C2=A0 =
Am I right to assume=C2=A0 it&#39;s not affected by your explanation, and t=
hat I can expect immediate return there?<div dir=3D"auto"><br></div><div di=
r=3D"auto">If so, there&#39;s some unfortunate combination of factors that =
cause a hard-to-reproduce hang in Emacs, at least in the packages where I u=
se it.=C2=A0 But that&#39;s a matter for a future issue...</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Thanks,</div><div dir=3D"auto">Jo=C3=A3o=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 8, =
2018, 21:25 Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; From: Jo=C3=A3o=
 T=C3=A1vora &lt;<a href=3D"mailto:joaotavora@HIDDEN" target=3D"_blank" =
rel=3D"noreferrer">joaotavora@HIDDEN</a>&gt;<br>
&gt; Date: Mon, 8 Oct 2018 21:06:12 +0100<br>
&gt; Cc: <a href=3D"mailto:32986 <at> debbugs.gnu.org" target=3D"_blank" rel=3D"=
noreferrer">32986 <at> debbugs.gnu.org</a><br>
&gt; <br>
&gt; I will fully read and process your thorough reply later tonight or tom=
orrow, but in the meantime let me just<br>
&gt; restate, or clarify in case it wasn&#39;t clear, that I expect the 30s=
, 15s and 0.1s case to break equally as quickly,<br>
&gt; namely as quick as I can type the first input.<br>
&gt; <br>
&gt; And indeed that&#39;s what happens on Linux and Mac OSX, but not on Wi=
ndows.=C2=A0 If your reply already addresses<br>
&gt; this apparent discrepancy, then I apologize for my premature clarifica=
tion in advance.<br>
<br>
I didn&#39;t investigate the difference in behavior between Windows and<br>
GNU/Linux, because I see similar behavior on both systems if I<br>
neutralize all the &quot;contaminating&quot; factors which I described.=C2=
=A0 It is<br>
possible that it&#39;s easier to get the 30-sec delay on Windows because<br=
>
keyboard input works without signals there, and uses messaging between<br>
2 threads running within the Emacs process.<br>
<br>
In any case, my point is that your expectation for immediate return is<br>
incorrect, and I tried to explain why.<br>
</blockquote></div>

--0000000000005cef5d0577bda0c0--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 09 Oct 2018 02:33:01 +0000
Resent-Message-ID: <handler.32986.B32986.153905237830562 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.153905237830562
          (code B ref 32986); Tue, 09 Oct 2018 02:33:01 +0000
Received: (at 32986) by debbugs.gnu.org; 9 Oct 2018 02:32:58 +0000
Received: from localhost ([127.0.0.1]:41029 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1g9hpS-0007wr-Ho
	for submit <at> debbugs.gnu.org; Mon, 08 Oct 2018 22:32:58 -0400
Received: from eggs.gnu.org ([208.118.235.92]:57421)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1g9hpQ-0007wf-Hw
 for 32986 <at> debbugs.gnu.org; Mon, 08 Oct 2018 22:32:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1g9hpF-00021I-8J
 for 32986 <at> debbugs.gnu.org; Mon, 08 Oct 2018 22:32:51 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50581)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1g9hpC-0001z7-NN; Mon, 08 Oct 2018 22:32:44 -0400
Received: from [176.228.60.248] (port=3639 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1g9hpA-0007kq-Od; Mon, 08 Oct 2018 22:32:42 -0400
Date: Tue, 09 Oct 2018 05:32:35 +0300
Message-Id: <83h8hvzw70.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Mon, 8 Oct 2018 21:39:53
 +0100)
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: João Távora <joaotavora@HIDDEN>
> Date: Mon, 8 Oct 2018 21:39:53 +0100
> Cc: 32986 <at> debbugs.gnu.org
> 
> Thank you for the clarification. I have now read the original explanation, and it makes sense.  Ultimately, I think
> the sit-for is the right approach for my wait-for-any-process-or-input problem.  Am I right to assume  it's not
> affected by your explanation, and that I can expect immediate return there?

sit-for waits for keyboard input, so yes, it should return once the
user presses some key.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 09 Oct 2018 08:49:02 +0000
Resent-Message-ID: <handler.32986.B32986.15390748979357 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.15390748979357
          (code B ref 32986); Tue, 09 Oct 2018 08:49:02 +0000
Received: (at 32986) by debbugs.gnu.org; 9 Oct 2018 08:48:17 +0000
Received: from localhost ([127.0.0.1]:41160 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1g9nge-0002Qq-Le
	for submit <at> debbugs.gnu.org; Tue, 09 Oct 2018 04:48:16 -0400
Received: from mail-qt1-f182.google.com ([209.85.160.182]:42507)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1g9ngd-0002QY-Pl
 for 32986 <at> debbugs.gnu.org; Tue, 09 Oct 2018 04:48:16 -0400
Received: by mail-qt1-f182.google.com with SMTP id j46-v6so711146qtc.9
 for <32986 <at> debbugs.gnu.org>; Tue, 09 Oct 2018 01:48:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=N7ObH2x5zqy0fFK3jJWjWY1FFKzAo9ENIMIJraRSb8E=;
 b=VifvPq9dzRNOJnvxhZXHKizXIgEG3H78fdikneDaUQBoFcDZx5u6Qf0ldLFJIbJ4pr
 VWq0ET6+/6YwVz+fyFPiIiB2SCdwsd4msj+tY5B0sS32a1NQ9rLMCMbSzIn2tULQXBXP
 lLYfKT0R/WHgOJG7ldaKsN1AFz6Fb1L71mQvLMDf6ujmG5nDRd9YTNqgxJzBvIgcs6hn
 5zYekpvWn0+ZTvCgbTDDhRykERTDme3+zvPk7HPf2urvffaz0VsOVv89X02cuLeRRtlL
 wjvznJZyHfsbF4ns06h3N9/yyCDhXXJqpQfvEQKX6k4bxp1+f/o2ItchREJsgDut0Qy3
 BUFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=N7ObH2x5zqy0fFK3jJWjWY1FFKzAo9ENIMIJraRSb8E=;
 b=AgV3LvMIgoR+wL0zcEsiY7e78jAenViVUjzFMniSFviCnZXXbBm+HhX42zThled6x0
 eOnnMGRMaGXus93Uel1odnPUiv8UkSX9z3ChzjESmPn035h5l6N4BUCZSa1xEHKClWxF
 Cxnu2Nckx2jdKZXNy3MMCd94YPRO5A5vAftKsTZqzEY+HPuIwu1Pk1LvOyoIq0Pl4Q/b
 IpEB6C23wZZ2PSgmLPkcpkbIK3oTNgPrN2SResOUjZ5G3YINEACB4IYGv29g5+L6/7hh
 ZON21Z7kaQ19uSR4yPH43jvzgYp1rO+Q/Qe/PWOEaV2l9hcQMTT3rOTnU4S817rK649m
 0xNw==
X-Gm-Message-State: ABuFfohf490YqnPOkBAQCo4ptcTRixg2P6kvMrAk/8iljXYC59JguCsr
 Qs29mBetGa++CN543nAnTu/EOq0wUGxlISDYfeDLQw==
X-Google-Smtp-Source: ACcGV63jZIc5jwD0QazAm4xXLj9tyQBHti5F705TSbfbHk2MYHP+olUScsGeP2gYEsLiRswtIrzhZwJw8x8/WEd4tC4=
X-Received: by 2002:aed:2647:: with SMTP id
 z65-v6mr21377452qtc.301.1539074890282; 
 Tue, 09 Oct 2018 01:48:10 -0700 (PDT)
MIME-Version: 1.0
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
In-Reply-To: <83h8hvzw70.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 9 Oct 2018 09:47:58 +0100
Message-ID: <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000001e3b670577c7cc5a"
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

--0000000000001e3b670577c7cc5a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 9, 2018, 03:32 Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> > Date: Mon, 8 Oct 2018 21:39:53 +0100
> > Cc: 32986 <at> debbugs.gnu.org
> >
> > Thank you for the clarification. I have now read the original
> explanation, and it makes sense.  Ultimately, I think
> > the sit-for is the right approach for my wait-for-any-process-or-input
> problem.  Am I right to assume  it's not
> > affected by your explanation, and that I can expect immediate return
> there?
>
> sit-for waits for keyboard input, so yes, it should return once the
> user presses some key.
>

Right. A final question: process input is also considered during the
sit-for, meaning a filter can throw to an enclosing tag and end it
prematurely and immediately, right?

>

--0000000000001e3b670577c7cc5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Tue, Oct 9, 2018, 03:32 Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN=
">eliz@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; =
From: Jo=C3=A3o T=C3=A1vora &lt;<a href=3D"mailto:joaotavora@HIDDEN" tar=
get=3D"_blank" rel=3D"noreferrer">joaotavora@HIDDEN</a>&gt;<br>
&gt; Date: Mon, 8 Oct 2018 21:39:53 +0100<br>
&gt; Cc: <a href=3D"mailto:32986 <at> debbugs.gnu.org" target=3D"_blank" rel=3D"=
noreferrer">32986 <at> debbugs.gnu.org</a><br>
&gt; <br>
&gt; Thank you for the clarification. I have now read the original explanat=
ion, and it makes sense.=C2=A0 Ultimately, I think<br>
&gt; the sit-for is the right approach for my wait-for-any-process-or-input=
 problem.=C2=A0 Am I right to assume=C2=A0 it&#39;s not<br>
&gt; affected by your explanation, and that I can expect immediate return t=
here?<br>
<br>
sit-for waits for keyboard input, so yes, it should return once the<br>
user presses some key.<br></blockquote></div></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Right. A final question: process input is also consid=
ered during the sit-for, meaning a filter can throw to an enclosing tag and=
 end it prematurely and immediately, right?</div><div dir=3D"auto"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--0000000000001e3b670577c7cc5a--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 09 Oct 2018 15:02:02 +0000
Resent-Message-ID: <handler.32986.B32986.153909731111272 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.153909731111272
          (code B ref 32986); Tue, 09 Oct 2018 15:02:02 +0000
Received: (at 32986) by debbugs.gnu.org; 9 Oct 2018 15:01:51 +0000
Received: from localhost ([127.0.0.1]:42467 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1g9tWB-0002vk-6I
	for submit <at> debbugs.gnu.org; Tue, 09 Oct 2018 11:01:51 -0400
Received: from eggs.gnu.org ([208.118.235.92]:49717)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1g9tWA-0002vU-2C
 for 32986 <at> debbugs.gnu.org; Tue, 09 Oct 2018 11:01:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1g9tW0-0007oD-18
 for 32986 <at> debbugs.gnu.org; Tue, 09 Oct 2018 11:01:44 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34672)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1g9tVz-0007o0-TL; Tue, 09 Oct 2018 11:01:39 -0400
Received: from [176.228.60.248] (port=2508 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1g9tVz-0005KJ-Fs; Tue, 09 Oct 2018 11:01:39 -0400
Date: Tue, 09 Oct 2018 18:01:35 +0300
Message-Id: <83d0sjyxio.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
 (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Tue, 9 Oct 2018 09:47:58
 +0100)
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
 <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: João Távora <joaotavora@HIDDEN>
> Date: Tue, 9 Oct 2018 09:47:58 +0100
> Cc: 32986 <at> debbugs.gnu.org
> 
> A final question: process input is also considered during the sit-for, meaning a filter can throw to an
> enclosing tag and end it prematurely and immediately, right?

You mean, if the only input is from a subprocess?  No, I don't think
so.  Do you have evidence to the contrary?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 14 Oct 2018 22:09:01 +0000
Resent-Message-ID: <handler.32986.B32986.153955492514937 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.153955492514937
          (code B ref 32986); Sun, 14 Oct 2018 22:09:01 +0000
Received: (at 32986) by debbugs.gnu.org; 14 Oct 2018 22:08:45 +0000
Received: from localhost ([127.0.0.1]:49651 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gBoZ0-0003so-34
	for submit <at> debbugs.gnu.org; Sun, 14 Oct 2018 18:08:45 -0400
Received: from mail-wm1-f41.google.com ([209.85.128.41]:54905)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1gBoYy-0003sZ-Fk
 for 32986 <at> debbugs.gnu.org; Sun, 14 Oct 2018 18:08:40 -0400
Received: by mail-wm1-f41.google.com with SMTP id r63-v6so16994112wma.4
 for <32986 <at> debbugs.gnu.org>; Sun, 14 Oct 2018 15:08:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=3ljvu/rkmX5nSOVZtr1a6llNxdK4LcZKWlZhh0oVt+M=;
 b=dYc59koMRxYL4siScLbET2VuGgbvYWVgnA/rwBxCWFP7FFRVcav5FATrqj56zd63kl
 COVBUiSF45UYpDLTMl0mYuU3oinfjCno+YriVqmHSEhCKkTfvw5g82RgiMUX9CcV1/PR
 EP9cZvaElDYaXYdDFxW7RyGZ4kfQINWOaI6ixLYqHZKjSBpPa4st/uAUvPH4T75GvHNJ
 ZrPkltJcjlkElNwRUKjX5gKHID7miLNbqqsSh5wYUwOFyt0vfWcuERGcJ6RY+0LXbC4t
 W73VDbQ9lrJicKfTrp+JMVEXWmSREtFPUMUYXOHgZKU5BoSXfdTwGZOsQ7h7FGUgfKQQ
 BM5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=3ljvu/rkmX5nSOVZtr1a6llNxdK4LcZKWlZhh0oVt+M=;
 b=cplPNOHzoGXs3a+oTvUPJ3X7illcCTD3Bv6pJql0DlkgJWr3rF/DeZiU/RFULHUMdT
 eyfOvLLlZxz+ADZUEvwplW/zA6u4ujuJD9y+h/SkAuRR+f1tKUeXXTJh3Gg6OysJVYl8
 foow4xGV+HqWoZL3IZZk8R+gwstAyaUWhhrCaExq5Awm0fcSomwyk8iWDjhaYgYvuV4t
 esZslLMV1q13Bi9h5l97TGMJ+w/USEzKfyIk1G9B60+lLyarGcbRwx1iej0EqJTN1Bqx
 zR5ghQLHkYEGXVGpfunlrvBOZ+J5UBVem5xBHf/I7ZhIeeQZc3LNHYKIW6nFhvPfZSOw
 fZVQ==
X-Gm-Message-State: ABuFfog2NfVl7PFmOK8zrHe+0PTccxuuCFXaIEDVYFYoCQt3FAIzBvqp
 v/a8fkj7JQoFbLkh/gkDYXyfOgFG
X-Google-Smtp-Source: ACcGV61F9qi/mtQkGbepDJirco1R4feJoq/nvJNI6TmW+ktNbYqZkhrFmOm3szyFjHbyt3g+goCeTg==
X-Received: by 2002:a1c:3795:: with SMTP id
 e143-v6mr11712974wma.9.1539554914393; 
 Sun, 14 Oct 2018 15:08:34 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
 [94.62.139.188])
 by smtp.gmail.com with ESMTPSA id 82-v6sm8364096wms.17.2018.10.14.15.08.33
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Sun, 14 Oct 2018 15:08:33 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
 <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
 <83d0sjyxio.fsf@HIDDEN>
Date: Sun, 14 Oct 2018 23:08:30 +0100
In-Reply-To: <83d0sjyxio.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 09 Oct
 2018 18:01:35 +0300")
Message-ID: <87bm7wxjtt.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
>> Date: Tue, 9 Oct 2018 09:47:58 +0100
>> Cc: 32986 <at> debbugs.gnu.org
>>=20
>> A final question: process input is also considered during the
>> sit-for, meaning a filter can throw to an
>> enclosing tag and end it prematurely and immediately, right?
>
> You mean, if the only input is from a subprocess?  No, I don't think
> so.  Do you have evidence to the contrary?

Hi Eli,

Sorry for the delay in my reply.

I meant the following, which appears to do what I want in my testing:

   (joaot/time
    (catch 'done
      (progn (make-process :name "test"
                           :filter (lambda (proc string)
                                     (message "Hey %s just got %s" proc str=
ing)
                                     (throw 'done nil))
                           :command '("sh" "-c" "sleep 2 && echo bla"))
             (while (sit-for 30))))) ; Took 02.011 seconds and returned nil

The above result is with C-u C-x C-e and no further keyboard input. If
however I press C-u C-x C-e SPC as in my previous experiments, I get the
expected very small delay.

In other words, subprocess input is considered during a 'sit-for'. It
doesn't end it, but that's OK if catch/throw is used.

I'd just like to confirm that I'm not dealing with an "dirty room"
situation here, to use your metaphor.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 15 Oct 2018 15:04:02 +0000
Resent-Message-ID: <handler.32986.B32986.153961579023473 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.153961579023473
          (code B ref 32986); Mon, 15 Oct 2018 15:04:02 +0000
Received: (at 32986) by debbugs.gnu.org; 15 Oct 2018 15:03:10 +0000
Received: from localhost ([127.0.0.1]:50920 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gC4Oj-00066W-W7
	for submit <at> debbugs.gnu.org; Mon, 15 Oct 2018 11:03:10 -0400
Received: from eggs.gnu.org ([208.118.235.92]:52252)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1gC4Og-000661-Kn
 for 32986 <at> debbugs.gnu.org; Mon, 15 Oct 2018 11:03:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1gC4OX-0000tg-Gb
 for 32986 <at> debbugs.gnu.org; Mon, 15 Oct 2018 11:03:01 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43341)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1gC4OX-0000tX-BV; Mon, 15 Oct 2018 11:02:57 -0400
Received: from [176.228.60.248] (port=1207 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1gC4OW-0002Ln-UF; Mon, 15 Oct 2018 11:02:57 -0400
Date: Mon, 15 Oct 2018 18:03:08 +0300
Message-Id: <8336t7tfpv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87bm7wxjtt.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sun, 14 Oct 2018 23:08:30 +0100)
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
 <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
 <83d0sjyxio.fsf@HIDDEN> <87bm7wxjtt.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: João Távora <joaotavora@HIDDEN>
> Cc: 32986 <at> debbugs.gnu.org
> Date: Sun, 14 Oct 2018 23:08:30 +0100
> 
> In other words, subprocess input is considered during a 'sit-for'. It
> doesn't end it, but that's OK if catch/throw is used.
> 
> I'd just like to confirm that I'm not dealing with an "dirty room"
> situation here, to use your metaphor.

I think you are right.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 15 Oct 2018 15:52:01 +0000
Resent-Message-ID: <handler.32986.B32986.153961867511275 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.153961867511275
          (code B ref 32986); Mon, 15 Oct 2018 15:52:01 +0000
Received: (at 32986) by debbugs.gnu.org; 15 Oct 2018 15:51:15 +0000
Received: from localhost ([127.0.0.1]:50994 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gC59G-0002vn-LD
	for submit <at> debbugs.gnu.org; Mon, 15 Oct 2018 11:51:14 -0400
Received: from mail-qt1-f177.google.com ([209.85.160.177]:36006)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1gC59F-0002vb-M2
 for 32986 <at> debbugs.gnu.org; Mon, 15 Oct 2018 11:51:13 -0400
Received: by mail-qt1-f177.google.com with SMTP id u34-v6so21982807qth.3
 for <32986 <at> debbugs.gnu.org>; Mon, 15 Oct 2018 08:51:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=NMvamRMSUPRDNFlThLrz5dOXLjjtkkGGqotFtFhcoa4=;
 b=Gfesu7tErh4u5sKvt3RQPKega49ePJSLN8xwELcLAjncnPHyNfSrP7MpOfgYNvcEmf
 G1kkDRV0Cf7hEb6I/BXuI8wBMf77ERZYu/LSEgMPlcRIFjFo81372KapUwPkma/Kzaqq
 kukfKeLwssHCp+6CZ3/gzdK5x0Gpv1twbhp+Q67/irFY7aKBmZZd2xW1ldBEhSWtHAsi
 /d9p5wpWhSHIfP+/Z52925t0u9508+M1t8N/5cH6nS11kJoDbFex7omXYrSOcqw0OCZb
 tKS1EDbbl/W2JFvefFY85RLPmO/0nBNHjJ9YGAtUiG/LAMd5+uYeb+Cgk8nBgCCISmDS
 5kgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=NMvamRMSUPRDNFlThLrz5dOXLjjtkkGGqotFtFhcoa4=;
 b=PtEOCPgxeCVy609Y1Vo1drT/tPUVFJmjD6q9PJiAHrfrHKJDn0eF908Y4mqpOak5fr
 Vc2DTVR0RYaYrDC1Z8hBkmAjeamgX8FHm1b1hNRo2FAgG7HSvhp2Mp6Jr/lupyUgqb46
 seN6VuxThiTPy3nKGiO6fsaqoUB0FNcja5JuvWeg6df8lXrFO8MkIPcRs7LUZplYJyV/
 FjqxyijGAwjVFqkc35A3ZYSZoiuB24ZyjCNQsu8IeQ85kpVanNSjeyOVRYOpHI31wcb5
 obpFwAiexbNahvqGB+TS/U6yFoAkved+1BB/dvqv0neiCAvdSfvfj2Vx7BSqsbh029q6
 +pBw==
X-Gm-Message-State: ABuFfojiFKHXpB3p4ToFpUuUS8n9RZGn/V7KyDFCCPPQdowNkwG9XDx3
 /NAHI4kAz+GONcnmm9SQ9iZ7pguF31vS24nUlNA=
X-Google-Smtp-Source: ACcGV61iGWauaKeKaTRzXrd+5Y1fN2JpWWnhZqPw979t+cFViFcnhy5AYgtSurQB+2fuHgBP2/BJ+COQjQ6FbNa+tHE=
X-Received: by 2002:aed:3b04:: with SMTP id
 p4-v6mr17005248qte.218.1539618667959; 
 Mon, 15 Oct 2018 08:51:07 -0700 (PDT)
MIME-Version: 1.0
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
 <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
 <83d0sjyxio.fsf@HIDDEN> <87bm7wxjtt.fsf@HIDDEN> <8336t7tfpv.fsf@HIDDEN>
In-Reply-To: <8336t7tfpv.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 15 Oct 2018 16:50:56 +0100
Message-ID: <CALDnm53-yDnd0KhYSX+CjtJk+TO9D9mFCtw+XiM4Cne4hM74mg@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000cb18610578466725"
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

--000000000000cb18610578466725
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, I agree (with myself :-).   I've just "cleaned the room" according to
your instructions and I still see the desired behavior.

So I guess this wraps up the issue. Thanks for all the help.

Jo=C3=A3o

On Mon, Oct 15, 2018 at 4:03 PM Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> > Cc: 32986 <at> debbugs.gnu.org
> > Date: Sun, 14 Oct 2018 23:08:30 +0100
> >
> > In other words, subprocess input is considered during a 'sit-for'. It
> > doesn't end it, but that's OK if catch/throw is used.
> >
> > I'd just like to confirm that I'm not dealing with an "dirty room"
> > situation here, to use your metaphor.
>
> I think you are right.
>


--=20
Jo=C3=A3o T=C3=A1vora

--000000000000cb18610578466725
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, I agree (with myself :-).=C2=A0 =C2=A0I&#39;ve just &=
quot;cleaned the room&quot; according to your instructions and I still see =
the desired behavior.<div><br></div><div>So I guess this wraps up the issue=
. Thanks for all the help.</div><div><br></div><div>Jo=C3=A3o</div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Oct 15, 2018 at 4:03 =
PM Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">&gt; From: Jo=C3=A3o T=C3=A1v=
ora &lt;<a href=3D"mailto:joaotavora@HIDDEN" target=3D"_blank">joaotavor=
a@HIDDEN</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:32986 <at> debbugs.gnu.org" target=3D"_blank">32986@d=
ebbugs.gnu.org</a><br>
&gt; Date: Sun, 14 Oct 2018 23:08:30 +0100<br>
&gt; <br>
&gt; In other words, subprocess input is considered during a &#39;sit-for&#=
39;. It<br>
&gt; doesn&#39;t end it, but that&#39;s OK if catch/throw is used.<br>
&gt; <br>
&gt; I&#39;d just like to confirm that I&#39;m not dealing with an &quot;di=
rty room&quot;<br>
&gt; situation here, to use your metaphor.<br>
<br>
I think you are right.<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Jo=C3=A3o T=
=C3=A1vora</div>

--000000000000cb18610578466725--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 11 Dec 2018 18:10:02 +0000
Resent-Message-ID: <handler.32986.B32986.15445517569847 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.15445517569847
          (code B ref 32986); Tue, 11 Dec 2018 18:10:02 +0000
Received: (at 32986) by debbugs.gnu.org; 11 Dec 2018 18:09:16 +0000
Received: from localhost ([127.0.0.1]:44169 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gWmT3-0002Yi-Lu
	for submit <at> debbugs.gnu.org; Tue, 11 Dec 2018 13:09:16 -0500
Received: from mail-wr1-f53.google.com ([209.85.221.53]:46190)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1gWmT0-0002YS-Ts
 for 32986 <at> debbugs.gnu.org; Tue, 11 Dec 2018 13:09:11 -0500
Received: by mail-wr1-f53.google.com with SMTP id l9so15034868wrt.13
 for <32986 <at> debbugs.gnu.org>; Tue, 11 Dec 2018 10:09:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=LFuFIsCe2g6wKkB9WVs8v4mvoIHPGSSGO4YIiRVnV9U=;
 b=NMLOxVGVUa91AFgUickY/ZhNs8H01f2iaWdLVpN5DCiMub8q9EJVz1f9pbRUJCELGh
 1b93cJpEJC5yKURX5ke9/KAzCGK1lAyIzr6Z/yrQfPKc6SANBEJvU8dl7rC4QiTYtnHn
 3FidR0+eaRk7liuPfMYgu9Qdzr5VlN3csC4q0mG3RHlH3Nk1jL9PVa8NxR2nufWpTLn1
 L0MKAQOpGdvsUU3HANt56uLhJqxOQpHI1LnyFt0mPDkiijaOUN+RzanZq7Yh75AC9ryk
 7RaJHIBtKIQ11YTw33CaFSfO/BPlCjKFgpKSHCTCR20cdHYR88Ea7RI1iLpVvW1B1l8S
 pCvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=LFuFIsCe2g6wKkB9WVs8v4mvoIHPGSSGO4YIiRVnV9U=;
 b=dq8nYvVLqgS+/PjzAxnyPAw3zlMLx6IRep021QkuQO5c4S11+4qGRj+vfoRgkAsI64
 zozjNdnA9Exifa2sSUmvoV16YUwxGx1v+bLYpUkG5nUCEd6obNU+VqZCH/0arasxSckF
 cZpgB7d1ZACvK8JNNn5GMnrLGPJachvPXGFM6o5pLXPDA/de4lHAXorV71vcMZ7uniCn
 bFZ02xCfOAdRvHkrg98vIa2vg+RYXxLzpgkvPDHz0HncdJihBzco/6aMzwxnT6vGVsbR
 lg1jgfZufklXLxzAhxOjs80iCVYMqqImLHvSRqQ1Qw8os+MiStCiPMS5ww+OQBeibW30
 /cNQ==
X-Gm-Message-State: AA+aEWbXSXzUWetSnc/fIh5wAxt1Vhqh10bi39FfceqFzP+CVs2e2jKf
 rvU1ibC46LtrTzYkI2UEE7vKjEW/
X-Google-Smtp-Source: AFSGD/X8FagAsnm8aRk1gUUt2Nbuo9a/JzLZkZhKRSuLprWUoeDc0Kx1XU4YcDaotr0jQaFoYK5tHQ==
X-Received: by 2002:adf:c5d3:: with SMTP id v19mr14140246wrg.30.1544551744546; 
 Tue, 11 Dec 2018 10:09:04 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.23])
 by smtp.googlemail.com with ESMTPSA id i186sm989551wmd.19.2018.12.11.10.09.02
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 11 Dec 2018 10:09:03 -0800 (PST)
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
 <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
 <83d0sjyxio.fsf@HIDDEN> <87bm7wxjtt.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <401dbba4-8c00-07f7-ee0a-62fe4b59cc12@HIDDEN>
Date: Tue, 11 Dec 2018 20:09:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101
 Thunderbird/64.0
MIME-Version: 1.0
In-Reply-To: <87bm7wxjtt.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

On 15.10.2018 1:08, João Távora wrote:

>     (joaot/time
>      (catch 'done
>        (progn (make-process :name "test"
>                             :filter (lambda (proc string)
>                                       (message "Hey %s just got %s" proc string)
>                                       (throw 'done nil))
>                             :command '("sh" "-c" "sleep 2 && echo bla"))
>               (while (sit-for 30))))) ; Took 02.011 seconds and returned nil

It's an interesting alternative to Company's async backend interface, 
where we have a similar piece of code waiting until either completions 
are returned or the user types something (in company--fetch-candidates).

Which of course makes sense, given that CAPF has no async calling 
convention.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 12 Dec 2018 21:43:02 +0000
Resent-Message-ID: <handler.32986.B32986.154465096023379 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.154465096023379
          (code B ref 32986); Wed, 12 Dec 2018 21:43:02 +0000
Received: (at 32986) by debbugs.gnu.org; 12 Dec 2018 21:42:40 +0000
Received: from localhost ([127.0.0.1]:45590 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gXCHA-000651-1Y
	for submit <at> debbugs.gnu.org; Wed, 12 Dec 2018 16:42:40 -0500
Received: from mail-qk1-f173.google.com ([209.85.222.173]:35681)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1gXCH7-00064o-W4
 for 32986 <at> debbugs.gnu.org; Wed, 12 Dec 2018 16:42:38 -0500
Received: by mail-qk1-f173.google.com with SMTP id w204so11754764qka.2
 for <32986 <at> debbugs.gnu.org>; Wed, 12 Dec 2018 13:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=doBEO2PXuMWLCrtbYBi7MokW6xEqUSSy1RVRx3TJU0w=;
 b=b7ME1AaHF095LnukoXEbIETJSSMLyrUFFDjvyUFpHCjtxIGaqqOV3TwvMnAbJaBMN3
 bOkZYQeVaigHXNZvmVDReoxEIF4t7pR3diiUHs4wmdmPq1jSjtJrktIrNbHfwuMd/iot
 vMBL0zoKHszREshVDXmwwYHhvYe3b1EPAA/wfgtkJJIzCWRbuvPuUBb1rOwchMP1k6XA
 wetW1aq7QIxFdKIMgjyc3HkSjSjQQaN2ymmnLdtAu3VfurcVZZe8OCOU14CTRFoiG+eO
 euRuUqpBZBUJfvKVEM135eSrJJQhjQZXIy14pcGlBUiJvrv+nxawTrM8yj6H3wa4AhSL
 wriA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=doBEO2PXuMWLCrtbYBi7MokW6xEqUSSy1RVRx3TJU0w=;
 b=c9Gm+iUv5sEx438cXZ5XBlQV9FQpUrTSkaa3LsSha/HYQ8sL/IEkp+hyB5YlP6Wzm9
 +RHaOXlEGj6bw27C0ZfBIg7JNvTIZUZGnYLUbUz/LwrGZu3Zbxr/sIxehDFrnazdArOo
 KmubztG6wzaJzREiVVT0oXBCzMkQaSTc0+2bT3MW4Kxi2qqmNLZp0IwpIx4cQQvNWsG1
 gP+e8e8jc/wu3ls8QFfM/7I/qazEaZUC4hZJUaplFW7dG1rHKCrb0P+N16MpQkGwESmW
 gESrJomrb0qzWzW2xP+bglvjXf3toyyyr0TvnjIyHPyHuXVxVizGdPu6yUFXbolg287h
 ALnQ==
X-Gm-Message-State: AA+aEWbjzUxYv5HcShkAY1FpfUSPclwUdPdYh35+SBjU1vpoGUSyQ90x
 jU+gfz+w2QajVLu3/K/T+12kx+Q4CxlJ9wNaFy0=
X-Google-Smtp-Source: AFSGD/WoOh2qePpHMfKmOB38Jy8hoQMGJsaKZ2hoh9ki6id/I1VqoimqSLAUjFfTSDARQpIE7coeAh31f2lIhy1oLQE=
X-Received: by 2002:a37:f706:: with SMTP id q6mr19026457qkj.96.1544650952354; 
 Wed, 12 Dec 2018 13:42:32 -0800 (PST)
MIME-Version: 1.0
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
 <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
 <83d0sjyxio.fsf@HIDDEN> <87bm7wxjtt.fsf@HIDDEN>
 <401dbba4-8c00-07f7-ee0a-62fe4b59cc12@HIDDEN>
In-Reply-To: <401dbba4-8c00-07f7-ee0a-62fe4b59cc12@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Wed, 12 Dec 2018 21:42:20 +0000
Message-ID: <CALDnm52iZ65mCbGBb2aM3t7ty6S1E3EtS7GSdiFemvPQPPmRug@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000512fbd057cda1357"
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

--000000000000512fbd057cda1357
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Indeed, I developed this for `company-capf`-based backends.

I still haven't ported it to jsonrpc.el tho (I think, will check...)

I've been meaning to ask you: in the long run, do you consider
separating company's frontend logic completely so that a simpler
mode non-company completion frontend can be integrated with
emacs (one that would use company-capf exclusively)?

Jo=C3=A3o

On Tue, Dec 11, 2018 at 6:09 PM Dmitry Gutov <dgutov@HIDDEN> wrote:

> On 15.10.2018 1:08, Jo=C3=A3o T=C3=A1vora wrote:
>
> >     (joaot/time
> >      (catch 'done
> >        (progn (make-process :name "test"
> >                             :filter (lambda (proc string)
> >                                       (message "Hey %s just got %s" pro=
c
> string)
> >                                       (throw 'done nil))
> >                             :command '("sh" "-c" "sleep 2 && echo bla")=
)
> >               (while (sit-for 30))))) ; Took 02.011 seconds and returne=
d
> nil
>
> It's an interesting alternative to Company's async backend interface,
> where we have a similar piece of code waiting until either completions
> are returned or the user types something (in company--fetch-candidates).
>
> Which of course makes sense, given that CAPF has no async calling
> convention.
>


--=20
Jo=C3=A3o T=C3=A1vora

--000000000000512fbd057cda1357
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Indeed, I developed this for `company-capf`-based bac=
kends.=C2=A0 <br></div><div><br></div><div>I still haven&#39;t ported it to=
 jsonrpc.el tho (I think, will check...)</div><div><br></div><div>I&#39;ve =
been meaning to ask you: in the long run, do you consider <br></div><div>se=
parating company&#39;s frontend logic completely so that a simpler</div><di=
v>mode non-company completion frontend can be integrated with</div><div>ema=
cs (one that would use company-capf exclusively)?<br></div><div><br></div><=
div>Jo=C3=A3o<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On T=
ue, Dec 11, 2018 at 6:09 PM Dmitry Gutov &lt;<a href=3D"mailto:dgutov@yande=
x.ru" target=3D"_blank">dgutov@HIDDEN</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">On 15.10.2018 1:08, Jo=C3=A3o T=C3=
=A1vora wrote:<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0(joaot/time<br>
&gt;=C2=A0 =C2=A0 =C2=A0 (catch &#39;done<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 (progn (make-process :name &quot;test&quot;=
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:filter (lambda (proc string)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(messa=
ge &quot;Hey %s just got %s&quot; proc string)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(throw=
 &#39;done nil))<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:command &#39;(&quot;sh&quot; &quot;-c&qu=
ot; &quot;sleep 2 &amp;&amp; echo bla&quot;))<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(while (sit-for =
30))))) ; Took 02.011 seconds and returned nil<br>
<br>
It&#39;s an interesting alternative to Company&#39;s async backend interfac=
e, <br>
where we have a similar piece of code waiting until either completions <br>
are returned or the user types something (in company--fetch-candidates).<br=
>
<br>
Which of course makes sense, given that CAPF has no async calling <br>
convention.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail-m_5803899102984890268gmail_signature">Jo=C3=A3o T=C3=A1vora</div></div=
>

--000000000000512fbd057cda1357--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 12 Dec 2018 23:52:01 +0000
Resent-Message-ID: <handler.32986.B32986.15446586973899 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.15446586973899
          (code B ref 32986); Wed, 12 Dec 2018 23:52:01 +0000
Received: (at 32986) by debbugs.gnu.org; 12 Dec 2018 23:51:37 +0000
Received: from localhost ([127.0.0.1]:45634 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gXEHw-00010p-Pd
	for submit <at> debbugs.gnu.org; Wed, 12 Dec 2018 18:51:36 -0500
Received: from mail-wm1-f54.google.com ([209.85.128.54]:38424)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1gXEHu-00010a-IA
 for 32986 <at> debbugs.gnu.org; Wed, 12 Dec 2018 18:51:34 -0500
Received: by mail-wm1-f54.google.com with SMTP id m22so572939wml.3
 for <32986 <at> debbugs.gnu.org>; Wed, 12 Dec 2018 15:51:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=SUY68cHH4T/gJyrW0JdSqSa2BoUzjg9/bCveyuP6XQ8=;
 b=K/hJio0mAEezfE+UC5359dxw+8aIUAELLx134RkVBmHV0BS3vniOgIVfTN/Jd47Mqb
 gyk6Lda9GBnkDuFgF/YA0AMS3oupwKwx8xsf0TXdsyoAClX+hvIJyhkoA7Qe0OlOFgsO
 3557pf+n57ID+aghjFLJ4o+dUyfzP4Wj5TpjCiYVHqDuDWUB8gtBBEIVICarKABF0saB
 m4jgDhOOlixPyQQEEzqachHAFZP3ccT4JGdm44mfwKrxap+kjXpZEQ1IPnsZN58cP7CY
 0xXJbV0XYe3sJFum1HZ/ai9d9pHCdDCNqDNN/vTZQ3ASMwQZTmbd1K34UaRwiDpxzIhB
 kdyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=SUY68cHH4T/gJyrW0JdSqSa2BoUzjg9/bCveyuP6XQ8=;
 b=fglwUKIaMYvAiQ6W9cnOGLxVQUJ3SUFwq+c0q6HrNNlFHWSvlypNUj49UHRCWAJlUY
 va6JTjYCcwhL3V4AQX6f4kN2SwFX9XNiD3Yu2zhaIHt5zYB3smvUk2hQwjuO714z4nuE
 M/m75C4xz97N6axgh+2WLttKWmrFlGcmnoM0kc3Dzp7T2icaP3lJeXj5+0MofJrizGFa
 edvcCLSQxAhB4l2MNEnXNP6FhcddrT8eXbndj63EQNBh8sKxKx5LTLj+ZG5OtIZrWCph
 STU3kcYCX9/5ItrSdnq/eSaU9O8+WlJ5/5rOJgW4sD9CR3uiDyEWaryo6x+5g3p/oWu4
 bAVQ==
X-Gm-Message-State: AA+aEWYN5zSnrhBY68wJ8exb+ek8cA1J4MG1m4MDaEeZMKArpc1jPVKM
 TAvtJuZKbydulHCjfNJNRaKoLpSq
X-Google-Smtp-Source: AFSGD/Vc4tcbaahg/R/jkbxC7osR7x7PDvwv5dh5GDLdpLCYqJM8vWi/txC6dUyOcwYQzrKbnQFxcw==
X-Received: by 2002:a1c:af08:: with SMTP id y8mr7700502wme.94.1544658687207;
 Wed, 12 Dec 2018 15:51:27 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.23])
 by smtp.googlemail.com with ESMTPSA id j202sm947949wmf.15.2018.12.12.15.51.25
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 12 Dec 2018 15:51:25 -0800 (PST)
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
 <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
 <83d0sjyxio.fsf@HIDDEN> <87bm7wxjtt.fsf@HIDDEN>
 <401dbba4-8c00-07f7-ee0a-62fe4b59cc12@HIDDEN>
 <CALDnm52iZ65mCbGBb2aM3t7ty6S1E3EtS7GSdiFemvPQPPmRug@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <b3a5da7f-f483-c2cb-0285-96dd42d2061e@HIDDEN>
Date: Thu, 13 Dec 2018 01:51:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101
 Thunderbird/64.0
MIME-Version: 1.0
In-Reply-To: <CALDnm52iZ65mCbGBb2aM3t7ty6S1E3EtS7GSdiFemvPQPPmRug@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

On 12.12.2018 23:42, João Távora wrote:

> I've been meaning to ask you: in the long run, do you consider
> separating company's frontend logic completely so that a simpler
> mode non-company completion frontend can be integrated with
> emacs (one that would use company-capf exclusively)?

Do you mean visualizations only? That would need some more code for 
company-capf to work. I guess if somebody used the pseudo-tooltip code 
(and something else) to visualize completion-at-point completions, that 
would be fine. I have no actual plans to implement that myself, though.

Otherwise, I'm not sure what you're proposing exactly, and what is the 
benefit vs just bundling Company with Emacs.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Dec 2018 23:15:02 +0000
Resent-Message-ID: <handler.32986.B32986.154474287110236 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32986
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32986 <at> debbugs.gnu.org
Received: via spool by 32986-submit <at> debbugs.gnu.org id=B32986.154474287110236
          (code B ref 32986); Thu, 13 Dec 2018 23:15:02 +0000
Received: (at 32986) by debbugs.gnu.org; 13 Dec 2018 23:14:31 +0000
Received: from localhost ([127.0.0.1]:47057 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1gXaBb-0002f2-9S
	for submit <at> debbugs.gnu.org; Thu, 13 Dec 2018 18:14:31 -0500
Received: from mail-wr1-f42.google.com ([209.85.221.42]:33954)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1gXaBa-0002eq-7h
 for 32986 <at> debbugs.gnu.org; Thu, 13 Dec 2018 18:14:30 -0500
Received: by mail-wr1-f42.google.com with SMTP id j2so3702152wrw.1
 for <32986 <at> debbugs.gnu.org>; Thu, 13 Dec 2018 15:14:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=Alo4xNzYehab1ppwDbuIp989RqzzK9oeIV1JXt5CT5o=;
 b=sr7FKxK2je07VXz2eFBSVt3WA72w9HyfPhjC4BoKf0VtzgSYWAE52nYUPSjXs6mEzz
 ms7Lhfo0L8XGlcfBP+4eumAAqlGIT1IGqyIzVZlH9y1V15GsvMYHaI72hYIaz+v13AEu
 fjNVRT97iVpgwA8R4oZ0kZBHDjsZmGVmNJtVR9fy3x54jSifbyciraA2APasF6l/iiRn
 s5Ac0ybtCYKhmQ1y8JwQAKVdk/n+2W/GAGA1qyQFXFs80Y+j4lC9h9fELkckWQBW6kvG
 GL0L4e9g8e4AwTm0X9o5YYJRiYqGL5rUowTvfRqeFdrm8arMAeZ6PZnvjZxctdbMkIYQ
 WoPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=Alo4xNzYehab1ppwDbuIp989RqzzK9oeIV1JXt5CT5o=;
 b=Hi/XFsB3yk34YRqWQL9BbpRSYFtGLlxaBgKzHC/3R2jpsAUe58P6kaxPohPk6SYorm
 RSHqJI+Ivn0CQeGv0fdZtseKkwCHVsshR3wA2wkHKv6t+efwDWJeYpbLHNJseGFRZ3nA
 fg6F0InHN2viq5DwWf5pACNjvLQd2Ggtiacenw74N7H22C6pk65/pq93U3X6N6Jb5FA1
 B4ZCaryMeBTpc3N7XfMOUesFmMVR026inJXDx7SVab8LDmRX/eJDJAoKq/BrWIJu/fI5
 JaLMIkLoC5vmiWngsxu7xuMs7JvXFQW0aeixp3lgClj0FL5nsd5b9FEDXfaNfHNkofn7
 +JFQ==
X-Gm-Message-State: AA+aEWY4XKs+/JJ1LH4bL5K4qVV4xkdzxDVO4sSt5KPAWl7gydYkYWwd
 AyUos9zUv8AT25dQcI9HDaD85r34
X-Google-Smtp-Source: AFSGD/W9/T4kCr/gFw2jbvxje7AH5ru5P8FL/MoFWrFuX7JyxGm5AIM8ecbB2LxenxR+b+V4/j0p8g==
X-Received: by 2002:a5d:4e82:: with SMTP id e2mr562960wru.291.1544742864145;
 Thu, 13 Dec 2018 15:14:24 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.23])
 by smtp.googlemail.com with ESMTPSA id b12sm2059814wrt.17.2018.12.13.15.14.22
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 13 Dec 2018 15:14:22 -0800 (PST)
References: <jjbh8hwpvdq.fsf@HIDDEN> <83sh1gzdey.fsf@HIDDEN>
 <CALDnm50ChASC3vmAwmNkY=4e3z_uUM72g5kqA-cYVeSqa79B2g@HIDDEN>
 <83in2cyymt.fsf@HIDDEN>
 <CALDnm52VvVYg8xEbEv6UhiMJ732fhiuwt1z0=JVZ6SqMqwvTyA@HIDDEN>
 <83h8hvzw70.fsf@HIDDEN>
 <CALDnm52miiyS94xRYXjg+cD_AOgb_j6A72RPCayxYYcPkR4eag@HIDDEN>
 <83d0sjyxio.fsf@HIDDEN> <87bm7wxjtt.fsf@HIDDEN>
 <401dbba4-8c00-07f7-ee0a-62fe4b59cc12@HIDDEN>
 <CALDnm52iZ65mCbGBb2aM3t7ty6S1E3EtS7GSdiFemvPQPPmRug@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <04f65cc9-f4c5-0a91-3368-99e3c8a22645@HIDDEN>
Date: Fri, 14 Dec 2018 01:14:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101
 Thunderbird/64.0
MIME-Version: 1.0
In-Reply-To: <CALDnm52iZ65mCbGBb2aM3t7ty6S1E3EtS7GSdiFemvPQPPmRug@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

On 12.12.2018 23:42, João Távora wrote:
> Indeed, I developed this for `company-capf`-based backends.

I imagine the chief drawback of this approach is if the user would try 
to "group" several backends like this, Company style.

CAPF has no handy way to do this, but we could add a macro in the 
future, and anyway, it's already possible to do this by means of 
function composition. It would be handy if, when we get to this point, 
several completion tables like this could fetch their completions 
simultaneously.

Just something to think about, for the future. In the meantime, LSP 
style with a smart server and one backend working with it is probably 
good enough for >90% users anyway.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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