From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#21112: 25; Patch: show minibuffer messages with a face Date: Thu, 27 Jun 2019 14:37:45 -0700 (PDT) Message-ID: <18c4ab5e-277c-4241-86dd-89ca1e870ee7@default> References: <55AF90B9.5040401@gmail.com> <87si0jvkgv.fsf@gnus.org> <87pnn11nm5.fsf@mail.linkov.net> <87y31orqm1.fsf@mail.linkov.net> <87zhm39bu3.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="149856"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 21112@debbugs.gnu.org, Raffaele Ricciardi To: Juri Linkov , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 27 23:39:04 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hgc6e-000cmu-Ks for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Jun 2019 23:39:00 +0200 Original-Received: from localhost ([::1]:54860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgc6c-0003wE-A7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Jun 2019 17:38:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33597) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgc5k-0003nF-GG for bug-gnu-emacs@gnu.org; Thu, 27 Jun 2019 17:38:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgc5i-0000H1-HC for bug-gnu-emacs@gnu.org; Thu, 27 Jun 2019 17:38:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54619) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgc5h-0000FZ-SQ for bug-gnu-emacs@gnu.org; Thu, 27 Jun 2019 17:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hgc5h-0006Dc-Ol for bug-gnu-emacs@gnu.org; Thu, 27 Jun 2019 17:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Jun 2019 21:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21112 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix patch Original-Received: via spool by 21112-submit@debbugs.gnu.org id=B21112.156167147623893 (code B ref 21112); Thu, 27 Jun 2019 21:38:01 +0000 Original-Received: (at 21112) by debbugs.gnu.org; 27 Jun 2019 21:37:56 +0000 Original-Received: from localhost ([127.0.0.1]:39930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgc5c-0006DI-0W for submit@debbugs.gnu.org; Thu, 27 Jun 2019 17:37:56 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:44688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgc5a-0006D4-5L for 21112@debbugs.gnu.org; Thu, 27 Jun 2019 17:37:54 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5RLXpsc084510; Thu, 27 Jun 2019 21:37:48 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-2018-07-02; bh=1F1OlQkh2d16GxhzQn9Qi1yMBBuJIu/P5NP58+iGFmQ=; b=TqDNJ91kR3X0iVTSySl+o56d9x57E0xGYy5WN6fFuKwb+22zn88DQv7KGFUyxFhNBQoG 5qu7Zw4i2yC9efyxxawVwr39qfHZjZlWKIFvWD2bx7UIFsxe4s7lJtu4KnS2/B4R8l6Y BUPhsKEhE6c1kOP8ED/SwFJjqcJc1FEqN5ZW3ckd99W6IsPMSV7zQ0bM7OxcE++OjUXy aZ5q1pN1Ir03fOOIlFwfLoQNofp41Xuj57RfnFjDuQcnrzJ1k6kcUAQVUaSDVSahoxbT Av/dwrmH9Y8jlifSkxgTyNVmaWT1wKc9VC6HSnGrr833TKbQm3yLbyPMcIzqKPaFn3pE vQ== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2t9c9q2kc4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Jun 2019 21:37:48 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5RLba3u169813; Thu, 27 Jun 2019 21:37:48 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2t9p6vjpe7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Jun 2019 21:37:48 +0000 Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x5RLbkvw006295; Thu, 27 Jun 2019 21:37:46 GMT In-Reply-To: <87zhm39bu3.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4861.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9301 signatures=668688 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906270247 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9301 signatures=668688 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906270247 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:161662 Archived-At: > Without highlighting of minibuffer messages there is a danger that the > message will remain unnoticed, especially in the multiline minibuffer. Danger? Really? Some people don't like danger notices. Some people don't like (what they call) "angry fruit salad". Some people don't like lots of highlighting - or even any highlighting, e.g. in something like Dired. Some people even turn off `font-lock-mode'. (I'm not one of those people, but they exist.) People are different. Their use cases and contexts of use are different. One size does not fit all. > So minibuffer messages need to be highlighted for the same reason > why the minibuffer prompt is already highlighted: "Need to be"? Neither of those things _needs_ to be highlighted. Lots of us users will appreciate that they can be highlighted. We'll also appreciate being able to choose how, how much, and whether they're highlighted. > 1. to designate non-editable read-only parts of the minibuffer; > 2. to help the users to turn attention to the active part > of the minibuffer. I agree (personally and generally) with those aids - helpful. I don't agree about there being "danger" if they are absent. > Thus all informational text in the minibuffer should be highlighted > consistently in one color to help not to miss important message. "Thus"? That doesn't follow, even if one accepts your argument above. Nothing in that argument implies that ALL informational text in the minibuffer should be highlighted CONSISTENTLY IN ONE COLOR. It's quite possible for important messages not to be missed without such a paint-it-all-the-same approach. It's quite possible that some code wants (and the users who choose to use that code want) to emphasize certain parts of a message specially - including precisely "to help not to miss" something particularly noteworthy. What is true in this regard of `message' is also true of `minibuffer-message'. Are you thinking of imposing the same kind of blanket treatment for `message'? If not, why not? Why doesn't that apply also to `minibuffer-message'? > Isn't it so already that elsewhere in Emacs font-lock is used > to highlight more important parts of the buffer? Font-lock does not impose a single face ("consistently in one color") for all its highlighting, does it? Why not? Because it can be useful to emphasize different things differently...