From unknown Sat Jun 21 05:00:05 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#77430 <77430@debbugs.gnu.org> To: bug#77430 <77430@debbugs.gnu.org> Subject: Status: compilation-start should remember shell-file-name Reply-To: bug#77430 <77430@debbugs.gnu.org> Date: Sat, 21 Jun 2025 12:00:05 +0000 retitle 77430 compilation-start should remember shell-file-name reassign 77430 emacs submitter 77430 Siyuan Chen severity 77430 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 01 09:42:51 2025 Received: (at submit) by debbugs.gnu.org; 1 Apr 2025 13:42:52 +0000 Received: from localhost ([127.0.0.1]:47187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzbt9-0006yd-Vm for submit@debbugs.gnu.org; Tue, 01 Apr 2025 09:42:51 -0400 Received: from lists.gnu.org ([2001:470:142::17]:41100) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzbt4-0006wf-NH for submit@debbugs.gnu.org; Tue, 01 Apr 2025 09:42:45 -0400 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 1tzbsu-0005qJ-Ad for bug-gnu-emacs@gnu.org; Tue, 01 Apr 2025 09:42:32 -0400 Received: from mail-yw1-x112f.google.com ([2607:f8b0:4864:20::112f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tzbss-0006do-6I for bug-gnu-emacs@gnu.org; Tue, 01 Apr 2025 09:42:31 -0400 Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-6fed0620395so51350107b3.3 for ; Tue, 01 Apr 2025 06:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743514947; x=1744119747; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=OFvdsgCljfQkxFyV/UuIP/oePMrLYXuy8L3icFhQARY=; b=gkvzH3MgpMZCtIq5RTMkQqeMThujTulAQAhWzbWVlRFBQltZG11GYal/+qMS9wO2WZ /8lZt9c1qyafqSlC85938xril5EKTNTfBlQxiVYvz+/zJA/AR67q9OQaudf/Q1p35Max 7KD3BKQtdIDwz1bWY0G1Dfn3LGcgjryO39sgRVJsQcXYKUd9crEq6k3HIwx68esC7hTr k036qp+hcOiQxnSUBiPqDQRXj0wuD2dmnTDGUtMgLa7wYRmrnJKVqu6ZVUC2TIU9Ax1i 53Deq89iHr92rUoDGbC2p9QoFO5sKVDPsqrI00yJ3VTcU60kCohohMaUiOy6enSccWI6 1xtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743514947; x=1744119747; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=OFvdsgCljfQkxFyV/UuIP/oePMrLYXuy8L3icFhQARY=; b=Yb9eXSLM2udT21pKUDfRwqWEqQQpwavFMN2TzlqTygc4iKVT8r+qkj28uT0kEpVR0L XJwUm+erTbA8NU0e9daIdsp7Z6MyXswiqZEeA+ndIh3wml1TYCk/Qeyw22PJapIBNYeM Vh/DmchXv2qiStJ3wbAacnbr9alcODUlTLJJHjEDh0f5iWEAPIFQegfxQXGCmfQ31od4 CYekjQlPudcM6z0TCnOC1cegQJ2+WCFmGCW6Lgd3jjuK1ybeEE2M+OO7Y65AmoQmFm6Q 6RF1NUFgjqn8+B8eCqlykiEVI3pPVkmlRCq8jt9sbVMw8dHbNzc1dqZ1Hhuj3cOffZHQ o54Q== X-Gm-Message-State: AOJu0YwvAXT0aeWnEjhD5LM7YfeUPdKfyjYnVEz2duxoB4j8LIeO2u2E u5WzYI8AG9LP1YoErRUU8wOV44lLCTv7pOecUvBmxJt2N3P83Bc5J4pXlM5h6pLZt1mKBnAVj1F RUqUl1S9SbzTkCTfiJJZr3YzMVMds1nVR X-Gm-Gg: ASbGnctZBa1E5IGwwa72WDHgxyPAhOiv5nzRhq0M98WDB8WcVDdPzQFSZlD+Mcb2/QX VKpV3/QaWsNhO7cwkSi138jp01AeziCqI0mpGCsqNhHMzeHoAOVnDk9ZsIwkgGtk5Th6+pffuHE Hu6j2GQKEC+usxPS7Yu12Y19DOxuT740tVQoZlX9Tn2HntxysiX+1rZIzZNw== X-Google-Smtp-Source: AGHT+IFnF69P8PNxjBWQuj6fN9fK1kjbtJHBHZBl2x04qmaBIInLh/8yGSjDQ6zMRq+7tGFFSPM2er2T+JYml2YcqMg= X-Received: by 2002:a05:690c:3383:b0:6fd:359a:8fd2 with SMTP id 00721157ae682-702572f19d4mr183853857b3.26.1743514947039; Tue, 01 Apr 2025 06:42:27 -0700 (PDT) MIME-Version: 1.0 From: Siyuan Chen Date: Tue, 1 Apr 2025 21:42:21 +0800 X-Gm-Features: AQ5f1JqxiIjHkZqaPzdp8kMxTKdM5hNxc2PoD0WJ8v7A1hMFPnVjVDUJ-uAGNK0 Message-ID: Subject: compilation-start should remember shell-file-name To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="00000000000014a6270631b7b50f" Received-SPF: pass client-ip=2607:f8b0:4864:20::112f; envelope-from=chansey97@gmail.com; helo=mail-yw1-x112f.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Background: Recently, I've been setting up a Haskell compilation environment with Emacs on Windows. The project depends on diagrams-cairo, which depends on GTK+, so I have to build it via msys64 with MINGW. It wo [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (chansey97[at]gmail.com) 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (chansey97[at]gmail.com) 0.0 HTML_MESSAGE BODY: HTML included in message X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --00000000000014a6270631b7b50f Content-Type: multipart/alternative; boundary="00000000000014a6260631b7b50d" --00000000000014a6260631b7b50d Content-Type: text/plain; charset="UTF-8" Background: Recently, I've been setting up a Haskell compilation environment with Emacs on Windows. The project depends on diagrams-cairo, which depends on GTK+, so I have to build it via msys64 with MINGW. It works well in a non Emacs environment, so I'd like to adapt it to the Emacs environment. Everything is OK, except when I press 'g' in the *compilation* buffer. To simplify the problem, below only the minimal test is provided. Reproduce steps: 1. Create a file test.el in E:/tmp 2. Open that file and paste the following code ``` (defun my/compile () (interactive) (let ((shell-file-name "C:/msys64/usr/bin/bash") (compilation-environment "PATH=/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl") ) (compile "ls") )) ``` NOTE: You can think of "ls" as a compilation command such as "stack build" in Haskell. 3. Evaluate Last S-expression. 4. M-x my/compile The *compilation* buffer lists the files normally. 5. Press 'g' in the *compilation* buffer, i.e. `recompile'. The expected behavior: List the files again. The actual behavior: Compilation exited abnormally. The problem is that `recompile' does not realize that `shell-file-name' has been updated to bash. It still uses the default cmdproxy. I have created a patch to workaround the issue. It remembers the original `shell-file-name' in `compilation-start', so we can use it when we `recompile'. Thanks. Best regards, Siyuan Chen --00000000000014a6260631b7b50d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Background:

Recently, I've been setting up a Ha= skell compilation environment with Emacs on Windows. The project depends on= diagrams-cairo, which depends on GTK+, so I have to build it via msys64 wi= th MINGW. It works well in a non Emacs environment, so I'd like to adap= t it to the Emacs environment.

Everything is OK, except when I press= 'g' in the *compilation* buffer.

To simplify the problem,= =20 below only the minimal test is provided.

Reproduce steps:

1. Create= a file test.el in E:/tmp

2. Open that file and paste the following = code
```
(defun my/compile ()
=C2=A0 (interactive)
=C2=A0 (let = ((shell-file-name "C:/msys64/usr/bin/bash")
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 (compilation-environment "PATH=3D/mingw64/bin:/usr/local/bi= n:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/= Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor= _perl:/usr/bin/core_perl")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 )
=C2=A0 = =C2=A0 (compile "ls")
=C2=A0 =C2=A0 ))
```
NOTE: You can= think of "ls" as a=20 compilation=20 command such as "stack build" in Haskell.

3. Evaluate Last= S-expression.

4. M-x my/compile

The *compilation* buffer lis= ts the files normally.

5. Press 'g' in the *compilation* buf= fer, i.e. `recompile'.

The expected behavior: List the files aga= in.

The actual behavior: Compilation exited abnormally.

The p= roblem is that `recompile' does not realize that `shell-file-name' = has been updated to bash. It still uses the default cmdproxy.

