From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: use-package Date: Fri, 13 May 2016 08:38:52 -0700 (PDT) Message-ID: <6f3a39f9-216c-4cfd-9a26-b2fb12e8be8f@default> 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> 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 1463153978 24237 80.91.229.3 (13 May 2016 15:39:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 May 2016 15:39:38 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, Stefan Monnier To: phillip.lord@russet.org.uk, Kaushal Modi Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 13 17:39:25 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 1b1FBP-0007UB-9V for geh-help-gnu-emacs@m.gmane.org; Fri, 13 May 2016 17:39:19 +0200 Original-Received: from localhost ([::1]:35036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1FBO-0006sf-PH for geh-help-gnu-emacs@m.gmane.org; Fri, 13 May 2016 11:39:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1FB8-0006kB-P3 for help-gnu-emacs@gnu.org; Fri, 13 May 2016 11:39:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b1FB5-0001ol-6U for help-gnu-emacs@gnu.org; Fri, 13 May 2016 11:39:02 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:21016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1FB4-0001oA-RO for help-gnu-emacs@gnu.org; Fri, 13 May 2016 11:38:59 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4DFcsc7008977 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 May 2016 15:38:55 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u4DFcsmP008783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 May 2016 15:38:54 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u4DFcr1c015505; Fri, 13 May 2016 15:38:54 GMT In-Reply-To: <87y47f7zt1.fsf@russet.org.uk> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:109942 Archived-At: > It is certainly the case that the lighters are sometimes useful. But > if by sometimes, we mean "occasionally" then it's an open question > how sensible it is showing all of this information. Sensible, here as elsewhere, is in the mind of the user. Users should have an easy way to specify what behavior they want for a given lighter. Most modes etc. should _provide_ a lighter, thus giving the user the possibility of choosing. But again, users do need an easy way to pick and choose. It is typically enough that a mode provide an option to show the lighter or not. The mode designer decides on the default value of the option. A user can override that default choice.=20 > I agree that setting defaults is difficult, but "show everything > in case it is useful", is to my mind not sensible. Nothing is useful at that black-&-white level of oversimplification. For most modes I think there probably is some use in providing a lighter. But yes, users need to be able to choose, for any given lighter. They can choose a lighter only if it exists to be chosen. And yes, of course, developers of some modes will decide that a lighter is not at all useful. > 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 dis= played 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. > 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. 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. I would not want to see a rule established based on some survey. > 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. 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. For example, the Icicles the lighter, `Icy', changes to indicate whether completion is available for the current minibuffer reading and, if so, what kind of completion: lax/strict, multi-command, multi-completion (those are not mutually exclusive). Display of the lighter is optional, controlled by option `icicle-highlight-lighter-flag=E2=80=99 (on by default). During input reading without completion, the lighter is not highlighted - it just tells you that Icicle mode is on. It is highlighted red (by default) during completion. `+' is appended to it (`Icy+') during multi-command completion (meaning you can act on multiple candidates) `||' is appended if completion candidates are multi-completions (meaning that you can match parts of a multi-part candidate, separately or together). The lighter is boxed (overline+underline) for strict completion. If the list of candidates shown in `*Completions*' is currently=20 truncated then the lighter is suffixed by `...'. The lighter text is `Icy' for case-sensitive completion and `ICY' when case-insensitive. https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#CompletionStatusInd= icators 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. I do the same thing for Isearch (not really a mode, but it does use a lighter). With Isearch+, the lighter is `Isearch' for case-sensitive search and `ISEARCH' for case-insensitive. The lighter also indicates, by using faces, whether search has wrapped or overwrapped. By default, for wrapped the lighter has a blue overline, and for overwrapped it has a deep-pink overline and wavy underline. https://www.emacswiki.org/emacs/IsearchPlus > Advice in the manual would be: "Don't do this, unless you > have a very good reason". I disagree. Most modes probably should provide a lighter. But whether the lighter for a given mode is very, slightly, or not at all useful to a particular user in a particular context is for that user to decide. And context, including how many modes/lighters are currently available, can be important. > 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. > Adding configuration options is, I feel, dumping > the responsibility onto the user. Making a blanket, one-size-fits-all judgment for everyone takes choice away from users. Advice from the manual that most modes should not use a lighter ("Don't do this, unless you have a very good reason") would mean that users would generally not have a choice: no lighter =3D> no choice. > Think we can get this done in time for Emacs-25.1? I hope we never "get this done". Just one opinion. It sounds like you and your mode line have not really gotten along very well, and you've looked for a way to master it. That does not imply that mode developers should in general not provide lighters or that users generally find them useful and annoying. 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.