Re: compile.el::grep-program - should it use egrep instead of grep?

Could you elaborate a little. The syntax of grep is not sufficient to make daily searches with M-x find-dired or M-x grep-find that happen frequently during searching system log files or looking into program and text document files. That is a rather specialized activity. It is a m

Re: compile.el::grep-program - should it use egrep instead of grep?

> $ echo -e "this\nthat" | grep '(this|that)' Try "grep '\(this\|that\)'" Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: compile.el::grep-program - should it use egrep instead of grep?

Jari Aalto <[EMAIL PROTECTED]> writes: > Andreas Schwab <[EMAIL PROTECTED]> writes: > > | Jari Aalto <[EMAIL PROTECTED]> writes: > | > | > Could you elaborate a little. The syntax of grep is not sufficient to > | > make daily searches with M-x find-dired or M-x grep-find that happen > | > frequen

Re: compile.el::grep-program - should it use egrep instead of grep?

Andreas Schwab <[EMAIL PROTECTED]> writes: | Jari Aalto <[EMAIL PROTECTED]> writes: | | > Could you elaborate a little. The syntax of grep is not sufficient to | > make daily searches with M-x find-dired or M-x grep-find that happen | > frequently during searching system log files or looking into

Re: compile.el::grep-program - should it use egrep instead of grep?

Jari Aalto <[EMAIL PROTECTED]> writes: > Could you elaborate a little. The syntax of grep is not sufficient to > make daily searches with M-x find-dired or M-x grep-find that happen > frequently during searching system log files or looking into program > and text document files. In GNU grep there

Re: compile.el::grep-program - should it use egrep instead of grep?

"Richard M. Stallman" <[EMAIL PROTECTED]> writes: | The use of grep(1) command in all of there is not optimal. So my question | was wheather there were any *nix OS that did not define egrep(1) and thus | would prevent using "egrep" as a default value. | | I do not want to change to eg

Re: compile.el

> Here's a slightly corrected new patch. > Please try this instead of the previous one. It works for all my tests. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emac

Re: compile.el

Here's a slightly corrected new patch. Please try this instead of the previous one. Index: compile.el === RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v retrieving revision 1.381 diff -c -c -r1.381 compi

Re: compile.el

> I think I fixed that bug. Here is a new version of my patch. > Please try this instead of the previous one. This works for compilation errors, but fails for grep hits, where the `directory' argument of `compilation-find-file' is nil: Debugger entered--Lisp error: (wrong-type-argument stringp n

Re: compile.el

I think I fixed that bug. Here is a new version of my patch. Please try this instead of the previous one. Index: compile.el === RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v retrieving revision 1.381 diff -c -c -r1.381

Re: compile.el

rying to visit a file with warnings/errors from the line like In toplevel form: progmodes/grep.el:1:1:Warning: reference to free variable `foo' doesn't find the location of `progmodes/grep.el'. Without the patch you sent in one of the previous messages, compile.el was able to e

Re: compile.el

It has another bug: visiting a saved compilation/grep file fails with the error message: Symbol's value as variable is void: comint-file-name-prefix I already added an autoload to that variable, so you just need to update loaddefs.el and rebuild. This is trivial to fix - just r

Re: compile.el

Since the issue of visiting saved compilation/grep logs is currently under consideration, I want also to point out that changing the file's default directory by the -*- line is not a good thing. It is potentially dangerous when an unsuspecting user assumes that the default dire

Re: compile.el::grep-program - should it use egrep instead of grep?

The use of grep(1) command in all of there is not optimal. So my question was wheather there were any *nix OS that did not define egrep(1) and thus would prevent using "egrep" as a default value. I do not want to change to egrep as the default value for grep-program. Sorry.

Re: compile.el::grep-program - should it use egrep instead of grep?

| There is | |(defvar grep-program "egrep" ...) | | in compile.el, | | No there isn't. The default value of grep-program is "grep" or "zgrep". | What version are you looking at? 21.3 + 21.4[1] use plain grep [2] in compile.el. The zgrep has b

Re: compile.el::grep-program - should it use egrep instead of grep?

There is (defvar grep-program "egrep" ...) in compile.el, No there isn't. The default value of grep-program is "grep" or "zgrep". What version are you looking at? but in some systems the grep is the old one, which does not provi

compile.el::grep-program - should it use egrep instead of grep?

There is (defvar grep-program "egrep" ...) in compile.el, but in some systems the grep is the old one, which does not provide the extended syntax. Would it be possible to set this by default to 'egrep'? I'm not aware of any *nix OS that would