I= have created a patch to workaround the issue. It remembers the original `s= hell-file-name' in `compilation-start', so we can use it when we `r= ecompile'.

Thanks.

Best regards,
Siyuan Chen
--00000000000014a6260631b7b50d-- --00000000000014a6270631b7b50f Content-Type: text/plain; charset="US-ASCII"; name="0001-Remember-the-original-shell-file-name-so-we-can-use-.patch" Content-Disposition: attachment; filename="0001-Remember-the-original-shell-file-name-so-we-can-use-.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m8yjq11b0 RnJvbSAwMjdlMmY1N2FmOTg0NDc4ZWYyY2MwOWJmMDk2MjhiMWY2NWRjNWRjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTaXl1YW4gQ2hlbiA8Y2hhbnNleTk3QG91dGxvb2suY29tPgpE YXRlOiBUdWUsIDEgQXByIDIwMjUgMjE6MDY6MDEgKzA4MDAKU3ViamVjdDogW1BBVENIXSBSZW1l bWJlciB0aGUgb3JpZ2luYWwgc2hlbGwtZmlsZS1uYW1lLCBzbyB3ZSBjYW4gdXNlIGl0IHdoZW4K IHdlIHJlY29tcGlsZS4KCi0tLQogbGlzcC9wcm9nbW9kZXMvY29tcGlsZS5lbCB8IDIgKysKIDEg ZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9saXNwL3Byb2dtb2Rl cy9jb21waWxlLmVsIGIvbGlzcC9wcm9nbW9kZXMvY29tcGlsZS5lbAppbmRleCAxY2E1OGIzYWM3 ZC4uMTNmMjAzMTFhODMgMTAwNjQ0Ci0tLSBhL2xpc3AvcHJvZ21vZGVzL2NvbXBpbGUuZWwKKysr IGIvbGlzcC9wcm9nbW9kZXMvY29tcGlsZS5lbApAQCAtMTk3Myw2ICsxOTczLDcgQEAgUmV0dXJu cyB0aGUgY29tcGlsYXRpb24gYnVmZmVyIGNyZWF0ZWQuIgogCSAgICAocmVwbGFjZS1yZWdleHAt aW4tc3RyaW5nICItbW9kZVxcJyIgIiIgKHN5bWJvbC1uYW1lIG1vZGUpKSkpCiAJICh0aGlzZGly IGRlZmF1bHQtZGlyZWN0b3J5KQogCSAodGhpc2VudiBjb21waWxhdGlvbi1lbnZpcm9ubWVudCkK KyAgICAgICAgICh0aGlzaGVsbCBzaGVsbC1maWxlLW5hbWUpCiAgICAgICAgICAoYnVmZmVyLXBh dGggKGFuZCAobG9jYWwtdmFyaWFibGUtcCAnZXhlYy1wYXRoKSBleGVjLXBhdGgpKQogICAgICAg ICAgKGJ1ZmZlci1lbnYgKGFuZCAobG9jYWwtdmFyaWFibGUtcCAncHJvY2Vzcy1lbnZpcm9ubWVu dCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJvY2Vzcy1lbnZpcm9ubWVudCkpCkBAIC0y MDQ4LDYgKzIwNDksNyBAQCBSZXR1cm5zIHRoZSBjb21waWxhdGlvbiBidWZmZXIgY3JlYXRlZC4i CiAgICAgICAgIDs7IE5COiBtdXN0IGJlIGRvbmUgYWZ0ZXIgKGZ1bmNhbGwgbW9kZSkgYXMgdGhh dCByZXNldHMgbG9jYWwgdmFyaWFibGVzCiAgICAgICAgIChzZXRxLWxvY2FsIGNvbXBpbGF0aW9u LWRpcmVjdG9yeSB0aGlzZGlyKQogICAgICAgICAoc2V0cS1sb2NhbCBjb21waWxhdGlvbi1lbnZp cm9ubWVudCB0aGlzZW52KQorICAgICAgICAoc2V0cS1sb2NhbCBzaGVsbC1maWxlLW5hbWUgdGhp c2hlbGwpCiAgICAgICAgIChpZiBidWZmZXItcGF0aAogICAgICAgICAgICAgKHNldHEtbG9jYWwg ZXhlYy1wYXRoIGJ1ZmZlci1wYXRoKQogICAgICAgICAgIChraWxsLWxvY2FsLXZhcmlhYmxlICdl eGVjLXBhdGgpKQotLSAKMi4zMi4wLndpbmRvd3MuMgoK --00000000000014a6270631b7b50f-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 01 10:35:19 2025 Received: (at 77430) by debbugs.gnu.org; 1 Apr 2025 14:35:20 +0000 Received: from localhost ([127.0.0.1]:47415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzcht-0005ly-NM for submit@debbugs.gnu.org; Tue, 01 Apr 2025 10:35:18 -0400 Received: from mail-yb1-xb2f.google.com ([2607:f8b0:4864:20::b2f]:58582) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tzchi-0005jj-I8 for 77430@debbugs.gnu.org; Tue, 01 Apr 2025 10:35:09 -0400 Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-e60ad903382so4019065276.0 for <77430@debbugs.gnu.org>; Tue, 01 Apr 2025 07:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743518096; x=1744122896; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=PwHoJguGxcOqUPK6LWRFa9yNB5/4kiv1ApoRdqKyT+4=; b=Y6EGxIz57Y4Y84idl5UWf0TS+K8aWozq9PaE1IQKNwNcVt47VcVSJ8xu2r2L7JuAvR Gp5ygpyl3R6lgAb1vWEbDZXEzIB595SshDRoPRB3Z2eFSz/lUw9KobsAmRHNSAariSCv zR0Sgao5U0L+UA/84YYPujwOMJMONytyct0gpc2g6C8o3jrTS3XEjp6oUgQECN2Nap4S NIL0COO9Gqx1tieX6NIP7AuDmdjYcL/OsaT2FH72e5womWrpt7QDtrWJ0JN3awmtpa3b RN+uBYAwqEd6j6BRO0DmtmW4JCMaUjhMxePL9NFCAnJQiz/aCWf34EG5Ws/kYgNCfQTh iLtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743518096; x=1744122896; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PwHoJguGxcOqUPK6LWRFa9yNB5/4kiv1ApoRdqKyT+4=; b=nqVF5eiWMWSlSAWQRmI+1OWmF/23V9pngXqu+Jq5UWJZTevU+vNv4URMQRHNQYXoKf ZH/no/HxadAxjEFhRJnROE3Odb+hKxvfY4JZHZjTd/n0m6AEDvKZOkaDhS4vIOIIzvPt cZSOJWFl5WpAVEl/T4isZJgbSOKMfGpUkw8J+kVhpCviD0Yaj6eug/TjwWLyO8BKHAPJ 5buJEZlU2bvw9x25NCOeDfhoSRsxiuegJ1RxULV1bN1wL391XLq7Wtpwk1fUMOE6ryOY WXpZhC/RIGghYpZ7SIwwtEsCMhaHxZfkYMaB+H2OxTPUCnOR8f7/Q3EfJAHozj741S0h 79hA== X-Gm-Message-State: AOJu0YyNO8DYCz3xt6ry0SJtYz//vcpWLYPD4WxkOu51crQ3lT0QDM4O gWJ2IHyb+OEjWx6fAx+159eUnl9vmxz6f6XpoW9ROWLpCijFdugaPV7xQJWwagE/6+B/dtSQOTu EUFEZiXl75Sf9G6wDEHGEyUzG40lNiU8w X-Gm-Gg: ASbGncstLRhPyWJDDHKOwHWBuWbvHeNlAGmaL6t7VdtRheuyB3D1Hbggj5aEcdgK7ut 8e+m5ROo7IW88k/uUmUYOqNanOBHQbIwRu0w2OLlxZYstoel75azw73R720KmhL14/RrUcSGfn8 ZGxgRlPWVOElajuHDHEJI+mLTkqUgqgGBB3YOIWaiRgqOphODX9I3TVY6j5w== X-Google-Smtp-Source: AGHT+IFqKJD++5GHyPJg7nLMBFw54spwoL14eweWGKMOU0g/j3sX9iM4hVTCbbcjh9QLQPr0y81ISvL2u1pMuSsIdxA= X-Received: by 2002:a05:6902:2586:b0:e6b:799e:a34b with SMTP id 3f1490d57ef6-e6b839592d0mr16777296276.21.1743518096053; Tue, 01 Apr 2025 07:34:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Siyuan Chen Date: Tue, 1 Apr 2025 22:34:49 +0800 X-Gm-Features: AQ5f1Joo_l6mC_uDlGqyEi4Qi7MPuNDRS2oDGPnTEmWwvlFAj0GF1XADQrvvBuA Message-ID: Subject: Re: bug#77430: compilation-start should remember shell-file-name To: 77430@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000c65f640631b870ed" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 77430 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000c65f640631b870ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I found another way to workaround: ``` (defun my/compile () (interactive) (compile "C:/msys64/usr/bin/bash --login -c ls")) ``` Keep =C2=B7shell-file-name=E2=80=98 unchanged. This avoids having to set the `compilation-environment' manually. Except that the *compilation* buffer will output the message: which: no bash in ((null)) but it doesn't seem to affect compilation. Best regards, Siyuan Chen On Tue, Apr 1, 2025 at 9:58=E2=80=AFPM Siyuan Chen wr= ote: > Background: > > Recently, I've been setting up a Haskell compilation environment with > Emacs on Windows. The project depends on diagrams-cairo, which depends on > GTK+, so I have to build it via msys64 with MINGW. It works well in a non > Emacs environment, so I'd like to adapt it to the Emacs environment. > > Everything is OK, except when I press 'g' in the *compilation* buffer. > > To simplify the problem, below only the minimal test is provided. > > Reproduce steps: > > 1. Create a file test.el in E:/tmp > > 2. Open that file and paste the following code > ``` > (defun my/compile () > (interactive) > (let ((shell-file-name "C:/msys64/usr/bin/bash") > (compilation-environment > "PATH=3D/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/= Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0= /:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl") > ) > (compile "ls") > )) > ``` > NOTE: You can think of "ls" as a compilation command such as "stack build= " > in Haskell. > > 3. Evaluate Last S-expression. > > 4. M-x my/compile > > The *compilation* buffer lists the files normally. > > 5. Press 'g' in the *compilation* buffer, i.e. `recompile'. > > The expected behavior: List the files again. > > The actual behavior: Compilation exited abnormally. > > The problem is that `recompile' does not realize that `shell-file-name' > has been updated to bash. It still uses the default cmdproxy. > > I have created a patch to workaround the issue. It remembers the original > `shell-file-name' in `compilation-start', so we can use it when we > `recompile'. > > Thanks. > > Best regards, > Siyuan Chen > --000000000000c65f640631b870ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I found another way to workaround:
```
(defun my/compile ()
=C2=A0 (interactive)=
=C2=A0 (compile "C:/msys64/usr/bin/bash --login -c ls"))=
```

Keep =C2=B7shell-file-name=E2=80=98= unchanged.

This avoids=20 having to set the `compilation-environment' manually. Except that the *compilation* buffer will output the message:

