From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tu Do Newsgroups: gmane.emacs.devel Subject: Re: Minibuffer per buffer Date: Sat, 7 Mar 2015 13:43:52 +0700 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3562ed4cc850510ad1fe1 X-Trace: ger.gmane.org 1425710641 31034 80.91.229.3 (7 Mar 2015 06:44:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Mar 2015 06:44:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Yuri Khan , fgunbin@fastmail.fm, joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 07 07:44:00 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 1YU8Su-0006CP-5m for ged-emacs-devel@m.gmane.org; Sat, 07 Mar 2015 07:44:00 +0100 Original-Received: from localhost ([::1]:33539 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YU8St-0000u5-Dx for ged-emacs-devel@m.gmane.org; Sat, 07 Mar 2015 01:43:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YU8Sp-0000tp-Vw for emacs-devel@gnu.org; Sat, 07 Mar 2015 01:43:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YU8So-0004rC-Sx for emacs-devel@gnu.org; Sat, 07 Mar 2015 01:43:55 -0500 Original-Received: from mail-la0-x231.google.com ([2a00:1450:4010:c03::231]:45039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YU8So-0004qz-Ki for emacs-devel@gnu.org; Sat, 07 Mar 2015 01:43:54 -0500 Original-Received: by labgq15 with SMTP id gq15so7777986lab.11 for ; Fri, 06 Mar 2015 22:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bp3L1fcg1j/x6EZI8pXEDSDBAan7vyzZ+s8WnGCAtwQ=; b=vJYjRI4SXHRHcMENIts57QTGYYu405GiNeN5lp1ibW0drF272GWofo7Jq9dZvCdgsH IteAwuONZQM/ZxFexC4ncVrvJcfHWTzYKnbaVHd2ULDPS/20yltP9oEMcFm9fZMmPFZY 3+GZ35JOyBB5afQVEap1Dyvku51MzCo1kxuPCrSw7F+qdQcIZ8p2kEEZOUVA4PUNy5Ap eubNzbIA+3ZB6Hp7mLp/qIA57FeW3NQkBt1mAhk0YdcumtYJ3dLldpliHswPYJ+Sfn50 pkL27t/lvuavqzYZo3MvcyeSmbixL6MOACl5M/12Yy1gQIdGcRxJRNYwUmhOhWYY8NRU EbwQ== X-Received: by 10.152.88.99 with SMTP id bf3mr15803565lab.37.1425710632977; Fri, 06 Mar 2015 22:43:52 -0800 (PST) Original-Received: by 10.112.54.135 with HTTP; Fri, 6 Mar 2015 22:43:52 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::231 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:183712 Archived-At: --001a11c3562ed4cc850510ad1fe1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just want to mention this issue to make it a feature request in the wishlist. Using frame as another minibuffer is not always nice because we have another OS window floating around. And it can't be used in the terminal. On Sat, Mar 7, 2015 at 12:42 PM, Yuri Khan wrote: > On Thu, Mar 5, 2015 at 3:43 PM, Filipp Gunbin wrote= : > > On 05/03/2015 11:47 +0700, Tu Do wrote: > >> As monitor becomes larger with higher resolution (i.e. 4k monitor), I > think it would be beneficial to have an option to activate minibuffer > >> per buffer. > > The motivation, as I understand it, is to bring the minibuffer closer > to the focus of user=E2=80=99s attention, which is in the selected window= . > > An easy workaround is to use multiple frames (perhaps with a tiling > window manager), each of which would by default have a minibuffer. > > I actually do this with a pre-4k (24=E2=80=B3 16:10 1920=C3=971200) monit= or, > splitting it into left and right halves. When working on code, I > frequently have both halves occupied with Emacs frames (each of which > may be further split into the top and bottom windows). > > > Where should echo messages (including not related to the current buffer= ) > > be displayed in this case? > > This can probably be solved the same way they choose a minibuffer when > multiple frames are involved. > --001a11c3562ed4cc850510ad1fe1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just want to mention this issue to make it a feature req= uest in the wishlist. Using frame as another minibuffer is not always nice = because we have another OS window floating around. And it can't be used= in the terminal.

= On Sat, Mar 7, 2015 at 12:42 PM, Yuri Khan <yuri.v.khan@gmail.com&= gt; wrote:
On Thu= , Mar 5, 2015 at 3:43 PM, Filipp Gunbin <fgunbin@fastmail.fm> wrote:
> On 05/03/2015 11:47 +0700, Tu Do wrote:
>> As monitor becomes larger with higher reso= lution (i.e. 4k monitor), I think it would be beneficial to have an option = to activate minibuffer
>> per buffer.

The motivation, as I understand it, is to bring the minibuffer close= r
to the focus of user=E2=80=99s attention, which is in the selected window.<= br>
An easy workaround is to use multiple frames (perhaps with a tiling
window manager), each of which would by default have a minibuffer.

I actually do this with a pre-4k (24=E2=80=B3 16:10 1920=C3=971200) monitor= ,
splitting it into left and right halves. When working on code, I
frequently have both halves occupied with Emacs frames (each of which
may be further split into the top and bottom windows).

> Where should echo messages (including not related to the current buffe= r)
> be displayed in this case?

This can probably be solved the same way they choose a minibuffer wh= en
multiple frames are involved.

--001a11c3562ed4cc850510ad1fe1--