From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Thu, 23 Jun 2022 18:08:53 -0400 Message-ID: References: <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87bkur72b7.fsf@gnus.org> <874k0j40e7.fsf@gnus.org> <871qvm16he.fsf@gnus.org> <83a6aanm5j.fsf@gnu.org> <87o7yozzj0.fsf@gnus.org> <83k098kg6c.fsf@gnu.org> <8335fvg8kz.fsf@gnu.org> <83y1xncjkj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29204"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Stefan Monnier , Ihor Radchenko , =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= , Tim Cross , rms@gnu.org, Alan Mackenzie , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 24 00:10:49 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 1o4V2H-0007Tc-0t for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Jun 2022 00:10:49 +0200 Original-Received: from localhost ([::1]:38916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4V2F-0001aU-Qq for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 18:10:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4V0g-0000Eu-6i for emacs-devel@gnu.org; Thu, 23 Jun 2022 18:09:10 -0400 Original-Received: from mail-oa1-x2d.google.com ([2001:4860:4864:20::2d]:46958) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4V0e-0003nN-Gq; Thu, 23 Jun 2022 18:09:09 -0400 Original-Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-1013ecaf7e0so1236070fac.13; Thu, 23 Jun 2022 15:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HLu5LDODEivkKcFjv3cnl2Ko10lPQjmPieUxkhhMxCo=; b=BK1PDxuZ3Z56zZTL0GCaTlhYqnysut2ChropTqfd9jNK3wkoolEOZ5tH5hsKO7W7Mx A9HDjOj9+qpF444TVO2Ok+E38gB2a0ZXGbWy1YJhMn7m/LhoPe0g4FAimCXqnqqzRFtI ElrYcd4m1z3QN3buZMYwXl4tgLg1MZVXNUb8wtvPmw0NhDyGw1iae7kX/lxDL872mDZR kaSYn13+V6jpyimYR5wN1IBD6yuGxjWpVmXEgSMnwyUn1ofnsFFLzLR1VPPsK4AgIPoY CZE7TuUhP0xsXT9oC6QBNiSNkwjVmMk6nipWnL4hyrOxH3UWk5jFm+Cyd2XHsx70VcI8 uHeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HLu5LDODEivkKcFjv3cnl2Ko10lPQjmPieUxkhhMxCo=; b=bWznTNgq2hfVadCYN9BIgjhyM2ngN3ho/cHu0PY9JBlPdTJ7nKxk9yJ71aw11DNLFn 0Z4adZpHH7SmmCtGAqWzI3SGO82wVm2X/lshVlQVCFm9sLBXBhdYSncuFF3T3v0jvp78 +Ly1k9t6kdtgeNTyPSfkKmXfH0qOs1ArAXPoAcAZNFPRGUWsvmEWY+F4Im9i9ifDgt17 xk3gGlSNZNH0QYT351RKDocdHDX5QDz2pjZxJdNZW6I7nwGX+0izVmwTDWlgyLNKLH2/ BeGtQZyTofmrdzTw7075RnIQbqex76asBQXT1JPeo7vohbQU+IfPQPq0My3IeVnw+6PV iUwA== X-Gm-Message-State: AJIora9EzvA9hQljPuMJSgmUKhpCD2tOrHhny0ntQ1/G2PE+Ifxhpfdv FvBjHVLRJjl/81HlMfKvfhhjJdkH/1xQMsXC2ZZxp2Ofc/5Z9A== X-Google-Smtp-Source: AGRyM1sstsUmzZ8o1ecGDqeA8Td9pCQEcaAtSo7YTuh/q7Qr2uxXlNRvkM6GvV/23W/B7N+TNoD+YsvGCRkZyyf1CqY= X-Received: by 2002:a05:6870:d791:b0:101:ad64:1e74 with SMTP id bd17-20020a056870d79100b00101ad641e74mr93278oab.162.1656022145782; Thu, 23 Jun 2022 15:09:05 -0700 (PDT) In-Reply-To: <83y1xncjkj.fsf@gnu.org> Received-SPF: pass client-ip=2001:4860:4864:20::2d; envelope-from=owinebar@gmail.com; helo=mail-oa1-x2d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=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=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:291544 Archived-At: On Thu, Jun 23, 2022 at 2:37 PM Eli Zaretskii wrote: > > What you describe is a full-time job, more or less. I'd love to have > someone who'd volunteer to record all those points, but we don't have > him/her yet. > > The only places where design is document are the large comments in > some source files. > > > It would help if there were some taxonomy of features/design > > points for > > reference. Is the bug database being used for that? > > I don't think so (IIUC what you mean by that), and I don't really see > how bugs could serve in that role. I agree, but some of the bug reports are classified as something along the lines of "feature request" or "wishlist". I haven't found any other database tracking anything corresponding to features, proposed or otherwise. In more formal environments, feature implementation would be preceded by some kind of ticket describing the problem to be solved or functionality to be implemented. I don't expect any strictly enforced workflow in this kind of project, but that kind of referent is still useful for the same reasons having an entry in a bug database to reference is useful. A crude taxonomy wouldn't be that hard to come up with, then elaborated with finer points: Value Representation ELisp Abstract Machine Memory Management Intermediate Representations Core Lisp Lisp Assembly LIMPLE Compiler Transformations Serialized Lisp Program Formats ELC ELN PDMP etc Some of these points are already documented in the Elisp manual, of course, and some in the code comments, and others in the emacs-devel archives. Once something is in place, no matter how bare-bones, the key would be maintainers mandating that any substantive introduction or revision of features be tied to appropriate entries for the corresponding design/spec documentation, in the same way and for the same reason coding standards are enforced. That's assuming the maintainers consider such documentation important enough for enabling future potential contributors and maintainers to hold otherwise useful contributions in limbo. And probably that doing so is convenient to do. > Most of the design changes and > redesigns in Emacs were developed without any bug report, simply > because those who did the job knew that a particular group of problems > needs to be taken care of. It's not like there isn't any discussion or justification of features offered prior to code being integrated into the main branch. It's more a challenge of how to weave what's there into a coherent account of what's going on in the code. It would just be easier to automate some sort of design note extraction from the git log if references to mails could be associated with relevant features. I've never used org, but maybe there's some syntax that would be useful? Or maybe some notation from supercite for precise pulling of relevant text from list archives? I feel like if I were a more savvy Emacs user, I would know all of this functionality is already implemented in some combination of CEDET-originated tools, one or more tagging systems, the various interfaces for using the tagging systems, org, etc. > > > Actually, a good example (even though it's more post facto description than > > prospective > > design & cost-benefit tradeoff analysis) would be > > https://github.com/rocky/elisp-bytecode > > That is really useful documentation that would ideally be in the emacs docs > > or etc directory. > > That's not design description, though. You probably have a more nuanced view than me on this. It's true, that document is focused on the specification (the "what") rather than the (detailed) "how" and "why" - is that what you mean? Either way, if you want to understand how the operational semantics of emacs lisp work in practice, a document of that sort is invaluable. Without that, a document explaining the "why" isn't going to be able to be very concrete.