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: Emacs for new users Date: Tue, 24 Nov 2009 10:03:15 -0800 Message-ID: References: <912155b0911230837i48326730m82e0d54d4004be59@mail.gmail.com> <485b0c380911230905t6513e718w1dd804e18003228@mail.gmail.com> <6E092AF13796494BADEBCE2C5C0361CE@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1259086745 6427 80.91.229.12 (24 Nov 2009 18:19:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2009 18:19:05 +0000 (UTC) Cc: per@starback.se, rms@gnu.org, 'Stephen Eilert' , emacs-devel@gnu.org To: "'Lennart Borgman'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 24 19:18:57 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NCzyR-00068w-MJ for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2009 19:18:48 +0100 Original-Received: from localhost ([127.0.0.1]:34370 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCzyR-0001qX-3R for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2009 13:18:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCzje-0005ld-ON for emacs-devel@gnu.org; Tue, 24 Nov 2009 13:03:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCzjZ-0005i4-UT for emacs-devel@gnu.org; Tue, 24 Nov 2009 13:03:30 -0500 Original-Received: from [199.232.76.173] (port=59048 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCzjZ-0005hx-IP for emacs-devel@gnu.org; Tue, 24 Nov 2009 13:03:25 -0500 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:52995 helo=rgminet12.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NCzjX-0005JE-4H; Tue, 24 Nov 2009 13:03:23 -0500 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nAOI3EYi028215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Nov 2009 18:03:15 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nAOHbRqa025290; Tue, 24 Nov 2009 18:05:13 GMT Original-Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 575904721259085794; Tue, 24 Nov 2009 10:03:14 -0800 Original-Received: from dradamslap1 (/24.5.185.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Nov 2009 10:03:13 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcptKbysAzNnhjLAT96ZBknwT8zsMgABRpLw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4B0C1FE4.00A3:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:117695 Archived-At: > >> For beginners I think it would be good if when minibuffer is active > >> clicking in other windows did not work. Or moving to > >> another window in any other way. > > > > Why? What possible reason could you have for such a suggestion? > > > > That would totally prevent using the mouse to interact with > > other buffers during minibuffer input. You wouldn't even be > > able to choose a completion from *Completions* using the mouse. > > Sorry, you are right. I did not think of that kind of use. > > What I meant was that they should not be allowed to leave the > minibuffer and go to another window. This is similar to how many GUI > programs work. I understand and understood. You didn't mean *Completions* (which is another window, BTW). I didn't either. It's important (to me) that users be able to interact normally with Emacs while the minibuffer is active, that is, as normally as possible except for whatever the minibuffer must modify wrt behavior. I do not want to see minibuffer inputting become something strictly modal that locks you into some restricted dialog. Users should be able to go anywhere and do pretty much anything while the minibuffer is active. > In some cases there are clever uses of other windows, for example the > one you mentioned. Such use should of course be allowed. (It is more > difficult to make that kind of use easy in Emacs since we can't for > example mark visually which window to interact with and which to not. > This is otherwise what many GUI applications do.) I do not want to in any way restrict "which window to interact with" during minibuffer input. Pretty much the only thing the minibuffer being active should change is the set of keybindings that are current in the minibuffer itself. The minibuffer can be active without the minibuffer being the current buffer. Think of the minibuffer being active as you would think of the debugger being active. When you are in the debugger buffer or the minibuffer buffer, certain key bindings and behavior are in effect. But nothing prevents you from doing things (pretty much anything) elsewhere. And you can have recursive minibuffers and recursive debuggers. It seems like you are thinking of the minibuffer in a very restricted way, akin to modal dialog box. It is not modal in that way and should not be.