From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.help Subject: Re: use-package Date: Mon, 16 May 2016 16:16:45 +0100 Message-ID: <87shxinici.fsf@russet.org.uk> References: <874magv15u.fsf@mat.ucm.es> <87d1p38ll6.fsf@mat.ucm.es> <87y47pg5da.fsf@russet.org.uk> <87shxwzkzg.fsf@russet.org.uk> <87d1outgo2.fsf@russet.org.uk> <87y47f7zt1.fsf@russet.org.uk> <6f3a39f9-216c-4cfd-9a26-b2fb12e8be8f@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1463411855 6846 80.91.229.3 (16 May 2016 15:17:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 May 2016 15:17:35 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, Stefan Monnier , Kaushal Modi To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 16 17:17:19 2016 Return-path: Envelope-to: geh-help-gnu-emacs@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 1b2KGb-0000Ds-JH for geh-help-gnu-emacs@m.gmane.org; Mon, 16 May 2016 17:17:09 +0200 Original-Received: from localhost ([::1]:44357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2KGa-0008MU-Vm for geh-help-gnu-emacs@m.gmane.org; Mon, 16 May 2016 11:17:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2KGK-0008IE-HN for help-gnu-emacs@gnu.org; Mon, 16 May 2016 11:16:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2KGG-00027d-7V for help-gnu-emacs@gnu.org; Mon, 16 May 2016 11:16:51 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:47951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2KGF-00026d-RW for help-gnu-emacs@gnu.org; Mon, 16 May 2016 11:16:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=kpMo5pp6BeRvXYD/OarogquJgYx5Fy1Y/+yqa3RVdms=; b=faKY+GYIu+d+GskioqedBsP1E/ eke7gjORR5TpxAgHCJSZxry6oQYUzM7vpPzq8jDw4sxk3BIKGaV6srJS/2u8HJBp90mnLKsEf0l7d FHrlT5uFYwWI5EaQlnYbT6NOqNwDrggtjeTyXJSApQIhOEvyMTR0emY9yiSZIyiMBvInUcR+GiLJb xOHaoSiGdJdpiWcyLPrZMm8x35IVkOkk5kwrngOSjmfC1LPak7Q1KKMMvTGm3O67KvANkRaO+73ek 7h45xPCsOgUMcUsnfCllIL1HwDKaOj4Kz8sU/Se7Zs1Ah3mf5AN5TGrlmKkM9l9H794bSapOR0Hq5 3KsONPpg==; Original-Received: from janus-nat-128-240-225-60.ncl.ac.uk ([128.240.225.60]:32519 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1b2KGE-001wVO-K3; Mon, 16 May 2016 16:16:46 +0100 In-Reply-To: <6f3a39f9-216c-4cfd-9a26-b2fb12e8be8f@default> (Drew Adams's message of "Fri, 13 May 2016 08:38:52 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 31.216.48.48 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:109972 Archived-At: Drew Adams writes: >> Consider, the current information about lighters in the manual. >> "Minor Mode Conventions" says nothing; in fact, the only place >> I can find anything is in the documentation about >> `define-minor-mode' which says: >>=20 >> The string LIGHTER says what to display in the mode line when the >> mode is enabled; if it is =E2=80=98nil=E2=80=99, the mode is not di= splayed in the >> mode line. >>=20 >> So no information about why should and should not appear. > > What would you expect it to say? Any consideration of whether to > provide a lighter requires some knowledge of the _particular_ mode. > It is up to the mode designer to judge whether it makes any sense > to provide a lighter. It should be up to a user to decide whether > to show a provided lighter. Most things require some knowledge of the use case, but that doesn't stop us from making statements or giving advice that may be relevant in certain circumstances. Things that might be useful to say: don't use a lighter if your mode is likely to be always on for any user that uses it at all; don't use a lighter if your mode provides immediate feedback that it is one (completion!). >> One thing that would be nice would be some way of surveying Emacs >> users. Perhaps an ELPA package that we could update occasionally, and >> each update would be a new survey. Still, a separate issue. > > A separate issue, yes. But as it relates to this discussion, my > voice is against asking for some summary yes/no from users. My thought was a something a bit richer; a cross-between "M-x report-emacs-bug" and a survey. For this question, for example, it would be good to know how many people are using rich-minority and for what purpose. > The utility of a particular lighter is 100% dependent on the > particular mode. And its utility to a particular user depends on that > user and possibly on different use contexts. These are assertions. You might be right, you might not. But I would not use "it all depends" as the basis for not making a decision. Always leaving things to the users and saying "well, it's configurable" is not a good way forward. > I would not want to see a rule established based on some survey. In the ideal world, we would establish practice on the basis of evidence. > >> I would suggest something more radical. >>=20 >> We replace the current list of lighters with a single item, which >> when clicked on gives a menu of minor modes. > > A lighter is meant to provide immediate information, directly and > continually, without having to ask for it (e.g. access a menu). > We already have menus that provide access to minor-mode info. Do we? Where? > So I strongly disagree with your suggestion. Among other things, > I have lighters that indicate more than two states (mode on/off). > And I would encourage this for other modes that might, in effect, > have multiple states. It puts the lie to the idea that lighters > are not very useful in general. Oh, I said "not often" not "in general". There are certainly examples. Likewise, projectile has a dynamic lighter. viper-mode, interesting, has a static lighter but changes the mode line in other ways. > https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#CompletionStatusI= ndicators > > This lighter thus communicates a fair amount of info using > only a few characters. This is no doubt not common, but I'd > bet that some other modes also could usefully provide more > info in a lighter than just on/off. And clearly, in this case, it is useful. So the question is, can we make more space for useful things? >> Rich-minority and diminish are papering over the cracks. >> Too much is happening in mode line. > > Again, a user judgment. It sounds like too much, for you, > was happening in your mode line. Emacs is rich in use > cases and users. Your mode line might bother me too - or > it might not. I think you need to distinguish between "your judgement"-- in this case that means mine, and "user judgement" as something that the user should reasonably be expected to make a decision on. Expecting users to unclutter the mode-line for themselves is not good. What neither of us knows is a) do many users find the mode-line cluttered b) do many users unclutter it for themselves and c) do they always unclutter the same things. > > You know, there are packages that give Emacs a spartan, > minimal look & feel - no title bar, menu bar, tool bar, > fringes, mode line,... That's great - for those users > who want such a look & feel. > > I'm all for such a possibility. What I am not for is > Emacs imposing or recommending this or that look & feel > in some blanket way. > > Let a hundred flowers bloom. Vive the mode line. A mode-line with 100 lighters really would be cluttered. Phil