From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74218: [PATCH] Ask confirmation before sending region to search engine. Date: Thu, 07 Nov 2024 10:12:53 +0100 Message-ID: References: <20241106005544.26516-1-me@fabionatali.com> <86pln8sfqe.fsf@gnu.org> <87ikt0gz7b.fsf@fabionatali.com> <86bjyrqvb0.fsf@gnu.org> Reply-To: Eshel Yaron Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19250"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74218@debbugs.gnu.org, stefankangas@gmail.com, me@fabionatali.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 07 10:14:22 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t8yas-0004mD-6B for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Nov 2024 10:14:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8yae-0006aP-Bp; Thu, 07 Nov 2024 04:14:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t8yaZ-0006Zv-Je for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 04:14:04 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t8yaZ-0006BW-9n for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 04:14:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=yL/APC1/Tco1obXDvCDLIPiDOVF/uZgrSs7phYYqBY4=; b=Jr9x53K3s2NXx53yRR7HQOdErSXVi0egyzob33zZIdTPwE4hD9C5TJA9hmsQgBhfW1Xnnmfc9caLmThr5avCY5qlyj+VHygSYY9rmzKcqSV3WaLq764cGkUPYcPQfLjaiS5OdFW6eFXQ5Z90fvs11S3ttO8KV3IxxH1b9kdjEt4ZXu4JPKNGYVSLHN1pnubiCw5refNLMBDH4mer4JaKq6wZihNhLtWbtzN/bZGyfFw5xt5ZfQHUaIC6YBD95cPP8Ka9ebqOATuQHdS0gTMl2GHIEUX5eQivPigO9ER1qLOer+0R8+xdX/IzLrRIjt52HgJLy+Y/m6xpXsdOmPo+pg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t8yaY-0004yK-5l for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 04:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Nov 2024 09:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74218 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74218-submit@debbugs.gnu.org id=B74218.173097078219029 (code B ref 74218); Thu, 07 Nov 2024 09:14:02 +0000 Original-Received: (at 74218) by debbugs.gnu.org; 7 Nov 2024 09:13:02 +0000 Original-Received: from localhost ([127.0.0.1]:47173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8yZa-0004wq-1w for submit@debbugs.gnu.org; Thu, 07 Nov 2024 04:13:02 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16]:47392 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8yZV-0004wO-LR for 74218@debbugs.gnu.org; Thu, 07 Nov 2024 04:13:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1730970777; bh=doIOJkfSxD7oWaYZmaKVnp5CCen5M6L2z9jQq+sSLm4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HrWDcAcz60TGngfrP/K6QSOsJ0fheH//tZYvlNB7Ze4bJgGc+W5KtUBJrKkcEijCx 27aj5wq2iwMWaNOsURl7IGJRQMNPWFBH6Sye6bjqFdMb1x0GxM0SCtOElSFuhjT+9E ZBdQ8eWwIRUk9LNbqi+++Pzqs7n4Xcz1Pjh/NUFibvzxLKfUNafpWd6sl9b5JTGiXf b5W8FXcuRkJKOSiYIpLAjLz+4hvK0ybCbrmo6YqxHuyO8ubRUEB2evZdFkP6LgET9J GSgF+uGSXLKPfjrsfwtRavxfp6/h8G7f/aO9GjrfgLaglH/2CgT1Xd+0HvvNgC3+GD MUDFpwniJOAFw== In-Reply-To: <86bjyrqvb0.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 07 Nov 2024 10:53:23 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295007 Archived-At: Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: Fabio Natali , Eli Zaretskii , >> 74218@debbugs.gnu.org >> Date: Thu, 07 Nov 2024 09:42:29 +0100 >> >> I too agree that it's a good idea to optionally require confirmation. >> However, I suspect that a yes/no question is not the best interface in >> this case. Instead, it's better to simply prepopulate the minibuffer >> with the contents of the region. Then you confirm with RET and cancel >> with C-g. In addition, this lets you examine and edit your input. > > Why copy the region into the mini-window when it is already shown in > the current buffer's window? By default, it will be highlighted, but > if not (e.g., transient-mark-mode was disabled), we could forcibly > highlight it. Why is that not enough? While point is always visible, mark can be out of view, so the region need not be fully visible in the selected window. But more importantly, using the minibuffer provides a smoother and more consistent UX compared to an additional yes/no question, IMO. > Copying stuff into the minibuffer has the disadvantage of resizing the > mini-window, and then it could hit the limits on such resizes, which > will prevent the user from seeing large portions of the text, if the > region is large. > > Also, does anyone have an opinion about asking for confirmation only > for regions that are large enough? E.g., when the region is a single > word, do we want to ask for confirmation anyway? I think it makes sense to have an option that is sensitive to the size of the region, although personally I'd probably stick to "always ask", especially if the prompt for confirmation isn't too obtrusive.