From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: noverlay branch Date: Mon, 10 Oct 2022 09:26:14 -0700 Message-ID: <87k0574pcp.fsf@rfc20.org> References: <87sfjzefvv.fsf@rfc20.org> <875ygt6gbj.fsf@rfc20.org> <87pmf04c7s.fsf@rfc20.org> <83ilksi4ca.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17575"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 10 18:31:47 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 1ohvgw-0004O5-ST for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 18:31:47 +0200 Original-Received: from localhost ([::1]:53006 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohvgv-0001Mg-DW for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 12:31:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohvbo-0004qW-FL for emacs-devel@gnu.org; Mon, 10 Oct 2022 12:26:28 -0400 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:42919) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohvbl-0000xk-PZ; Mon, 10 Oct 2022 12:26:27 -0400 Original-Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id EE7BDFF806; Mon, 10 Oct 2022 16:26:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1665419180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=reLJl1WqOSiB+jR65B8KHfw1Rj5sqHawveL48iv6lTU=; b=EQQsPf993fOGucNwap9z+L+GP/iiV5fCs9wCr1XYOI/KYXk0LjAxtzHIFzNFhSDomT5RoJ 3MJlmJ/gIy/TCtYYyq4UUEA4k0iuYIdhnSJPqqvMeppyxIlye12IZTz6i3p1IOQUY6/R+U 90pIz8DPQ+q4QFDgvccmuyQ2MaRFYW11TUrHtvCOc2GUr2PFzX9mVZt/PICgb1njtdRLQ3 3QPQKx4IxA4/pi2pSSUAO1DyQer7/LSzeaFuZLaabYmpaK7G8TRr87FHQEen49ExTKjztl oFsSu8h2ZqquHc5REb74HQUjomiERK3fB6ei9TfQfdJHFGE08MuuAOYhQl7j8w== Original-Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1ohvba-0083Vk-2J; Mon, 10 Oct 2022 09:26:14 -0700 In-Reply-To: <83ilksi4ca.fsf@gnu.org> Received-SPF: pass client-ip=217.70.183.199; envelope-from=matt@rfc20.org; helo=relay9-d.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:297383 Archived-At: Eli Zaretskii writes: > Unless the checks are _very_ expensive, I'd prefer not to introduce > yet another "enable-checking" knob, and instead condition those just > by ENABLE_CHECKING. Ok, withdrawn. I haven't experienced extreme slowness myself. The problem is theoretical at this point. Because the checks validate the entire overlay tree before and after primitive operations (insert, erase, etc.) they do have the potential to be worse than the old overlay implementation running with checks on (exponential performance, etc.). I left the --enable_checking=overlays diffs here sould we want them later: https://git.sr.ht/~matta/emacs/log/my/shelve/enable-checking-overlays > Please also consider whether we need some checks to be invoked > manually, e.g. when something goes wrong in a session that might be > related to overlays. E.g., a command that dumps the overlay tree(s) > to stderr could be perhaps useful in such cases. I believe there is code for a new lisp function that returns a representation of the tree. I have never used it, and I'm not sure if it is enabled.