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

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

[debbugs-tracker] bug#8340: closed (23.2; recompile does not retain comp


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#8340: closed (23.2; recompile does not retain compilation-environment needed by vc-git-grep)
Date: Thu, 08 Sep 2011 12:19:02 +0000

Your message dated Thu, 08 Sep 2011 15:12:41 +0300
with message-id <address@hidden>
and subject line Re: bug#8340: 23.2; recompile does not retain 
compilation-environment needed by vc-git-grep
has caused the GNU bug report #8340,
regarding 23.2; recompile does not retain compilation-environment needed by 
vc-git-grep
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
8340: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8340
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 23.2; recompile does not retain compilation-environment needed by vc-git-grep Date: Thu, 24 Mar 2011 18:45:12 +0000 User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
Version 23.2.

In the function vc-git-grep inside vc-git.el, the compilation environment is set as

    (compilation-environment '("PAGER="))

because git grep needs that. If I use M-x recompile in the *grep* buffer after using M-x vc-git-grep, compilation-environment is not set, and a warning that the "terminal is not fully functional" is displayed, one page of results is shown, and git grep blocks waiting on standard input, since it is using more as a pager.

To fix this, I applied the following patch to compile.el that stores compile-environment in a similar way to default-directory. It works for me, but I do not really know elisp.

--- a/compile.el    2011-03-24 18:24:01.000000000 +0000
+++ b/compile.el    2011-03-24 18:27:44.000000000 +0000
@@ -511,6 +511,9 @@
 (defvar compilation-directory nil
   "Directory to restore to when doing `recompile'.")

+(defvar recompilation-environment nil
+  "Environment to restore when doing `recompile'.")
+
 (defvar compilation-directory-matcher
   '("\\(?:Entering\\|Leavin\\(g\\)\\) directory `\\(.+\\)'$" (2 . 1))
   "A list for tracking when directories are entered or left.
@@ -1106,7 +1109,8 @@
If the optional argument `edit-command' is non-nil, the command can be edited."
   (interactive "P")
   (save-some-buffers (not compilation-ask-about-save) nil)
-  (let ((default-directory (or compilation-directory default-directory)))
+  (let ((default-directory (or compilation-directory default-directory))
+ (compilation-environment (or recompilation-environment compilation-environment)))
     (when edit-command
       (setcar compilation-arguments
               (compilation-read-command (car compilation-arguments))))
@@ -1236,6 +1240,7 @@
         ;; affected by the special handling of "cd ...;".
;; NB: must be fone after (funcall mode) as that resets local variables
         (set (make-local-variable 'compilation-directory) thisdir)
+ (set (make-local-variable 'recompilation-environment) compilation-environment)
     (if highlight-regexp
         (set (make-local-variable 'compilation-highlight-regexp)
          highlight-regexp))




--- End Message ---
--- Begin Message --- Subject: Re: bug#8340: 23.2; recompile does not retain compilation-environment needed by vc-git-grep Date: Thu, 08 Sep 2011 15:12:41 +0300 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu)
>>> But I'd prefer to refrain from making compilation-environment a defcustom
>>> for now, until we find a really good use for it.
>> There have been requests to make it a defcustom, and you even agreed
>> to that ;-)
>> http://lists.gnu.org/archive/html/emacs-devel/2009-02/msg00118.html
>> It will allow the users to find and change it more easily in cases like this:
>> http://lists.gnu.org/archive/html/help-gnu-emacs/2011-02/msg00338.html
>
> OK, sounds fine, go ahead,

Done.


--- End Message ---

reply via email to

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