From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#24104: 25.1.50; frame-or-buffer-changed-p also check file size Date: Fri, 29 Jul 2016 07:57:59 -0700 (PDT) Message-ID: <950031e8-3e82-4cd3-9b39-37e8e4359051@default> References: <> <<83fuqsr36k.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 1469804371 13356 80.91.229.3 (29 Jul 2016 14:59:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2016 14:59:31 +0000 (UTC) Cc: 24104@debbugs.gnu.org To: Eli Zaretskii , Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 29 16:59:18 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1bT9Ft-0001WM-D9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jul 2016 16:59:17 +0200 Original-Received: from localhost ([::1]:59991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bT9Fn-00048w-HS for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jul 2016 10:59:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bT9Fh-00048o-FU for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2016 10:59:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bT9Fe-0002E0-8R for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2016 10:59:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bT9Fe-0002Dw-58 for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2016 10:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bT9Fd-0004nm-Su for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2016 10:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Jul 2016 14:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24104 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24104-submit@debbugs.gnu.org id=B24104.146980429618406 (code B ref 24104); Fri, 29 Jul 2016 14:59:01 +0000 Original-Received: (at 24104) by debbugs.gnu.org; 29 Jul 2016 14:58:16 +0000 Original-Received: from localhost ([127.0.0.1]:50862 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bT9Et-0004mo-QB for submit@debbugs.gnu.org; Fri, 29 Jul 2016 10:58:16 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:25126) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bT9Er-0004ma-TV for 24104@debbugs.gnu.org; Fri, 29 Jul 2016 10:58:14 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6TEw4Pt002478 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2016 14:58:05 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u6TEw474013285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2016 14:58:04 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6TEw000024814; Fri, 29 Jul 2016 14:58:01 GMT In-Reply-To: <<83fuqsr36k.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: aserv0022.oracle.com [141.146.126.234] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:121685 Archived-At: > > Assume a buffer BUF, with size, SIZE, returning non-nil for predicate > > 'buffer-modified-p'; then we write some text on BUF, so that the > > new size is SIZE_2 !=3D SIZE. > > In this scenario, 'frame-or-buffer-changed-p' return nil, i.e., > > the buffer state appears to not have changed. >=20 > Because it didn't. The buffer was changed, and it still is. In > particular, the original change that caused buffer-modified-p to > return non-nil could also be (and normally is) a change in the size of > the buffer. If the meaning of `frame-or-buffer-changed-p' in this scenario is, as you suggest, intended to reflect whether or not `buffer-modified-p' has changed (and not whether the buffer has changed), then its doc should say so. Whether `buffer-modified-p' has changed is something different from whether the buffer state has changed. If `buffer-modified-p' is already non-nil then additional changes to the buffer will not cause a change in `buffer-modified-p', as Tino's example illustrates. The name `frame-or-buffer-changed-p', and its current doc, suggest that it should return non-nil if the buffer appears to have changed. The buffer has changed in this case, even if the value of `buffer-modified-p' has not changed (it is still non-nil). But apparently the buffer does not "appear" to have changed. That's OK, but what's involved in this appearing is unclear. Something should be said in the doc about what kinds of changes lead to a change "appearing" to have occurred (or what kinds do not lead to that). IOW, the doc should say something about how the "appearance" of change is judged/detected. If read-only and modified flags determine this (alone), then the doc should say so. Something should be said about just what is meant by (included in) a buffer state change and a frame state change. If all that is meant, for buffer change, is what is said (later) in the doc for VARIABLE, i.e., all that is checked are the (1) read-only and (2) modified flags, then just say that up front, and not only for VARIABLE. That, I think, would make most of the above clear. Except for frame state change - that part is still completely unspecified, AFAICT. Just what is meant by (included in) the frame state, and how is a change in frame state detected/recorded by Emacs ("appear" to have occurred). For buffer changes: read-only and modified flags - OK. What about for frame-state changes? Finally, the doc should not talk about some "internal vector" BEFORE that has been introduced. Assuming that the "an internal variable" of the last paragraph is what holds "the internal vector", it needs to be introduced before we talk about "the internal vector". And the fact that the value of the internal variable is "the internal vector" should be made explicit. The last sentence of the doc is confusing/scary. If a user can call the function without passing an argument, is that different from calling it and passing a nil argument? If the behavior is different then this is REALLY an exception - I've never heard of such a thing. What is this all about? I'm guessing that that last sentence should just be removed. On the other hand, if the first part of the doc is to be believed, VARIABLE, if present, must be a symbol that is a variable - which excludes the symbol `nil'. In that case it's still not clear to me how the absence of VARIABLE is distinguished from the presence of nil as an argument. Perhaps that is done at the C level and this is a real exception to the rule of &optional arguments. If so, that needs to be spelled out clearly. If this is really about passing a symbol, and not its value (see below), then, again, there is no need for the confusing last doc sentence. And in that case if a user _does_ pass nil as the argument then is an error raised saying that nil is a constant and not a variable? (And again, how is this case distinguished from an absence of VARIABLE?) The doc seems to be essentially backward, and it doesn't make explicit the connections that I think the author intended. It should say (IIUC, but I probably do not) that the state of frames and buffers - or of frame and buffer changes (?) is kept in a vector that is the value of an internal variable, and which for buffers records the read-only and modified flags (only), and which for frames records [???]. The function returns non-nil if this recorded state indicates that a change has occurred. It should then say that you can provide a different such variable to use by passing it as optional argument VARIABLE. The doc says that VARIABLE "is a variable name whose value is ...". The value of a _name_ cannot be nil or a vector. Presumably what is meant is that VARIABLE is a variable (symbol) whose value is.... The value of the symbol's _name_ is a string (`symbol-name'). So you pass a symbol and not its value (nil or a vector), I guess. Why is that? In sum, this doc needs some work, I think, for it to help users more and not confuse them more. It confuses me, at least. You can't make good use of a function if you don't know what its intended behavior is. Of course you can try to discover that by trial and error ... but that's what we have doc for.