From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "T.V Raman" Newsgroups: gmane.emacs.devel Subject: Re: bytecomp: doc string wider than 80 spurious warnings are back Date: Thu, 28 Sep 2023 07:16:43 -0700 Message-ID: <25877.35531.898469.897554@retriever.mtv.corp.google.com> References: <25876.19565.180274.795481@retriever.mtv.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26880"; mail-complaints-to="usenet@ciao.gmane.io" Cc: raman@google.com, emacs-devel@gnu.org, ohwoeowho@gmail.com To: stefankangas@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 28 16:18:12 2023 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 1qlrqF-0006jB-RH for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Sep 2023 16:18:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qlroz-0000JT-2w; Thu, 28 Sep 2023 10:16:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qlrow-0000Im-L4 for emacs-devel@gnu.org; Thu, 28 Sep 2023 10:16:50 -0400 Original-Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qlrou-000523-MI for emacs-devel@gnu.org; Thu, 28 Sep 2023 10:16:50 -0400 Original-Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1c5bf7871dcso104709555ad.1 for ; Thu, 28 Sep 2023 07:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695910606; x=1696515406; darn=gnu.org; h=references:in-reply-to:subject:cc:to:date:message-id :content-transfer-encoding:mime-version:from:from:to:cc:subject:date :message-id:reply-to; bh=NOHS4Bdf+U8WDga+/ynLcjribYgsqSei+yeRyYhccsw=; b=1DbvWivIpYKORgzm4oFEy7CFE+7EpHa/3AnI2KIX2TRDT7E9JcOCEnQuwo8fEEYXRa wCLchBIto5zoiQFE3DyFqzcT0v6NHKpx8rmKMzswAvgaklLf6jAJLkEqIpnqbO7P3Pru TN2bu+iPF7KZp+p9R7Kzx77oG1qX0Bjwtzec3RjA9nmrqOln6Yz2wv0i8c6zFjJ34gbe DNfOy0gDXXFmkQ4DV9TE10WJXCP5xxZgPTacmpnAKKybgRCh3Ut0cJ3AFcX1sO67x1+f xFzaMfyy5Qk/6lTIhHkVqvaij824dLSf1/k0Uz+wikHOpHHi/oJNescLGQpsi7T8gmcR Fm2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695910606; x=1696515406; h=references:in-reply-to:subject:cc:to:date:message-id :content-transfer-encoding:mime-version:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=NOHS4Bdf+U8WDga+/ynLcjribYgsqSei+yeRyYhccsw=; b=ARqstlJYHaTjP4tok7vtnJI+pUIM4xB3di6fiL5GcD7Qj8Qr0G5UPScpsXv8iik8nA ZmkCJ+9FsO2Uzb1Y9XqeLF/kcN/HdZJ3b/pNUlKam5wDDPFqzKvv/J8gjmrcbyDy6FWk cVNVxUnZQQYhYbdoZaLgJHN7FxZJGplhunbeVQoW1pNwxqs/op6WvXvsLiAfO56onN0w iZ+gjJTE0o7kcWtvA2dcrxFifvpSTJqyC6XVscYoZjVjv8CGmSg/B546q4COAEXevCSm iiuUN2ZJHp4SpSaNDd7bG8ATwq+TOg/Y7WE86tVxdRhy0kDqouAWW7r21KVYPwWIf08t qdOQ== X-Gm-Message-State: AOJu0Yzya848RU4bjAQ3kQIJt3ivrR1DDjbn7kd1g7lEdoKFSr2PwejU m0WBbx7SCzgZgAVOweswgmw40mqZ+ktILynp9pTdKw== X-Google-Smtp-Source: AGHT+IFTo0/7SErtu8gY/cfsn9pdGElH9RDTriZ3S6v6mFiYjVPVKF3/fR5VGcmC/8XF+gr41aTYEA== X-Received: by 2002:a17:902:e74d:b0:1c7:3f5f:1b9f with SMTP id p13-20020a170902e74d00b001c73f5f1b9fmr560889plf.45.1695910605603; Thu, 28 Sep 2023 07:16:45 -0700 (PDT) Original-Received: from retriever.mtv.corp.google.com ([2620:15c:b5:2:d774:13af:4e0b:59a4]) by smtp.gmail.com with ESMTPSA id jh5-20020a170903328500b001bb9bc8d232sm15070483plb.61.2023.09.28.07.16.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 07:16:44 -0700 (PDT) In-Reply-To: X-Mailer: VM 8.1.1 under 30.0.50 (x86_64-pc-linux-gnu) Received-SPF: pass client-ip=2607:f8b0:4864:20::629; envelope-from=raman@google.com; helo=mail-pl1-x629.google.com X-Spam_score_int: -190 X-Spam_score: -19.1 X-Spam_bar: ------------------- X-Spam_report: (-19.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, NICE_REPLY_A=-1.473, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311129 Archived-At: Agreed on everything except the last: Yes, we cant do anything about third party macros, but we == Emacs is the one displaying the docstring, so we can surely break ourselves free from the docstring not being wider than 80 chars; and for instance, in your example, the function name passed is a 128-char hyphenated string, then how to handle that is still better handled in the display algorithm, Stefan Kangas writes: > "T.V Raman" writes: > > > Hope it gets fixed upstream in Hydra. But stepping back a level: > > > > 1. Byte Compiler warnings are really useful when developing in Emacs > > Lisp. > > 2. But they lose their value if the byte compiler gets noisy > > No disagreement there. > > > -- in > > this case I think this warning qualifies as noise because: > > > > A. The developer who is hit with this warning can do nothing > > about it > > B. It obscures more useful warnings > > > > A typical case looks like this: > > (defmacro foo (name) > `(defun bar () > ,(format "foo %s." name))) > > If someone passes in a string NAME longer than 80 characters, that will > generate a warning. It is the responsibility of whoever writes a macro > to ensure it doesn't generate long docstrings by properly wrapping it. > The same is true for any byte-compiler warning. > > In core we use `internal--format-docstring-line' for this, which means > that fixed code for the above would look like this: > > (defmacro foo (name) > `(defun bar () > ,(internal--format-docstring-line > (format "foo %s." name)))) > > I don't think there's anything we can do about macros in third-party > packages, unfortunately. Perhaps `internal--format-docstring-line' is > useful enough not to be marked internal, though? I'm not sure. > > > And by the way when this was fixed a few months ago, it > > ws fixed in the Emacs tree. > > But that warning was due to a macro in our tree, right? --