From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#17139: Race condition in complete-in-region: should we be using pre-command-hook, not post-command-hook? Date: Sun, 30 Mar 2014 14:49:59 -0700 Message-ID: <53389187.3090901@dancol.org> References: <53362D5C.2070502@dancol.org> <53363260.9060207@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B8Pm5rfrVuklb2or0rJQbJGkR5R3UiDFf" X-Trace: ger.gmane.org 1396216284 25301 80.91.229.3 (30 Mar 2014 21:51:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2014 21:51:24 +0000 (UTC) Cc: 17139@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 30 23:51:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WUNdO-00060U-GZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Mar 2014 23:51:18 +0200 Original-Received: from localhost ([::1]:45939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUNdO-0000Ux-6t for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Mar 2014 17:51:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUNdF-0000U0-Io for bug-gnu-emacs@gnu.org; Sun, 30 Mar 2014 17:51:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WUNd9-0002QR-3R for bug-gnu-emacs@gnu.org; Sun, 30 Mar 2014 17:51:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUNd8-0002QN-S6 for bug-gnu-emacs@gnu.org; Sun, 30 Mar 2014 17:51:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WUNd8-0002GL-Cc for bug-gnu-emacs@gnu.org; Sun, 30 Mar 2014 17:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Mar 2014 21:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17139 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17139-submit@debbugs.gnu.org id=B17139.13962162108631 (code B ref 17139); Sun, 30 Mar 2014 21:51:02 +0000 Original-Received: (at 17139) by debbugs.gnu.org; 30 Mar 2014 21:50:10 +0000 Original-Received: from localhost ([127.0.0.1]:57355 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WUNcH-0002F8-6n for submit@debbugs.gnu.org; Sun, 30 Mar 2014 17:50:09 -0400 Original-Received: from dancol.org ([96.126.100.184]:50944) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WUNcB-0002Ej-Fu for 17139@debbugs.gnu.org; Sun, 30 Mar 2014 17:50:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ktEoY3yyGPMJd+iwIXPiOnSilTkEOdUHU9uD3ELsX9E=; b=mYbPEppKrfvM+6TgjrEZtGVC1xUmBs1JUb0Eh/yvi/jPrbIbBE4wDbHX25z+labpKafJt2LSbk2RLY1Cje0QXXZ0bJglh83Hpty2IelEHhviYNTCWvnHyCVZXmqlUBoCnbONvu+aan2W1giNlLURMcIxkffB5BbUESpNiZsMRjcKO3lKLuBCyPmmOlLO9N0C5SVTGPUkQztU/ju7SVLRqUTjuyA3Auwi0NuxE6lMwcsMSiG4KQrqhOm4uwi6VGG9TWyuwlFt1XbYsYlrvtQQGg8XYb2YRlGPoQwuGNbOJsYpwzEPxoZ6m8+UvORqXfXoxGvbfxC4t9CkRZrrODlLjQ==; Original-Received: from c-24-19-133-76.hsd1.wa.comcast.net ([24.19.133.76] helo=[192.168.1.174]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WUNc9-0002n9-AJ; Sun, 30 Mar 2014 14:50:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: X-Enigmail-Version: 1.6 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:87562 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B8Pm5rfrVuklb2or0rJQbJGkR5R3UiDFf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/30/2014 02:39 PM, Stefan Monnier wrote: >>> run post-command-hook; completion-in-region--postch is on the list of= >>> hooks to run. This function runs completion-in-region-mode--predicat= e, >>> which makes a hidden call to the subprocess; >=20 > Using the subprocess from completion-in-region--postch sounds > like a problem/bug, indeed. Why do we(I?) do that? >=20 >>> Why can't we do the completion-in-region--postch stuff in pre-command= -hook? >=20 > Because pre-command-hook would come even later (it would only disable > completion-in-region-mode at the beginning of the next command after RE= T). You're right: that's a bad solution. I was thinking we could somehow detect RET and other side-effect-ful commands, but just augmenting comint-send-input is better. >=20 >> + ;; If we're currently completing, stop. We're definitely done >> + ;; completing, and by sending the input, we might cause side effect= s >> + ;; that will confuse the code running in the completion >> + ;; post-command-hook. >> + (when completion-in-region-mode >> + (completion-in-region-mode -1)) >=20 > I see you installed it, thanks, I think it's OK. But I'd also like to > know why we contact the subprocess from completion-in-region--postch, > because that's risky. In my case, I have a JavaScript repl to which Emacs connects over a socket. Each connection gets a separate JavaScript global environment, so completion in the comint buffer has to use the same underlying socket that's connected to the buffer. Completion works by using comint redirection to send JavaScript over the socket, then waiting for a reply. completion-in-region--postch needs to use the normal completion machinery (via the predicate set up in completion-at-point) to detect whether the completion region has changed, and this machinery contacts the subprocess to find the completion candidates. Come to think of it, supplying a function instead of a simple list of strings as the completion table returned from the completion function would probably help too, since then completion-in-region--postch could inspect the first element of the returned list (the completion region start) without having to actually "force the promise" and resolve the whole list after every command. --B8Pm5rfrVuklb2or0rJQbJGkR5R3UiDFf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTOJGHAAoJEMAaIROpHW7INp8QAMUZCzK5C7D/VTkBmkpRLJ7i P2vmgxDDt3ahwYpbdXDEKKQps6IHaOS9WGsSfdK2dsNyspTjzjxh2TPiWNZhdYiG 6foe84MMUZb0XScQTF1lfkbI8jkwMFKMpOY9HwfnHNkc63/nFTGWDd8KhuUWx6Xq But307zcRg46O07YQG1CCDP0uQpc1e+ldMRWPFcvlTaJwN446lJqZIE5L6kbfLsj c+pZ7f2liSli9tgNMqA4dn+jxOwQghj4flv5LZfOejsJRxb7jGF+j3iCrZcHMm8F fCSLyfVghjjpxMoKGF7eRj5nEx57Wr2Tesdg0uI4pYobBq0ZpLFmu1GsPPRo2Fku dQfsRfiBICOAI96eAymODluY8abyJ7ibhXIVNEYXeDnflhqkf6i8jAmyeUYc2W3y 7SWzX+xh0+C//+Igv9TADQTTSE407jVlDfl3drIXhdRDoMcFOkLEScf8X+DLjsrT HkeEFirPgtBqYeo9S2S0Sf8XU+5jL8vDzFwSHppdBMnqiZu94bNHOrWI3gKIViHf ghtYPKRzPjo6UZ9UarSUzxbf3catWaMiGvQlfp5tfFY15F3e7itzO15KoUyHm9lq 9WI9qmRYugfbHvPCRuvyeNnnzwUC5cx4cj67hyjfc6iKCkUMuPlhfoemAv5sLK5a 61kJU2qWhVP7zheGEPKm =152o -----END PGP SIGNATURE----- --B8Pm5rfrVuklb2or0rJQbJGkR5R3UiDFf--