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 07:50:32 -0700 (PDT) Message-ID: <77205e15-f38a-46dc-9451-4030a318900a@default> 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> 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="167659"; mail-complaints-to="usenet@blaine.gmane.org" To: Karl Fogel , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 26 16:59:16 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 1i2GSg-000hJ7-3E for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 16:59:14 +0200 Original-Received: from localhost ([::1]:54424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2GSe-0003qc-TE for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 10:59:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48975) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2GKN-0005G2-O9 for emacs-devel@gnu.org; Mon, 26 Aug 2019 10:50:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2GKL-0003lU-Ml for emacs-devel@gnu.org; Mon, 26 Aug 2019 10:50:39 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:39572) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i2GKL-0003kh-Bq for emacs-devel@gnu.org; Mon, 26 Aug 2019 10:50:37 -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 x7QEniD4022289; Mon, 26 Aug 2019 14:50:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=ntIxmU/R0BPNwhNGa9KlEw8go1iR1Rdb6Gc805g3VUs=; b=ZLyayQkwbOeTOxnPuNkTd8ey5rXipTTMI/01Ji71t5X0fEo5Iz8gmtP4XayCjaXXu8IF n3iVjjOk6+LWZcf8k5WqJqmTJqkK57SUF/2svmWBCraiBoKKpCp7RY+LvTThKqge8icd ufZx1SUwQhvEbcEfrhwbV1tP6CZlPPGlSrZycGTuAwMuakpk/hRc3bqRnPCH3K9WHHHe Jix9tCC7+i0rutRb5LY8K6HKbgsma22zUbPJpGcaeZNWVYKTsiBZEOmsgogGD4jnR6fb 1QbaoS4WUhLiSng2vXDjEaRAYxY5jdYN1BzQCNzAQWAQmaVq2FlkYydmkTVxL3opxk60 ZA== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2ujwvq9nr9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Aug 2019 14:50:35 +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 x7QEmtvE098884; Mon, 26 Aug 2019 14:50:34 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2ujw6uy6pj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Aug 2019 14:50:34 +0000 Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x7QEoX18031145; Mon, 26 Aug 2019 14:50:33 GMT In-Reply-To: <871rx87b9h.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-1908260157 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-1908260157 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:239576 Archived-At: > Remember that you started out that new thread > (on August 14th) with these words: >=20 > > This is similar to what Karl submitted today. > > Not a replacement for that; something different. That was only the intro sentence. Yes, the general idea is something different, additional. Which is why I created a new thread. But the message also directly relates to your command, which was the starting point. A few sentences later I said this: I think Karl's `isearch-yank-until-char' should also be made to support backward search. And the patch modifies your command to do that. And the message argues for a different key for your command (after my earlier message where I said that `C-M-c' was OK by me). The intro sentence could perhaps have made clear that it enhances your command, but that it's not limited to doing that. The more important message is that it provides something new that applies generally. > Since your followups were all in that thread, > I assumed they were about something that was > "not a replacement" for what I'd posted, and > therefore wouldn't affect the question of > whether what I posted should be installed. > (I rely pretty heavily on thread discipline, > not just in Emacs Devel but generally.) Fair enough. But my message really does relate to your command and patch. That's not the main message, but it's closely related to that message. > > Commands like `isearch-yank-until-char', which > > yank consecutive buffer text at the search > > point, are better if they can also work with > > backward search. My patch implements that for > > this command and others. >=20 > It sounds like your patch does two conceptually > distinct things: >=20 > 1) Implement one or more new commands [which work with backward search]. > 2) Make a bunch of isearch commands work > with backward search. Yes, if you want to look at it that way. But switch the order, and then see if you still see them as so different/separate. It lets yank commands work properly with backward search. And so it fixes the relevant yank commands to do that. There are only a few yank commands that are relevant (not really "a bunch"). My message also categorizes Isearch yank commands, saying that the relevant ones here are those that yank buffer text at the search hit. That is, it makes clear that this doesn't apply to ad hoc yanks, such as yanking from the kill-ring. > If I were to install my patch (as it's currently > written, though maybe with the keybinding changed), > that doesn't really affect any of your new code. Correct, with the exception of the key binding. But my patch subsumes your patch (except that it doesn't address the manuals or News). It seemed appropriate to fix your command at the same time as the others, especially since it was still being discussed. > However, I would still say your patch should be > divided into two conceptually distinct patches, > one for (1) and one for (2). This is not a > judgement about the technical merits or the UX > merits of your patch. I'm just saying that we > should do one thing at a time. I could do that. But they're not so separate. I added the Boolean option because Juri requested it for the existing commands, to not change their default behavior. (I don't think such an option is needed, but I respected that request.) I could also split the patch into 3, splitting off the command-defining macro and the two commands it defines. Or I could split it into 4. Different approaches are possible. I thought (and think) it makes more sense to present all of those changes together with a general explanation of the feature - they all go together. If someone wants to understand the behavior and rationale, it makes sense to have code that demonstrates it. But if you want to try the patch and ignore the changes to existing commands, that's possible, just by setting the option value to nil. Or if you want to try it and ignore the new commands, you can do that too. If you consider them "conceptually distinct" then just use the option to separate them. And if it really helps to split the patch, I can do that. > >And I argued that `C-M-c' would be better used in > >Isearch for my command `isearch-yank-through-move', > >which initiates a recursive edit to allow arbitrary > >cursor movement. In that case, `C-M-c' both starts > >and ends such movement (since globally it is > >`exit-recursive-edit'). >=20 > *nod* That's a separate question from the above. > I don't think it's very important that C-M-c be the > binding for `isearch-yank-until-char'. If we want > to save C-M-c for this other potential use, that > seems reasonable to me. Good to hear. > Your patch suggested "C-M-." for > 'isearch-yank-until-char', which seems good. > Another possibility, to keep the "c" for "char" > mnemonic, is to use M-c. I'm open on the key for `isearch-yank-until-char', except that I think it makes sense to save `C-M-c' in case we have a command that involves using that to end recursive editing. There are keys available. The usual problem with Isearch is that people will argue, with reason, that they like to use such-and-such a key to exit Isearch and act on the buffer text. As you say, in Isearch `M-c' is currently for toggling case. If it were not, I could imagine someone saying that s?he wants to continue using `M-c' as `capitalize-word', to end search and capitalize the word at the destination. Incidentally, this is why, in `isearch+.el', I put all Isearch yank commands on a prefix key, `C-y'. (I have more Isearch yank commands.) Some, like `isearchp-yank-sexp-symbol-or-char', are also on other keys. for ease of use - e.g. `C-(' as well as `C-y C-('. > Right now that key seems to toggle > case-sensitivity, but I'm not sure > that's deliberate -- according to the > `isearch-forward' documentation, "M-s c" is > for that, while "M-c" isn't documented at all. > Given that the current action of M-c isn't > documented, and given that another keybinding > both does that action and is documented to do > so, using "M-c" for `isearch-yank-until-char' > might be okay. I'm all for that kind of discussion - finding a good fit. > The code above suggests that it is not > important for M-c to remain redundantly bound > to `isearch-toggle-case-fold', but I could be > wrong. If anyone knows more, please say. If > we can't figure out the answer, I guess I'd say > let's go with "C-M-.", out of general conservatism. I like the fact that you provide reasons, and you discuss openly and with details. I suggest that we run a discussion about possible key bindings for this command and others in parallel with the overall discussion that's begun about Isearch yank commands. As opposed, e.g., to trying to first decide about a key for `isearch-yank-until-char'. Let's work out the commands first - including consideration of my proposed commands, and then figure out what keys to use. Just a suggestion. And given that we're discussing adding to the set of yank commands, maybe we want to consider putting them all on some prefix key. That would certainly give us more options.