From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: Possible minibuffer completion enhancements Date: Wed, 17 Jan 2024 20:17:50 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14733"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 17 20:18:39 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rQBQs-0003c5-Nc for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Jan 2024 20:18:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQBQC-0005Kp-Sn; Wed, 17 Jan 2024 14:17:56 -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 1rQBQB-0005Kg-0k for emacs-devel@gnu.org; Wed, 17 Jan 2024 14:17:55 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rQBQ9-0008TV-5y for emacs-devel@gnu.org; Wed, 17 Jan 2024 14:17:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1705519072; bh=lJfTiRhuvBUiC5ohCb28RoCCcRFdGRZDml4ATyhJ264=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bV4bFnceuB6FZIZu6OJtLP3xA7LXqtx7Pd84IArrA8EJU5i5Qo25XRrzAvIqumWRh K/VyLX8dXMaTngasjW6XryTU25iSk28tSdF9IPQaRyC7l5d1FfRLSLUQxHo2bG5Cp9 fFsOW49GIaAmzXL+TfXvjjdTKzddljImHXyWtYFITlq6nymgV5euG4U2/meDUKscmy OwPMxBv/2cBy0P53FHrLb3tNRY7A8NqzhXIjkMnADjKBNy5gQjY4MMvOrRXssFeOL7 1MbEn79HUDVpmzfDrA3BT0ZOQdstL9JAmS0cWcAG/Rd30gU1764rXVkO/ROqtbA982 SaaVzERKPp4Bw== In-Reply-To: (Stefan Kangas's message of "Tue, 16 Jan 2024 16:44:27 -0600") Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315044 Archived-At: Stefan Kangas writes: > Eshel Yaron writes: > >> Stefan Kangas writes: >> >>> Eshel Yaron writes: >>> >>>> In general, I'm happy to upstream anything that seems useful/desirable >>>> in my working branch, even if I haven't mentioned it here specifically. >>> >>> Thanks. Could I ask that you send patches to us for the changes you >>> think might be generally useful? >> >> Sure, I've just sent one in Bug#68508. > > Thank you. I also saw some doc fixes that might be worth considering, > and maybe there's more? > > It takes extra work to pick out changes in an external branch where your > changes are mixed in with the ones from the official tree. So the more > you can send, the more we are likely to integrate, I think. Yeah, that makes sense. There's a small bugfix that I'll try to send later today, and I'll check the doc fixes to see if they're relevant. >> Do you feel that any of the minibuffer commands I suggested should be >> sent for review as well? > > I don't use the default completion, but based on their descriptions I > don't see why we shouldn't want to consider all of them. > > If the changes are orthogonal, it might make sense with one bug report > per patch, otherwise it might make more sense with a feature branch. > > It really is whichever makes it easier to test and review the changes, > and probably you are in a the best position to say what you think about > that. Then we'll take it from there. I think a feature branch could be nice. The changes are conceptually orthogonal in the sense that each enhancement can be useful by itself, but the code changes are not separated as some of them touch the same areas of minibuffer.el. I can pick the relevant changes and create a tidy feature branch with just these new minibuffer commands added on top of master, if that helps. Eshel