which: no bash in ((null))

but it doesn't seem to affect compil= ation.

Best regards,
Siyuan Chen


On Tue, Apr 1, 2025 at 9:58=E2= =80=AFPM Siyuan Chen <chansey97@g= mail.com> wrote:
Background:

Recently, I've been setting= up a Haskell compilation environment with Emacs on Windows. The project de= pends on diagrams-cairo, which depends on GTK+, so I have to build it via m= sys64 with MINGW. It works well in a non Emacs environment, so I'd like= to adapt it to the Emacs environment.

Everything is OK, except when= I press 'g' in the *compilation* buffer.

To simplify the pr= oblem,=20 below only the minimal test is provided.

Reproduce steps:

1. Create= a file test.el in E:/tmp

2. Open that file and paste the following = code
```
(defun my/compile ()
=C2=A0 (interactive)
=C2=A0 (let = ((shell-file-name "C:/msys64/usr/bin/bash")
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 (compilation-environment "PATH=3D/mingw64/bin:/usr/local/bi= n:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/= Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor= _perl:/usr/bin/core_perl")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 )
=C2=A0 = =C2=A0 (compile "ls")
=C2=A0 =C2=A0 ))
```
NOTE: You can= think of "ls" as a=20 compilation=20 command such as "stack build" in Haskell.

3. Evaluate Last= S-expression.

4. M-x my/compile

The *compilation* buffer lis= ts the files normally.

5. Press 'g' in the *compilation* buf= fer, i.e. `recompile'.

The expected behavior: List the files aga= in.

The actual behavior: Compilation exited abnormally.

The p= roblem is that `recompile' does not realize that `shell-file-name' = has been updated to bash. It still uses the default cmdproxy.

I= have created a patch to workaround the issue. It remembers the original `s= hell-file-name' in `compilation-start', so we can use it when we `r= ecompile'.

Thanks.

