all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Per Starbäck" <per@starback.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: John Wiegley <jwiegley@gmail.com>,
	rms@gnu.org, Drew Adams <drew.adams@oracle.com>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: lax matching is not a great default behavior
Date: Fri, 4 Dec 2015 13:04:24 +0100	[thread overview]
Message-ID: <CADkQgvvznOzWDJOPh3S92RGeXUOWj21gGsQP2zZ7CuK=bRs5DQ@mail.gmail.com> (raw)
In-Reply-To: <83wpsuh6cr.fsf@gnu.org>

>> > I see no real reasons yet for such a decision.  Character folding was
>> > introduced with the explicit goal of giving users what the other
>> > text-editing and word-processing environments provide, what they
>> > therefore are expected to expect.  To revert that decision will take
>> > more than just "I think it's wrong" kind of posts.
>>
>> I didn't follow its creation, but I don't think users generally expect
>> that (yet). (I just checked searches in Gedit and Firefox where there
>> were no such features, at least not in the versions that are standard
>> in my operating system distribution.)
>
> Try more serious editing environments.  E.g., MS Word does that by
> default.

I don't have access to MS Word, I don't think experiences from that
influences what users expect in an editor much, and I think it is
beside the point anyway. A good feature is good anyway.

> The entire time interval between Nov 15 this year and until we release
> Emacs 25.1 (which will take a few months, probably more than 6,
> judging by past experience) is supposed to provide that feedback.

The main feedback won't come until after it is available in a released version.
What we were talking about is what should be the default in the next
released version. Since you are instead talking about the default
*before release* we are maybe not in disagreement after all.

>> I may have missed something, but I have not read a single "I think
>> it's wrong" post.
>
> Any post that doesn't explain why folding characters might be _wrong_
> in _most_ situations is not providing any useful arguments for turning
> off the default.  Most posts I've seen explained why their authors
> don't like this feature.

Big problems are big even if they only affect 5% of the users. The
example I have given where this feature for Scandinavians is like
having a search for "I" find "J" is such a problem. That just isn't
acceptable, and will affect _most_ editing session for some, but of
course not _most_ situations for all users combined. Some adaptations
by language are needed to make this a good feature, and that won't be
there in place for the next release, and also we won't know which
adaptations are needed for other languages until more get to use this.

And this is strange. I haven't read a single such post, and yet it's
most posts you have seen. I wonder if you have read that into any post
by me.

> I do realize it's a massive change.  And you are wrong assuming that I
> almost only write in English (look at my locale), let alone that this
> is some American-centered view (which would have dictated exactly the
> opposite default).

I'm not assuming that (and know that it's not so). This is not
personal, but Emacs as a whole is American-centered. Its understanding
of the needs for other languages that don't use a Latin script has
earlier proved to be a better than its understanding of the needs for
other languages using a Latin script.
(And no, it certainly wouldn't. The harder you have to type áàẩããǎ the
better it is for you to be able to search for them easily when they
happen to be in a buffer.)



  parent reply	other threads:[~2015-12-04 12:04 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-28  5:04 lax matching is not a great default behavior Drew Adams
2015-11-28  8:29 ` Andreas Schwab
2015-11-28 14:50   ` Drew Adams
2015-12-01  9:23   ` Andreas Röhler
2015-12-01 10:38     ` Andreas Schwab
2015-12-01 10:42       ` Yuri Khan
2015-12-01 15:38         ` Eli Zaretskii
2015-12-01 15:36     ` Eli Zaretskii
2015-11-28  8:44 ` Eli Zaretskii
     [not found]   ` <<m2mvtv1ldi.fsf@newartisans.com>
2015-11-30 16:51   ` John Wiegley
2015-12-01 14:40     ` Richard Stallman
2015-12-01 15:55       ` Eli Zaretskii
2015-12-01 18:49         ` Mark Oteiza
2015-12-01 18:56           ` Eli Zaretskii
2015-12-01 19:32             ` David Kastrup
2015-12-01 19:36               ` Eli Zaretskii
2015-12-01 19:38             ` Mark Oteiza
2015-12-01 19:36           ` Artur Malabarba
2015-12-01 19:51             ` Mark Oteiza
2015-12-01 20:01               ` Eli Zaretskii
2015-12-01 20:04                 ` Eli Zaretskii
2015-12-01 23:31                   ` Artur Malabarba
2015-12-01 23:45                     ` Drew Adams
2015-12-02  3:37                     ` Eli Zaretskii
2015-12-02  8:23                       ` martin rudalics
2015-12-02 13:45                         ` Eli Zaretskii
2015-12-02 13:06                       ` Artur Malabarba
2015-12-02 13:44                         ` Eli Zaretskii
2015-12-02 17:25                           ` Artur Malabarba
     [not found]               ` <<83r3j6j5vj.fsf@gnu.org>
     [not found]                 ` <<83poyqj5qb.fsf@gnu.org>
2015-12-01 21:17                   ` Drew Adams
2015-12-02 17:52         ` Richard Stallman
2015-12-03 22:27         ` Per Starbäck
2015-12-03 23:00           ` Drew Adams
2015-12-04  0:09             ` Artur Malabarba
2015-12-04  8:28           ` Eli Zaretskii
2015-12-04  9:33             ` Per Starbäck
2015-12-04 10:10               ` Eli Zaretskii
2015-12-04 10:57                 ` David Kastrup
2015-12-04 11:19                   ` Eli Zaretskii
2015-12-04 12:04                 ` Per Starbäck [this message]
2015-12-04 14:42                   ` Eli Zaretskii
2015-12-04 17:47                     ` John Wiegley
2015-12-05  8:02                       ` Eli Zaretskii
2015-12-04 15:55             ` Drew Adams
2015-12-04 19:05               ` Eli Zaretskii
     [not found]       ` <<83610ikvto.fsf@gnu.org>
     [not found]         ` <<CADkQgvs-WvPX=qZ0B_un9j53RF6S4V5OmDTATSW1ZwTY50o2Rg@mail.gmail.com>
     [not found]           ` <<83bna6ipn7.fsf@gnu.org>
     [not found]             ` <<45e1580a-863c-4bd7-82ec-38c27a0d930e@default>
     [not found]               ` <<831tb2ghkf.fsf@gnu.org>
2015-12-04 21:30                 ` Drew Adams
2015-12-04 22:16                   ` David Kastrup
2015-12-04 22:37                     ` Artur Malabarba
2015-12-04 23:08                       ` David Kastrup
2015-12-04 23:57                     ` Drew Adams
2015-12-05  7:53                   ` Eli Zaretskii
2015-12-01  3:54   ` Discussions that led to changes in the defaults, was: " Dmitry Gutov
2015-11-28  8:49 ` David Kastrup
     [not found] <<d77851fd-da55-4020-82e8-abbd13f9b048@default>
     [not found] ` <<83twnxfi0h.fsf@gnu.org>
2015-12-05  9:27   ` Drew Adams
2015-12-05 11:15     ` Eli Zaretskii
     [not found]   ` <<6741424b-fb48-48d1-a2fe-a5b755373c46@default>
     [not found]     ` <<83fuzhf8op.fsf@gnu.org>
2015-12-05 15:59       ` Drew Adams
2015-12-06  1:37         ` John Wiegley
     [not found] <<c9f3197f-b5f3-42f3-817c-bf560842b4d7@default>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADkQgvvznOzWDJOPh3S92RGeXUOWj21gGsQP2zZ7CuK=bRs5DQ@mail.gmail.com' \
    --to=per@starback.se \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jwiegley@gmail.com \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.