From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#2034: [PATCH] 27.0.50; Support mode line constructs for `mode-name' in c-mode Date: Tue, 03 Jul 2018 10:53:30 +1200 Message-ID: <870f8e5df67e29f9070abd858a98a037@webmail.orcon.net.nz> References: <87skn8xhia.fsf@transitory.lefae.org> <47fd3239-fe83-0f2f-b903-e18713cc60f6@orcon.net.nz> <83sh51k65l.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1530571926 32324 195.159.176.226 (2 Jul 2018 22:52:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Jul 2018 22:52:06 +0000 (UTC) User-Agent: Orcon Webmail Cc: 2034@debbugs.gnu.org, bug-gnu-emacs To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 03 00:52:01 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 1fa7ft-0008GR-Nt for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2018 00:52:01 +0200 Original-Received: from localhost ([::1]:36247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fa7i0-0000rP-Rs for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Jul 2018 18:54:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fa7ht-0000ov-K0 for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2018 18:54:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fa7hq-00059W-It for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2018 18:54:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36257) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fa7hq-000599-ES for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2018 18:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fa7hq-0006I7-7d for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2018 18:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Jul 2018 22:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 2034 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug wontfix Original-Received: via spool by 2034-submit@debbugs.gnu.org id=B2034.153057201624140 (code B ref 2034); Mon, 02 Jul 2018 22:54:02 +0000 Original-Received: (at 2034) by debbugs.gnu.org; 2 Jul 2018 22:53:36 +0000 Original-Received: from localhost ([127.0.0.1]:44154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fa7hQ-0006HI-7h for submit@debbugs.gnu.org; Mon, 02 Jul 2018 18:53:36 -0400 Original-Received: from smtp-4.orcon.net.nz ([60.234.4.59]:56471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fa7hN-0006H6-Cy for 2034@debbugs.gnu.org; Mon, 02 Jul 2018 18:53:34 -0400 Original-Received: from [10.253.37.70] (port=40243 helo=webmail.orcon.net.nz) by smtp-4.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1fa7hK-0005qt-LX; Tue, 03 Jul 2018 10:53:30 +1200 Original-Received: from wlgwil-nat-office.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Tue, 03 Jul 2018 10:53:30 +1200 In-Reply-To: <83sh51k65l.fsf@gnu.org> X-Sender: psainty@orcon.net.nz X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- 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:148130 Archived-At: On 2018-07-03 03:29, Eli Zaretskii wrote: > I've just skimmed the patch, so apologies in advance if what I'm > saying makes no sense. That said, did you try to compare the old and > the new code when the flag strings have text properties, like faces or > colors? The mode-line formatting code is tricky when text properties > are involved. I haven't, but I don't *think* that's going to be a concern here. The code which formats the string of flags hasn't changed, and the substrings (individual flags) which are passed to `format' are string literals with no properties, so AFAICS the formatted string of flags will not have any text properties when it is generated (which happens afresh each time `c-update-modeline' is called). If I'm missing something here, I think I'll need some guidance on how to test for potential problems. > Please always provide a :version tag for new/modified defcustoms. Right, I knew I'd missed something there. > Finally, I think this needs a NEWS entry, if not a suitable change to > the manual. Agreed. My current approach may need more work. At present it still assumes that `mode-name' will *start out* as a string, and it tests `stringp' to decide whether to wrap the additional constructs around it. That is still an improvement on the pre-existing situation which throws errors, but does mean that if a mode was itself defined to set a non-string `mode-name' then the new code would not add the minor mode flags at all; so it might be desirable to support that case as well. To do this I think I'd need an additional buffer-local variable to indicate (in place of that `stringp' test) whether or not `mode-name' had been processed by `c-update-modeline', as otherwise it seems like it would be awkward to decide whether or not to add the new constructs. Although as I have added the buffer-local `c-modeline-flags', I guess I can make that nil by default, and use that state as the indicator I need. I'll write a revised patch to address these points. -Phil