From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: Exposing Isearch toggleable options Date: Fri, 30 Oct 2015 08:01:53 -0400 Message-ID: References: <87611q7c3f.fsf@mail.linkov.net> <877fm5tefl.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d57c6902bbe052351319e X-Trace: ger.gmane.org 1446206532 8391 80.91.229.3 (30 Oct 2015 12:02:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Oct 2015 12:02:12 +0000 (UTC) Cc: Emacs developers To: Bruce Connor Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 30 13:02:12 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 1Zs8Nn-00007w-2K for ged-emacs-devel@m.gmane.org; Fri, 30 Oct 2015 13:02:11 +0100 Original-Received: from localhost ([::1]:50116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs8Nm-0000Iz-Dx for ged-emacs-devel@m.gmane.org; Fri, 30 Oct 2015 08:02:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs8NY-0000Ip-Dz for emacs-devel@gnu.org; Fri, 30 Oct 2015 08:01:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zs8NX-0007qJ-CO for emacs-devel@gnu.org; Fri, 30 Oct 2015 08:01:56 -0400 Original-Received: from mail-oi0-x22f.google.com ([2607:f8b0:4003:c06::22f]:35809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs8NX-0007qB-6f for emacs-devel@gnu.org; Fri, 30 Oct 2015 08:01:55 -0400 Original-Received: by oifu63 with SMTP id u63so58258414oif.2 for ; Fri, 30 Oct 2015 05:01:54 -0700 (PDT) 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=NQj128CRpJX5fmMDDp3HPFbmu+2eqkLFyuFOAnBTUmk=; b=T1U92zMDMtj6ylzKv/1w+cfxMJtCoRISUcL2okvdoVwpMnWt4U94o4fskneJKw2kTz N7JH1mXeaGKEH40oKWTmvwCu3ifzMNhEo8ExL4fMvwSaGiG80KJuSUYjmSDQ4pBpfxvd fAwpAD/zNEhpytGLmWGokb7uaJHnkAzPg3dkhkdgwG3I2wXVrdlVFr61ryDP9NwLLpzd cg31U6Y87WN3+XvoeBbz+eR0H50+6tyZQh8fNt746zCP3imirz5aRWlpmyBX7EDTobyt wUgnP4BOwRdIqePcZGHHie7KjE0b7KJO/y9y0JC9NX1Wk5BUjaEEuawLbeDFmV6cTUzs bObw== X-Received: by 10.202.221.68 with SMTP id u65mr5178050oig.34.1446206514406; Fri, 30 Oct 2015 05:01:54 -0700 (PDT) Original-Received: by 10.202.44.8 with HTTP; Fri, 30 Oct 2015 05:01:53 -0700 (PDT) Original-Received: by 10.202.44.8 with HTTP; Fri, 30 Oct 2015 05:01:53 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c06::22f 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:192962 Archived-At: --001a113d57c6902bbe052351319e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The hydra option looks good. A user can even customize that hydra if they want to. But as Marcin said, do we then need to bundle hydra with emacs. In addition to that option, it would be nice to always show the toggle starts in the mode-line. The hydra can also show the current states of all the toggles. But it would be useful to show "a representation of the toggle states" in the mode-line so that the user does not need to launch the hydra just to see the states. By "representation", I recall what Drew had mentioned in one of the earlier threads discussing this: If modeline shows: "AbCd", the search will be case sensitive, without char folding. If modeline shows: "abcd", the search will be case insensitive, without char folding. If modeline shows: "=C3=A2bcd", the search will be case insensitive, with c= har folding. And so on... But then "abcd" example might not fit the bill for all toggles. Instead, should we have 2-letter acronyms for all toggles in the modeline and change their face based on the toggle state? Let's say, these are the acronyms: Cs - Case sensitive RE - Regular expressions =C4=8CF - Char folding LW - Lax Whitespace ... And so on. This list of 2-char acronyms can again be made user customizable. But the association of acronyms to the toggle var should be kept fixed to prevent confusion and unneeded complication. Those acronyms will be displayed with sort of a dimmed out, gray face when the respective toggle is disabled. But the face will be changed to something like bold green when enabled. It goes without saying that the faces would be customizable. What do you guys think? --001a113d57c6902bbe052351319e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The hydra option looks good. A user can even customize that = hydra if they want to. But as Marcin said, do we then need to bundle hydra = with emacs.

In addition to that option, it would be nice to always show = the toggle starts in the mode-line. The hydra can also show the current sta= tes of all the toggles. But it would be useful to show "a representati= on of the toggle states" in the mode-line so that the user does not ne= ed to launch the hydra just to see the states.

By "representation", I recall what Drew had mentio= ned in one of the earlier threads discussing this:

If modeline shows: "AbCd", the search will be case= sensitive, without char folding.

If modeline shows: "abcd", the search will be case= insensitive, without char folding.

If modeline shows: "=C3=A2bcd", the search will be= case insensitive, with char folding.

And so on...

But then "abcd" example might not fit the bill for= all toggles.

Instead, should we have 2-letter acronyms for all toggles in= the modeline and change their face based on the toggle state?

Let's say, these are the acronyms:

Cs - Case sensitive
RE - Regular expressions
=C4=8CF - Char folding
LW - Lax Whitespace
... And so on.

This list of 2-char acronyms can again be made user customiz= able. But the association of acronyms to the toggle var should be kept fixe= d to prevent confusion and unneeded complication.

Those acronyms will be displayed with sort of a dimmed out, = gray face when the respective toggle is disabled. But the face will be chan= ged to something like bold green when enabled. It goes without saying that = the faces would be customizable.

What do you guys think?

--001a113d57c6902bbe052351319e--