From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: IDE Date: Mon, 12 Oct 2015 07:39:30 -0700 (PDT) Message-ID: References: <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <5618E51D.4070800@yandex.ru> <83twpzrp05.fsf@gnu.org> <5618ED93.8000001@yandex.ru> <83lhbbrnn7.fsf@gnu.org> <56191D6B.8040405@yandex.ru> <838u7assvj.fsf@gnu.org> <561A3582.5080806@yandex.ru> <561A3756.1010404@gmx.at> <561A41CA.6060908@yandex.ru> <87io6c5ov5.fsf@gmail.com> <561B999D.2060900@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1444660842 16951 80.91.229.3 (12 Oct 2015 14:40:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 14:40:42 +0000 (UTC) Cc: martin rudalics , Eli Zaretskii , adatgyujto@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov , Oleh Krehel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 16:40:29 2015 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 1ZleH6-0007W9-TH for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 16:40:29 +0200 Original-Received: from localhost ([::1]:55841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZleGt-0004C7-Ba for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 10:40:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZleGT-0004AK-Er for emacs-devel@gnu.org; Mon, 12 Oct 2015 10:39:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZleGS-00083H-2U for emacs-devel@gnu.org; Mon, 12 Oct 2015 10:39:49 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:44449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZleGM-00081i-Bq; Mon, 12 Oct 2015 10:39:42 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9CEdW17026807 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Oct 2015 14:39:32 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t9CEdWCl030663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2015 14:39:32 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t9CEdVgV024332; Mon, 12 Oct 2015 14:39:31 GMT In-Reply-To: <561B999D.2060900@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:191341 Archived-At: > I agree, the Microsoft IDE looks slicker here, but the examples > are basically the same, in that they use separate frames for > the completion list and documentation, not the same one. Whether separate frames are used or not is not so important. It is important, though, to be _able_ to show the completions without necessarily showing the help for the current one. IOW, separate display can be useful, whether or not separate frames are used for that. The Icicles approach lets you show the complete help for the current candidate (systematically or on demand), but it does not mandate that. It happens to use separate windows (or frames), but that is not important here, IMO - the same effect could be provided with a single frame. Icicles also automatically (by default - option turns on/off) shows short help in the mode line (of `*Completions*'), systematically. Maybe that's all you had in mind, a one-liner? If so, then users would be missing the ability to show the complete help for the current candidate (again, systematically or on demand). Being able to do that is a big help, IMO. Summary: 1. Users should be able to show candidates without also the help. 2. Whether the same or separate frames or windows are used is not important. (It could be important to a given user, and it could be made a user choice.) 3. For simple, one-liner reminder help, the mode-line suffices. 4. Users should be able to show the complete help for the current candidate. One-liner help is no substitute for this. > > The first part is just Emacs' style of doing things: we usually > > enter stuff in the minibuffer, so it makes sense for completion > to display >=20 > A lot of users are fine with that, but I think we should do better. What is better, and why? Please don't gloss over this. I would not argue that minibuffer input is always better than other methods (e.g. at-point cycling). But it has different pros & cons. In particular, (1) it allows actual (and complete) editing, and (2) it provides its own keymap, for completion features or cycling features or candidate-action features. (And users can easily customize that keymap.) Those are pros. A con is that the minibuffer and `*Completions*' are not necessarily displayed close to point. That's a display question that could be addressed in various ways. > You'd think so, but displaying the docstring automatically, like > Auto-Complete does (as well as certain IDEs), has been a common > request for a while. And now, https://github.com/expez/company- > quickhelp is pretty popular. Does it display the complete doc string? If not, I'd say users are missing out. If yes, and this is done systematically, I'd say that users are being force-fed. They should have a choice. For systematic display (but it should still be "offable"), one-line help is fine. But it's not a replacement for being able to see the whole doc string.