Best regards,
Siyuan Chen
--000000000000c65f640631b870ed-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 01 10:47:06 2025 Received: (at 77430) by debbugs.gnu.org; 1 Apr 2025 14:47:08 +0000 Received: from localhost ([127.0.0.1]:48749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzctK-0008F5-4B for submit@debbugs.gnu.org; Tue, 01 Apr 2025 10:47:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35418) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzct5-00089u-ML for 77430@debbugs.gnu.org; Tue, 01 Apr 2025 10:46:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tzcsz-0007gW-1l; Tue, 01 Apr 2025 10:46:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sRDNaFy6+xL1nkcSrqczcPHAIKBKNuIdnC+gs8iJ3k8=; b=SqUYgAIdDCbd GszncMZEiEbjt017ZawNyyGbYsKjqFT+wG/KStz86XwmwOMfrI85ACos11ggoYeXlanhSArh+ZDRo Bw9H5iCryAqEDt/HbqQM02Wq/rYczjpZbSa6t8BSLWjIaA2WNRiBaZ/A88V/myBwp7VyppRmx9Q0/ +kbvlx4BKjg1YQC9TrMghqSTTu5t76s9ebHxk+TwdX9EnYShQ0MNItERyJyRcrEI+vgTeUXTLDPAT nB8inzDuZrI61B5zfbFa3tUJ07DD4mptPSfgDNZFShqPDiy0mmDgi0P6izqPfVnrNAlLOBSsZRH7x NZNmoK71MBKAZ7NSTp/o0g==; Date: Tue, 01 Apr 2025 17:46:37 +0300 Message-Id: <868qok2b3m.fsf@gnu.org> From: Eli Zaretskii To: Siyuan Chen In-Reply-To: (message from Siyuan Chen on Tue, 1 Apr 2025 21:42:21 +0800) Subject: Re: bug#77430: compilation-start should remember shell-file-name References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77430 Cc: 77430@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Siyuan Chen > Date: Tue, 1 Apr 2025 21:42:21 +0800 > > Recently, I've been setting up a Haskell compilation environment with Emacs on Windows. The project > depends on diagrams-cairo, which depends on GTK+, so I have to build it via msys64 with MINGW. It works > well in a non Emacs environment, so I'd like to adapt it to the Emacs environment. > > Everything is OK, except when I press 'g' in the *compilation* buffer. > > To simplify the problem, below only the minimal test is provided. > > Reproduce steps: > > 1. Create a file test.el in E:/tmp > > 2. Open that file and paste the following code > ``` > (defun my/compile () > (interactive) > (let ((shell-file-name "C:/msys64/usr/bin/bash") > (compilation-environment > "PATH=/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl") > > ) > (compile "ls") > )) > ``` Why cannot your my/compile function do this: (setq-local shell-file-name "C:/msys64/usr/bin/bash") instead of let-binding it? > I have created a patch to workaround the issue. It remembers the original `shell-file-name' in > `compilation-start', so we can use it when we `recompile'. Thanks, but I don't think it's TRT for 'compile' to record the shell by default. In your case, you want to use the same shell each time, but that is not always true. Since you already have a tailored compilation command, I suggest that the same command does this job for you. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 01 11:14:00 2025 Received: (at 77430) by debbugs.gnu.org; 1 Apr 2025 15:14:00 +0000 Received: from localhost ([127.0.0.1]:50115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzdJQ-0005Rz-1m for submit@debbugs.gnu.org; Tue, 01 Apr 2025 11:14:00 -0400 Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]:57366) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tzdJM-0005RE-Rc for 77430@debbugs.gnu.org; Tue, 01 Apr 2025 11:13:57 -0400 Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e60aef2711fso3958465276.2 for <77430@debbugs.gnu.org>; Tue, 01 Apr 2025 08:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743520431; x=1744125231; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rgNeTTZva4doidxyI7KnWIQAldmfra7fJooLY3HaeaI=; b=VSdHf92vfYoEA+mNrLaFdorj5jXhX7MksL51K9oTuxiMXL4CsRdQDlQOtWvxWzf7K7 5JeS6r6gLW3SqAH+0cmFN3ggKQnWw9VTkejxggJRN8DB3WTIIqRTNpiYBPIT7sHDlN/b IZT9Muoj0V1aFMTo9NmY5fD9J+q2VehbDtxZps+LWuBmudtzbuB+pHg3//MD63LCNvGj B5lYvHSr5Sh69+X9TlpuXNhICdesQvWiC98Ny8OVrHY5Cgu2hQrHDLFxbLJIkxdq3uKC Xt3y9FtA4aNOp7p3ogXOS6PFKW6pas+URxN/S2edUVBZ592BM6FU8JdSrA4KKJuYwB4v 7O1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743520431; x=1744125231; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rgNeTTZva4doidxyI7KnWIQAldmfra7fJooLY3HaeaI=; b=tPakzUwnoAz5lllLRjXnss5tk+8CSd5/4IcIz4ZwJy7BOHbYPT9HjJVpgr76ti8iQQ 1IQ3IAD5yDxncgR7FgNlN2s/DYF7LqSXzZf381kYLHG6xCct13NNP9B5JG443/KOXzkD ml3TAlaEg2loXzAUKngc7aTQxW4Rs5Mb26acNxX2Kp5U3kRu5SAMJlRrrjKOFQ6no3+6 eZsLhCaPxbC1I7EyNMPWEfmR50ileaBqD1vTZ6mPLztvxXQuvGKd4BwQpgHJn36iBHd9 wXpaEIA7vBd0jIPPyPKsMbj+lG3zotjujtHv+aqjxeZ1tq8D/PVs3yoIRCvIc1uP9KWx WD4g== X-Gm-Message-State: AOJu0YxKJHw2tOKBQlxEofeL1ZVuSAnc01yiXdmJ1f4LmesXZ9aIzBwP oAqzsYviQG6MVwylErI+65/kZ39KT18SdcqxkIEcs932UMoXtlu2zIHsBX7aCqOQdvMnFJ1A5Lt iv17qk33Be3X8ydHEvXq0M+lzncI= X-Gm-Gg: ASbGnculUGjVkpCldJicneiY+qfxHnWqTkPD2JVG2h4GTpRHzQrMr60/c2KxZU8DTPR 8W8HcVut6Ox+YiSDcCc1ON/M1nRLIvMXblfURDieb/jKBic6S8YWzM/Io9RjADFJ7olyW65865l d450eikCWKXH4iEuH9mseTkubgO6FOmHccrxXoWVbmLqno4Y4jTcNJpdlzxdKD60YndyJj X-Google-Smtp-Source: AGHT+IF1RVh/PSBCMBxWM4EMLfVoPlwaSqKezYRqUd9WgFR9Iz+QW7jBoVHEWn4F8EvEfic6BCMWzlf2ygy8AemYJy8= X-Received: by 2002:a05:6902:2382:b0:e63:4917:f7d5 with SMTP id 3f1490d57ef6-e6b83ad99c4mr16710621276.49.1743520430986; Tue, 01 Apr 2025 08:13:50 -0700 (PDT) MIME-Version: 1.0 References: <868qok2b3m.fsf@gnu.org> In-Reply-To: <868qok2b3m.fsf@gnu.org> From: Siyuan Chen Date: Tue, 1 Apr 2025 23:13:46 +0800 X-Gm-Features: AQ5f1JpXsYLXGtBQ1GophDexShtlyO6Vc1O6lgBnDI969ryax5bHnBp8fxbFWrA Message-ID: Subject: Re: bug#77430: compilation-start should remember shell-file-name To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000f29fc80631b8fb8a" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 77430 Cc: 77430@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000f29fc80631b8fb8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Why cannot your my/compile function do this: > > (setq-local shell-file-name "C:/msys64/usr/bin/bash") > > instead of let-binding it? This is only for the current file buffer. For example, if you focus on a project file buffer (e.g. test.hs) and M-x my/compile, it only sets `shell-file-name' for that file buffer. However, the `compile` actually using the `shell-file-name' belongs to the *compilation* buffer. ``` (defun compilation-start (command &optional mode name-function highlight-regexp continue) ... (with-current-buffer outbuf ; <--- The `outbuf' is the *compilation* buffer ... (comint-exec outbuf (compilation--downcase-mode-name mode-name) shell-file-name ; <--- use the buffer local variable shell-file-name in the *compilation* buffer nil `(,shell-command-switch ,command)) ... ) ... ) ``` So the following code doesn't work: ``` (defun my/compile () (interactive) (let ( (compilation-environment "PATH=3D/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Wi= ndows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:= /usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl") ) (setq-local shell-file-name "C:/msys64/usr/bin/bash") (compile "ls") )) ``` M-x my/compile Compilation exited abnormally. Best regards, Siyuan Chen On Tue, Apr 1, 2025 at 10:46=E2=80=AFPM Eli Zaretskii wrote: > > From: Siyuan Chen > > Date: Tue, 1 Apr 2025 21:42:21 +0800 > > > > Recently, I've been setting up a Haskell compilation environment with > Emacs on Windows. The project > > depends on diagrams-cairo, which depends on GTK+, so I have to build it > via msys64 with MINGW. It works > > well in a non Emacs environment, so I'd like to adapt it to the Emacs > environment. > > > > Everything is OK, except when I press 'g' in the *compilation* buffer. > > > > To simplify the problem, below only the minimal test is provided. > > > > Reproduce steps: > > > > 1. Create a file test.el in E:/tmp > > > > 2. Open that file and paste the following code > > ``` > > (defun my/compile () > > (interactive) > > (let ((shell-file-name "C:/msys64/usr/bin/bash") > > (compilation-environment > > > "PATH=3D/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/= Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0= /:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl") > > > > ) > > (compile "ls") > > )) > > ``` > > Why cannot your my/compile function do this: > > (setq-local shell-file-name "C:/msys64/usr/bin/bash") > > instead of let-binding it? > > > I have created a patch to workaround the issue. It remembers the > original `shell-file-name' in > > `compilation-start', so we can use it when we `recompile'. > > Thanks, but I don't think it's TRT for 'compile' to record the shell > by default. In your case, you want to use the same shell each time, > but that is not always true. Since you already have a tailored > compilation command, I suggest that the same command does this job > for you. > --000000000000f29fc80631b8fb8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 Why cannot your my/compile function do this:
>=C2=A0
>=C2=A0 (setq-local shell-file-name "C:/msys64/usr/bin/bash")<= br> >=C2=A0
> instead of let-binding it?
This is only for the current file buffer.= =C2=A0

For example, if you focus on a project file buf= fer (e.g. test.hs) and M-x my/compile, it only sets `shell-file-name' for that file buffer. However, the `comp= ile` actually using the `shell-file-name' belongs to the *compilation* = buffer.

```
(defun compilation-start (co= mmand &optional mode name-function highlight-regexp
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 continue)
=C2=A0 ...
=C2=A0 (with-cur= rent-buffer outbuf ; <--- The `outbuf' is the *compilation* buffer <= br>=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 (comint-exec
=C2=A0 =C2=A0 =C2=A0o= utbuf (compilation--downcase-mode-name mode-name)
=C2=A0 =C2=A0 =C2=A0sh= ell-file-name ;=20 <--- use the buffer local variable=20 shell-file-name in the *compilation* buffer=20
=C2=A0 =C2=A0 =C2=A0nil `(,shell-command-switch ,command))
=C2=A0 = =C2=A0 ...
=C2=A0 =C2=A0 )
...
)
```

So the f= ollowing code doesn't work:
<= br>
```
(defun m= y/compile ()
=C2=A0 (interactive)
=C2=A0 (let (
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 (compilation-environment "PATH=3D/mingw64/bin:/usr/local/bi= n:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/= Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor= _perl:/usr/bin/core_perl")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 )
=C2=A0 = =C2=A0 (setq-local shell-file-name "C:/msys64/usr/bin/bash")
= =C2=A0 =C2=A0 (compile "ls")
=C2=A0 =C2=A0 ))
```

M-x my/compile

Compilation exited abnormally.

Best regards,
Siyuan Chen

On Tue, Apr 1, 2025 at 10:46=E2=80=AFPM Eli Z= aretskii <eliz@gnu.org> wrote:
> From: Siyuan = Chen <chansey97= @gmail.com>
> Date: Tue, 1 Apr 2025 21:42:21 +0800
>
> Recently, I've been setting up a Haskell compilation environment w= ith Emacs on Windows. The project
> depends on diagrams-cairo, which depends on GTK+, so I have to build i= t via msys64 with MINGW. It works
> well in a non Emacs environment, so I'd like to adapt it to the Em= acs environment.
>
> Everything is OK, except when I press 'g' in the *compilation*= buffer.
>
> To simplify the problem, below only the minimal test is provided.
>
> Reproduce steps:
>
> 1. Create a file test.el in E:/tmp
>
> 2. Open that file and paste the following code
> ```
> (defun my/compile ()
>=C2=A0 =C2=A0(interactive)
>=C2=A0 =C2=A0(let ((shell-file-name "C:/msys64/usr/bin/bash")=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(compilation-environment
> "PATH=3D/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/Syst= em32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerSh= ell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl")=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0)
>=C2=A0 =C2=A0 =C2=A0(compile "ls")
>=C2=A0 =C2=A0 =C2=A0))
> ```

