emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45765: closed ([PATCH] 28.0.50; Change default-directory before prom


From: GNU bug Tracking System
Subject: bug#45765: closed ([PATCH] 28.0.50; Change default-directory before prompting in project-compile)
Date: Sat, 16 Jan 2021 03:52:01 +0000

Your message dated Sat, 16 Jan 2021 05:51:47 +0200
with message-id <5ad49c92-6a29-ff7f-6b2a-2c3e5505334d@yandex.ru>
and subject line Re: bug#45765: [PATCH] 28.0.50; Change default-directory 
before prompting in project-compile
has caused the debbugs.gnu.org bug report #45765,
regarding [PATCH] 28.0.50; Change default-directory before prompting in 
project-compile
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
45765: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45765
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: [PATCH] 28.0.50; Change default-directory before prompting in project-compile Date: Sun, 10 Jan 2021 13:57:07 +0100
Hello,

Unlike project-shell-command, project-compile first prompts for a
command, then binds default-directory and calls compile.  Binding
default-directory first makes completion work from the project root,
which is useful for completing on filenames relative to the root, on
targets from the toplevel Makefile, etc.

I see three ways to achieve this:

(1) Rewrite project-compile with call-interactively, the way
project-shell-command is written (see patch #1).

(2) Set COMMAND to nil in the interactive spec, then prompt for it after
binding default-directory (see patch #2).

(3) Let-binding default-directory once in the interactive spec, and
again before calling compile.


I'm assuming (1) is out of the question, given 2020-06-02
"* lisp/progmodes/project.el (project-vc-dir, project-shell): New
commands." (2c1e5b9e77).  I'm CC'ing Juri to get his opinion though;
project-compile is new in Emacs 28.1, so its argument list is not yet
set in stone.

I've taken a stab at (2), but my patch changes the semantics of COMMAND
for an edge case: for now calling (project-compile nil) from Lisp causes
(compile nil) to be called (which errors out); with my patch,
(project-compile nil) yields a prompt.

This can be solved using called-interactively-p (or using an optional
INTERACTIVE argument); I just don't know if it's worth the hassle?

I haven't given much thought to (3), so I haven't yet figured out how to
avoid prompting twice for the project (on the rare occasions where
prompting is needed).


Thanks for your time.


Attachment: 0001-Change-default-directory-before-prompting-in-project-1.patch
Description: Text Data

Attachment: 0001-Change-default-directory-before-prompting-in-project-2.patch
Description: Text Data


In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo 
version 1.16.0)
 of 2021-01-04 built on my-little-tumbleweed
Repository revision: 2c847902522ae74c9b25b2a3fa60565e0187fd0a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: openSUSE Tumbleweed

Configured using:
 'configure --with-xwidgets --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS JSON
PDUMPER LCMS2

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

--- End Message ---
--- Begin Message --- Subject: Re: bug#45765: [PATCH] 28.0.50; Change default-directory before prompting in project-compile Date: Sat, 16 Jan 2021 05:51:47 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
On 13.01.2021 21:46, Kévin Le Gouguec wrote:
Dmitry Gutov <dgutov@yandex.ru> writes:

I'm not a big fan of the 'interactive' argument. It could be replaced
by using (called-interactively-p 'interactive), though I'm not sure
how idiomatic that is.

Not necessarily a fan either, but my takeaway from recent discussions on
emacs-devel is that the argument is preferred to called-interactively-p,
which should only be used when a function's arglist is set in stone.

<E1k7A3J-0005gG-4K@fencepost.gnu.org>
https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg00463.html

<jwvzh6ubtbe.fsf-monnier+emacs@gnu.org>
https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg00472.html

I see a few dozen hits for "&optional \([\w-]+ \)*interactive)" under
lisp/, so it seems to be an established practice.

All right, that makes sense. It will help the next time such question comes up.

PS: I've just seen Juri's reponse in bug#45765#26; I'm glad there is a
consensus on the first patch, because after looking at more in-tree
examples of optional INTERACTIVE arguments, I found myself agonizing
over spelling the spec (list nil nil t), '(nil nil t), or "i\ni\np".

I know the feeling ;-)

Patch installed, closing. Thanks again.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]