From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.bugs Subject: bug#22147: Obsolete search-forward-lax-whitespace Date: Wed, 18 May 2016 03:00:35 +0000 Message-ID: References: <87wpsk7dcs.fsf@mail.linkov.net> <87d1ubz3w9.fsf@mail.linkov.net> <87r3ipoofk.fsf@mail.linkov.net> <87zixcblno.fsf@mail.linkov.net> <874mfjchp1.fsf@mail.linkov.net> <87r3d4z7uf.fsf@mail.linkov.net> <8ec0f5d4-a500-42c1-bab8-eaba00f0915c@default> <87shxjjb0h.fsf@mail.linkov.net> <8e655300-1a72-4df6-87cf-91fd006cb3d7@default> <8737pgwgiu.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114304565408e705331510f0 X-Trace: ger.gmane.org 1463540486 11632 80.91.229.3 (18 May 2016 03:01:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 May 2016 03:01:26 +0000 (UTC) Cc: 22147@debbugs.gnu.org To: Drew Adams , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 18 05:01:17 2016 Return-path: Envelope-to: geb-bug-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 1b2rjY-0006ri-9W for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 May 2016 05:01:16 +0200 Original-Received: from localhost ([::1]:42691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2rjX-0004aK-7Q for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 May 2016 23:01:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2rjO-0004a9-LK for bug-gnu-emacs@gnu.org; Tue, 17 May 2016 23:01:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2rjK-0006VF-20 for bug-gnu-emacs@gnu.org; Tue, 17 May 2016 23:01:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44100) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2rjJ-0006V9-VP for bug-gnu-emacs@gnu.org; Tue, 17 May 2016 23:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b2rjJ-0000Ig-MD for bug-gnu-emacs@gnu.org; Tue, 17 May 2016 23:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Artur Malabarba Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 May 2016 03:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22147 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22147-submit@debbugs.gnu.org id=B22147.14635404531132 (code B ref 22147); Wed, 18 May 2016 03:01:01 +0000 Original-Received: (at 22147) by debbugs.gnu.org; 18 May 2016 03:00:53 +0000 Original-Received: from localhost ([127.0.0.1]:56437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2rjB-0000IC-AV for submit@debbugs.gnu.org; Tue, 17 May 2016 23:00:53 -0400 Original-Received: from mail-vk0-f52.google.com ([209.85.213.52]:33151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2rj9-0000Hw-Cx for 22147@debbugs.gnu.org; Tue, 17 May 2016 23:00:51 -0400 Original-Received: by mail-vk0-f52.google.com with SMTP id z184so44859162vkg.0 for <22147@debbugs.gnu.org>; Tue, 17 May 2016 20:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6UiyU2E4K+IaeBl0Qj6nmd/T/FRLSWLUUjN3IvYLEUc=; b=emHmxPxNN9BSf2Tt2at92J7ISpxRnYf+L156VAIciz6zbDcYTTTIRCdPIVU2+eZtTt crNROTvxw4w+duzfxMrKxdJbCh7RVj8K3BPf3dCzpfujH6d2Vj4YMUx1odHQ5snBQw7n Lgjpz7bLanIGWVqowwr0EvgSk7P/alS1Gm69znoA0yybHVV+IF7mBpXKvSAzFF7HoQ85 lLlQ7thC39B+zRvKF9IzwKdyXDKMzBznqnxtmbpFm2Fk31ha37mwDs7clj437KVVNFgs qmJ9CbrQWwEWBLbGgMpy2377I6YC3dljX1oOf7bgrr2L3Yfhc2tznDiyHfk93E+2iOK7 fvPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6UiyU2E4K+IaeBl0Qj6nmd/T/FRLSWLUUjN3IvYLEUc=; b=ItaHlKDBK8YWhbOrvaTenehCfPLx0EO7zYk3C4INxHzsIsRanao/uy3g9Bx/uaJV8F jIFZyptiubysBX//lnrj0mXrHmCwJ6eCO9HiHNDfC+roLq+/zdmX5C3LJUknCd/XUwaP Rd1CxzDZE6F6soUXSTsC8O6J7ULaP45RIx5+/ZZ06sbiqHJZTV5JVKRSvMZhBQVsEUua IGRjxzSf+7KbwtJExZGEZJ+ye5szES5VpZSSCfB3LzJVjuS6qM8ZLrnjvENeFd+22POy HDur6lxUEiGxWsWLlfPz1dKON7m0FmkEndDILtgIfCbMWYacudjD63twW8VOWh2wJtRB DvKg== X-Gm-Message-State: AOPr4FUeBu4tVjJV04DE5xFsSvxhw66NxmRYJtHhPrhpTSVBNf56GpVUG/VgAk1RTXD/QDQF7eEAOUJRi7o2Mg== X-Received: by 10.31.59.205 with SMTP id i196mr2761873vka.76.1463540444823; Tue, 17 May 2016 20:00:44 -0700 (PDT) In-Reply-To: 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: 208.118.235.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:118375 Archived-At: --001a114304565408e705331510f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First of all, thanks for taking the time to help with this, Juri. I'm of the opinion that we should avoid over thinking this feature for the first release. And I'm also of the opinion that complicated custom-vars (like alists of alists) are less helpful than simple custom vars. So I'd strongly prefer if we don't turn this variable into something more complicated. Also (although I'm perfectly in favor of a variable for ad-hoc foldings), I wouldn't mind it if this bug was removed from the release blocking list. It's a feature request, not a proper bug, so the release wouldn't be flawed without it. On Tue, 17 May 2016 6:55 pm Drew Adams, wrote: > > > Another consideration (for me, at least): I think (and hope) that > > > eventually users will be able to have multiple such lists (sets) > > > of char mappings that they can choose (and mix and match - sets of > > > such sets, for different purposes/contexts). IOW, I don't see just > > > a single set of ad-hoc char mappings. But this is anyway for the > > > future. > > > > Yes, we have to take into consideration that in addition to the > > plain customizable list we are adding to the next release, > > in later versions we might also add more customizable lists, > > e.g. with categories and other character groups. > > One possibility is to (now), instead of having an option with a single > list of ad-hoc mappings as value, have an option with an alist of such > lists as its value, where the car of an alist entry names the particular > ad-hoc mapping. > > See my suggestion in an earlier mail in this thread. > > > >> Another thing we need to do is to allow customization to remove > > >> default mappings. Maybe this is possible by using the same > > >> defcustom with a rule like: remove default mappings when a char > > >> is mapped to an empty list, e.g. > > >> > > >> - adding more mappings for =E2=80=98`=E2=80=99: > > >> (defcustom char-fold-ad-hoc '((?` "=E2=9D=9B" "=E2=80=98" "=E2=80= =9B" "=F3=A0=80=A2" "=E2=9D=AE" "=E2=80=B9")) > > >> > > >> - removing default mappings for =E2=80=98`=E2=80=99: > > >> (defcustom char-fold-ad-hoc '((?`)) > > > > > > Yes, I would think that would work (already). But I could be wrong. > > > > > > Thanks for taking a look at this. > > > > After long-planned terminology improvements, I'd wait for sync between > > branches to avoid merge conflicts, and then I'll submit a patch taking > > into account all opinions about the default value for users who will > > enable this feature in the next release. > > Sounds good. Thx. > --001a114304565408e705331510f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