Re: compile.el

> My patch to compile.el has a bug; here's a revised patch. It has another bug: visiting a saved compilation/grep file fails with the error message: Symbol's value as variable is void: comint-file-name-prefix This is trivial to fix - just restore `(boundp 'comint-file-name

compile.el

My patch to compile.el has a bug; here's a revised patch. *** compile.el 20 Aug 2005 17:41:24 -0400 1.375 --- compile.el 22 Aug 2005 03:32:32 -0400 *** *** 1770,1776 (defun compilation-get-file-structure (file &optional fmt) "Retrieve FILE&#x

Re: Changes to emacs/lisp/progmodes/compile.el

On Fri, 12 Aug 2005 19:13:55 +0200, Romain Francoise wrote: > > > [patch for compile.el] > > This line gets fontified as a match in grep mode, it doesn't look good. > > (The line looks like "Grep started at Fri Aug 12 19:05:29", the part up > to the first co

Re: Underlining in compile.el

It's a nice simplification, so please do install it. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Underlining in compile.el

while some non-link parts are underlined). There is already a face variable `compilation-message-face' with `nil' value by default. compile.el puts the face from this variable exactly on the link areas active for navigation (together with text properties `message', `help-echo&#

Re: Underlining in compile.el

> > Have you tried this with the latest CVS? This was fixed two weeks ago. > > Sorry, this was my mistake. I hadn't updated my loaddefs.el. After CVS update I always run: make; make -C lisp EMACS=../src/emacs recompile updates; make; make tags; make info

Re: Underlining in compile.el

> Have you tried this with the latest CVS? This was fixed two weeks ago. Sorry, this was my mistake. I hadn't updated my loaddefs.el. I still get a slight discrepancy with byte compiling: textmodes/org.el:7542:12:Warning: `make-local-hook' is an obsolete function ^

Re: Underlining in compile.el

Juri Linkov writes: > > The mouse-face and mouse-1 binding lasts until the end of the first > > match (shown by carets): > > > > newcomment.el:279:(insert cs " hello " ce) > > ^ > > > > I think it should be: > > > > newcomment.el:279:

Re: Underlining in compile.el

> The mouse-face and mouse-1 binding lasts until the end of the first > match (shown by carets): > > newcomment.el:279: (insert cs " hello " ce) > ^ > > I think it should be: > > newcomment.el:279: (insert cs " hello " ce) > ^^

Re: Underlining in compile.el

> My next preference would be to restrict the area where mouse-1 worked > e.g in grep just on file and line number while mouse-2 could still work > over the whole line. I would not know how to do this, but I am > prepared to work on it after the release. > > This is already

Re: Underlining in compile.el

My next preference would be to restrict the area where mouse-1 worked e.g in grep just on file and line number while mouse-2 could still work over the whole line. I would not know how to do this, but I am prepared to work on it after the release. This is already the case when I t

Re: Underlining in compile.el

If compile and grep buffers had full-line links, the links would be easier to access, they would help with visual alignment (like using a ruler in a parts catalog), and there would be no need to underline them. I see. However, we don't want mouse-1 to be active on the whole line, for

Re: Underlining in compile.el

> However, ISTR that this complaint was made when there were bugs > causing too much of the line to be highlighted. If fixing those bugs > was enough to solve the problem, we don't need to do any more. Would > those that found the situation confusing before please speak up now? My preference

RE: Underlining in compile.el

To me, it still seems like the entirely wrong approach to add new faces everywhere something may look like a link. The idea that beginners will be less confused if links are underlined seems inherently plausible. A common practice used on Web pages with tables or lists tha

Re: Underlining in compile.el

To me, it still seems like the entirely wrong approach to add new faces everywhere something may look like a link. The idea that beginners will be less confused if links are underlined seems inherently plausible. As for adding new faces, that's the implementation I saw how to write, but I

Re: Underlining in compile.el

"Richard M. Stallman" <[EMAIL PROTECTED]> writes: > Does anyone want to write a cleaner implementation of > the feature of underlining the link areas in compile.el? Did anyone else actually express any support for that change? To me, it still seems like the entirely wro

Underlining in compile.el

Does anyone want to write a cleaner implementation of the feature of underlining the link areas in compile.el? *** compile.el 12 Jun 2005 06:10:07 -0400 1.362 --- compile.el 16 Jun 2005 22:04:13 -0400 *** *** 493,517 ;; backward-compatibility alias (put

Re: compile.el underlining

Is there a reason you use '((default :inherit font-lock-warning-face) (((supports :underline t)) :underline t)) rather than '((default :inherit font-lock-warning-face) (t :underline t)) after all, if it's not supported the setting is harmless.

Re: compile.el underlining

> + (defface compilation-error-file-name > + '((default :inherit font-lock-warning-face) > + (((supports :underline t)) :underline t)) > + "Face for displaying file names in compilation errors." > + :group 'font-lock-highlighting-faces > + :version "22.1") Is there a reason you use

Re: compile.el underlining

> rather than >'((default :inherit font-lock-warning-face) > (t :underline t)) Of course that should be '((t :inherit font-lock-warning-face :underline t)) -- Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/

compile.el underlining

Here's a patch to make compile.el underline the file names and line numbers and column numbers. Please try this and tell me what you think. There is surely a more elegant way to do this which does not involve making so many new faces; someone who knows better how to set up font-lock-key

[EMAIL PROTECTED]: RE: Update for Microsoft compile expressions - COMPILE.EL.]

Those who are interested in Windows support, please DTRT with this suggestion. (I don't know whether the current compile.el still has the problem.) --- Start of forwarded message --- From: "Michael Hotchin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subjec

compile.el problem running the ANT tool

I'm noting this problem here because I don't have time to look into a fix right now. At least noting it here will tell people of the problem. ANT 1.6 does not work with Emacs if the ANT "environment" property primitive is used, eg: The line that the ant shell script runs Java with is someth

Re: gcov support in compile.el

If you find it works, please install it. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: gcov support in compile.el

> +(add-to-list 'auto-mode-alist '("\\.gcov$" . compilation-mode)) ^^^ \\' -- Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listi

gcov support in compile.el

I have written a regexp to handle a gcov output in compile.el. 2005-04-05 Masatake YAMATO <[EMAIL PROTECTED]> * progmodes/compile.el (compilation-error-regexp-alist-alist): Add regexp for gcov. 2005-04-05 Masatake YAMATO <[EMAIL PROTECTED]> * compilation

Re: Documentation for compile.el and grep.el?

> Instead of arguing about general policies, which it is very unlikely > we will change, would you like to check a few files of the Lisp > manual? I don't think it would very fruitful for me to check the lisp manual as I am not an expert in these matters. However, I have provided documentation

Re: Documentation for compile.el and grep.el?

FOR-RELEASE does not mention this. In any case, shouldn't it be done *before* the Emacs manual is proofread, otherwise new errors will creep in. I did go through and update the Lisp manual fully. However, that was about a year ago, after which things stalled because I could not convince p

Re: Documentation for compile.el and grep.el?

Given the extensive changes to compile.el and grep.el, I'm surprised that the documentation has changed so little. This may not be incorrect. The changes mostly affect aspects not described in the manual--for instance, to get better results when the user edits the buffer and then

Re: Documentation for compile.el and grep.el?

> From: Nick Roberts <[EMAIL PROTECTED]> > Date: Sun, 27 Feb 2005 10:20:29 +1300 > Cc: emacs-devel@gnu.org > > > Some of these are mentioned in etc/NEWS, and they are not marked with > > a "+++', which means the documentation was not yet updated to reflect > > that change. Someone will do that

Re: Documentation for compile.el and grep.el?

the text you cited is incorrect as it stands, and should > be fixed. Well, if I type 'C-c C-k' which presumably sends a signal, I still get exit, but I'll take your word for it. > > Given the extensive changes to compile.el and grep.el, I'm surprised that > &

Re: Documentation for compile.el and grep.el?

text you cited is incorrect as it stands, and should be fixed. > Given the extensive changes to compile.el and grep.el, I'm surprised that the > documentation has changed so little. > > For example, compilation-directory-properties does something (mouse-2: visit > current direct

Documentation for compile.el and grep.el?

t code in square brackets e.g [0] for normal, [1] for abnormal. Given the extensive changes to compile.el and grep.el, I'm surprised that the documentation has changed so little. For example, compilation-directory-properties does something (mouse-2: visit current directory) but I don't

Re: compile.el does not find errors in numeric filenames

Richard Stallman <[EMAIL PROTECTED]> writes: > files like > > ../../C:/hello.cc are recognized as valid filenames by cvs version. Is it > valid? > > That is a valid file name on GNU or Unix. Perhaps on MS Windows it is > not. However, if compile.el recog