From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrii Kolomoiets Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Fri, 13 Nov 2020 00:51:25 +0200 Message-ID: References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> <834klv26vu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6853"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin) Cc: spacibba@aol.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 12 23:52:29 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 1kdLS7-0001hX-NU for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 23:52:27 +0100 Original-Received: from localhost ([::1]:46366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdLS6-0007Wh-ML for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 17:52:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47228) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdLRE-00073f-Ed for emacs-devel@gnu.org; Thu, 12 Nov 2020 17:51:32 -0500 Original-Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:42882) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kdLRC-0003NM-Jj; Thu, 12 Nov 2020 17:51:32 -0500 Original-Received: by mail-lf1-x133.google.com with SMTP id u18so10934612lfd.9; Thu, 12 Nov 2020 14:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=tw/yOnSv2Wv+Gb5vef86WymK96BwwU2LeUea3Ec83OA=; b=JOxmMGtIK6weyx6KTzDGU5/Ki7iD5sYjbMOOUs5k4+XusouoanouV5Y5JyOPDE6iWB 2eq0eesMHwJrb/3dwxUyNHcsgJWBvaX9O30kpLiUtR/p0qBpPTA1dSQz342U0KoAKRXQ LBOdaYH+yWsLE8zMN/kBHIsNFXw7Js8cdPFtmEDPRnLzT7ESmk7CzpxoM+oqE34Wa9at yGMGO6elnriTokTaUv6/lQZ9gAHpgdjnjqOFPkKYEYH2CixCOFTuAztQFDi+N1Y4A+l1 u+DhKOBtAmxn27ER+9Hwxg9hZtNZQ3lg+pFIHMWMkFiuI7+zkELz7tqy1it6cO/o+6bS UpLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=tw/yOnSv2Wv+Gb5vef86WymK96BwwU2LeUea3Ec83OA=; b=G0GhvwRcTt+eOK7FdzAzuFv8t0ZHpqp8qdrLpoHzzGnpz1gDFj9OTQhvazAGikpXcx twBKjDd/3lrhHZB1MM/LM+IoTLTgF3mznRvXlvI5N8zk2VHXgUjkrpGuEiIH1NgMvbPx JJi9sIBSLi9xTC88g1MClQui617e8gCKkohKmQgnWgVOiqsKslMMBxpeCPel4RMzazw1 esk6+tMj0hwDRJE3jHxRKEzPQlJWqqlAj+twO1e0GDYQAW2p74zXjgSJ/VfOPdf7LFNm KYV797lAfqEPVFI2Qq/bP7AOhrrFxZ7XHYyLIMqiwWuWr33p1XJO4kUVsEmCRE3RXBsu XbaA== X-Gm-Message-State: AOAM532+9q/XJ11EzEUKi21jFde/nuKlTcJpRuOo7+87ZLY1uKrDaT0H lMhlNYoXEeNR3KDa22gl8B4= X-Google-Smtp-Source: ABdhPJx0KpO5ZTRQmzatVBiR9puH+qb+h36K82LJ4X/5iawOaN0s5Pg7J9yOsUdojCx1vugMJ9CZ0A== X-Received: by 2002:a19:57:: with SMTP id 84mr646266lfa.79.1605221487928; Thu, 12 Nov 2020 14:51:27 -0800 (PST) Original-Received: from muffinmac ([91.206.110.192]) by smtp.gmail.com with ESMTPSA id q20sm1019683lfr.110.2020.11.12.14.51.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Nov 2020 14:51:27 -0800 (PST) In-Reply-To: <834klv26vu.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 11 Nov 2020 18:30:29 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::133; envelope-from=andreyk.mad@gmail.com; helo=mail-lf1-x133.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:259108 Archived-At: Eli Zaretskii writes: >> I don't take the overlay text as the actual text but rather like a hint >> or helper. E.g. in icomplete-mode overlay text shows what part of the >> text can be automatically completed. Overlay text can be completelly >> hidden and even in this case I will be able to enter the text. >> >> The prompt is more important. Imagine there are two prompts: "Selected >> file will be deleted. Select file: " and "Selected file will be >> opened. Selected file: ". I certainly don't want to see only "Select >> file:" because all the space is occupied by hints. Hide hints but show >> me the full prompt. > > That is one way of looking at this. But it is not the only one, or at > least it doesn't necessarily fit all the uses of the minibuffer. > > First, the overlay text is not just a "hint": sometimes it is very > important to let you know what to type next. For example, the list of > files in a large directory that are completion candidates is very > important to see, unless you know in advance what file you want. > Moreover, in some cases those "hints" are the _only_ way of knowing > what inputs are acceptable: Can you please show me the example of such usage in the default configuration? As I can see, Emacs by default doesn't show any hints in the minibuffer while reading user input. Even with the icomplete-mode enabled, possible completions are not visible by default if the input is empty: one must also enable icomplete-show-matches-on-no-input. > imagine a multiple-selection question where only a finite set of > possible answers is acceptable, and you don't know in advance what > that set is. E.g., this: > > Send this email message by: {Mailclient, Smtp, XDG-email} > - - - > > Without seeing the possible answers, what are your chances of knowing > what to type? Chances are pretty good: I'll press TAB to see the *Completions* buffer. Those completion hints are not replacing usage of the usual Emacs completion system, but complements it, at least in the icomplete-mode. > OTOH, sometimes the prompt is not important: when you yourself invoke > the command that prompts. For example, if you type "C-x C-f", how > important is it for you to see the "Find file" prompt? Probably not > too important. Next to "C-x C-f" is "C-x C-d", so if you accidentally hit the "d" instead of the "f", the prompt is the only one who can tell you why no files are showed in the completion hints. For me the prompt is important. Sometimes I hit "C-x v d" instead of "C-x C-f" and try to complete filename to find. >> IMO the minibuffer behavior about the prompt, the text and the overlay >> should be: show as much text before point as possible (including the >> prompt), then show the rest of the text (in case the point is not at the >> end of the text) and then show the overlay text. > > Do you still think this is always true? > >> And here I come to the answer to your question: for me, the bug here is >> that the prompt is hidden in favor of the overlay text. > > The strategy Emacs uses to display stuff in the mini-window is shared > by both minibuffer and echo-area display -- in the latter case your > proposal that distinguishes between the prompt, the rest of the text, > and the overlay at the end, will not necessarily make sense. Oh, in this case let's try even simpler approach: show as much text before point as possible. > The design of that strategy assumed that text displayed in the > mini-window is relatively short. It is easy to break this strategy by > using features that were never intended to be extensively used in the > mini-window. Yes, and I'm not really fond of those insane examples with multiline promts. And if it is the application responsible for keeping the prompt short, we must be ready for long user inputs. For example, better show me the prompt and the default directory on "C-x C-f" rather than all filenames in the directory. > But those uses don't invalidate the design assumptions, they just > demand support for very different use cases. Then I have a question about the display strategy: why is the tail of the message is more important than the head? For example, evaluate this buffer: (setq max-mini-window-height 1) (set-frame-width nil 77) Now move point to the "max-mini-window-height" and wait to eldoc message to come up. What I see in the echo-area is "fer and the echo area).". > Thus, a "bug" is not an appropriate name for what you are bringing up, > and I hope you will agree that a single strategy will never be able to > cover all the possible uses of the mini-window. Yes, I agree. > The conclusion, IMO, is that the application should tell the display > engine how it wants to display the stuff in the mini-window in the > "unusual" cases, where the default strategy produces sub-optimal > results. I see many applications are trying their best to fit the text into the miniwindow. Can the display strategy be changed to display the beginning of the text by default? Or every application must use solution provided by Gregory? BTW, icomplete-mode is trying way too hard :) Just found this while playing with completing-read: Evaluate buffer: (icomplete-mode) (setq max-mini-window-height 1) (setq icomplete-prospects-height 1) (setq icomplete-show-matches-on-no-input t) (completing-read "Long prompt to ask user how to send this email message. By: " '("Mailclient" "Smtp" "XDG-email")) Now use C-. to switch between completion candidates. All but "Smtp" are hidden with just "[Matched]" printed. In this letter I have tried to give real examples that describes my point of view. It would be interesting for me to know about use cases with the opposite point of view. Thanks!