From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Newsgroups: gmane.emacs.devel Subject: Re: ASCII-folded search [was: Re: Upcoming loss of usability ...] Date: Fri, 26 Jun 2015 08:13:43 -0400 Message-ID: References: <20150615142237.GA3517@acm.fritz.box> <87ioamz8if.fsf@petton.fr> <32013464-2300-46c6-ba46-4a3c36bfee5d@default> <87twu62nnt.fsf@mbork.pl> <87oakdfwim.fsf@uwakimon.sk.tsukuba.ac.jp> <83wpz1lh7c.fsf@gnu.org> <83oakdl7yj.fsf@gnu.org> <83ioall3x5.fsf@gnu.org> <87h9pzxtyi.fsf@mail.linkov.net> <87k2uudoqr.fsf@mail.linkov.net> <87616c94g4.fsf@mail.linkov.net> <87h9pw6922.fsf@mail.linkov.net> <87a8vn75r7.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0878ead486df05196aab5e X-Trace: ger.gmane.org 1435320848 18680 80.91.229.3 (26 Jun 2015 12:14:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jun 2015 12:14:08 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel , "Stephen J. Turnbull" , Stefan Monnier , Juri Linkov To: Bruce Connor Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 26 14:14:07 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 1Z8SWE-0003n4-1D for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 14:14:06 +0200 Original-Received: from localhost ([::1]:59769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8SWC-0006hN-Vc for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 08:14:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8SVv-0006hH-It for emacs-devel@gnu.org; Fri, 26 Jun 2015 08:13:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8SVu-0005p4-D1 for emacs-devel@gnu.org; Fri, 26 Jun 2015 08:13:47 -0400 Original-Received: from mail-yk0-x231.google.com ([2607:f8b0:4002:c07::231]:36166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8SVs-0005og-49; Fri, 26 Jun 2015 08:13:44 -0400 Original-Received: by ykdr198 with SMTP id r198so56348128ykd.3; Fri, 26 Jun 2015 05:13:43 -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=LwDvws1/Iuh0oCOXPuTBDoofZVjq7idZduRU6wiT04k=; b=Zw60xbG5AcEbZ1dp2VQj8QjiXPxxGSP9hqO/SExoiUPTlOBWWSX4CDFEcJwFtBIisp IqpBlQ4Pv355X/UXkuhYKhUt24pqOruvN3fvaF2CBzoTFvMQ8cnWsZlz4vCpTEwrfDgZ VsPWb2VpzvAhf7tVidv1V+tGJRQOf6NLMKIa5R7WWwMLdr60pJsLBHeTxNYOZsvvIXYu ccszIiYf6FmzYvQQSjhnIl7VzqOGaFAHGwWIEatYnkTOalTsGjbvJup8T+7fbo5R+GLN TtBcAH2jPeJ9zcQv9IleeopjsKKPPbK2xaH9tI8A4/9FQI5erEWPosCtPwKsVvNYufWj V8VQ== X-Received: by 10.13.232.8 with SMTP id r8mr1470963ywe.167.1435320823611; Fri, 26 Jun 2015 05:13:43 -0700 (PDT) Original-Received: by 10.13.253.5 with HTTP; Fri, 26 Jun 2015 05:13:43 -0700 (PDT) Original-Received: by 10.13.253.5 with HTTP; Fri, 26 Jun 2015 05:13:43 -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:4002:c07::231 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:187562 Archived-At: --94eb2c0878ead486df05196aab5e Content-Type: text/plain; charset=UTF-8 @Juri I read that that bug report is more than 2 years old. Did you recently submit a patch? Or were you referring to a patch from Drew in that bug report? @ Artur Using the modeline is a very neat idea! There is one package (anzu) I know of that makes partial use of the mode line to display the search pattern counts. We will need a solution that doesn't break these other packages. Or should the info be simply added to `minor-mode-alist` with "button click properties"? (I forgot the exact property name). abo-abo creates a pseudo minibuffer on top of the actual minibuffer to display the hints in his hydra.el package. That could also work here? My earlier suggestion was simply based in the current code. I saw that a `sleep-for` was used to flash the isearch setting change momentarily. I wondered if we just keep that isearch setting change display static and then remove that at the next search character input by the user. Let's say that the user is search for "abc" and he has already typed "ab". > Isearch: ab| Now the user decides to toggle one of the isearch toggles, let's say case-fold toggle and hits `M-c`. Then the minibuffer can display this > Isearch: ab| [case-sensitive] That should stay like that till the user continues typing > Isearch: abc| But, showing the isearch settings persistently in a separate area is a better idea. On Jun 26, 2015 5:32 AM, "Artur Malabarba" wrote: > > > - If we don't want to flash that message, the message can be displayed >> and >> > be allowed to stay there till user starts/resumes typing in the >> minibuffer. >> > >> > Thoughts? >> >> This will be fixed by bug#12988. I'll send the latest patch there. >> > > I don't know how you're planning on solving doing this, but I was going > to suggest that isearch could just take over the mode-line while in effect, > that would it give it a lot of space to verbosely display the searching > options (and maybe even list the key binds for each) and each option could > be a button that toggles itself. > --94eb2c0878ead486df05196aab5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@Juri
I read that that bug report is more than 2 years old. Did you recently subm= it a patch? Or were you referring to a patch from Drew in that bug report? =

@ Artur
Using the modeline is a very neat idea!

There is one package (anzu) I know of that makes partial use= of the mode line to display the search pattern counts.

We will need a solution that doesn't break these other p= ackages. Or should the info be simply added to `minor-mode-alist` with &quo= t;button click properties"? (I forgot the exact property name).

abo-abo creates a pseudo minibuffer on top of the actual min= ibuffer to display the hints in his hydra.el package. That could also work = here?

My earlier suggestion was simply based in the current code. = I saw that a `sleep-for` was used to flash the isearch setting change momen= tarily. I wondered if we just keep that isearch setting change display stat= ic and then remove that at the next search character input by the user.

Let's say that the user is search for "abc" an= d he has already typed "ab".

> Isearch: ab|

Now the user decides to toggle one of the isearch toggles, l= et's say case-fold toggle and hits `M-c`. Then the minibuffer can displ= ay this

> Isearch: ab| [case-sensitive]

That should stay like that till the user continues typing

> Isearch: abc|

But, showing the isearch settings persistently in a separate= area is a better idea.

On Jun 26, 2015 5:32 AM, "Artur Malabarba&q= uot; <bruce.connor.am@gmail= .com> wrote:
=

> - If we don't want to flash that message, the message can be displ= ayed and
> be allowed to stay there till user starts/resumes typing in the minibu= ffer.
>
> Thoughts?

This will be fixed by bug#12988.=C2=A0 I'll send the latest patch there= .

I don't know how you're planning on solv= ing doing this,=C2=A0 but I was going to suggest that isearch could just ta= ke over the mode-line while in effect, that would it give it a lot of space= to verbosely display the searching options (and maybe even list the key bi= nds for each) and each option could be a button that toggles itself.
--94eb2c0878ead486df05196aab5e--