From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#30186: 27.0.50; Password is not hidden in read-passwd Date: Sat, 27 Jan 2018 11:37:13 +0000 Message-ID: <20180127113713.GB4049@ACM> References: <87y3kp8thj.fsf@mail.linkov.net> <87372w8ddp.fsf@mail.linkov.net> <20180125173937.GA3857@ACM> <87vafp7i82.fsf@mail.linkov.net> <20180126183702.GA5056@ACM> <831sicl9p3.fsf@gnu.org> <20180126200027.GB5056@ACM> <83r2qbk5bf.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1517053467 5394 195.159.176.226 (27 Jan 2018 11:44:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Jan 2018 11:44:27 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: 30186@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 27 12:44:22 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efOu3-0000GH-KZ for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Jan 2018 12:44:11 +0100 Original-Received: from localhost ([::1]:43567 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efOw2-0004M5-J2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Jan 2018 06:46:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efOvu-0004KT-8T for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2018 06:46:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1efOvr-0003HM-2g for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2018 06:46:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36515) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1efOvq-0003Gm-TX for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2018 06:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1efOvq-000458-Gu for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2018 06:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Jan 2018 11:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30186 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30186-submit@debbugs.gnu.org id=B30186.151705352515636 (code B ref 30186); Sat, 27 Jan 2018 11:46:02 +0000 Original-Received: (at 30186) by debbugs.gnu.org; 27 Jan 2018 11:45:25 +0000 Original-Received: from localhost ([127.0.0.1]:44412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efOvE-000448-T9 for submit@debbugs.gnu.org; Sat, 27 Jan 2018 06:45:25 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:11846 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1efOvC-00043y-Kg for 30186@debbugs.gnu.org; Sat, 27 Jan 2018 06:45:23 -0500 Original-Received: (qmail 39427 invoked by uid 3782); 27 Jan 2018 11:45:20 -0000 Original-Received: from acm.muc.de (p548C7E39.dip0.t-ipconnect.de [84.140.126.57]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 27 Jan 2018 12:45:18 +0100 Original-Received: (qmail 30141 invoked by uid 1000); 27 Jan 2018 11:37:13 -0000 Content-Disposition: inline In-Reply-To: <83r2qbk5bf.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de 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:142578 Archived-At: Hello, Eli. On Sat, Jan 27, 2018 at 11:40:36 +0200, Eli Zaretskii wrote: > > Date: Fri, 26 Jan 2018 20:00:27 +0000 > > Cc: juri@linkov.net, 30186@debbugs.gnu.org > > From: Alan Mackenzie > > Do you have any opinion on my suggestion: > > > > Perhaps an alternative would be for Emacs to provide a flag which > > > > indicates to a before/after-change-function whether the current > > > > change is a "proper" change or merely a text property change. > > > > Change hook functions could then test this flag and, for example, > > > > refrain from doing anything for a text property change. > I'm not sure it would be possible to provide such a flag. Did you > look at the internals involved, and if so, can you tell where do we > know which kind of change caused the hooks to run? I envisage adding an extra boolean argument to prepare_to_modify_buffer, and to signal_after_change. When called from the text property routines, that argument would be true, otherwise it would be false. The essence of this argument would be a guarantee that the change is not going to alter the buffer text. There may be other primitives besides text properties for which we could set this argument. > I also don't understand the problem you have in CC Mode with > text-property changes. Can you elaborate on that? Yes. In a largish CC Mode file, mark the entire buffer, kill-ring-save, and append it after itself, with C-x h, M-w, M->, C-y . In buffer-undo-list there are no entries for text property changes. Before the with-silent-modifications was put in, there were many such entries. Assume this in the next paragraph Now undo this latest change with C-_. Each of the entries for text property changes wants to invoke CC Mode's before/after-change-functions, which would make the operation slow. (But see below.) The workaround (currently in Emacs) for this, back in 2015, was to put with-silent-modifications around the text property manipulations in remove-yank-excluded-properties. This prevents these manipulations getting into the undo list, but also stops read-passwd from working properly. I now see there is a second workaround, in CC Mode itself, where c-before-change and c-after-change use backtrace-frame to check the primitive invoking them, and do nothing if that primitive is, e.g., put-text-property. This is not an elegant workaround. So, I'm changing my mind, after looking into it a bit more. Removing the with-silent-modifications from remove-yank-excluded-properties would not slow down undo in CC Mode buffers noticeably. It might slow down other modes which make extensive use of before/after-change-functions. The extra flag for the change hooks might still be a good idea. It no longer seems pertinent for solving the current bug, though. -- Alan Mackenzie (Nuremberg, Germany).