From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: PATCH: isearch-yank-until-char Date: Mon, 26 Aug 2019 14:57:41 -0700 (PDT) Message-ID: References: <87tvakfnv4.fsf@red-bean.com> <87lfvvjxjs.fsf@mail.linkov.net> <87sgq1r9rb.fsf@red-bean.com> <87lfvt6m1e.fsf@mail.linkov.net> <877e7256uc.fsf@red-bean.com> <604cbbef-7e25-486a-a97a-9bc1adf23928@default> <871rx87b9h.fsf@red-bean.com> <77205e15-f38a-46dc-9451-4030a318900a@default> <874l23ak8m.fsf@red-bean.com> <87k1az8vk5.fsf@red-bean.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="72115"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Emacs developers To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 26 23:59:08 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2N11-000IYL-Dp for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 23:59:07 +0200 Original-Received: from localhost ([::1]:57998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2N0z-0005D1-HK for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 17:59:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44574) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2N0O-0005AM-Jj for emacs-devel@gnu.org; Mon, 26 Aug 2019 17:58:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2N0N-0000Ge-2r for emacs-devel@gnu.org; Mon, 26 Aug 2019 17:58:28 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:48064) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i2N0M-0000Fp-QY for emacs-devel@gnu.org; Mon, 26 Aug 2019 17:58:27 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7QLrXxh024753; Mon, 26 Aug 2019 21:58:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=OVZIfZBAC9Hm3GI8dFEubRIN6M61ixeD9saUi+YlEj0=; b=ocgfduYLjwEjRGjZCwqv8mKCkduRTmAKFNdrDXKm+5AOUusDYd+Bm1icsGzcbkaNdSQv KC4t3vfIQ8u+rFvH50Cocim8fUL79n0sUEM2fpiq/S0xMtPCklEZFxpSm8F+69TByRVW 5UM/iq8/QF5EYAQgrexrzlaSkbhF3FfoPi9giGGOVu0V+383C/hcMH2wRfNMHDEGzYE+ Xzf1rSDM2p9Xu5MlW//0mbrBWcQW/ZMPpoZD1nDQwv91BwHRUGNYfQVhV8/chmVvH48y E5owZB1FNt7BysiBOGFw7uTpufGNubopjT+8non0qvh4sHX3Ogeh/aYe68Jl5mONGoT6 kw== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2umqbe848c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Aug 2019 21:58:23 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7QLwKue054805; Mon, 26 Aug 2019 21:58:22 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2umhu7xk8t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Aug 2019 21:58:22 +0000 Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x7QLvg83012811; Mon, 26 Aug 2019 21:57:46 GMT In-Reply-To: <87k1az8vk5.fsf@red-bean.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4873.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9361 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908260204 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9361 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908260203 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.85 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:239595 Archived-At: > >> the use cases: when the goal character is a letter > >> at all, one is either looking at that letter > >> on the screen *or* the letter is some known > >> syntactic delimiter and its case is therefore > >> known as well even if the letter is off the screen > >> right now.) > > ... > > There's no reason to have this command make an > > assumption about whether its char-search should be > > case-sensitive. I don't think the either...or > > assumption you made above is good for the command > > to make. Better to let users control whether to > > search for the char case-sensitively. >=20 > When I think about the circumstances under which this > command is actually used, which I tried to characterize > above, I couldn't think of any in which case-insensitive > matching would make sense > ... > Can you say which part of the assumptions I gave above > seems wrong to you? I guess my question is about the "circumstances under which this command is actually used". Why are those two cases obviously the only ones? =20 I don't see why a user would necessarily either (1) be looking at the target letter or (2) want to grab text up to the first case-sensitive occurrence of a letter. A user might well want to grab text up to the next occurrence of the letter `Q', regardless of letter case, no? That could be the case, for example, if the text in the buffer is generally indifferent wrt case. And in such a situation I'd generally expect that `case-fold-search' _would_ be an appropriate guide for both (1) this grab-up-to search and (2) the search afterward with the updated search string. Perhaps I'm wrong, and I really have no axe to grind (don't care) about this. I just haven't (so far) seen why the only reasonable scenarios are the two you assume. Can you give an example where you think case insensitivity would be inappropriate for this, but it would be appropriate for the search with the updated search string? (Not that I'm arguing for case-insensitivity here. I just wonder why case-sensitivity is always TRT.)