From: Eli Zaretskii <eliz@gnu.org>
To: Tino Calancha <tino.calancha@gmail.com>
Cc: 24104@debbugs.gnu.org
Subject: bug#24104: 25.1.50; frame-or-buffer-changed-p also check file size
Date: Fri, 29 Jul 2016 16:20:35 +0300 [thread overview]
Message-ID: <83fuqsr36k.fsf@gnu.org> (raw)
In-Reply-To: <alpine.DEB.2.20.1607292109340.27947@calancha-pc> (message from Tino Calancha on Fri, 29 Jul 2016 21:10:29 +0900 (JST))
> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Fri, 29 Jul 2016 21:10:29 +0900 (JST)
>
>
> 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 != SIZE.
> In this scenario, 'frame-or-buffer-changed-p' return nil, i.e.,
> the buffer state appears to not have changed.
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.
> It might be convenient to extend 'frame-or-buffer-changed-p' so that,
> it also check the buffer size.
This function is used to decide whether we need to recompute menus, so
your proposed change will cause extra recomputation of them. I'm not
sure we want that, as recomputing menus might be expensive.
> Then, for instance, Ibuffer operating
> on auto mode ('ibuffer-auto-mode') would update the listing.
If Ibuffer has some problem, I suggest to describe that problem and
try solving it for Ibuffer alone.
Thanks.
next prev parent reply other threads:[~2016-07-29 13:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-29 12:10 bug#24104: 25.1.50; frame-or-buffer-changed-p also check file size Tino Calancha
2016-07-29 13:20 ` Eli Zaretskii [this message]
2016-07-29 13:57 ` Tino Calancha
2020-08-12 1:59 ` Stefan Kangas
[not found] <<alpine.DEB.2.20.1607292109340.27947@calancha-pc>
[not found] ` <<83fuqsr36k.fsf@gnu.org>
2016-07-29 14:57 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83fuqsr36k.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=24104@debbugs.gnu.org \
--cc=tino.calancha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).