First of all, thanks for taking the time to help with this, = Juri.

I'm of the opinion that we should avoid over thinking th= is feature for the first release. And I'm also of the opinion that comp= licated custom-vars (like alists of alists) are less helpful than simple cu= stom vars. So I'd strongly prefer if we don't turn this variable in= to something more complicated.

Also (although I'm perfectly in favor of a variable for = ad-hoc foldings), I wouldn't mind it if this bug was removed from the r= elease blocking list. It's a feature request, not a proper bug, so the = release wouldn't be flawed without it.


On Tue, 17 May 2016 6:55 pm= Drew Adams, <drew.adams@oracle= .com> wrote:
> > Anoth= er consideration (for me, at least): I think (and hope) that
> > eventually users will be able to have multiple such lists (sets)<= br> > > of char mappings that they can choose (and mix and match - sets o= f
> > such sets, for different purposes/contexts).=C2=A0 IOW, I don'= ;t see just
> > a single set of ad-hoc char mappings.=C2=A0 But this is anyway fo= r the
> > future.
>
> Yes, we have to take into consideration that in addition to the
> plain customizable list we are adding to the next release,
> in later versions we might also add more customizable lists,
> e.g. with categories and other character groups.

One possibility is to (now), instead of having an option with a single list= of ad-hoc mappings as value, have an option with an alist of such lists as= its value, where the car of an alist entry names the particular ad-hoc map= ping.

See my suggestion in an earlier mail in this thread.

> >> Another thing we need to do is to allow customization to remo= ve
> >> default mappings.=C2=A0 Maybe this is possible by using the s= ame
> >> defcustom with a rule like: remove default mappings when a ch= ar
> >> is mapped to an empty list, e.g.
> >>
> >> - adding more mappings for =E2=80=98`=E2=80=99:
> >>=C2=A0 =C2=A0(defcustom char-fold-ad-hoc '((?` "=E2= =9D=9B" "=E2=80=98" "=E2=80=9B" "=F3=A0=80=A2= " "=E2=9D=AE" "=E2=80=B9"))
> >>
> >> - removing default mappings for =E2=80=98`=E2=80=99:
> >>=C2=A0 =C2=A0(defcustom char-fold-ad-hoc '((?`))
> >
> > Yes, I would think that would work (already).=C2=A0 But I could b= e wrong.
> >
> > Thanks for taking a look at this.
>
> After long-planned terminology improvements, I'd wait for sync bet= ween
> branches to avoid merge conflicts, and then I'll submit a patch ta= king
> into account all opinions about the default value for users who will > enable this feature in the next release.

Sounds good. Thx.
--001a114304565408e705331510f0--