From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function Date: Thu, 4 Apr 2019 16:29:24 +0300 Message-ID: References: <83a7i15vrk.fsf@gnu.org> <787f765a-42f4-40d0-3b78-e751f546fe6c@yandex.ru> <831s3c3ta8.fsf@gnu.org> <8f7ae869-2e94-5535-f16f-476348036dc2@yandex.ru> <83r2bc2csd.fsf@gnu.org> <83h8c63ek1.fsf@gnu.org> <7240d82b-5919-cee8-e3bc-81be8d996400@yandex.ru> <83pnqsyw68.fsf@gnu.org> <83pnq1diqk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="257459"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Thunderbird/67.0 Cc: 34763@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 04 15:30:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hC2Rd-0014oI-Fe for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Apr 2019 15:30:17 +0200 Original-Received: from localhost ([127.0.0.1]:54800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hC2Rc-0002ak-9K for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Apr 2019 09:30:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hC2RS-0002ZL-8c for bug-gnu-emacs@gnu.org; Thu, 04 Apr 2019 09:30:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hC2RR-0007lD-5u for bug-gnu-emacs@gnu.org; Thu, 04 Apr 2019 09:30:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58500) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hC2RO-0007ei-Rn for bug-gnu-emacs@gnu.org; Thu, 04 Apr 2019 09:30:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hC2RO-00082O-B2 for bug-gnu-emacs@gnu.org; Thu, 04 Apr 2019 09:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Apr 2019 13:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34763 X-GNU-PR-Package: emacs Original-Received: via spool by 34763-submit@debbugs.gnu.org id=B34763.155438457830834 (code B ref 34763); Thu, 04 Apr 2019 13:30:02 +0000 Original-Received: (at 34763) by debbugs.gnu.org; 4 Apr 2019 13:29:38 +0000 Original-Received: from localhost ([127.0.0.1]:43811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hC2R0-00081G-2r for submit@debbugs.gnu.org; Thu, 04 Apr 2019 09:29:38 -0400 Original-Received: from mail-wm1-f41.google.com ([209.85.128.41]:54141) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hC2Qy-000814-DA for 34763@debbugs.gnu.org; Thu, 04 Apr 2019 09:29:36 -0400 Original-Received: by mail-wm1-f41.google.com with SMTP id q16so3067243wmj.3 for <34763@debbugs.gnu.org>; Thu, 04 Apr 2019 06:29:36 -0700 (PDT) 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=GYK7LtDw5blC4tnUbzR19+lrq8GpyNxTe+eO5SIss8k=; b=nLg431lsMficBr8ikDuOqA3WnBU9ycDnXHvQD/LllFAJl0PnS5xml0ni258fWNKSVg SaFG/WIrtZO+0fXFrBNo6FlrsNu0aS9DbG+b5pzuSoXuQj+SxH9Qqfs6gEERa8cu5lwM 9ERRqvFUuqV+XMcy6pHAbqv1yn4s5QeQciOahk9xGzDVu5ZB8eW/shUiBoBFU2oyfout G/7YThy+GsgWr19QLRTz9hhHpJ0xuTPv89IOWqLwLMiIUvxU8dcd5vMe+z4NcCLEMZPd 85qBjUXwVM+yZBSID9jXb8GZ0A58eKAfbzetNGvN2YpnPdwVjCuaWdacvWCQihwFzNkr T+HA== 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=GYK7LtDw5blC4tnUbzR19+lrq8GpyNxTe+eO5SIss8k=; b=c1FCTs7JpuW0qz/C2cOqYjtVmF0bcoGELgu1bcqIXb274xNxD4vFN4D85heiV/+uER Slh05iUYfIoatEvM8MPTPbpwyWxpjcUifDJpGkI8pg8bdrOU13fYw6wQ5o5UfVagyxZs LibyaPrlIC/+UI9Y+//DibFPYWwIuR1sgQUhqTl3zpgqTOUmq7c3/b2zO9+ORANq0376 hvpMbb4p//rBkhT0p5zgh5oK6y68bMHYNJDujxZsmZsVorCNO2pbCA4zUMdtJ8VKN7+P sZANGgGjo9fSP2Z9XhuEsvpzitVY3fkvL4VxKzfi9/v9wtaNfRPzT7TDB9dy0xLLSVDc YI8w== X-Gm-Message-State: APjAAAWKk1UQz2NyPHxwou0pdLa4xTbNWBGhTv3rSbhMS++F6DTp5wN2 TudF+c1XLV+IGa9K6k7fN3SLfrhj X-Google-Smtp-Source: APXvYqzaRdBiakH1HagjU53nnm2YqSd7sYJHdy/+TnWXDh/quh0l/KqjjkMtGes6wT+w05OizgGa4w== X-Received: by 2002:a1c:c8:: with SMTP id 191mr4040274wma.44.1554384569301; Thu, 04 Apr 2019 06:29:29 -0700 (PDT) Original-Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id p6sm11693410wrs.6.2019.04.04.06.29.25 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 06:29:26 -0700 (PDT) In-Reply-To: <83pnq1diqk.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:157165 Archived-At: On 04.04.2019 16:04, Eli Zaretskii wrote: > If that's the intent, why does it need to explicitly quit in Lisp? > Just letting the code leave the form where inhibit-quit is non-nil > will let Emacs quit at the first opportunity, with no need for any > Lisp code for that. Because accept-process-output doesn't abort on user input? And url-retrieve-synchronously calls it with 1 second timeout (which is a fairly long wait). I wonder if the original author remembers the idea, now 15 years after the code was submitted. We can try removing the 'error' calls and see if things improve, but: 1. I guess we'll also need to wrap the accept-process-output call in while-no-input. And concerns? 2. I wonder if there are cases where some part of the asynchronous code takes too long, where it should be allowed to be aborted by the user right away. Meaning when url-retrieve is used, not url-retrieve-synchronously.