From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: select yank via completion Date: Sun, 22 Nov 2020 01:48:49 +0300 Message-ID: References: <87mtzfzt9a.fsf@mail.linkov.net> <87k0uifp3w.fsf@mail.linkov.net> <87d009iykt.fsf@mail.linkov.net> <3341c426-3a86-4ef0-a0ca-9102191a925b@default> <87o8jsiems.fsf@mail.linkov.net> <87pn46sfd4.fsf@mail.linkov.net> <0ff3cdb6-e735-4eaa-86d9-7ab980b74431@default> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29492"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: spacibba@aol.com, andreyk.mad@gmail.com, emacs-devel@gnu.org, rudalics@gmx.at, Stefan Monnier , Gregory Heytings , Eli Zaretskii , Juri Linkov To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 21 23:52:09 2020 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 1kgbjl-0007ZZ-0H for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Nov 2020 23:52:09 +0100 Original-Received: from localhost ([::1]:51098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgbjk-00031l-28 for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Nov 2020 17:52:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgbhD-0000X4-Qi for emacs-devel@gnu.org; Sat, 21 Nov 2020 17:49:31 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:49877) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgbhC-0002qo-7w; Sat, 21 Nov 2020 17:49:31 -0500 Original-Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C000B.000000005FB99978.00001A3A; Sat, 21 Nov 2020 22:49:27 +0000 Content-Disposition: inline In-Reply-To: <0ff3cdb6-e735-4eaa-86d9-7ab980b74431@default> Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:259556 Archived-At: * Drew Adams [2020-11-22 01:22]: > > >> So now a new patch let-binds (minibuffer-completing-file-name t) > > >> around completing-read to allow inserting SPC, problem solved: > > > > > > Please don't, since we're not actually completing file names. > > > > > > I agree with Drew that we should probably just get rid of the SPC > > > binding in minibuffer completions, > > > > SPC can be an obstacle even in some completion styles > > where words are separated by SPC. > > Please provide an example/recipe. > > Completion candidates can contain SPC chars. Hundreds of thousands of my completion candidates in the database have spaces and I use standard completion about just as fast. People's names and organization names have spaces. So I complete all time candidates with spaces. But SPACE is compatible with that type of completion with `minibuffer-complete-word' as it will automatically give me the right choice! Yet I find the standard completion with SPC how it is now just fine to complete those candidates with spaces that I usually have. It is bound to (minibuffer-complete-word) and if there is any change then is better that such change becomes optional as defcustom, so that default is not changed. Otherwise it would be a game changer to me. If you decide to change it to SPC as self-insert-command then it breaks habits of many other users as well and it could be better to just introduce customization for that new feature, and not change. I say "new" because it is new to users who have different habit of completing with space. I have changed key bindings temporarily to self-insert and it becomes weird and confusing as I am not familiar with it as my expectation was to complete words with space. Example for this candidate: 10010 Maro's Country Home [PDF by Page Nr.] I have expected that this below would complete but then where do I go back? (as thoughts) Which space or how many to delete here (as thoughts). So confusion is taking place. 10010 Mar Cou Then I was at this point: 10010 Maro's Country Home <--- spaces end here and I could not complete So there would be various programming demands for changes when space becomes suddenly out of blue self-insert instead minibuffer-complete-word as usual. Major problem would be changing what is default.