all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Lennart Borgman'" <lennart.borgman@gmail.com>
Cc: per@starback.se, rms@gnu.org,
	'Stephen Eilert' <spedrosa@gmail.com>,
	emacs-devel@gnu.org
Subject: RE: Emacs for new users
Date: Tue, 24 Nov 2009 10:03:15 -0800	[thread overview]
Message-ID: <FDD2E9F2D11C41AAA6E14699D865B03F@us.oracle.com> (raw)
In-Reply-To: <e01d8a50911240915h7f6e5782tcbfde9432ab9411a@mail.gmail.com>

> >> 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.





  parent reply	other threads:[~2009-11-24 18:03 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-23 16:37 Emacs for new users Per Starbäck
2009-11-23 16:59 ` Giuseppe Scrivano
2009-11-23 18:47   ` Chong Yidong
2009-11-23 20:49     ` bug#1305: " Chong Yidong
2009-11-23 20:49     ` Chong Yidong
2009-11-26 22:35       ` bug#1305: Beeping (was: Emacs for new users) Juri Linkov
2009-11-26 22:35       ` Juri Linkov
2009-11-26 23:12         ` bug#1305: " Lennart Borgman
2009-11-26 23:12         ` Lennart Borgman
2009-11-27  4:12           ` bug#1305: Beeping Stefan Monnier
2009-11-27  4:12           ` Beeping Stefan Monnier
2009-11-27  6:48             ` Beeping Lennart Borgman
2009-11-27 19:25               ` Beeping Stefan Monnier
2009-11-27 20:25                 ` bug#1305: Beeping Lennart Borgman
2009-11-27 20:25                 ` Beeping Lennart Borgman
2009-11-27 23:12                   ` Beeping Stefan Monnier
2009-11-27 23:15                     ` Beeping Lennart Borgman
2009-11-28  1:49                       ` Beeping Stefan Monnier
2009-11-28  2:47                         ` Beeping Lennart Borgman
2009-11-27 19:25               ` bug#1305: Beeping Stefan Monnier
2009-11-27  6:48             ` Lennart Borgman
2009-11-23 17:05 ` Emacs for new users Stephen Eilert
2009-11-24 14:10   ` Richard Stallman
2009-11-24 14:43     ` Renaud Casenave-Péré
2009-11-24 16:10       ` Andreas Schwab
2009-11-25 21:01       ` Richard Stallman
2009-11-30 23:02       ` Giorgos Keramidas
2009-11-24 15:51     ` Lennart Borgman
2009-11-24 16:41       ` Drew Adams
2009-11-24 17:15         ` Lennart Borgman
2009-11-24 17:27           ` Chong Yidong
2009-11-24 17:35             ` Lennart Borgman
2009-11-24 17:51             ` Deniz Dogan
2009-11-24 18:37               ` Chong Yidong
2009-11-24 18:03           ` Drew Adams [this message]
2009-11-24 18:06             ` Lennart Borgman
2009-11-24 18:22               ` Drew Adams
2009-11-24 18:30                 ` Lennart Borgman
2009-11-24 19:35                   ` Drew Adams
2009-11-24 19:40                     ` Lennart Borgman
2009-11-25 21:02           ` Richard Stallman
2009-11-25 21:04             ` Lennart Borgman
2009-11-25 21:57             ` Fernando C.V.
2009-11-25 22:05               ` Drew Adams
2009-11-25 22:27                 ` Fernando C.V.
2009-11-25 22:34                   ` Drew Adams
2009-11-26  6:23               ` Richard Stallman
2009-11-23 18:56 ` Lennart Borgman
2009-11-23 19:35   ` Les Harris
2009-11-23 20:28     ` Lennart Borgman
2009-11-23 21:04       ` Chong Yidong
2009-11-23 21:16         ` Lennart Borgman
2009-11-23 21:56           ` Stefan Monnier
2009-11-23 22:05             ` Lennart Borgman
2009-11-30 22:55         ` Giorgos Keramidas
2009-11-30 23:01           ` Lennart Borgman
2009-12-01  9:13           ` Deniz Dogan
2009-12-01 10:13             ` Miles Bader
2010-11-13 19:14               ` separating CUA rectangles from CUA selection mode [was: Emacs for new users] Drew Adams
2009-11-23 21:16     ` Emacs for new users Stephen Eilert
2009-11-23 22:06       ` Per Starbäck
2009-11-23 22:43         ` Per Starbäck
2009-11-23 22:46           ` Lennart Borgman
2009-11-23 23:55           ` Sebastian Rose
2009-11-24  6:43           ` tomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FDD2E9F2D11C41AAA6E14699D865B03F@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.com \
    --cc=per@starback.se \
    --cc=rms@gnu.org \
    --cc=spedrosa@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.