From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Fri, 24 Jun 2022 09:53:55 +0300 Message-ID: <83pmiyd01o.fsf@gnu.org> 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 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, yantar92@gmail.com, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 24 08:57:08 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 1o4dFb-0006jJ-Q1 for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Jun 2022 08:57:08 +0200 Original-Received: from localhost ([::1]:50416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4dFa-00025Y-HY for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Jun 2022 02:57:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4dCh-0000Xn-Ie for emacs-devel@gnu.org; Fri, 24 Jun 2022 02:54:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56466) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4dCg-0004uf-V2; Fri, 24 Jun 2022 02:54:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/DN01XWszsiS6745v6ngBPhaJTVBHtUkrnv20YAvBww=; b=bdWJG5ZVxgESe5V3qsNf 8znm0dcoh1dlTTXKkkrpE1jnPYko8k5ZhF47nP/AiGMZgmq9fUqJlhUOtx+OIByKHRM6TxjsbZjmP F2HJG+5fdUAeo6xnB8g9jD4fWizrPjh+H1o5dFbfz+pH6gpyAHUbNDLKbiF1LFa3mPIVKvt3sfCq2 LAOfbjkarztBqZNfESoDRnD1G+h96ZyEDE8PMgYpVR/d1L9IB+BiFsxqDQPRUGtB+4yLf24GSRgR2 qURVmpkNVzf7rRgxaejRx/DQPXP2KF0hzZCRo44irc3TH8dxaACiI7R7E7JE7T9UNcDxCz4mQ88vg nZiNuti1rApKFg==; Original-Received: from [87.69.77.57] (port=2568 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4dCd-0003jL-E3; Fri, 24 Jun 2022 02:54:03 -0400 In-Reply-To: (message from Lynn Winebarger on Thu, 23 Jun 2022 18:08:53 -0400) 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:291553 Archived-At: > From: Lynn Winebarger > Date: Thu, 23 Jun 2022 18:08:53 -0400 > Cc: Lars Ingebrigtsen , Stefan Monnier , > Ihor Radchenko , Mattias Engdegård , > Tim Cross , rms@gnu.org, Alan Mackenzie , > emacs-devel > > On Thu, Jun 23, 2022 at 2:37 PM Eli Zaretskii wrote: > > > > > > 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". If you look at those, you will see that almost all of them request minor features that have no impact on the design whatsoever. It is very rare to have a feature request on the bug tracker that changes the design or introduces new designs. I would even dare to say it never happened, definitely not on my watch. > I haven't found any other database tracking anything corresponding > to features, proposed or otherwise. We do have etc/TODO. Did you look there? > 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. I think you are greatly underestimating the efforts required to maintain documentation of this kind, let alone the effort for creating it basically from scratch. Programmers usually don't like writing documentation, and most of them cannot write good documentation even if they did want, in large part because that take years of practice actually doing it. In a project like Emacs, it is nigh impossible to force contributors and developers do what they are reluctant to do in the first place. Without everyone updating the documentation as they change code, any documentation about design and internals will quickly become outdated, and thus not just useless, but downright harmful. We have trouble keeping even our user documentation up-to-date. Are you aware of _any_ Free Software project that has any useful documentation of this kind? Every project I ever knew or was involved with which tried ended up abandoning that. A case in point is GDB, which once had a "GDB Internals" manual -- it was always outdated, and was eventually scrapped because the maintainers decided they could not and didn't want to invest the effort. XEmacs tried in its time to have the internals documented, but that was basically a one-man effort, and even in it whole chapters were never written. Etc. etc. I think there's some conclusion waiting here. > 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 you think we don't? Of course we do! We also want to release Emacs much more frequently, and we want it to have no bugs, and a few other things. But somehow, each such goal cannot be reached for some boring practical reasons, none of them related to their importance in our eyes. We do in general consider it somewhat more important to develop Emacs and accept contributions than to document its internals, that's true. Which is why I said up-thread that without someone who'd volunteer to do this job (thus dedicating his/her time almost exclusively to it), this will probably never happen, given the current state of our resources, which are barely enough to maintain the status quo and move forward at some reasonable pace. > > 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. IME, you are wrong in that assumption. The significant changes in Emacs design are almost never publicly discussed, not in the way that would allow someone to glean the design from them. E.g., take the bidirectional display example. That one I'm intimately familiar with, so I can tell you with 100% confidence: the current design cannot be possibly gleaned from any discussions. Quite the contrary: the special emacs-bidi mailing list, created back there for such discussions, holds many ideas expressed by people, none of them actually relevant to what we have in Emacs today. At some point I realized that I should stop wasting my time on those discussions, and instead sit down and code this stuff, or the job will never be done. It is no coincidence that the discussions on emacs-bidi died right about the time I started implementing. I did document the main design points in bidi.c, but if you look for design decisions explained there, you won't find such explanations, only the description of the design's end point. And this example is somewhat exceptional, because the amount of documentation of the design and the implementation there is relatively large. In other areas the situation is more bleak. > 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 wish this were true. It isn't. The discussions and the commit log messages rarely describe the design, and in many cases barely describe even the particular implementation. In a project where people with write access can commit changes without any review, I don't know how can anything else to be expected. We basically rely on each individual to do the job perfectly and contribute to what you want to see documented. The results are before our eyes, and they shouldn't surprise anyone. > > > 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? Of course. > 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. I agree, but the "what" is usually already available in the comments to the code, though not everywhere and for every significant feature. The "why" and "how", by contrast are almost completely missing. To summarize: I'm not sure we should continue this discussion, because I don't see where is it going and what could it possibly change in practice. I agree with the value of having all of that documented, I'm just saying it's a large job that needs dedicated individuals, and I don't see how that could be replaced by any semi-automated means.