From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: GNU Emacs raison d'etre Date: Sun, 17 May 2020 11:57:56 -0700 (PDT) Message-ID: References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <87v9kwi6ta.fsf@osv.gnss.ru> <83wo5ccgg4.fsf@gnu.org> <87lflshxtq.fsf@osv.gnss.ru> <83mu68cbbb.fsf@gnu.org> <87h7wghxdz.fsf@osv.gnss.ru> <87eerkgey1.fsf@osv.gnss.ru> <112aecd7-8165-6cae-ef69-08d14d843841@yandex.ru> <5d158a63-7173-424c-9d9f-ce7856f1eae7@default> <4bb36686-34e7-4ac8-898c-74e254902349@default> <29f65907-affb-481e-82f3-62522a766f69@default> <83sgfybn22.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="42034"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jean-Christophe Helary , Richard Stallman , =?iso-8859-1?B?QW5kcmVhcyBS9mhsZXI=?= , Emacs developers , Karl Fogel , homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, Sergey Organov , Stefan Kangas , dgutov@yandex.ru, Eli Zaretskii To: Arthur Miller , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 17 20:58:56 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jaOUw-000AnH-I9 for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 20:58:54 +0200 Original-Received: from localhost ([::1]:58706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaOUv-0001zU-Ko for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 14:58:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44614) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaOUC-0001WU-R2 for emacs-devel@gnu.org; Sun, 17 May 2020 14:58:08 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:60542) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaOUB-00034q-0i; Sun, 17 May 2020 14:58:07 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04HIw2se009781; Sun, 17 May 2020 18:58:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=iUKrsm46Nwgy7JvF7g9/5PGVvENEE4k26C8WW4lFhbs=; b=E8LSzxADGfmbKjUsDV6tPLlZiFL7Tr1R0tjRLFQTKKyQTRuot25vk3lo0ClYxQjfDLq9 So/yXazuvk1cHAqXnIviIU8X7SYD49mPU2dvj4UgEuDOE50fAaBejTpNtyBK6a2NnLPh tc4mB6fpywYJhc96k3hjdDIDl4anTBUMwCXQDXJZbFbX3Vc4WKdd6ijx1zxfwsscgmAn 2D+MIg30R5Mw5k8rgDBsACOpISP8ss2qnb4p3+OH7FL9YIF1m8VuAjztzuGG+WQPqM2p zOis8PhFiHgdbDfONbYjaUu1gPhFlFbFl7Hvzfgws/7+C2e86/RpK98YjZtIsBbL/mnu tA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 31284kkpcb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 17 May 2020 18:58:03 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04HImFVk191299; Sun, 17 May 2020 18:58:03 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 312t3u5qm4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 May 2020 18:58:03 +0000 Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 04HIvwHc000942; Sun, 17 May 2020 18:57:59 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9624 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 phishscore=0 bulkscore=0 suspectscore=18 mlxscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005170173 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9624 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 mlxscore=0 cotscore=-2147483648 impostorscore=0 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 phishscore=0 spamscore=0 bulkscore=0 adultscore=0 priorityscore=1501 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005170174 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/17 13:59:29 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250648 Archived-At: > "autohide" (similar as windows taskbar) could be a way? But it is > hardcoded in c-code that minibuffer cannot be hidden. That's not true (depending on what you mean, I guess). 1. It's trivial to move a minibuffer-only frame off screen (and bring it back on screen). 2. Alternatively, it's possible to make a frame invisible (and visible again). (modify-frame-parameters 1on1-minibuffer-frame '((alpha . 0))) (modify-frame-parameters 1on1-minibuffer-frame '((alpha . 100))) ___ [No, alpha is not a satisfactory solution for trying to get real invisibility. Zero doesn't make a frame completely invisible. And the frame is still present, at the same location, which can be bothersome in terms of interaction. Presumably, frame parameter `visibility' would also be usable for this, but it doesn't seem to have an effect on a minibuffer-only frame, at least on MS Windows. Same with parameter `minibuffer-exit', and same with functions `make-frame-(in)visible'. Dunno whether those are just bugs. As I said, my impression is that use of minibuffer frames doesn't get tested much when features are introduced.] > What I learned some decades ago when I took my driving license is that > human eye is trained to register motion, better then static objects. So > if minibuffer poped/raised/lowered (like a quake console :-)) when > needed, that motion could draw attention more then just some text > prompting in a tatic minibuffer. Same effect is probably achieved by > flushing minibuffers background/foreground colors or similar. One person's helpful attention attracter is another person's annoyance. So yes, but such things need to be optional - user preferences.