From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: locked narrowing in ELisp Date: Wed, 17 Aug 2022 16:40:01 +0300 Message-ID: <8816ba91-3c71-c04b-32fd-122047795421@yandex.ru> References: <2d4a8d8f-d17d-6f84-cd45-586db2f9728c@yandex.ru> <79484704-f981-5c12-e000-333b75499520@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34628"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 17 15:41:43 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oOJIl-0008nc-An for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 15:41:43 +0200 Original-Received: from localhost ([::1]:42348 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOJIk-00051x-0N for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 09:41:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOJHM-0003zx-S4 for emacs-devel@gnu.org; Wed, 17 Aug 2022 09:40:17 -0400 Original-Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:33546) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oOJHK-0003yk-QB for emacs-devel@gnu.org; Wed, 17 Aug 2022 09:40:16 -0400 Original-Received: by mail-wm1-x335.google.com with SMTP id m3-20020a05600c3b0300b003a5e0557150so1865466wms.0 for ; Wed, 17 Aug 2022 06:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc; bh=HzRISYBtGaa5jFZcYbOUPvxB4O+wIQgG0KblwNJlAvk=; b=W6j61Wvfg9YYoQSL457IdhDRJRHZcBCP0EqCqdCI7GjmS9urYEo7ETZy2ob7IHa3Un k9OJjTbOqaYCct5905KJRr99+xEuZWD9iOxtJ2wo+Ux8eV74DiwWglk3Jm43PxYUy6Kv SeSYGHwmCBTdMCPRLZK3mgQJJfPI45U9PoRN1+wkU8zB5rRx+IvUARnuh9WllvE0WAXw CXWEnfFUWgCyLaVr8I14wd1da+NNwKT8sugBum3kden4QAWPoR/n3fNZd1BcgWqgBJlq EqbWSLaya+NplANS1OGP4ZsH7zbeTMsUO0j4JQaFkMSQ6r2p8RDsExBYh93T6CqzD1P9 T1NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc; bh=HzRISYBtGaa5jFZcYbOUPvxB4O+wIQgG0KblwNJlAvk=; b=0hTgfYgQ1cj78GC0ZpoPpwZxd3CPYqGKQVTOSQVsjBhUPT440Pq1LC8GlEfQa+xpNE PiFiw1xzPRQ8MbXRvNr6C/kEf1yARJ7JNxKZFYQUszRxxM3wahICewVlyuoEDGa0bAfo sKOoc03zZbB+r96OsKE1mB+RMmWnGUrlR3mzKAHS5P94CgC1Pua2eMZMPYVZekLERJnz kInBnb8QTYSsKbjVZO+g7WqWHVaT+0B5ceDtRTIFHDh3/53J/9/qo9ZFa3k9WI/399/y 2rohBtgGuznK2YnUdQHBhMzuKW9X2sZFu9/nSPhpTJtFk85fi99Z0gdhryN/i0J7wExb MPAg== X-Gm-Message-State: ACgBeo2PqWkiJ/kjZ6GxbUZbAo0bmHRXXy0DA1aQx1dfsGre/hh0I6wx EUujrLRz8IfbpnTsYdZAsak= X-Google-Smtp-Source: AA6agR6x/SDWPGf0Yc2+yO/POtS4TwgYLcIdx+kS0JYOgeP+3KKviKLzoPpRfBX7i+5cWqpA8sm1jg== X-Received: by 2002:a7b:cb0a:0:b0:3a4:eafc:367d with SMTP id u10-20020a7bcb0a000000b003a4eafc367dmr2299155wmj.0.1660743603258; Wed, 17 Aug 2022 06:40:03 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c188-20020a1c35c5000000b003a5f4fccd4asm2313742wma.35.2022.08.17.06.40.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Aug 2022 06:40:02 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=raaahh@gmail.com; helo=mail-wm1-x335.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293557 Archived-At: On 17.08.2022 16:03, Stefan Monnier wrote: >>> Such a display-only narrowing might be a good alternative for many uses >>> of narrowing, but narrowing is also used quite commonly (either by the >>> end-user or in ELisp code) in order to restrict the effect of an >>> operation (like search&replace) to a particular region. >> >> Certain operations could look up the "soft narrowing" bounds and act >> accordingly, if it's implemented in the core and appropriately documented. > > Could be, but unless we go through the whole C code looking for checks > of BEGV/ZV and updating the code to also check the "soft bounds" this > won't work reliably enough to replace existing uses of narrowing. The point is to avoid doing that. If we can. For instance, use two overlays in the current buffer with `invisible' property rather than have the display engine refer to the new kind of narrowing bounds. >> To my understanding, there are more commands and facilities that want to >> ignore user-level narrowing, rather than the ones that want to obey it. Also >> a lot of "undecided" ones, waiting for someone to report that they should, >> in fact, ignore narrowing. > > But for backward compatibility reasons, we can't break the cases that > need the bounds to be hard, even if it could fix some cases. The "regular" narrowing will play the role of the hard one because there will be little need to protect against 'widen' calls all around. I agree the migration path is non-obvious, though.