Why cannot your my/compile function do this:

=C2=A0 (setq-local shell-file-name "C:/msys64/usr/bin/bash")

instead of let-binding it?

> I have created a patch to workaround the issue. It remembers the origi= nal `shell-file-name' in
> `compilation-start', so we can use it when we `recompile'.

Thanks, but I don't think it's TRT for 'compile' to record = the shell
by default.=C2=A0 In your case, you want to use the same shell each time, but that is not always true.=C2=A0 Since you already have a tailored
compilation command, I suggest that the same command does this job
for you.
--000000000000f29fc80631b8fb8a-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 01 11:50:58 2025 Received: (at 77430) by debbugs.gnu.org; 1 Apr 2025 15:50:58 +0000 Received: from localhost ([127.0.0.1]:50357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzdtB-0001jZ-OK for submit@debbugs.gnu.org; Tue, 01 Apr 2025 11:50:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53816) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzdt9-0001ie-P8 for 77430@debbugs.gnu.org; Tue, 01 Apr 2025 11:50:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tzdsz-0001gi-SW; Tue, 01 Apr 2025 11:50:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3KgI5BXwTCaZ4ogewKaAyaMX1bakOqMQn/7jAGvTO0Q=; b=qol3bPY00FaC aVodk+XqAn/bVzoKO0EMKM6InaUrtKGQzSstfa0wIyRxfgafjJy07ssyb6Dc6VYGG4gg/rA2Xmejl eRl6nEkYhVzJ3oBd1sc/Oc3brExJ4/JO6WbQMtynlHko7gqSyUjmsA7Qj5hpeovS0kYuC5jR8QfV/ khY0KuEyBiqbg5dEwpxazvWo+NqtQKX9DDaldl/tTGb+oRg8EuUqwto9E+2ATj7mk4Ci8cyN2nH0G +MFtZeLSxeXgyrmzfJuHpWvRYFLgS8l5jk0k5ZCGhA+cGGRgrYHw8uvN7opO6zbBNfhteRNouqeYK igGngTrm4H9NwLFKjiYWnw==; Date: Tue, 01 Apr 2025 18:50:36 +0300 Message-Id: <864iz73mpf.fsf@gnu.org> From: Eli Zaretskii To: Siyuan Chen In-Reply-To: (message from Siyuan Chen on Tue, 1 Apr 2025 23:13:46 +0800) Subject: Re: bug#77430: compilation-start should remember shell-file-name References: <868qok2b3m.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77430 Cc: 77430@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Siyuan Chen > Date: Tue, 1 Apr 2025 23:13:46 +0800 > Cc: 77430@debbugs.gnu.org > > > Why cannot your my/compile function do this: > > > > (setq-local shell-file-name "C:/msys64/usr/bin/bash") > > > > instead of let-binding it? > > This is only for the current file buffer. > > For example, if you focus on a project file buffer (e.g. test.hs) and M-x my/compile, it only sets > `shell-file-name' for that file buffer. However, the `compile` actually using the `shell-file-name' belongs to the > *compilation* buffer. > > ``` > (defun compilation-start (command &optional mode name-function highlight-regexp > continue) > ... > (with-current-buffer outbuf ; <--- The `outbuf' is the *compilation* buffer > ... > (comint-exec > outbuf (compilation--downcase-mode-name mode-name) > shell-file-name ; <--- use the buffer local variable shell-file-name in the *compilation* buffer > nil `(,shell-command-switch ,command)) > ... > ) > ... > ) > ``` > > So the following code doesn't work: > > ``` > (defun my/compile () > (interactive) > (let ( > (compilation-environment > "PATH=/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl") > > ) > (setq-local shell-file-name "C:/msys64/usr/bin/bash") > (compile "ls") > )) > ``` > > M-x my/compile > > Compilation exited abnormally. Sorry, I don't understand: are you saying that you cannot arrange for the buffer-local value of shell-file-name to point to Bash and stay that way for the subsequent commands? If you need to use with-current-buffer or something similar, it should be easy no? Or what am I missing? From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 01 11:57:18 2025 Received: (at 77430) by debbugs.gnu.org; 1 Apr 2025 15:57:18 +0000 Received: from localhost ([127.0.0.1]:50396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzdzK-0002Ve-0v for submit@debbugs.gnu.org; Tue, 01 Apr 2025 11:57:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32994) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzdzI-0002V9-3m for 77430@debbugs.gnu.org; Tue, 01 Apr 2025 11:57:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tzdzB-0003IT-BI; Tue, 01 Apr 2025 11:57:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=68bcHvVlYI+KZ8K7CeSZhkdaPt6VB0tCPwW1c8Do8J0=; b=ptA4q8SKs6tZ 8OlIuyRitDjLiviw+8M5+oajCVqLfKyxPKjFsiivPgIToZ4NlBMHTcVh45IEcn0cLfL44jb6EmPhg FuZ8288FvpF9+y8Pnk2QjhOfyW52XIAmsERDuaxXIwod5ngs27dfHfSffaTTRam03QONt6TCjlTtL sz/401uckMAamZGd+H5otsC/Kgolv30okOiP5b+SlXGZ/trHhB2NbC5yFkM2GmOjBeJnVuOzCh1T0 s4GEJcR1ItmwP1e4hSwFHOX2YO66NyrJXoZxiueXAWNstAKTkzncWLFAGW4ADbKFrtI3ctNxp0VII Ll8dusgLf8fZf7jl2WPHPg==; Date: Tue, 01 Apr 2025 18:57:06 +0300 Message-Id: <8634er3mel.fsf@gnu.org> From: Eli Zaretskii To: chansey97@gmail.com In-Reply-To: <864iz73mpf.fsf@gnu.org> (message from Eli Zaretskii on Tue, 01 Apr 2025 18:50:36 +0300) Subject: Re: bug#77430: compilation-start should remember shell-file-name References: <868qok2b3m.fsf@gnu.org> <864iz73mpf.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77430 Cc: 77430@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 77430@debbugs.gnu.org > Date: Tue, 01 Apr 2025 18:50:36 +0300 > From: Eli Zaretskii > > > From: Siyuan Chen > > Date: Tue, 1 Apr 2025 23:13:46 +0800 > > Cc: 77430@debbugs.gnu.org > > > > > Why cannot your my/compile function do this: > > > > > > (setq-local shell-file-name "C:/msys64/usr/bin/bash") > > > > > > instead of let-binding it? > > > > This is only for the current file buffer. > > > > For example, if you focus on a project file buffer (e.g. test.hs) and M-x my/compile, it only sets > > `shell-file-name' for that file buffer. However, the `compile` actually using the `shell-file-name' belongs to the > > *compilation* buffer. > > > > ``` > > (defun compilation-start (command &optional mode name-function highlight-regexp > > continue) > > ... > > (with-current-buffer outbuf ; <--- The `outbuf' is the *compilation* buffer > > ... > > (comint-exec > > outbuf (compilation--downcase-mode-name mode-name) > > shell-file-name ; <--- use the buffer local variable shell-file-name in the *compilation* buffer > > nil `(,shell-command-switch ,command)) > > ... > > ) > > ... > > ) > > ``` > > > > So the following code doesn't work: > > > > ``` > > (defun my/compile () > > (interactive) > > (let ( > > (compilation-environment > > "PATH=/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl") > > > > ) > > (setq-local shell-file-name "C:/msys64/usr/bin/bash") > > (compile "ls") > > )) > > ``` > > > > M-x my/compile > > > > Compilation exited abnormally. > > Sorry, I don't understand: are you saying that you cannot arrange for > the buffer-local value of shell-file-name to point to Bash and stay > that way for the subsequent commands? If you need to use > with-current-buffer or something similar, it should be easy no? Alternatively, how about making a Windows batch file, which would invoke the compilation command via Bash. So you compile command would look like this: M-x compile RET mycomp ls RET where mycomp.bat is a batch file which does @echo off C:\msys64\usr\bin\bash --login -c %* I think this is the cleanest solution for problems like this on Windows, since you don't really want to override shell-file-name, you just want to invoke the commands via Bash. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 04 04:15:08 2025 Received: (at 77430) by debbugs.gnu.org; 4 Apr 2025 08:15:08 +0000 Received: from localhost ([127.0.0.1]:36994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u0cCg-0004xY-Us for submit@debbugs.gnu.org; Fri, 04 Apr 2025 04:15:08 -0400 Received: from mail-yb1-xb36.google.com ([2607:f8b0:4864:20::b36]:50610) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u0cCc-0004ua-8n for 77430@debbugs.gnu.org; Fri, 04 Apr 2025 04:15:03 -0400 Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e643f235a34so1351383276.1 for <77430@debbugs.gnu.org>; Fri, 04 Apr 2025 01:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743754496; x=1744359296; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9Ho60Muh86pOu6aARhmaV5+Z2xXtI4aGOXQp6IHzXwU=; b=kIDYr7f9aEtSwxFAqKPVbDt3pIdm8yC35vcN5amCofdbSdoLXsQAKS8+IbC3NoOUka xPiVMr4ZTRcptEqy658ZFvkBWrgehnL7x9W1GLegfT/Co9UuUa6sVInwUFGkyrdne8B4 XTsYvmaeZRjZBMSMphYkvpbkekpHTh8HsK1QKzhqjVJI3QlnvgCufhKUZAuLyzZn55PT Rf6JP+2GUqCIHKPHOn8kp058ZwPhph4p7+8B9ZMQ4n8tOjcG5QljN86KbTiMM6W9kIbR 1ITztgGjWk8ViZzj3FJm+cRZVE4wScCPR6e5HDPtvDDBtymBvqHFr2hL8HO7+EGaVFqm cMfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743754496; x=1744359296; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9Ho60Muh86pOu6aARhmaV5+Z2xXtI4aGOXQp6IHzXwU=; b=uDMLYpjU/JhbuSL0GwBsDPuGFIxzE6Ke3DkxWeUMy/R2aT+6t1QxZmrQCZx6xyuc0s /KCh6SVty7RWxLHGH0n8rOiCC/1142t8igvgPqT31VvjBeIyRbCTOcl0oSSdxpOSX2B1 KLvH+Wes76z68bKUckWsgWjhCd5c2iz4aVqpmSE4Q756Id4DpbLhgXjbj3GFUl7rtRQn RG0lGSLpHIRhVr1s8Tm3diVmMcUri0Wc0nRZ7wT2D11Cl38rbwGIVHXI3A5sjiRekGfi Qp/VLuaINoudN0L6J/pxS+TFlfjtPQjnBOiDjvfhxr1eldxKwZluQr45nSZXyB3Gv/gk hw7A== X-Gm-Message-State: AOJu0Yw24zspL0/D/OgZr6yIoW6PqAVBJKQ4s8Tn7IvtN+IrKDoxdBGD Dfcffwl0GdANKvde+aP5MXbw8N0CV+AjXOy0aWK/ml0S9qTveScvP06uEe0+p3xCTKDNdtQ2qso w/pDGSJ+IbCP2VM/m46L2Ox5w/if68Vii X-Gm-Gg: ASbGnct520itNkMtqVhO4LGOe4p3RJewV2zwkVP+roN72+fsxeXGpbvZqENb+eLSTxF p1rkisc5StrEmiFOkWcovOxH0jY6fI7+BnfYrurbz7Z0SGH6aXr93iCnCuFlF/neyGV5NA9tCMt J/Flx1utu4IPWUkZ55nJiQx4vkR3jtWOaWn0HKRMXc/xaCTXXrRN/oL+t80Dopiv8qF3N3 X-Google-Smtp-Source: AGHT+IEpbIdCPIbTi/wBNiwtjQnskUBu+CwJU9ALVCGOcAEuhhTzedGjTBRpC+kECpb19TchxtnhuMqkE2vZKWEPYL8= X-Received: by 2002:a25:b1a7:0:b0:e6e:84a:e7e5 with SMTP id 3f1490d57ef6-e6e1c1a7467mr3446711276.7.1743754496328; Fri, 04 Apr 2025 01:14:56 -0700 (PDT) MIME-Version: 1.0 References: <868qok2b3m.fsf@gnu.org> <864iz73mpf.fsf@gnu.org> <8634er3mel.fsf@gnu.org> In-Reply-To: <8634er3mel.fsf@gnu.org> From: Siyuan Chen Date: Fri, 4 Apr 2025 16:15:06 +0800 X-Gm-Features: AQ5f1JpRINn1agY1AJfl9-S7Qh3DuzxGo_O8OSX5a6ybbuM-GEvg6QYUdR0fbYM Message-ID: Subject: Re: bug#77430: compilation-start should remember shell-file-name To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000544d4a0631ef7b6a" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 77430 Cc: 77430@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000544d4a0631ef7b6a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Sorry, I don't understand: are you saying that you cannot arrange for the buffer-local value of shell-file-name to point to Bash and stay that way for the subsequent commands? If you need to use with-current-buffer or something similar, it should be easy no? The original problem is not about `compile' but `recompile', i.e. press 'g' in the *compilation* buffer. The *compilation* buffer doesn't know anything about the last shell-file-name, so it uses cmdproxy by default. Anyway, this is no longer a problem now, see below. > I think this is the cleanest solution for problems like this on Windows, since you don't really want to override shell-file-name, you just want to invoke the commands via Bash. Your method really inspired me. Thank you so much! Based on it, I've redesigned my compilation workflow. Basically, whenever users invoke `sc-haskell-projectile-stack-compile' (a tailored compile command integrated with projectile), it firstly generates two files in the Haskell project folder: .emacs_stack_launch.bat ``` set MSYSTEM=3DMINGW32 "c:/Users/Chansey/AppData/Local/Programs/stack/x86_64-windows/msys2-2023052= 6/usr/bin/bash" --login "e:/my-haskell-project/.emacs_stack_launch_script.sh" %* ``` .emacs_stack_launch_script.sh ``` export STACK_ROOT=3D/c/sr export PATH=3D/c/env/haskell/stack/v2.15.1:/c/Users/Chansey/AppData/Roaming/local/= bin:/c/PROGRA~1/Git/cmd:$PATH $* ``` then it calls (compile ".emacs_stack_launch.bat stack build"). This method is working great so far. Plus, the file generation brings several benefits: 1. We can set local variables in .dir-locals (e.g. msys2-path, environment-variables) per project for fine-grained control over compilation. 2. No need to tailored `recompile'. It just uses the last generated files. So it works pretty well when users press 'g' in the *compilation* buffer. 3. Support all the compile commands and opts, like stack build, stack run, stack build --test, etc. 4. Easy debugging with .emacs_stack_launch.bat and .emacs_stack_launch_script.sh. The code is something like this: ``` (defun sc-haskell-projectile-stack--run-project-cmd (command) (let* ((default-directory (projectile-compilation-dir)) (command (projectile-read-command "Compile command: " (or projectile-project-compilation-cmd command)))) (sc-haskell-projectile-stack--gen-launch-file) (sc-haskell-projectile-stack--gen-launch-script-file) (compile (format "%s %s" ".emacs_stack_launch.bat" command) projectile-compile-use-comint-mode))) (defun sc-haskell-projectile-stack-compile () (sc-haskell-projectile-stack--run-project-cmd "stack build")) (defun sc-haskell-projectile-stack-test () (sc-haskell-projectile-stack--run-project-cmd "stack build --test")) (defun sc-haskell-projectile-stack-run () (sc-haskell-projectile-stack--run-project-cmd "stack run")) ``` Additionally, I also created a projectile-based shell command, which has to be different from projectile-based compile command. ``` (defun sc-haskell-projectile-stack-shell () (interactive) (let ((current-prefix-arg 4) (explicit-shell-file-name (expand-file-name "usr/bin/bash" sc-haskell-projectile-stack-msys2-path)) (explicit-bash-args '("--login" "--noediting" "-i"))) (sc-haskell-projectile-stack--gen-msys2-bashrc-init-file) (with-environment-variables (("MSYSTEM" "MINGW32")) (call-interactively 'projectile-run-shell)))) ``` Unlike the previous method, this one still rebinds explicit-shell-file-name, otherwise we have to call "bash --login --noediting -i" in the .emacs_stack_launch_script.sh, which would invoke bash twice =E2=80=94 something I'd rather avoid (it still can work though). My solution is to add a hook in .bashrc ``` if [ -f $HOME/.bashrc_init.sh ]; then . $HOME/.bashrc_init.sh rm $HOME/.bashrc_init.sh fi ``` Basically, whenever users invoke `sc-haskell-projectile-stack-shell, it generates .bashrc_init.sh in the msys2 home USER folder. The commands in .bashrc_init.sh are similar to those in emacs_stack_launch_script and can, of course, be configured via .dir-locals.el. It might seem a bit unusual, but it works well so far. Just like to share my current design here =E2=80=94 any suggestions would b= e greatly appreciated. Thank you! On Tue, Apr 1, 2025 at 11:57=E2=80=AFPM Eli Zaretskii wrote: > > Cc: 77430@debbugs.gnu.org > > Date: Tue, 01 Apr 2025 18:50:36 +0300 > > From: Eli Zaretskii > > > > > From: Siyuan Chen > > > Date: Tue, 1 Apr 2025 23:13:46 +0800 > > > Cc: 77430@debbugs.gnu.org > > > > > > > Why cannot your my/compile function do this: > > > > > > > > (setq-local shell-file-name "C:/msys64/usr/bin/bash") > > > > > > > > instead of let-binding it? > > > > > > This is only for the current file buffer. > > > > > > For example, if you focus on a project file buffer (e.g. test.hs) and > M-x my/compile, it only sets > > > `shell-file-name' for that file buffer. However, the `compile` > actually using the `shell-file-name' belongs to the > > > *compilation* buffer. > > > > > > ``` > > > (defun compilation-start (command &optional mode name-function > highlight-regexp > > > continue) > > > ... > > > (with-current-buffer outbuf ; <--- The `outbuf' is the *compilation= * > buffer > > > ... > > > (comint-exec > > > outbuf (compilation--downcase-mode-name mode-name) > > > shell-file-name ; <--- use the buffer local variable > shell-file-name in the *compilation* buffer > > > nil `(,shell-command-switch ,command)) > > > ... > > > ) > > > ... > > > ) > > > ``` > > > > > > So the following code doesn't work: > > > > > > ``` > > > (defun my/compile () > > > (interactive) > > > (let ( > > > (compilation-environment > > > > "PATH=3D/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/= Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0= /:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl") > > > > > > ) > > > (setq-local shell-file-name "C:/msys64/usr/bin/bash") > > > (compile "ls") > > > )) > > > ``` > > > > > > M-x my/compile > > > > > > Compilation exited abnormally. > > > > Sorry, I don't understand: are you saying that you cannot arrange for > > the buffer-local value of shell-file-name to point to Bash and stay > > that way for the subsequent commands? If you need to use > > with-current-buffer or something similar, it should be easy no? > > Alternatively, how about making a Windows batch file, which would > invoke the compilation command via Bash. So you compile command would > look like this: > > M-x compile RET mycomp ls RET > > where mycomp.bat is a batch file which does > > @echo off > C:\msys64\usr\bin\bash --login -c %* > > I think this is the cleanest solution for problems like this on > Windows, since you don't really want to override shell-file-name, you > just want to invoke the commands via Bash. > --000000000000544d4a0631ef7b6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Sorry, I don't understand: are you saying that yo= u cannot arrange for
the buffer-local value of shell-file-name to point = to Bash and stay
that way for the subsequent commands?=C2=A0 If you need= to use
with-current-buffer or something similar, it should be easy no?<= br>
The original problem is not about `compile' but `recompile',= i.e. press 'g' in the *compilation* buffer. The *compilation* buff= er doesn't know anything about the last shell-file-name, so it uses cmd= proxy by default.

