From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#43730: 27.1; Running (visual-line-mode 1) twice Date: Thu, 01 Oct 2020 04:15:43 +0200 Message-ID: <878scqvghc.fsf@gnus.org> References: <86eemjdr5c.fsf@miha-pc> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13174"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 43730@debbugs.gnu.org To: Miha =?UTF-8?Q?Rihtar=C5=A1i=C4=8D?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 01 04:16:34 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNo93-0003IG-Vx for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Oct 2020 04:16:34 +0200 Original-Received: from localhost ([::1]:50310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNo92-0004aY-N1 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Sep 2020 22:16:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNo8b-0004Zg-31 for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2020 22:16:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50241) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kNo8Y-0006Mj-Av for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2020 22:16:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kNo8Y-0001Ur-74 for bug-gnu-emacs@gnu.org; Wed, 30 Sep 2020 22:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Oct 2020 02:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43730 X-GNU-PR-Package: emacs Original-Received: via spool by 43730-submit@debbugs.gnu.org id=B43730.16015185595605 (code B ref 43730); Thu, 01 Oct 2020 02:16:02 +0000 Original-Received: (at 43730) by debbugs.gnu.org; 1 Oct 2020 02:15:59 +0000 Original-Received: from localhost ([127.0.0.1]:33554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNo8V-0001Rz-AW for submit@debbugs.gnu.org; Wed, 30 Sep 2020 22:15:59 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:53072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNo8R-0001JM-RL for 43730@debbugs.gnu.org; Wed, 30 Sep 2020 22:15:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jl9KeqiDMSQycYHl3n40DaXYBgh5L3SMLuZPEhoW2Wo=; b=QiZB1XsCjz/gyJg7uZ4iq37KZw lCF1ynKneVT74VPp6bxR2ODw4bz/XjmEe973/2NOeHBSqUWYuV7my4eah6lpZX5qncVEgk2rOcr7q 9jIpc3N22AiNe5j16uveWer2Zv9YcqXQcyN7gTTEw5/r6KWfualeFW7zLeBCWEm9hUGQ=; Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNo8H-0000n7-0c; Thu, 01 Oct 2020 04:15:48 +0200 X-Now-Playing: Seigen Ono's _Comme des =?UTF-8?Q?Gar=C3=A7ons=5F:?= "All Men Are Heels" In-Reply-To: <86eemjdr5c.fsf@miha-pc> ("Miha =?UTF-8?Q?Rihtar=C5=A1i=C4=8D?="'s message of "Wed, 30 Sep 2020 21:02:39 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:189454 Archived-At: Miha Rihtar=C5=A1i=C4=8D writes: > Running (visual-line-mode 1) twice is inconsistent due to variable > visual-line--saved-state being set twice. > > A real life example, producible with emacs -Q would be to run > > (setq-default truncate-lines t) > (add-hook 'text-mode-hook 'visual-line-mode) > (add-hook 'prog-mode-hook 'visual-line-mode) > > and visit a buffer in mhtml-mode, which runs both text-mode-hook and > prog-mode-hook. > visual-line-mode sets the local value of truncate-lines to nil as > expected but turning it off with > M-x visual-line-mode > fails to restore truncate-lines back to t, due to incorrect > visual-line--saved-state. Thanks for the analysis. It seems to me that the way to fix this problem would be to do something general in define-minor-mode. It has always confused me that the resulting mode function starts like this: (defun ,modefun (&optional arg ,@extra-args) ,(easy-mmode--mode-docstring doc pretty-name keymap-sym) ;; Use `toggle' rather than (if ,mode 0 1) so that using ;; repeat-command still does the toggling correctly. (interactive (list (or current-prefix-arg 'toggle))) (let ((,last-message (current-message))) (,@setter (if (eq arg 'toggle) (not ,getter) ;; A nil argument also means ON now. (> (prefix-numeric-value arg) 0))) ,@body This means that all the modes basically have bodies that start like this: (if visual-line-mode (progn And the modes do not know whether the mode was already on, or whether we're switching it on now, because the only clue it has is the value of visual-line-mode, and that has just been set based on ARG. So. One really aggressive way to try to fix this would be for define-minor-mode to just not call the body at all if the value of the mode variable doesn't change. That is, the second call here would do absolutely nothing: (visual-line-mode 1) (visual-line-mode 1) I think that would be logical change, but... it's a pretty radical change? Who knows what it would affect? A much less invasive change would be to bind a variable in the defun there, like (let ((,previous-state ,modevar)) =20=20=20=20=20=20=20=20=20=20=20=20 and then modes like visual-line-mode could go (when (not (eq visual-line-mode previous-state)) (if visual-line-mode (progn Any opinions? --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no