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 08:02:25 -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> <561BC85E.8060901@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 1444662211 7740 80.91.229.3 (12 Oct 2015 15:03:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 15:03:31 +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 17:03:19 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 1ZledB-0004yT-Tg for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 17:03:18 +0200 Original-Received: from localhost ([::1]:55935 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZledB-0006gM-BZ for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 11:03:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlecc-0006fJ-H1 for emacs-devel@gnu.org; Mon, 12 Oct 2015 11:02:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zlecb-000864-5e for emacs-devel@gnu.org; Mon, 12 Oct 2015 11:02:42 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:27781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlecR-000842-NX; Mon, 12 Oct 2015 11:02:31 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9CF2RvB005246 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Oct 2015 15:02:27 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t9CF2Qnj024732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2015 15:02:26 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t9CF2QLE020084; Mon, 12 Oct 2015 15:02:26 GMT In-Reply-To: <561BC85E.8060901@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: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:191346 Archived-At: > > 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. >=20 > If you're forced to use the same frame, you're forced to make the > documentation pane and the completions menu the same height (or > width), or just have an empty rectangle somewhere. That's not ideal. I agree. I personally use separate frames for them, and the frames are fit to the content they display. My point was that what is important is the ability to separate their display - not couple them in a hardcoded way. Whether separate frames are used for that is a separate question, and less important. (But yes, I too prefer separate frames.) Separate frames allow not only elimination of wasted space, for the reason you gave. They can also be overlapped, which can be useful for additional space savings. IOW, sometimes you don't need to see all of the contents of each frame, and you want to additionally see other stuff on your display at the same time. Frames allow great flexibility for screen real estate. > > What is better, and why? Please don't gloss over this. >=20 > Not having to always look at the minibuffer when entering stuff. If what you are entering is simple then you don't have to look at it. And if not then you still need to look at the place where you are inputting/editing the pattern to complete. I agree that it can be handy for that to be point in the main buffer. But a con in that scenario is the attendant "busyness" of that area: input pattern editing + output completions & help display. And if you allow not just completion and help, but also actions on the current candidate (a la Helm or Icicles) then the display can become even busier in that area. And for a complex input pattern, which might be multiline, using a separate editing buffer (the minibuffer) is a plus, IMO. > > 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. >=20 > The user can disable the minor mode. What does that mean? Does it (can it) display the complete doc string?