Anyway, this is no longer a problem now, see belo= w.

> I think this is the cleanest solution for problems like this= on
Windows, since you don't really want to override shell-file-name= , you
just want to invoke the commands via Bash.

Your method real= ly inspired me.=20 Thank you so much!=20

Based on it, I've redesigned my compilation workflow. Basically= , whenever users invoke `sc-haskell-projectile-stack-compile' (a tailor= ed compile command integrated with projectile), it firstly generates two fi= les in the Haskell project folder:

.emacs_stack_launch.bat
```set MSYSTEM=3DMINGW32
"c:/Users/Chansey/AppData/Local/Programs/st= ack/x86_64-windows/msys2-20230526/usr/bin/bash" --login "e:/my-ha= skell-project/.emacs_stack_launch_script.sh" %*
```

.emacs_s= tack_launch_script.sh
```
export STACK_ROOT=3D/c/sr
export PATH=3D= /c/env/haskell/stack/v2.15.1:/c/Users/Chansey/AppData/Roaming/local/bin:/c/= PROGRA~1/Git/cmd:$PATH
$*
```

then it calls (compile ".em= acs_stack_launch.bat stack build").

This method is working grea= t so far. Plus, the file generation brings several benefits:

1. We c= an set local variables in .dir-locals (e.g. msys2-path,=C2=A0environment-va= riables) per project for fine-grained control over compilation.

