From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Wed, 18 Dec 2013 09:43:46 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <8761qmkyn1.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <87li0kdrsz.fsf@flea.lifelogs.com> <878uwi8t3r.fsf@mail.jurta.org> <83ob5ee7ow.fsf@gnu.org> <87d2ltl2if.fsf@mail.jurta.org> <8338moevm3.fsf@gnu.org> <8761rkaa5e.fsf@flea.lifelogs.com> <87txf0390n.fsf@flea.lifelogs.com> <87y53komex.fsf@flea.lifelogs.com> <87haa8moh6.fsf@flea.lifelogs.com> <874n67n450.fsf@flea.lifelogs.com> <87eh5bkxca.fsf@flea.lifelogs.com> <87d2kuzzqj.fsf@uwakimon.sk.tsukuba.ac.jp> <87a9fylusq.fsf@flea.lifelogs.com> <878uvizrwz.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1387377777 16100 80.91.229.3 (18 Dec 2013 14:42:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Dec 2013 14:42:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 18 15:43:01 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VtIKw-0007DX-QD for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2013 15:42:59 +0100 Original-Received: from localhost ([::1]:39032 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtIKw-0006dx-GA for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2013 09:42:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtIKo-0006UI-3u for emacs-devel@gnu.org; Wed, 18 Dec 2013 09:42:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtIKi-0007rq-98 for emacs-devel@gnu.org; Wed, 18 Dec 2013 09:42:50 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:35833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtIKh-0007qf-UY for emacs-devel@gnu.org; Wed, 18 Dec 2013 09:42:44 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VtIKf-0006va-1b for emacs-devel@gnu.org; Wed, 18 Dec 2013 15:42:41 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Dec 2013 15:42:41 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Dec 2013 15:42:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 89 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:dJXg1MuUk29DshMc0n3fFsvFdhw= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:166583 Archived-At: On Wed, 18 Dec 2013 13:47:40 +0900 "Stephen J. Turnbull" wrote: SJT> Oh, in *that* sense, yes -- but that's cheating. *Your* argument SJT> requires the meaning "familiar to people who aren't familiar with SJT> Emacs", and I adopted your terminology. I am trying to explain that people like what's familiar to them and call it "intuitive" and "easy to use." The vast majority of applications in existence have adopted some conventions for how to select items from a list, so "users" in general are familiar with those conventions. Emacs users and developers have developed their own UI conventions, many predating modern user interfaces (both the conventions and the users/developers!). So any time you try to discuss improvements to the Emacs UI, you have two versions of "familiar" and each side in the debate is very attached to their version of it and somewhat blind to the other side's version. The best way forward seems to be to look at specific solutions of the problem outside Emacs, preferably without mentioning Apple or Microsoft products because they tend to polarize the debate quickly. Please also understand I am not talking about actual functionality here, only about the user experience. Emacs is by far more powerful and useful than most products on the market, but without a good user experience it's harder to discover that. SJT> HCI research is mostly crap, AFAICT. OK, I guess that settles it. >> Hey, I think you need an example! libreadline (and most shells that use >> it). Attacking the Notepad/W32/crapGUI straw man won't help this >> discussion. SJT> At that point Emacs and the rest of the world (including shells) part SJT> company, and I don't see anything in your argument that deals with SJT> that discontinuity. I understand the concern, and think that the following suggestions are not badly discontinuous for simple list selection, a very common use case: * selection candidates should be displayed near the point where the user requested the list. In a buffer, this is (point). In the minibuffer, this is the input position. * they should be displayed without a dedicated *Completions* buffer, like `widget-choose' does it (special text buffer in text mode, nice popup in graphical mode) * up/down should move between candidates until selection * any other self-insert character should narrow the selection further and get inserted in the original context * RET should complete the selection * ESC or C-g should cancel the selection * further TABs could have special effects, e.g. select current candidate and move on to next selection step (Stefan's example of doing more than basic list selection). I don't feel strongly about this one, personally. SJT> Feel free to expand on the libreadline example, though. I suspect it SJT> falls apart in the sense that I know that I want *consistent* SJT> completion throughout Emacs, where a minibuffer is just a buffer that SJT> happens to be one line high. Whereas libreadline is highly optimized SJT> to work with the constraint that the buffer *is* exactly one line SJT> high. But that's mostly uninformed intuition, somewhat informed by SJT> the idea of a "reality discontinuity". I was trying to give you examples of other solutions to the same problem that are closer to the Emacs users' and developers' expectations, because I feel talking about GUIs inevitably gets into the wrong kind of arguments about Office and so on (none of which interests me, as I mentioned above I only want to discuss the user experience, not the functionality). libreadline is very familiar to our group and is a good API example to study, but it has significant limitations as you know. zsh completion is another great example, where you have highly context-sensitive modules to complete command options and values, written in a fairly primitive language. The user can choose to enable or disable completion modules and change completion options. zsh completion supports multiline display of candidates and in many ways behaves like the in-buffer completion Emacs does today, including dismiss-on-input behavior. Ted