From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality Date: Thu, 24 Mar 2016 09:24:03 -0700 (PDT) Message-ID: <27fb184f-5bd3-41c7-b9a5-3f6c55cb480c@default> References: <<<20160322022539.16038.77264@vcs.savannah.gnu.org>> <> <> <<8737riqouj.fsf@gmail.com>> <<221845e0-b194-433e-bfbc-105272ae5752@default>> <<87twjyp21k.fsf@gmail.com>> <> <<56F242E0.7060004@online.de>>> <<<877fgtpfrw.fsf@gmail.com>> <<56F293E7.2000703@online.de>>> <<<87a8lpnusg.fsf@gmail.com>> <<83r3f12oo5.fsf@gnu.org>>> <<<56F2D156.9040401@online.de>> <<83k2kt2i51.fsf@gnu.org>>> <<<56F2E643.4060903@online.de>> <<592bbafa-76ae-49d9-b5cd-644b3619a0d8@default>> <<838u1835si.fsf@gnu.org>> <9307373f-0ecd-4825-8b9c-20280b9c92c0@default>> <<83zitn26t0.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458836700 14792 80.91.229.3 (24 Mar 2016 16:25:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Mar 2016 16:25:00 +0000 (UTC) Cc: spinuvit@gmail.com, andreas.roehler@online.de, emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 24 17:24:48 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aj83x-0006BD-D4 for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 17:24:45 +0100 Original-Received: from localhost ([::1]:51724 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj83w-0001ek-3B for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 12:24:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj83V-0001b1-4D for emacs-devel@gnu.org; Thu, 24 Mar 2016 12:24:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj83T-0005sg-VE for emacs-devel@gnu.org; Thu, 24 Mar 2016 12:24:17 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:38104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj83O-0005rP-7i; Thu, 24 Mar 2016 12:24:10 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2OGO5vF027136 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 16:24:06 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2OGO5Ek032601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 16:24:05 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2OGO4BL016709; Thu, 24 Mar 2016 16:24:05 GMT In-Reply-To: <<83zitn26t0.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202185 Archived-At: > > > > And the text about indentation and the use of sub-mode for only a > given > > > > chunk of text in a buffer is incomprehensible without some > explanation. > > > > Normally, a major mode, no matter whether it is derived from some > other > > > > major mode, has its effect on the entire buffer. > > > > > > > > It seems there is some non-negligible functionality/behavior/featur= e > > > > that has not been documented. Not up to Emacs standards, it appear= s. > > > > > > > > It looks like someone perhaps implemented something and just tossed > > > > some minimal doc into the manual, in the form of doc-string-like te= xt > > > > for a couple functions. Insufficient. > > > > > > "Compliments" such as these for something that caused me a > > > considerable effort to produce where no documentation by the code > > > developers existed in the first place is a very efficient method of > > > convincing me never to make such efforts again. Not for this > > > community, anyway. Thanks a lot! > > > > Please consider it instead as a statement that "the code > > developers" for this feature (whatever it might be) should > > themselves have documented it. Which is also what I think > > you suggest. > > > > My plaint wrt what the user sees now (incomplete doc) is > > essentially the same as your plaint that the code developers > > did not provide adequate doc. I don't at all complain about > > your effort to improve a complete lack by providing something > > helpful. >=20 > The documentation is complete. I have just re-read it to be sure, and > I see no flaws there. If you still think there are gaps, and if the > current text is unclear to you, that's a clear sign that the use cases > in which these features are supposed to be used are something you > never bumped into, and therefore you don't have a clear picture of the > issues. Which is not a catastrophe, but it does mean that you are not > the best person to criticize this part of the documentation. >=20 > > As a user learning about this question for the first time, I > > searched the manuals for "sub-mode" and similar expressions > > to learn more, and came up empty-handed. I reported that. >=20 > It is clear to anyone who understand the situations which need these > features. Examples of such situations are part of the text in the > manual. The fact is that this discussion thread references "sub-mode" > or "submode" several times, and people who used that terminology > evidently have to difficulty understanding what it is. ^^ no (?) Excuse me, but that's a crock. You are essentially saying that it is OK to refer to a "florksit" over and over, with no explanation of what such a critter is, as long as some developers who implemented the code that uses and provides for florsits understand what it is. This is the Elisp manual - for all users of Elisp. Imagine if we did that for other concepts: keymap, syntax table, or whatever. Instead, we introduce the concept with some care, so that readers of doc about functions that make use of keymaps etc. know what that doc is talking about. As I said earlier, one might guess that a "sub-mode" is a mode that derives from another mode. OK. But one will not guess what that might mean for zones of text in one or another sub-mode, what it might mean for indentation there, or whether sub-modes can nest or otherwise overlap. And so on. None of this is clear to a reader of this doc, and it should be, IMO. What's a "sub-mode" in this context? Answer that clearly in the doc and Bob will be our uncle.