2. N= o need to tailored `recompile'. It just uses the last generated files. = So it works pretty well when users press 'g' in the *compilation* b= uffer.

3. Support all the compile commands and opts, like stack= build, stack run, stack build --test, etc.

4. Eas= y debugging with=20 .emacs_stack_launch.bat and=20 .emacs_stack_launch_script.sh.

The code is something like this:

```
(defun sc-haskell-= projectile-stack--run-project-cmd (command)
=C2=A0 (let* ((default-direc= tory (projectile-compilation-dir))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(co= mmand (projectile-read-command
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0"Compile command: "
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or projectile-proje= ct-compilation-cmd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0command))))
=C2=A0 =C2=A0 (sc-haskell-pro= jectile-stack--gen-launch-file)
=C2=A0 =C2=A0 (sc-haskell-projectile-sta= ck--gen-launch-script-file)
=C2=A0 =C2=A0 (compile (format "%s %s&q= uot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0".emacs_stack_launch.bat"
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0command)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0projectile-compile-use-comint-mode)))=

(defun sc-haskell-projectile-stack-compile ()
=C2=A0 (sc-haskell= -projectile-stack--run-project-cmd "stack build"))

(defun = sc-haskell-projectile-stack-test ()
=C2=A0 (sc-haskell-projectile-stack-= -run-project-cmd "stack build --test"))

