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 07:41:50 -0700 (PDT) Message-ID: <9307373f-0ecd-4825-8b9c-20280b9c92c0@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>> 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 1458830552 5974 80.91.229.3 (24 Mar 2016 14:42:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Mar 2016 14:42:32 +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 15:42:19 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 1aj6So-00016i-CH for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 15:42:18 +0100 Original-Received: from localhost ([::1]:50746 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6Sm-0007bl-Ug for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 10:42:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6Se-0007ao-6i for emacs-devel@gnu.org; Thu, 24 Mar 2016 10:42:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj6Sa-00022f-15 for emacs-devel@gnu.org; Thu, 24 Mar 2016 10:42:08 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:50510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6ST-00021t-Fw; Thu, 24 Mar 2016 10:41:57 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2OEfqw0029720 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Mar 2016 14:41:53 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2OEfqO5010382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 14:41:52 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2OEfpG2006459; Thu, 24 Mar 2016 14:41:52 GMT In-Reply-To: <<838u1835si.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: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:202176 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/feature > > that has not been documented. Not up to Emacs standards, it appears. > > > > It looks like someone perhaps implemented something and just tossed > > some minimal doc into the manual, in the form of doc-string-like text > > for a couple functions. Insufficient. >=20 > "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. You improved things by adding some explanation. I made a (minor) effort to improve things after that, by saying that, IMO, the doc is still not sufficient. My guess is that those responsible for adding this feature are the best placed to provide the technical content (if not necessarily the wording) for telling users what it is. I don't know what that content is - dunno what the feature is. 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. Perhaps you too have only a partial feel for this feature. I have no gripe whatsoever with what you've done to help us understand this, Eli. Quite the contrary. Had you not documented this at all, I would not have noticed it and would not have posed questions about it. You need not be defensive about my saying the doc is incomplete here. You can be proud that you tried to make it more complete. Thank you for that. In fact, I thank Emacs everyday for your unflagging concern about the doc and your efforts to maintain and improve it. This concern with doc is an Emacs tradition that dates from Day One and for which RMS was always a prominent advocate and participant. Today, you remain the main stalwart in this endeavor. Thank goodness you are still at it.