From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode Date: Fri, 30 Jul 2021 20:54:11 +0300 Organization: LINKOV.NET Message-ID: <87r1ffit6k.fsf@mail.linkov.net> References: <20210727211521.15408.98852@vcs0.savannah.gnu.org> <20210727211523.AE6F72065F@vcs0.savannah.gnu.org> <877dhabg5s.fsf@gnus.org> <87zgu6h0e1.fsf@mail.linkov.net> <87a6m6tn0e.fsf@gnus.org> <87r1figz3p.fsf@mail.linkov.net> <87zgu4ri8b.fsf@gnus.org> <837dh8s6fj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32353"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: Lars Ingebrigtsen , Stefan Monnier , leungbk@mailfence.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 30 20:06:13 2021 Return-path: Envelope-to: ged-emacs-devel@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 1m9Wth-00089T-IF for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Jul 2021 20:06:13 +0200 Original-Received: from localhost ([::1]:34096 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9Wtf-0007xI-Uq for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Jul 2021 14:06:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55008) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9Wr7-0003bh-7b for emacs-devel@gnu.org; Fri, 30 Jul 2021 14:03:33 -0400 Original-Received: from relay12.mail.gandi.net ([217.70.178.232]:53951) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9Wr4-0002QW-KA; Fri, 30 Jul 2021 14:03:32 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id C6BB9200002; Fri, 30 Jul 2021 18:03:25 +0000 (UTC) In-Reply-To: <837dh8s6fj.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 30 Jul 2021 08:43:12 +0300") Received-SPF: pass client-ip=217.70.178.232; envelope-from=juri@linkov.net; helo=relay12.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:271858 Archived-At: > I'm not sure it's a warning. It's an informative message, and some of > them are always displayed during bootstrap. Making them warnings > would then apply pressure on us to remove them, which we cannot easily > do in the case of those other messages (unlike the one caused by the > changeset in this bug). For example, today's compilation displayed as lot of such lines: Warning: Eager macro-expansion skipped due to cycle: … => (load "byte-opt.el") => (macroexpand-all … Warning: Eager macro-expansion skipped due to cycle: … => (load "byte-opt.el") => (macroexpand-all … … I don't know if these are actionable but they are designated as warnings, and displayed with the same compilation-enter-directory-face as these unimportant messages: Pure-hashed: 16071 strings, 4220 vectors, 41688 conses, 3769 bytecodes, 267 others make[1]: Entering directory > My personal advice is to read carefully every line displayed by the > build process, and not limit yourself to warnings. Messages that > aren't supposed to appear during a normal build should be discovered > regardless of whether they are warnings/errors or not. It's not realistic to read thousands of lines from every compilation. It should be enough just to look at the compilation's mode line to see the total number of errors (in red color), warnings (orange), and the number of informational messages (in green color). So if you think such messages are not warnings then such messages should be detected as informational messages displayed with the green color that has the corresponding indicator on the mode line and at the end of the compilation output. etc/compilation.txt demonstrates the supported syntax: foo.c:8:I: message foo.c:8.23: note: message foo.c:8.23: info: message foo.c:8:23:information: message foo.c:8.23-45: Informational: message Another problem is that such syntax requires as least a file name and a line number that is not always available. A workaround is to display a fake name and number.