(defun sc-haskell-= projectile-stack-run ()
=C2=A0 (sc-haskell-projectile-stack--run-project= -cmd "stack run"))
```

Additionally, I also created a p= rojectile-based shell command, which has to be different from=20 projectile-based compile=20 command.

```
(defun sc-haskell-projectile-stack-shell ()
=C2= =A0 (interactive)
=C2=A0 (let ((current-prefix-arg 4)
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 (explicit-shell-file-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(expand-file-name "usr/bin/bash" sc-haskell-projectile-stack-m= sys2-path))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (explicit-bash-args
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0'("--login" "--noediting"= ; "-i")))
=C2=A0 =C2=A0 (sc-haskell-projectile-stack--gen-msys= 2-bashrc-init-file)
=C2=A0 =C2=A0 (with-environment-variables (("MS= YSTEM" "MINGW32"))
=C2=A0 =C2=A0 =C2=A0 (call-interactive= ly 'projectile-run-shell))))
```

Unlike the previous method, = this one still rebinds explicit-shell-file-name, otherwise we have to call = "bash --login --noediting -i" in the .emacs_stack_launch_script.s= h, which would invoke bash twice =E2=80=94 something I'd rather avoid (= it still=20 can=20 work though).

My solution is to add a hook in .bashrc

```
= if [ -f $HOME/.bashrc_init.sh ]; then
=C2=A0 =C2=A0 . $HOME/.bashrc_init= .sh
=C2=A0 =C2=A0 rm $HOME/.bashrc_init.sh
fi
```

Basically= , whenever users invoke `sc-haskell-projectile-stack-shell, it generates .b= ashrc_init.sh in the msys2 home USER folder. The commands in .bashrc_init.s= h are similar to those in emacs_stack_launch_script and can, of course, be = configured via .dir-locals.el. It might seem a bit unusual, but it works we= ll so far.

Just like to share my current design here =E2=80=94 any = suggestions would be greatly appreciated.

Thank you!

On Tue, Apr 1, 2025 at 11:57=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> Cc: 77430@debbugs.gnu.org
> Date: Tue, 01 Apr 2025 18:50:36 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Siyuan Chen <chansey97@gmail.com>
> > Date: Tue, 1 Apr 2025 23:13:46 +0800
> > Cc: 77= 430@debbugs.gnu.org
> >
> > >=C2=A0 Why cannot your my/compile function do this:
> > >=C2=A0
> > >=C2=A0 (setq-local shell-file-name "C:/msys64/usr/bin/ba= sh")
> > >=C2=A0
> > > instead of let-binding it?
> >
> > This is only for the current file buffer.
> >
> > For example, if you focus on a project file buffer (e.g. test.hs)= and M-x my/compile, it only sets
> > `shell-file-name' for that file buffer. However, the `compile= ` actually using the `shell-file-name' belongs to the
> > *compilation* buffer.
> >
> > ```
> > (defun compilation-start (command &optional mode name-functio= n highlight-regexp
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continue)
> >=C2=A0 =C2=A0...
> >=C2=A0 =C2=A0(with-current-buffer outbuf ; <--- The `outbuf'= ; is the *compilation* buffer
> >=C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0 =C2=A0(comint-exec
> >=C2=A0 =C2=A0 =C2=A0 outbuf (compilation--downcase-mode-name mode-= name)
> >=C2=A0 =C2=A0 =C2=A0 shell-file-name ; <--- use the buffer loca= l variable shell-file-name in the *compilation* buffer
> >=C2=A0 =C2=A0 =C2=A0 nil `(,shell-command-switch ,command))
> >=C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0 =C2=A0)
> > ...
> > )
> > ```
> >
> > So the following code doesn't work:
> >
> > ```
> > (defun my/compile ()
> >=C2=A0 =C2=A0(interactive)
> >=C2=A0 =C2=A0(let (
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(compilation-environment
> > "PATH=3D/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows= /System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPo= werShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl&q= uot;)
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0)
> >=C2=A0 =C2=A0 =C2=A0(setq-local shell-file-name "C:/msys64/us= r/bin/bash")
> >=C2=A0 =C2=A0 =C2=A0(compile "ls")
> >=C2=A0 =C2=A0 =C2=A0))
> > ```
> >
> > M-x my/compile
> >
> > Compilation exited abnormally.
>
> Sorry, I don't understand: are you saying that you cannot arrange = for
> the buffer-local value of shell-file-name to point to Bash and stay > that way for the subsequent commands?=C2=A0 If you need to use
> with-current-buffer or something similar, it should be easy no?

Alternatively, how about making a Windows batch file, which would
invoke the compilation command via Bash.=C2=A0 So you compile command would=
look like this:

=C2=A0 M-x compile RET mycomp ls RET

where mycomp.bat is a batch file which does

=C2=A0 @echo off
=C2=A0 C:\msys64\usr\bin\bash --login -c %*

I think this is the cleanest solution for problems like this on
Windows, since you don't really want to override shell-file-name, you just want to invoke the commands via Bash.
--000000000000544d4a0631ef7b6a-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 19 09:49:14 2025 Received: (at 77430-done) by debbugs.gnu.org; 19 Apr 2025 13:49:14 +0000 Received: from localhost ([127.0.0.1]:60372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u68ZF-00050v-Ir for submit@debbugs.gnu.org; Sat, 19 Apr 2025 09:49:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43486) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u68Z9-00050T-Cj for 77430-done@debbugs.gnu.org; Sat, 19 Apr 2025 09:49:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u68Z3-0001K3-LU; Sat, 19 Apr 2025 09:49:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=PYtTSFUEHo4sX2+4dh05afUCkMiaOG8f/+hPHgFovUs=; b=OnOaowxQGnjA/u6K2BVK KtWSGWbSAm8gu/M2UMB76J6R423hSHf8C6Pu0+C/24YP3z7T8mGnqgLU/S+esePZBnErDyzOrj9/2 jWFB7DKAu9zEgqova9q82U1bm3xC/JbqWRBREmSh0wh3dz+8Ndz5axs7gwUbEWXIXkCsf95HFQ5BX uUGD20mrj9xBUdoWBPmwI50rT4BPoMgBWuT6jHjTPVElvsDKLK8bneO07QRlRtUvSPCNce1X5xIBP WfYxLppDI7CcDSjD4aeRlfzS3IxbbV6o3+HBgIlpsIG0lv2eQIQ1mWo8eV+s5VJvFls/8I96BqLkg MIwUVRrgLBSwTQ==; Date: Sat, 19 Apr 2025 16:48:57 +0300 Message-Id: <86ecxo8do6.fsf@gnu.org> From: Eli Zaretskii To: Siyuan Chen In-Reply-To: (message from Siyuan Chen on Fri, 4 Apr 2025 16:15:06 +0800) Subject: Re: bug#77430: compilation-start should remember shell-file-name References: <868qok2b3m.fsf@gnu.org> <864iz73mpf.fsf@gnu.org> <8634er3mel.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77430-done Cc: 77430-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Siyuan Chen > Date: Fri, 4 Apr 2025 16:15:06 +0800 > Cc: 77430@debbugs.gnu.org > > > Sorry, I don't understand: are you saying that you cannot arrange for > the buffer-local value of shell-file-name to point to Bash and stay > that way for the subsequent commands? If you need to use > with-current-buffer or something similar, it should be easy no? > > The original problem is not about `compile' but `recompile', i.e. press 'g' in the *compilation* buffer. The > *compilation* buffer doesn't know anything about the last shell-file-name, so it uses cmdproxy by default. > > Anyway, this is no longer a problem now, see below. > > > I think this is the cleanest solution for problems like this on > Windows, since you don't really want to override shell-file-name, you > just want to invoke the commands via Bash. > > Your method really inspired me. Thank you so much! > > Based on it, I've redesigned my compilation workflow. Basically, whenever users invoke > `sc-haskell-projectile-stack-compile' (a tailored compile command integrated with projectile), it firstly > generates two files in the Haskell project folder: > > .emacs_stack_launch.bat > ``` > set MSYSTEM=MINGW32 > "c:/Users/Chansey/AppData/Local/Programs/stack/x86_64-windows/msys2-20230526/usr/bin/bash" --login > "e:/my-haskell-project/.emacs_stack_launch_script.sh" %* > ``` > > .emacs_stack_launch_script.sh > ``` > export STACK_ROOT=/c/sr > export > PATH=/c/env/haskell/stack/v2.15.1:/c/Users/Chansey/AppData/Roaming/local/bin:/c/PROGRA~1/Git/cmd:$PATH > > $* > ``` > > then it calls (compile ".emacs_stack_launch.bat stack build"). > > This method is working great so far. Plus, the file generation brings several benefits: > > 1. We can set local variables in .dir-locals (e.g. msys2-path, environment-variables) per project for > fine-grained control over compilation. > > 2. No need to tailored `recompile'. It just uses the last generated files. So it works pretty well when users > press 'g' in the *compilation* buffer. > > 3. Support all the compile commands and opts, like stack build, stack run, stack build --test, etc. > > 4. Easy debugging with .emacs_stack_launch.bat and .emacs_stack_launch_script.sh. > > The code is something like this: > > ``` > (defun sc-haskell-projectile-stack--run-project-cmd (command) > (let* ((default-directory (projectile-compilation-dir)) > (command (projectile-read-command > "Compile command: " > (or projectile-project-compilation-cmd > command)))) > (sc-haskell-projectile-stack--gen-launch-file) > (sc-haskell-projectile-stack--gen-launch-script-file) > (compile (format "%s %s" > ".emacs_stack_launch.bat" > command) > projectile-compile-use-comint-mode))) > > (defun sc-haskell-projectile-stack-compile () > (sc-haskell-projectile-stack--run-project-cmd "stack build")) > > (defun sc-haskell-projectile-stack-test () > (sc-haskell-projectile-stack--run-project-cmd "stack build --test")) > > (defun sc-haskell-projectile-stack-run () > (sc-haskell-projectile-stack--run-project-cmd "stack run")) > ``` > > Additionally, I also created a projectile-based shell command, which has to be different from projectile-based > compile command. > > ``` > (defun sc-haskell-projectile-stack-shell () > (interactive) > (let ((current-prefix-arg 4) > (explicit-shell-file-name > (expand-file-name "usr/bin/bash" sc-haskell-projectile-stack-msys2-path)) > (explicit-bash-args > '("--login" "--noediting" "-i"))) > (sc-haskell-projectile-stack--gen-msys2-bashrc-init-file) > (with-environment-variables (("MSYSTEM" "MINGW32")) > (call-interactively 'projectile-run-shell)))) > ``` > > Unlike the previous method, this one still rebinds explicit-shell-file-name, otherwise we have to call "bash - > -login --noediting -i" in the .emacs_stack_launch_script.sh, which would invoke bash twice — something I'd > rather avoid (it still can work though). > > My solution is to add a hook in .bashrc > > ``` > if [ -f $HOME/.bashrc_init.sh ]; then > . $HOME/.bashrc_init.sh > rm $HOME/.bashrc_init.sh > fi > ``` > > Basically, whenever users invoke `sc-haskell-projectile-stack-shell, it generates .bashrc_init.sh in the msys2 > home USER folder. The commands in .bashrc_init.sh are similar to those in emacs_stack_launch_script and > can, of course, be configured via .dir-locals.el. It might seem a bit unusual, but it works well so far. > > Just like to share my current design here — any suggestions would be greatly appreciated. Thanks. I guess we can close this bug now. From unknown Sat Jun 21 05:00:05 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 18 May 2025 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator