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: Writing manuals Date: Sat, 04 Sep 2021 18:54:02 +0300 Message-ID: <83zgssuyjp.fsf@gnu.org> References: <83lf4x1kme.fsf@gnu.org> <83k0kh1j84.fsf@gnu.org> <83tuj0x09l.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="33145"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 04 17:54:38 2021 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 1mMY04-0008OH-Lg for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 17:54:36 +0200 Original-Received: from localhost ([::1]:60064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMY03-0005R6-IO for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 11:54:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMXzW-0004m8-03 for emacs-devel@gnu.org; Sat, 04 Sep 2021 11:54:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35514) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMXzV-00065J-OY; Sat, 04 Sep 2021 11:54:01 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3594 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 1mMXzU-0003Xk-6K; Sat, 04 Sep 2021 11:54:01 -0400 In-Reply-To: (message from Yuan Fu on Sat, 4 Sep 2021 08:48:36 -0700) 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:273912 Archived-At: > From: Yuan Fu > Date: Sat, 4 Sep 2021 08:48:36 -0700 > Cc: emacs-devel@gnu.org > > >> And, IIUC nodes are uniquely named in a manual, I think maybe it’s not a good idea to use generic node names like “Language Definition”, “Pattern Matching”, etc > > > > Why not? Once again, if we ever support other similar libraries, we > > should strive to have similar facilities described in the same nodes, > > not in separate nodes. > > Not general in that sense, but in the sense that some other Emacs feature unrelated to parsing could need that name. For example, pcase is a kind of “Pattern Matching”, an input method could have a “Language Definition”. I wouldn't worry about that, at least not now. "Pattern", "matching", "language", etc. are terms that are overloaded many times, and if we'd worry about this, we'd be unable to come up with useful node names. But you could say "Pattern Matching with Nodes" and "Programming Language Definitions" instead, if you think that's better.