From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jeremy Bryant Newsgroups: gmane.emacs.devel Subject: Re: Quality of life improvements to macroexp.el Date: Thu, 18 Jul 2024 21:40:59 +0100 Message-ID: <878qxybfhg.fsf@jeremybryant.net> References: <87ikx62j5e.fsf@gmail.com> <87frs7da94.fsf@jeremybryant.net> <87bk2uyhpu.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35137"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Thuna , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 18 22:41:27 2024 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 1sUXwM-0008u7-H0 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Jul 2024 22:41:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sUXw6-00026p-Vp; Thu, 18 Jul 2024 16:41:11 -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 1sUXw4-00026Q-Ik for emacs-devel@gnu.org; Thu, 18 Jul 2024 16:41:08 -0400 Original-Received: from out-189.mta0.migadu.com ([2001:41d0:1004:224b::bd]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sUXw2-0001Du-LU for emacs-devel@gnu.org; Thu, 18 Jul 2024 16:41:08 -0400 X-Envelope-To: emacs-devel@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeremybryant.net; s=key1; t=1721335262; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FujWo2EDGVnyO3CaHSFkIBopC1PTmpDiUfQnVpRvInA=; b=ofauLfehZGqb/jcJETmTeUKNENPf9LW4Mskc08PojEQJmz6eePKEFp8mr0H6ESfo/+6z9a f4yJ+CdRE2a/P3nNKBkMKSb23Q7J5xyJDVUZes6kQwgXxdFbKWEDq1TyxxySbBrmFvoV5F aKk/t2pTAN72gHTkL7C4NBG+7mwyDTM7HpVfX3ORS5S8qmPXxDHivFWtyDJ0sZYpQYYCYn KXLWI8VgEhDDzc2S+I4BuxlrqNVLSQakmiXfO4ZzbFHP7umDs9s4qTcUfYayHywekGEVj2 rDJ78WTVD5ghv3xueYK9SEUrcpJo8yflUWxqm2UvOpTsqlCd8m79WvfRYhYVvQ== X-Envelope-To: thuna.cing@gmail.com X-Envelope-To: luangruo@yahoo.com X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-Reply-To: <87bk2uyhpu.fsf@yahoo.com> (Po Lu's message of "Thu, 18 Jul 2024 21:04:13 +0800") X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=2001:41d0:1004:224b::bd; envelope-from=jb@jeremybryant.net; helo=out-189.mta0.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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.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:321810 Archived-At: Po Lu writes: > Jeremy Bryant writes: > >> Thuna writes: >> >>> I was just looking into using macroexp.el and found some features that I >>> felt were lacking. These were: 1. accepting multiple forms in >>> `macroexp-if' and `macroexp-let*', 2. flattening of `progn's in >>> `macroexp-progn' and `macroexp-unprogn', 3. getting rid of branches in >>> `macroexp-if' in case the TEST is constant (and consequently a way to >>> tell whether a constant form is nil or non-nil). I've went through the >>> rest of macroexp.el and haven't found anything else that stood out, >>> though I might change my mind as I keep using it. >>> >>> I've attached a patch for possible implementations of these, though this >> >> Thanks. For the fastest response and ease of tracking in the bug tracker: >> >> Every patch must have several pieces of information before we can properly evaluate it. They are described below. >> >> When you have all these pieces, use the M-x submit-emacs-patch command to send the patch. > > This is in nowise a cast-iron requirement for submitted patches, > especially for small patches such as this is. OK, thanks Po for clarifying. I was emphasizing the benefits of the bug tracker's features, together with wider patch conventions, but I accept they could be overkill in this situation.