[Top][All Lists]

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

bug#33618: 27.0.50; ada-mode breaks M-x grep

From: Ludovic Brenta
Subject: bug#33618: 27.0.50; ada-mode breaks M-x grep
Date: Fri, 04 Jan 2019 18:27:16 +0100


I'd like to chime in as one of a team of 25 people using emacs ada-mode
on a large software project for the past 20+ years.  We usually use one
"project" per emacs process only, so we're not concerned about supporting
multiple "projects" in an emacs process.  However we are very concerned
about compilation buffers containing absolute paths. Our source files are
spread in about 50 directories, the full paths of which are routinely
longer than 120 characters. Inside each directory are hundreds of source files, the names of which can be another 40 characters each. We use etags
and gnatfind to navigate quickly and efficiently between these files,
without ever needing to remember, type or see the full directory name.
This is especially true in a compilation buffer; RET simply jumps to the
correct file even if only its name is displayed.

So, we've also been hit by this bug when running grep but quickly worked
around it in our ~/.emacs like so:

(add-hook 'grep-mode-hook
          (lambda ()
"In grep buffers, do not use the compilation-search-path to look for source files. Make a local binding to the variable that overrides the one from any Ada mode or other language project files." (set (make-local-variable 'compilation-search-path) '(nil))))

and we left it at that until now.

I do agree that the idea of a single, global, defcustom
compilation-search-path seems to make too many assumptions about the
various tools that can run in a compilation buffer, their current working
directory, which source file (if any) they were called from, etc.. so
maybe this idea should be revisited.  I do like the ideas so far:

- make a new, buffer-local, non-defcustom variable;
- copy its value into a buffer-local variable when creating a new
  compilation buffer;
- reuse the buffer-local variable of a compilation buffer when reusing the
  buffer (i.e. recompile).

Ludovic Brenta.

reply via email to

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