From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: problems importing keys via epa-search-keys Date: Sun, 12 Mar 2023 08:33:30 +0200 Message-ID: <83o7oyv5qd.fsf@gnu.org> References: <87zg8mz998.fsf@xelera.eu> <83mt4jycxt.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39826"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 12 07:34:25 2023 Return-path: Envelope-to: geh-help-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 1pbFHl-000ABz-JJ for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 12 Mar 2023 07:34:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbFHG-000779-Iq; Sun, 12 Mar 2023 01:33:54 -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 1pbFH7-0006zL-Aj for help-gnu-emacs@gnu.org; Sun, 12 Mar 2023 01:33:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbFH5-0005jH-E7 for help-gnu-emacs@gnu.org; Sun, 12 Mar 2023 01:33:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=OJW/Sb0AX8/Zvq/NK7TG+s7U+cU00ndKBN9xROp1Tgc=; b=QuUsMyCAFcKr NGDM9BCJJ7jNSgd+auVa4pqAvKEr7UNzyf113CRBLyJSxGso35FssB892lGEqgpuTcCWRhasy9Wmu icGpV+ZPw+2E09HlSEcRt+jk+Mo8LuvOPrQnXn6F54y49ifiqZieepgGr1ic06ZhHolp3ZHiiaKe/ 0VRVQp4xOlXzJyg2MCLq2ek9L8MKY2I2WUAjZeN5OBlqNpUKRmafql9d2nkIORoEx+E6YLDs0Sjvr 2l30dpi7kRE/VsWkJQyp2p1cRGgfpKB2TJ3V86NvAKUZbteBK55NgGJXuhYNWCKJLExDOs3+auVkQ pHjclkRXMDYJHAHvTXtqkA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbFH4-00036u-I0 for help-gnu-emacs@gnu.org; Sun, 12 Mar 2023 01:33:43 -0500 In-Reply-To: (message from Filipp Gunbin on Sun, 12 Mar 2023 02:04:21 +0300) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142994 Archived-At: > From: Filipp Gunbin > Cc: help-gnu-emacs@gnu.org > Date: Sun, 12 Mar 2023 02:04:21 +0300 > > On 11/03/2023 09:17 +0200, Eli Zaretskii wrote: > > > It's a regression that existed since Emacs 28.1, right? So its fix > > should try to avoid changing APIs. Therefore, please try to make a > > change that leaves the signature of epa-ks--query-url unchanged, I > > think it should be easy in this case. (Yes, I know it's an internal > > function, but that doesn't mean we can change the signature when we > > can avoid that.) > > Yes, since 28.1. The updated patch is below. > > But why an internal function is part of API? Don't we assume that > anyone using them is doing so at their own risk? In this case the > default for operation is "index" (to preserve compatibility), but it's > better here to not have the default value at all. I agree that we can break the API if we need, but we don't need to, and it is always better to keep the signature unless it's impossible. So please modify your patch to leave the signature intact, I don't think it's hard in this case. > > P.S. And why are you posting patches and their discussion here, not on > > the bug tracker? > > Because OP wrote here? And we didn't open a bug for this. Should we, > even for such simple fixes? It's better, because then the discussion is recorded and referenced in the commit.