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

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

[Juri Linkov]

Daniel Pfeiffer <occitan@esperanto.org> writes:
> 	(grep-regexp-alist): Give it the full functionality of gnu style
> 	compilation messages with line and column ranges.  Ask me for the
> 	perl script I'm working on, that uses these.

Requiring Emacs users to use a perl script is not a good solution.
But what about using the match highlighting feature of GNU grep?
With some changes in `compilation-mode-font-lock-keywords' and
`compilation-error-properties' this will allow to call functions
to compute columns of matches marked by grep.

Index: lisp/progmodes/compile.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.322
diff -u -r1.322 compile.el
--- lisp/progmodes/compile.el	18 Jun 2004 23:00:46 -0000	1.322
+++ lisp/progmodes/compile.el	25 Jun 2004 01:33:48 -0000
@@ -579,12 +579,17 @@
     (and end-line
 	 (setq end-line (match-string-no-properties end-line))
 	 (setq end-line (string-to-number end-line)))
-    (and col
-	 (setq col (match-string-no-properties col))
-	 (setq col (- (string-to-number col) compilation-first-column)))
-    (if (and end-col (setq end-col (match-string-no-properties end-col)))
-	(setq end-col (- (string-to-number end-col) compilation-first-column -1))
-      (if end-line (setq end-col -1)))
+    (if col
+        (if (functionp col)
+            (setq col (funcall col))
+          (and
+           (setq col (match-string-no-properties col))
+           (setq col (- (string-to-number col) compilation-first-column)))))
+    (if (and end-col (functionp end-col))
+        (setq end-col (funcall end-col))
+      (if (and end-col (setq end-col (match-string-no-properties end-col)))
+          (setq end-col (- (string-to-number end-col) compilation-first-column -1))
+        (if end-line (setq end-col -1))))
     (if (consp type)			; not a static type, check what it is.
 	(setq type (or (and (car type) (match-end (car type)) 1)
 		       (and (cdr type) (match-end (cdr type)) 0)
@@ -726,9 +731,9 @@
 	      ,@(when end-line
 		  `((,end-line compilation-line-face nil t)))
 
-	      ,@(when col
+	      ,@(when (integerp col)
 		  `((,col compilation-column-face nil t)))
-	      ,@(when end-col
+	      ,@(when (integerp end-col)
 		  `((,end-col compilation-column-face nil t)))
 
 	      ,@(nthcdr 6 item)

Index: lisp/progmodes/grep.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/grep.el,v
retrieving revision 1.15
diff -u -r1.15 grep.el
--- lisp/progmodes/grep.el	18 Jun 2004 23:01:30 -0000	1.15
+++ lisp/progmodes/grep.el	25 Jun 2004 01:37:22 -0000
@@ -64,6 +64,21 @@
   :version "21.4"
   :group 'grep)
 
+(defcustom grep-highlight-matches t
+  "*Non-nil to use grep markers to highlight matching strings.
+
+Some grep programs are able to surround matching strings with
+special markers in grep output.  Such markers can be used to
+highlight matching strings in grep mode.
+
+This option sets the environment variable GREP_COLOR to specify
+markers for highlighting and GREP_OPTIONS to place the --color
+option in front of any explicit grep options before starting
+the grep."
+  :type 'boolean
+  :version "21.4"
+  :group 'grep)
+
 (defcustom grep-scroll-output nil
   "*Non-nil to scroll the *grep* buffer window as output appears.
 
@@ -217,6 +232,12 @@
 
 (defvar grep-regexp-alist
   '(("^\\(.+?\\)[:( \t]+\\([0-9]+\\)\\([:) \t]\\)\\(?:\\([0-9]+\\)\\(?:-\\([0-9]+\\)\\)?\\3\\)?" 1 2 (4 . 5))
+    ("^\\(.+?\\)[:(]+\\([0-9]+\\)\\([:)]\\)[^\033\n]*\033\\[01;41m\\([^\033\n]*\\)\033\\[00m" 1 2
+     ((lambda ()
+        (setq compilation-error-screen-columns nil)
+        (- (match-beginning 4) (match-end 3) 8))
+      .
+      (lambda () (- (match-end 4) (match-end 3) 8))))
     ("^Binary file \\(.+\\) matches$" 1 nil nil 1))
   "Regexp used to match grep hits.  See `compilation-error-regexp-alist'.")
 
@@ -244,7 +265,13 @@
      ("^Grep \\(exited abnormally\\) with code \\([0-9]+\\).*"
       (0 '(face nil message nil help-echo nil mouse-face nil) t)
       (1 compilation-warning-face)
-      (2 compilation-line-face)))
+      (2 compilation-line-face))
+     ("\033\\[01;41m\\([^\033\n]*\\)\033\\[00m"
+      (1 (list 'face compilation-column-face
+               'font-lock-face compilation-column-face) t)
+      ((lambda (p))
+       (progn (delete-region (match-end       1) (match-end       0))
+              (delete-region (match-beginning 0) (match-beginning 1))))))
    "Additional things to highlight in grep output.
 This gets tacked on the end of the generated expressions.")
 
@@ -281,6 +308,10 @@
 (defun grep-process-setup ()
   "Setup compilation variables and buffer for `grep'.
 Set up `compilation-exit-message-function' and run `grep-setup-hook'."
+  (when grep-highlight-matches
+    ;; Modify `process-environment' locally bound in `compilation-start'
+    (setenv "GREP_OPTIONS" (concat (getenv "GREP_OPTIONS") " --color=always"))
+    (setenv "GREP_COLOR" "01;41"))
   (set (make-local-variable 'compilation-exit-message-function)
        (lambda (status code msg)
 	 (if (eq status 'exit)

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Daniel Pfeiffer]

Hi Juri,

Juri Linkov <juri@jurta.org> skribis:

> Daniel Pfeiffer <occitan@esperanto.org> writes:
> > 	(grep-regexp-alist): Give it the full functionality of gnu style
> > 	compilation messages with line and column ranges.  Ask me for the
> > 	perl script I'm working on, that uses these.
> 
> Requiring Emacs users to use a perl script is not a good solution.

I'm not requiring them to just, as Emacs doesn't require GNU grep, which sadly
is not omnipresent.  Instead grep.el bends over backwards in horrible ways to
get something out of simple greps and find.  Mine is just an alternative that
might or might not be distributed with Emacs.  Being in Perl it has the
advantage of running as is on very many machines -- no compilation needed.

Besides showing column numbers it has some other nice features, like
multi-line matches.  And it doesn't plonk a 98-character long file-name before
some deeply buried file.  Instead it uses compile's recognition of "Entering
directory" lines, to only give the file name.

There's also the possibilty to act upon the file contents with a perl
expression.  This allows you to drop out of files, e.g. if the first line
doesn't look like #! /usr/bin/perl or whatever.  Or you can massage the lines
to eliminate comments or ignore lines in certain sections, like perl's pod
(=xyz ... =cut or EOF).

> But what about using the match highlighting feature of GNU grep?
> With some changes in `compilation-mode-font-lock-keywords' and
> `compilation-error-properties' this will allow to call functions
> to compute columns of matches marked by grep.

Without having tried it yet, this looks like an interesting approach. 
Somebody
had suggested parsing the grep command and creating font-lock-keywords based
on what I think grep matched.  Your approach is much more elegant and bound to
be correct!

+   
("^\\(.+?\\)[:(]+\\([0-9]+\\)\\([:)]\\)[^\033\n]*\033\\[01;41m\\([^\033\n]*\\
)\033\\[00m" 1 2

This won't work if the line contains an ESC before or within the match. 
Better would be

("^\\(.+?\\)[:(]+\\([0-9]+\\)\\([:)]\\).*?\033\\[01;41m\\(.*?\\)\033\\[00m" 1
2

> +     ("\033\\[01;41m\\([^\033\n]*\\)\033\\[00m"
> +      (1 (list 'face compilation-column-face
> +               'font-lock-face compilation-column-face) t)
> +      ((lambda (p))
> +       (progn (delete-region (match-end       1) (match-end       0))
> +              (delete-region (match-beginning 0) (match-beginning 1))))))

This part is bad, because you are removing the basis for the column
determination.  So if you save the *grep* buffer, you won't get the same
result when reloading it.  Likewise if you modify the line.  Instead you
should put an 'invisble and maybe 'intangible property on the escape sequence.

And you don't need to match them twice.  Instead you could additionally put
normal font-lock HIGHLIGHTs into your grep-regexp-alist rule: (REGEXP FILE
[LINE COLUMN TYPE HYPERLINK HIGHLIGHT...]).  Something like '(face nil
invisble t intangible t).

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Juri Linkov]

dapfy@t-online.de (Daniel Pfeiffer) writes:
> I'm not requiring them to just, as Emacs doesn't require GNU grep, which sadly
> is not omnipresent.  Instead grep.el bends over backwards in horrible ways to
> get something out of simple greps and find.  Mine is just an alternative that
> might or might not be distributed with Emacs.  Being in Perl it has the
> advantage of running as is on very many machines -- no compilation needed.

Perl is definitely superior in its capabilities to grep.  You can
implement many useful search extensions in Perl.  If you make your
Perl script available either within Emacs or separately, many people
might find it useful.  But I think we should also try to exploit the
ability of GNU grep to mark matches by escape sequences.  This means
that `grep-regexp-alist' could have two entries: one for a regexp with
explicit column numbers, and one for matching escape sequences from
GNU grep.

>> +     ("\033\\[01;41m\\([^\033\n]*\\)\033\\[00m"
>> +      (1 (list 'face compilation-column-face
>> +               'font-lock-face compilation-column-face) t)
>> +      ((lambda (p))
>> +       (progn (delete-region (match-end       1) (match-end       0))
>> +              (delete-region (match-beginning 0) (match-beginning 1))))))
>
> This part is bad, because you are removing the basis for the column
> determination.  So if you save the *grep* buffer, you won't get the same
> result when reloading it.  Likewise if you modify the line.  Instead you
> should put an 'invisble and maybe 'intangible property on the escape sequence.

Invisible text often produces unexpected effects, e.g. a search fails
on invisible escape sequences, copying the text reveals the hidden parts
and copies them too...

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Daniel Pfeiffer]

Saluton,

Juri Linkov <juri@jurta.org> skribis:

> But I think we should also try to exploit the
> ability of GNU grep to mark matches by escape sequences.  This means
> that `grep-regexp-alist' could have two entries: one for a regexp with
> explicit column numbers, and one for matching escape sequences from
> GNU grep.

By all means -- I'm all for your patch once we agree on how to do it.

> > This part is bad, because you are removing the basis for the column
> > determination.  So if you save the *grep* buffer, you won't get the same
> > result when reloading it.  Likewise if you modify the line.  Instead you
> > should put an 'invisble and maybe 'intangible property on the escape
> > sequence.
> 
> Invisible text often produces unexpected effects, e.g. a search fails
> on invisible escape sequences, copying the text reveals the hidden parts
> and copies them too...

If there is something wrong with invisible text, then it's a general Emacs
problem with this feature.  So that should be adressed, instead of not using
the feature.  Are there maybe other additional properties (like skip-search)
or options that would improve the things you don't like?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Richard Stallman]

Would you please say precisely what job this Perl script does,
and what purpose people would use it for?  Those details are
not clear to me, so I don't understand what question we are
discussing.

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

[Daniel Pfeiffer]

Saluton, Moin,

Richard Stallman <rms@gnu.org> skribis:

> Would you please say precisely what job this Perl script does,
> and what purpose people would use it for?  Those details are
> not clear to me, so I don't understand what question we are
> discussing.

I've written a little Perl script, which is not production quality yet.  This
serves two purposes I'm frequently confronted with:

- easily deployable on machines without GNU grep
- can match over several lines.

=head1 NAME

plgrep -- Perl grep specially useful within Emacs

=head1 SYNOPSIS

 plgrep -n3 'regexp spanning\n upto\n 3 lines' file ...
 plgrep -R -c 'regexp looked for in C sources in and recursively under dir'
dir ...
 plgrep --eval 'script "perl"' 'regexp looked for only in all perl scripts in
pwd'
 plgrep --eval 'script "perl"; $_ = 0 if /^=/../^=cut/ or /^\s*#/' 'same,
excluding POD or comment lines'

Unlike other greps, this prints out only the name of the file.  Instead of
prepending the directory on every line, it outputs "Entering directory"
messages as necessary.  It also outputs column numbers.  Emacs M-x grep picks
up this information.

The regexps are in Perl syntax, giving you very rich possibilities.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Adrian Aichner]

dapfy@t-online.de (Daniel Pfeiffer) writes:

> Saluton, Moin,
>
> Richard Stallman <rms@gnu.org> skribis:
>
>> Would you please say precisely what job this Perl script does,
>> and what purpose people would use it for?  Those details are
>> not clear to me, so I don't understand what question we are
>> discussing.
>
> I've written a little Perl script, which is not production quality yet.  This
> serves two purposes I'm frequently confronted with:
>
> - easily deployable on machines without GNU grep
> - can match over several lines.

Hi Daniel,

I use
(setq igrep-options "-Pi")
and
(setq grep-command "grep -Pni ")
which gives me multi-line match capability with
grep (GNU grep) 2.5
under
CYGWIN_NT-5.1 D5DC120J 1.5.7(0.109/3/2) 2004-01-30 19:32 i686 unknown unknown Cygwin
in
XEmacs 21.5  (beta17) "chayote" (+CVS-20040611) [Lucid] (i586-pc-win32, Mule) of Sat Jun 12 2004 on D5DC120J

I guess if I had no grep, but only perl, your script could be useful.

Adrian

>
> =head1 NAME
>
> plgrep -- Perl grep specially useful within Emacs
>
> =head1 SYNOPSIS
>
>  plgrep -n3 'regexp spanning\n upto\n 3 lines' file ...
>  plgrep -R -c 'regexp looked for in C sources in and recursively under dir'
> dir ...
>  plgrep --eval 'script "perl"' 'regexp looked for only in all perl scripts in
> pwd'
>  plgrep --eval 'script "perl"; $_ = 0 if /^=/../^=cut/ or /^\s*#/' 'same,
> excluding POD or comment lines'
>
> Unlike other greps, this prints out only the name of the file.  Instead of
> prepending the directory on every line, it outputs "Entering directory"
> messages as necessary.  It also outputs column numbers.  Emacs M-x grep picks
> up this information.
>
> The regexps are in Perl syntax, giving you very rich possibilities.
>
> coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
> Daniel Pfeiffer

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

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

[Richard Stallman]

    I've written a little Perl script, which is not production quality yet.  This
    serves two purposes I'm frequently confronted with:

    - easily deployable on machines without GNU grep
    - can match over several lines.

If searching directory subtrees is useful, let's request
the feature in grep.

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

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> If searching directory subtrees is useful, let's request
> the feature in grep.

GNU grep has a -r option (which works fine with emacs).

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

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

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I've written a little Perl script, which is not production
>     quality yet.  This serves two purposes I'm frequently confronted
>     with:
> 
>     - easily deployable on machines without GNU grep
>     - can match over several lines.
> 
> If searching directory subtrees is useful, let's request
> the feature in grep.

There is grep-find already.  In my opinion, its main shortcoming is
its name.  It took years for me to find it since I had expected it
under the name of find-grep (we also have find-grep-dired).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Daniel Pfeiffer]

Saluton,

David Kastrup <dak@gnu.org> skribis:

> Richard Stallman <rms@gnu.org> writes:
> 
> >     I've written a little Perl script, which is not production
> >     quality yet.  This serves two purposes I'm frequently confronted
> >     with:
> > 
> >     - easily deployable on machines without GNU grep
> >     - can match over several lines.
> > 
> > If searching directory subtrees is useful, let's request
> > the feature in grep.

GNU grep has this with the -R as in my command.  What GNU grep also claims to
have is Perl regexps, but I have a hard time believing they can really keep
pace with all that Perl can do with regexps.  What GNU grep doesn't have (but
could learn) is predefined file sets, like everything that smells of a C/C++
source.

What GNU grep will hardly learn is deciding file treatment besed on content
(other than binary) or doing something with the content, like ignoring certain
parts (e.g. comments).  This requires a builtin interpreter, which in my case
is naturally Perl.

Multiline matching would be a _very_ useful extension to GNU grep, but this
collides with their (and Posix') specification of -F.  Other than that, GNU
grep has tons of features I've never used, which I'm not sure I'll emulate.

> There is grep-find already.  In my opinion, its main shortcoming is
> its name.  It took years for me to find it since I had expected it
> under the name of find-grep (we also have find-grep-dired).

When I redesigned compile, I was stunned at all the grep stuff that's in
Emacs.  Till today I've not fully understood all there is.  Alas it's not
consistent, e.g. M-x grep ignores the <C> constructs it's brethren have. Since
it works by generating varous complex commands, it's quite an art and requires
being good at Unix to even understand what that command is.

This is where my command makes things easier, because everything is just
accessible with an option, of a fairly simple command.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Eli Zaretskii]

> Date: Mon, 28 Jun 2004 10:40:13 +0200
> From: dapfy@t-online.de (Daniel Pfeiffer)
> 
> What GNU grep doesn't have (but could learn) is predefined file
> sets, like everything that smells of a C/C++ source.
> 
> What GNU grep will hardly learn is deciding file treatment besed on content
> (other than binary) or doing something with the content, like ignoring certain
> parts (e.g. comments).

When I need that, I use ID-Utils (and the small Emacs package that
comes with it), not Grep.  Isn't "M-x gid" from that package what you
want?

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

[Daniel Pfeiffer]

Saluton,

"Eli Zaretskii" <eliz@gnu.org> skribis:

> > Date: Mon, 28 Jun 2004 10:40:13 +0200
> > From: dapfy@t-online.de (Daniel Pfeiffer)
> > 
> > What GNU grep doesn't have (but could learn) is predefined file
> > sets, like everything that smells of a C/C++ source.
> > 
> > What GNU grep will hardly learn is deciding file treatment besed on
> > content(other than binary) or doing something with the content, like
> > ignoring certain parts (e.g. comments).
> 
> When I need that, I use ID-Utils (and the small Emacs package that
> comes with it), not Grep.  Isn't "M-x gid" from that package what you
> want?

Sounds interesting.  But it also sound kinda big, like Glimpse it requires
indexing, which is certainly efficient (unless the indexed stuff changes
frequently).  And I frequently grep in various corners of various machines, on
all of which I'd have to install this, which is already my turn off with GNU
grep...  At first sight my little script gives me more bang for the euro.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Eli Zaretskii]

> Date: Mon, 28 Jun 2004 23:22:16 +0200
> From: dapfy@t-online.de (Daniel Pfeiffer)
> > 
> > When I need that, I use ID-Utils (and the small Emacs package that
> > comes with it), not Grep.  Isn't "M-x gid" from that package what you
> > want?
> 
> Sounds interesting.  But it also sound kinda big, like Glimpse it requires
> indexing, which is certainly efficient (unless the indexed stuff changes
> frequently).

There's no need to reindex too frequently, unless you make major
changes to one or more of the project's files.

> And I frequently grep in various corners of various machines, on
> all of which I'd have to install this, which is already my turn off with GNU
> grep...  At first sight my little script gives me more bang for the euro.

Doesn't your script need Perl to be installed?  Perl is by far a
larger package than ID-Utils.  While ID-Utils is a bit larger than
Grep, it's not much larger; its lightning-fast response to queries and
programming language awareness more than make up for the need to
install a fairly small package.

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

[Daniel Pfeiffer]

Saluton, Moin,

"Eli Zaretskii" <eliz@gnu.org> skribis:

> > And I frequently grep in various corners of various machines, on
> > all of which I'd have to install this, which is already my turn off with
> > GNU grep...  At first sight my little script gives me more bang for the
> > euro.
> 
> Doesn't your script need Perl to be installed?  Perl is by far a
> larger package than ID-Utils.

Sure, but Linux distros as well as commercial Unices like Solaris or
Fujitsu-Siemens' Reliant Unix have it installed by default.

> While ID-Utils is a bit larger than
> Grep, it's not much larger; its lightning-fast response to queries and
> programming language awareness more than make up for the need to
> install a fairly small package.

You're whetting my appetite, but we're getting off topic here.  The
interesting question is what to do with M-x grep for highlighting the matched
string:

- Is it better to delete the Escape sequences as Juri suggested and thus
irreversibly change the buffer contents such that it can't be rehighlighted?

- Or do we maintain save-to-file and editability, by making the Escape
sequences invisible (and maybe solving the drawbacks somehow)?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Eli Zaretskii]

> Date: Tue, 29 Jun 2004 22:08:51 +0200
> From: dapfy@t-online.de (Daniel Pfeiffer)
> > 
> > Doesn't your script need Perl to be installed?  Perl is by far a
> > larger package than ID-Utils.
> 
> Sure, but Linux distros as well as commercial Unices like Solaris or
> Fujitsu-Siemens' Reliant Unix have it installed by default.

Not in my experience.  I always had to install Perl on anything that
isn't GNU/Linux.

> - Is it better to delete the Escape sequences as Juri suggested and thus
> irreversibly change the buffer contents such that it can't be rehighlighted?
> 
> - Or do we maintain save-to-file and editability, by making the Escape
> sequences invisible (and maybe solving the drawbacks somehow)?

I missed that part of the discussion, but why not use something like
ansi-color.el to _display_ the highlighted substrings as if they were
on a text-mode terminal?

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

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Tue, 29 Jun 2004 22:08:51 +0200
>> From: dapfy@t-online.de (Daniel Pfeiffer)
>> - Is it better to delete the Escape sequences as Juri suggested and thus
>> irreversibly change the buffer contents such that it can't be rehighlighted?
>> 
>> - Or do we maintain save-to-file and editability, by making the Escape
>> sequences invisible (and maybe solving the drawbacks somehow)?
>
> I missed that part of the discussion, but why not use something like
> ansi-color.el to _display_ the highlighted substrings as if they were
> on a text-mode terminal?

ansi-color.el is good for displaying highlighted substrings,
but it _deletes_ escape sequences after highlighting the substrings.
So, as Daniel pointed out, substrings can't be rehighlighted later
after saving and reloading the *grep* buffer.  Moreover, ansi-color.el
conflicts with font-lock which is used to calculate column positions
of matches based on relative locations of escape sequences in grep output.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Daniel Pfeiffer]

Saluton,

"Eli Zaretskii" <eliz@gnu.org> skribis:

> > Date: Tue, 29 Jun 2004 22:08:51 +0200
> > From: dapfy@t-online.de (Daniel Pfeiffer)

> > - Is it better to delete the Escape sequences as Juri suggested and thus
> > irreversibly change the buffer contents such that it can't be
> > rehighlighted?
> > 
> > - Or do we maintain save-to-file and editability, by making the Escape
> > sequences invisible (and maybe solving the drawbacks somehow)?
> 
> I missed that part of the discussion, but why not use something like
> ansi-color.el to _display_ the highlighted substrings as if they were
> on a text-mode terminal?

It is not immediately clear to me how to hook that into font-lock or
specifically grep.el.  But it would seem to also delete the Escape sequences,
which was my criticism of Juri's code.

Is there no way of making text invisible, such that it doesn't get in the way
when searching of copy/pasting it?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Juri Linkov]

dapfy@t-online.de (Daniel Pfeiffer) writes:
> The interesting question is what to do with M-x grep for
> highlighting the matched string:
>
> - Is it better to delete the Escape sequences as Juri suggested and thus
> irreversibly change the buffer contents such that it can't be rehighlighted?
>
> - Or do we maintain save-to-file and editability, by making the Escape
> sequences invisible (and maybe solving the drawbacks somehow)?

Solving the drawbacks of invisible text is a separate issue.  There is
a `search-invisible' option in isearch.el, but it can't find a string
with invisible text inside it.  To discard invisible text when yanking
it's possible to implement an option like `yank-excluded-properties'.
Another problem with invisible text is that C-M-f or C-M-b on
invisible parens like ^[[01;41m signals an error "Unbalanced parentheses".

But perhaps these drawbacks are negligible for grep mode.  If not,
they might be addressed later, or we can add an option to choose
between hiding and deleting escape sequences.

Anyhow, there is a new patch below which puts an `invisible' property
on matched strings.  I tested it, and I find it acceptable even with
invisible text since I don't operate too much on the grep buffer.

Daniel, you added a new option `grep-error-screen-columns' recently.
But I don't see where it is used.  Could you tell how do you plan to
use it?  Currently I set `compilation-error-screen-columns' to nil in
`grep-regexp-alist', but perhaps I should use `grep-error-screen-columns'?

BTW, as you can see below I also changed handling of `end-mk' in
`compilation-goto-locus'.  Currently it activates the region around a
matched string.  This is very inconvenient.  I changed this to put a
highlighted overlay on a matched string just as it does now for the
whole line.

Index: lisp/progmodes/grep.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/grep.el,v
retrieving revision 1.16
diff -u -r1.16 grep.el
--- lisp/progmodes/grep.el	23 Jun 2004 23:10:33 -0000	1.16
+++ lisp/progmodes/grep.el	30 Jun 2004 03:27:24 -0000
@@ -64,6 +64,21 @@
   :version "21.4"
   :group 'grep)
 
+(defcustom grep-highlight-matches t
+  "*Non-nil to use grep markers to highlight matching strings.
+
+Some grep programs are able to surround matching strings with
+special markers in grep output.  Such markers can be used to
+highlight matching strings in grep mode.
+
+This option sets the environment variable GREP_COLOR to specify
+markers for highlighting and GREP_OPTIONS to place the --color
+option in front of any explicit grep options before starting
+the grep."
+  :type 'boolean
+  :version "21.4"
+  :group 'grep)
+
 (defcustom grep-scroll-output nil
   "*Non-nil to scroll the *grep* buffer window as output appears.
 
@@ -227,6 +242,22 @@
   '(("^\\(.+?\\)[:( \t]+\
 \\([0-9]+\\)\\([.:]?\\)\\([0-9]+\\)?\
 \\(?:-\\(?:\\([0-9]+\\)\\3\\)?\\.?\\([0-9]+\\)?\\)?[:) \t]" 1 (2 . 5) (4 . 6))
+    ("^\\(.+?\\)[:(]+\\([0-9]+\\)\\([:)]\\).*?\\(\033\\[01;41m\\)\\(.*?\\)\\(\033\\[00m\\)"
+     1 2
+     ((lambda ()
+        (setq compilation-error-screen-columns nil)
+        (- (match-beginning 5) (match-end 3) 8))
+      .
+      (lambda () (- (match-end 5) (match-end 3) 8)))
+     nil nil
+     (4 (list 'face nil 'invisible t 'intangible t))
+     (5 (list 'face compilation-column-face))
+     (6 (list 'face nil 'invisible t 'intangible t))
+     ;; highlight other matches on the same line
+     ("\\(\033\\[01;41m\\)\\(.*?\\)\\(\033\\[00m\\)"
+      nil nil
+      (1 (list 'face nil 'invisible t 'intangible t))
+      (2 (list 'face compilation-column-face) t)
+      (3 (list 'face nil 'invisible t 'intangible t))))
     ("^Binary file \\(.+\\) matches$" 1 nil nil 1))
   "Regexp used to match grep hits.  See `compilation-error-regexp-alist'.")
 
@@ -291,6 +322,10 @@
 (defun grep-process-setup ()
   "Setup compilation variables and buffer for `grep'.
 Set up `compilation-exit-message-function' and run `grep-setup-hook'."
+  (when grep-highlight-matches
+    ;; Modify `process-environment' locally bound in `compilation-start'
+    (setenv "GREP_OPTIONS" (concat (getenv "GREP_OPTIONS") " --color=always"))
+    (setenv "GREP_COLOR" "01;41"))
   (set (make-local-variable 'compilation-exit-message-function)
        (lambda (status code msg)
 	 (if (eq status 'exit)

Index: lisp/progmodes/compile.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.322
diff -u -r1.322 compile.el
--- lisp/progmodes/compile.el	18 Jun 2004 23:00:46 -0000	1.322
+++ lisp/progmodes/compile.el	30 Jun 2004 03:35:13 -0000
@@ -579,12 +579,17 @@
     (and end-line
 	 (setq end-line (match-string-no-properties end-line))
 	 (setq end-line (string-to-number end-line)))
-    (and col
-	 (setq col (match-string-no-properties col))
-	 (setq col (- (string-to-number col) compilation-first-column)))
-    (if (and end-col (setq end-col (match-string-no-properties end-col)))
-	(setq end-col (- (string-to-number end-col) compilation-first-column -1))
-      (if end-line (setq end-col -1)))
+    (if col
+        (if (functionp col)
+            (setq col (funcall col))
+          (and
+           (setq col (match-string-no-properties col))
+           (setq col (- (string-to-number col) compilation-first-column)))))
+    (if (and end-col (functionp end-col))
+        (setq end-col (funcall end-col))
+      (if (and end-col (setq end-col (match-string-no-properties end-col)))
+          (setq end-col (- (string-to-number end-col) compilation-first-column -1))
+        (if end-line (setq end-col -1))))
     (if (consp type)			; not a static type, check what it is.
 	(setq type (or (and (car type) (match-end (car type)) 1)
 		       (and (cdr type) (match-end (cdr type)) 0)
@@ -726,9 +731,9 @@
 	      ,@(when end-line
 		  `((,end-line compilation-line-face nil t)))
 
-	      ,@(when col
+	      ,@(when (integerp col)
 		  `((,col compilation-column-face nil t)))
-	      ,@(when end-col
+	      ,@(when (integerp end-col)
 		  `((,end-col compilation-column-face nil t)))
 
 	      ,@(nthcdr 6 item)
@@ -1535,9 +1542,7 @@
   (unless (eq (goto-char mk) (point))
     (widen)
     (goto-char mk))
-  (if end-mk
-      (push-mark end-mk nil t)
-    (if mark-active (setq mark-active)))
+  (if mark-active (setq mark-active))
   ;; If hideshow got in the way of
   ;; seeing the right place, open permanently.
   (dolist (ov (overlays-at (point)))
@@ -1557,26 +1562,31 @@
 			     compilation-highlight-regexp)))
     (compilation-set-window-height w)
 
-    (when (and highlight-regexp
-	       (not (and end-mk transient-mark-mode)))
+    (when highlight-regexp
       (unless compilation-highlight-overlay
 	(setq compilation-highlight-overlay
 	      (make-overlay (point-min) (point-min)))
-	(overlay-put compilation-highlight-overlay 'face 'region))
+	(overlay-put compilation-highlight-overlay 'face next-error-face))
       (with-current-buffer (marker-buffer mk)
 	(save-excursion
-	  (end-of-line)
+	  (if end-mk (goto-char end-mk) (end-of-line))
 	  (let ((end (point)))
-	    (beginning-of-line)
+	    (if mk (goto-char mk) (beginning-of-line))
 	    (if (and (stringp highlight-regexp)
 		     (re-search-forward highlight-regexp end t))
 		(progn

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Daniel Pfeiffer]

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

Saluton,

Thanks a lot for your patch.  I'm sending what I discussed below, and it seems
to work.  Could you please reverify and also write a ChangeLog?

Juri Linkov <juri@jurta.org> skribis:

> dapfy@t-online.de (Daniel Pfeiffer) writes:

> Anyhow, there is a new patch below which puts an `invisible' property
> on matched strings.  I tested it, and I find it acceptable even with
> invisible text since I don't operate too much on the grep buffer.

Without my understanding why, patch barfed at both halves of this, so I had to
apply it manually :-(

> Daniel, you added a new option `grep-error-screen-columns' recently.
> But I don't see where it is used.  Could you tell how do you plan to
> use it?  Currently I set `compilation-error-screen-columns' to nil in
> `grep-regexp-alist', but perhaps I should use `grep-error-screen-columns'?

Ah ha!  Grep inherits from compilation, so all the like-named variables get
passed through.  As for your setting this on every match, I don't see the
point, not even setting this once.  This is an option, which means that people
could set it to match the understanding of whatever external prog they use.

> BTW, as you can see below I also changed handling of `end-mk' in
> `compilation-goto-locus'.  Currently it activates the region around a
> matched string.  This is very inconvenient.  I changed this to put a
> highlighted overlay on a matched string just as it does now for the
> whole line.

This was Stef's idea for users of transient-mark-mode.  It has the advantage
of staying around longer, but your approach is more useful for everyone.  (I
suspect transient-mark-mode is not so popular, at least not with me.)

> diff -u -r1.16 grep.el
> --- lisp/progmodes/grep.el	23 Jun 2004 23:10:33 -0000	1.16
> +++ lisp/progmodes/grep.el	30 Jun 2004 03:27:24 -0000

> +     (4 (list 'face nil 'invisible t 'intangible t))
> +     (5 (list 'face compilation-column-face))
> +     (6 (list 'face nil 'invisible t 'intangible t))

I've simplified these a little and made the face customizable, defaulting to
isearch's.

> diff -u -r1.322 compile.el
> --- lisp/progmodes/compile.el	18 Jun 2004 23:00:46 -0000	1.322
> +++ lisp/progmodes/compile.el	30 Jun 2004 03:35:13 -0000

> +	(overlay-put compilation-highlight-overlay 'face next-error-face))

This variable is undefined.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

[-- Attachment #2: gnu-grep.patch --]
[-- Type: application/octet-stream, Size: 5462 bytes --]

--- /home/pfeiffer/.emacs.d/cvs/lisp/progmodes/compile.el.~1.322.~	2004-06-19 01:00:08.000000000 +0200
+++ compile.el (buffer)	2004-07-02 23:50:01.414072000 +0200
@@ -579,12 +579,17 @@
     (and end-line
 	 (setq end-line (match-string-no-properties end-line))
 	 (setq end-line (string-to-number end-line)))
-    (and col
-	 (setq col (match-string-no-properties col))
-	 (setq col (- (string-to-number col) compilation-first-column)))
-    (if (and end-col (setq end-col (match-string-no-properties end-col)))
-	(setq end-col (- (string-to-number end-col) compilation-first-column -1))
-      (if end-line (setq end-col -1)))
+    (if col
+	(if (functionp col)
+	    (setq col (funcall col))
+	  (and
+	   (setq col (match-string-no-properties col))
+	   (setq col (- (string-to-number col) compilation-first-column)))))
+    (if (and end-col (functionp end-col))
+	(setq end-col (funcall end-col))
+      (if (and end-col (setq end-col (match-string-no-properties end-col)))
+	  (setq end-col (- (string-to-number end-col) compilation-first-column -1))
+	(if end-line (setq end-col -1))))
     (if (consp type)			; not a static type, check what it is.
 	(setq type (or (and (car type) (match-end (car type)) 1)
 		       (and (cdr type) (match-end (cdr type)) 0)
@@ -726,10 +731,10 @@
 	      ,@(when end-line
 		  `((,end-line compilation-line-face nil t)))
 
-	      ,@(when col
-		  `((,col compilation-column-face nil t)))
-	      ,@(when end-col
-		  `((,end-col compilation-column-face nil t)))
+	      ,@(when (integerp col)
+ 		  `((,col compilation-column-face nil t)))
+	      ,@(when (integerp end-col)
+ 		  `((,end-col compilation-column-face nil t)))
 
 	      ,@(nthcdr 6 item)
 	      (,(or (nth 5 item) 0)
@@ -1535,9 +1540,7 @@
   (unless (eq (goto-char mk) (point))
     (widen)
     (goto-char mk))
-  (if end-mk
-      (push-mark end-mk nil t)
-    (if mark-active (setq mark-active)))
+  (if mark-active (setq mark-active))
   ;; If hideshow got in the way of
   ;; seeing the right place, open permanently.
   (dolist (ov (overlays-at (point)))
@@ -1557,17 +1560,16 @@
 			     compilation-highlight-regexp)))
     (compilation-set-window-height w)
 
-    (when (and highlight-regexp
-	       (not (and end-mk transient-mark-mode)))
+    (when highlight-regexp
       (unless compilation-highlight-overlay
 	(setq compilation-highlight-overlay
 	      (make-overlay (point-min) (point-min)))
 	(overlay-put compilation-highlight-overlay 'face 'region))
       (with-current-buffer (marker-buffer mk)
 	(save-excursion
-	  (end-of-line)
+	  (if end-mk (goto-char end-mk) (end-of-line))
 	  (let ((end (point)))
-	    (beginning-of-line)
+	    (if mk (goto-char mk) (beginning-of-line))
 	    (if (and (stringp highlight-regexp)
 		     (re-search-forward highlight-regexp end t))
 		(progn
--- /home/pfeiffer/.emacs.d/cvs/lisp/progmodes/grep.el.~1.16.~	2004-06-24 01:07:08.000000000 +0200
+++ grep.el (buffer)	2004-07-02 23:49:17.042372000 +0200
@@ -64,6 +64,21 @@
   :version "21.4"
   :group 'grep)
 
+(defcustom grep-highlight-matches t
+  "*Non-nil to use grep markers to highlight matching strings.
+
+Some grep programs are able to surround matching strings with
+special markers in grep output.  Such markers can be used to
+highlight matching strings in grep mode.
+
+This option sets the environment variable GREP_COLOR to specify
+markers for highlighting and GREP_OPTIONS to place the --color
+option in front of any explicit grep options before starting
+the grep."
+  :type 'boolean
+  :version "21.4"
+  :group 'grep)
+
 (defcustom grep-scroll-output nil
   "*Non-nil to scroll the *grep* buffer window as output appears.
 
@@ -227,6 +242,21 @@
   '(("^\\(.+?\\)[:( \t]+\
 \\([0-9]+\\)\\([.:]?\\)\\([0-9]+\\)?\
 \\(?:-\\(?:\\([0-9]+\\)\\3\\)?\\.?\\([0-9]+\\)?\\)?[:) \t]" 1 (2 . 5) (4 . 6))
+    ("^\\(.+?\\)[:(]+\\([0-9]+\\)\\([:)]\\).*?\\(\033\\[01;41m\\)\\(.*?\\)\\(\033\\[00m\\)"
+     1 2
+     ((lambda () (- (match-beginning 5) (match-end 3) 8))
+      .
+      (lambda () (- (match-end 5) (match-end 3) 8)))
+     nil nil
+     (4 '(face nil invisible t intangible t))
+     (5 grep-match-face)
+     (6 '(face nil invisible t intangible t))
+     ;; highlight other matches on the same line
+     ("\\(\033\\[01;41m\\)\\(.*?\\)\\(\033\\[00m\\)"
+      nil nil
+      (1 '(face nil invisible t intangible t))
+      (2 grep-match-face t)
+      (3 '(face nil invisible t intangible t))))
     ("^Binary file \\(.+\\) matches$" 1 nil nil 1))
   "Regexp used to match grep hits.  See `compilation-error-regexp-alist'.")
 
@@ -241,6 +271,9 @@
 (defvar grep-error-face	compilation-error-face
   "Face name to use for grep error messages.")
 
+(defvar grep-match-face	'isearch-lazy-highlight-face
+  "Face name to use for grep matches with GNU grep.")
+
 (defvar grep-mode-font-lock-keywords
    '(;; Command output lines.
      ("^\\([A-Za-z_0-9/\.+-]+\\)[ \t]*:" 1 font-lock-function-name-face)
@@ -291,6 +324,10 @@
 (defun grep-process-setup ()
   "Setup compilation variables and buffer for `grep'.
 Set up `compilation-exit-message-function' and run `grep-setup-hook'."
+  (when grep-highlight-matches
+    ;; Modify `process-environment' locally bound in `compilation-start'
+    (setenv "GREP_OPTIONS" (concat (getenv "GREP_OPTIONS") " --color=always"))
+    (setenv "GREP_COLOR" "01;41"))
   (set (make-local-variable 'compilation-exit-message-function)
        (lambda (status code msg)
 	 (if (eq status 'exit)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

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

[Stefan]

>> BTW, as you can see below I also changed handling of `end-mk' in
>> `compilation-goto-locus'.  Currently it activates the region around a
>> matched string.  This is very inconvenient.  I changed this to put a
>> highlighted overlay on a matched string just as it does now for the
>> whole line.

> This was Stef's idea for users of transient-mark-mode.  It has the advantage
> of staying around longer, but your approach is more useful for everyone.

My original use of transient-mark-mode for such errors was for sml-mode.el
where the region specified by an error can span several screenfuls of text
(narrowing down such error reports to something more useful is actively
being worked on, but is still a research problem).  In such a case it is
very useful to be able to jump to each end of the region.
So using transient-mark-mode was just very natural and had the added
advantage of being extremely easy to code.

> (I suspect transient-mark-mode is not so popular, at least not with me.)

Seeing how much tmm-specific code has been written, I tend to believe
the opposite.  I suspect tmm is unpopular among Emacs veterans but I
also suspect that GUI-happy users have a hard time believing that it's not
enabled by default.


        Stefan

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

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

>
> > (I suspect transient-mark-mode is not so popular, at least not with me.)
> 
> Seeing how much tmm-specific code has been written, I tend to
> believe the opposite.  I suspect tmm is unpopular among Emacs
> veterans but I also suspect that GUI-happy users have a hard time
> believing that it's not enabled by default.

"GUI-happy" users are mostly surprised of its stickiness: they tend
to expect that it is just active when you mark regions with a mouse,
or use a special marking sequence.

We are getting closer with temporary transient-mark-mode on
mouse-drag, but I don't think we are "there" yet with regard to
"expected" behavior.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stefan]

>> > (I suspect transient-mark-mode is not so popular, at least not with me.)
>> 
>> Seeing how much tmm-specific code has been written, I tend to
>> believe the opposite.  I suspect tmm is unpopular among Emacs
>> veterans but I also suspect that GUI-happy users have a hard time
>> believing that it's not enabled by default.

> "GUI-happy" users are mostly surprised of its stickiness: they tend
> to expect that it is just active when you mark regions with a mouse,
> or use a special marking sequence.

That's a different issue.  I still think that they're baffled at it being
disabled by default, even if they might also think it doesn't work right.
I.e. it doesn't work right but it's better than nothing.

> We are getting closer with temporary transient-mark-mode on
> mouse-drag, but I don't think we are "there" yet with regard to
> "expected" behavior.

Agreed.  But the "expected behavior" for such users is that both
region-beginning and region-end are independent from point, so it's
a non-trivial change.


        Stefan

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

[Richard Stallman]

    "GUI-happy" users are mostly surprised of its stickiness: they tend
    to expect that it is just active when you mark regions with a mouse,
    or use a special marking sequence.

    We are getting closer with temporary transient-mark-mode on
    mouse-drag, but I don't think we are "there" yet with regard to
    "expected" behavior.

Can you name some specific "unexpected" behaviors that we
might look for ways to change?

    But the "expected behavior" for such users is that both
    region-beginning and region-end are independent from point, so it's
    a non-trivial change.

That does sound thoroughly incompatible with Emacs.  However, the
programs I've seen don't seem to cancel the selection when you move
point.  That would not be difficult, and is what we now do
after a mouse drag.

Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Daniel Pfeiffer]

Hi,

Richard Stallman <rms@gnu.org> skribis:

>     But the "expected behavior" for such users is that both
>     region-beginning and region-end are independent from point, so it's
>     a non-trivial change.
> 
> That does sound thoroughly incompatible with Emacs.  However, the
> programs I've seen don't seem to cancel the selection when you move
> point.  That would not be difficult, and is what we now do
> after a mouse drag.

Region handling seem to recently have been screwed up, and it's utterly
annoying.  In some cases, which I have not yet figured out, I get errors at
least from M-w (not sure what else I may have come across) that the mark is
not activated.  But it does exist, because I can do C-x C-x and afterwards M-w
works. 

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Richard Stallman]

      In some cases, which I have not yet figured out, I get errors at
    least from M-w (not sure what else I may have come across) that the mark is
    not activated.  But it does exist, because I can do C-x C-x and afterwards M-w
    works. 

You did not say whether you are using Transient Mark mode.
If you are using Transient Mark mode, it is normal that the
mark can exist but not be active.  There may be a bug that does
this in a case where it should not happen.

Re: Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Daniel Pfeiffer]

Saluton,

Richard Stallman <rms@gnu.org> skribis:

>       In some cases, which I have not yet figured out, I get errors at
>     least from M-w (not sure what else I may have come across) that the mark
>     is not activated.  But it does exist, because I can do C-x C-x and
>     afterwards M-w works. 
> 
> You did not say whether you are using Transient Mark mode.
> If you are using Transient Mark mode, it is normal that the
> mark can exist but not be active.  There may be a bug that does
> this in a case where it should not happen.

No I don't.  I even have (setq-default transient-mark-mode nil) without
remembering why I put that in long ago.

You were nevertheless right: I found out that dragging the mouse to mark
something sets transient-mark-mode to 'identity behind my back.  Even with
emacs -q.

This then might be linked to another irritating thing I recently noticed: when
double-clicking, the marked word is shown in region face, but reverts to
normal
face immediately.  The next double click sets region face semi permanently
(till doing something else).  The next double click again only blinks region
face, and so on.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Richard Stallman]

    You were nevertheless right: I found out that dragging the mouse to mark
    something sets transient-mark-mode to 'identity behind my back.  Even with
    emacs -q.

This is a feature.  When the user drags a region, it is highlighted
for the next command, and various commands will operate on that region.

Could you explain why this strikes you as a bug?  What is the precise
sequence of inputs that you use, and what behavior do you see?

Re: Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Daniel Pfeiffer]

Saluton,

Richard Stallman <rms@gnu.org> skribis:

>     You were nevertheless right: I found out that dragging the mouse to mark
>     something sets transient-mark-mode to 'identity behind my back.  Even
>     with emacs -q.
> 
> This is a feature.  When the user drags a region, it is highlighted
> for the next command, and various commands will operate on that region.
> 
> Could you explain why this strikes you as a bug?  What is the precise
> sequence of inputs that you use, and what behavior do you see?

I don't care about this itself.  The bug is that after this, the mark is not
active.  If I do (for example)  drag click M->  it says "Mark set".  But then 
M-w  complains "The mark is not active now".

This is a fairly recent change, as I do this kind of thing quite often and
never had this error message before.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Richard Stallman]

    I don't care about this itself.  The bug is that after this, the mark is not
    active.  If I do (for example)  drag click M->  it says "Mark set".  But then 
    M-w  complains "The mark is not active now".

That does not happen for me.  The code in keyboard.c turns off the
temporary transient mark mode after the next command, but it does not
deactivate the mark.

Can you debug why the mark gets deactivated?

Re: Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Daniel Pfeiffer]

Saluton, Moin,

Richard Stallman <rms@gnu.org> skribis:

>     I don't care about this itself.  The bug is that after this, the mark is
>     not active.  If I do (for example)  drag click M->  it says "Mark set". 
>     But then M-w  complains "The mark is not active now".
> 
> That does not happen for me.  The code in keyboard.c turns off the
> temporary transient mark mode after the next command, but it does not
> deactivate the mark.

I don't know why you don't get this.  I just rebuilt a new CVS Emacs, and even
with -q it still happens.

> Can you debug why the mark gets deactivated?

I haven't got a clue on how to debug something that depends on the events
Emacs gets.  Here are the events I give it:

<down-mouse-1> <mouse-movement> <mouse-movement> <drag-mouse-1> 
<down-mouse-1> <mouse-1> M-> M-w <f1> l

And the resulting messages:

Loading mwheel...done
(.emacs.d/cvs/src/emacs -q /etc/passwd)
Loading tooltip...done
Loading image...done
Note: file is write protected
Mark set
The mark is not active now
Loading help-mode...done

I also happens with writable files, but I chose one that would not load some
special mode.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Richard Stallman]

    This then might be linked to another irritating thing I recently
    noticed: when double-clicking, the marked word is shown in region
    face, but reverts to normal face immediately.  The next double
    click sets region face semi permanently (till doing something
    else).  The next double click again only blinks region face, and
    so on.

That is definitely a bug; I think I can debug it from this.
Thanks.

Re: Mark handling (Was: Changes to emacs/lisp/progmodes/grep.el)

[Richard Stallman]

    This then might be linked to another irritating thing I recently
    noticed: when double-clicking, the marked word is shown in region
    face, but reverts to normal face immediately.  The next double
    click sets region face semi permanently (till doing something
    else).  The next double click again only blinks region face, and
    so on.

Does this fix it?

*** mouse.el	15 Jun 2004 22:47:00 -0400	1.248
--- mouse.el	07 Jul 2004 11:56:19 -0400	
***************
*** 625,631 ****
  
  (defun mouse-set-region-1 ()
    ;; Set transient-mark-mode for a little while.
!   (setq transient-mark-mode (or transient-mark-mode 'only))
    (setq mouse-last-region-beg (region-beginning))
    (setq mouse-last-region-end (region-end))
    (setq mouse-last-region-tick (buffer-modified-tick)))
--- 625,632 ----
  
  (defun mouse-set-region-1 ()
    ;; Set transient-mark-mode for a little while.
!   (if (memq transient-mark-mode '(nil identity))
!       (setq transient-mark-mode 'only))
    (setq mouse-last-region-beg (region-beginning))
    (setq mouse-last-region-end (region-end))
    (setq mouse-last-region-tick (buffer-modified-tick)))

Re: Transient mark mode (was: Changes to emacs/lisp/progmodes/grep.el)

[Paul Pogonyshev]

> > (I suspect transient-mark-mode is not so popular, at least not with me.)
> 
> Seeing how much tmm-specific code has been written, I tend to believe
> the opposite.  I suspect tmm is unpopular among Emacs veterans but I
> also suspect that GUI-happy users have a hard time believing that it's not
> enabled by default.

Well, if you are interested, here is my opinion.  I'm not a Emacs veteran
(used to use "modern-conventional" editors like those where you select
text with Shift pressed until about 1.5 years ago).

I never (literally never) use mouse for editing text, and so I don't quite
understand how to work without transient mark.  When tmm is disabled, I
never see what part of text I'm working with and memorizing mark position
is extremely inconvenient.  So, for me tmm is vital when I want to work
with arbitrary regions (M-d, C-k and the like are not always enough).

Paul

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

[Daniel Pfeiffer]

Saluton,

Stefan <monnier@iro.umontreal.ca> skribis:

> > This was Stef's idea for users of transient-mark-mode.  It has the
> > advantage of staying around longer, but your approach is more useful for
> > everyone.
> 
> My original use of transient-mark-mode for such errors was for sml-mode.el
> where the region specified by an error can span several screenfuls of text
> (narrowing down such error reports to something more useful is actively
> being worked on, but is still a research problem).  In such a case it is
> very useful to be able to jump to each end of the region.

This is of course a very special usage, but uncontestably useful to you.

> So using transient-mark-mode was just very natural and had the added
> advantage of being extremely easy to code.

Juri's patch was no harder to code, if you look at how little he changed
there.  My annoyance is that 0.5s is too short, so I would like to change the
semantics of compilation-highlight-regexp and the corresponding parameters to
be not t, but the duration.  Or simply make it much longer, because it's
sit-for, so it goes away as soon as the user does something.

As for tmm, what shall we do?  I feel that treating hits with column
information and without the same way, assuming first to last column in the
latter case is "clean".  With an overlay it doesn't hurt at all.

If we then however make it an option between overlay or tmm, that would mean
you'd get tmm for every compiler output line.  Would you find this annoying?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Juri Linkov]

dapfy@t-online.de (Daniel Pfeiffer) writes:
> Stefan <monnier@iro.umontreal.ca> skribis:
>> So using transient-mark-mode was just very natural and had the added
>> advantage of being extremely easy to code.
>
> Juri's patch was no harder to code, if you look at how little he changed
> there.  My annoyance is that 0.5s is too short, so I would like to change the
> semantics of compilation-highlight-regexp and the corresponding parameters to
> be not t, but the duration.  Or simply make it much longer, because it's
> sit-for, so it goes away as soon as the user does something.

Please look at http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00970.html
Is it ok for you?

> As for tmm, what shall we do?  I feel that treating hits with column
> information and without the same way, assuming first to last column in the
> latter case is "clean".  With an overlay it doesn't hurt at all.
>
> If we then however make it an option between overlay or tmm, that would mean
> you'd get tmm for every compiler output line.  Would you find this annoying?

To be able to jump to the end of the region it is enough to simply set
the mark at the other end, but activating the region for no reason is
too annoying for users of transient-mark-mode since they should
deactivate the mark by typing `C-g' after every match visit in the
source buffer.

So what is needed is to replace (push-mark end-mk nil t) with
(push-mark end-mk) and use highlighted overlay in all cases.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Daniel Pfeiffer]

Saluton,

Juri Linkov <juri@jurta.org> skribis:

> Please look at
> http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00970.html
> Is it ok for you?

Fringe-arrow is a nice idea, since this is used in the compilation buffer as
well.  But I would like this in addition, not alternatively to overlay.

The new face is misnamed not only because of the "error" part, but also
because of the "next".  It results from going to next-*, but by the time the
user sees it, it's the current one.  As for me, I don't use C-x ` much,
instead scrolling through the buffer and clicking mouse-2.  So it's "this"
error for me and not next.

As for "error", "hits" etc. I had considered radically extracting almost all
of compile into a new auto-hypertext-mode.  I dropped that idea when someone
arbitrarily pulled alittle bit of compile out to simple.  But I'm not sure all
these aliases or renaming the base mechanism helps much.

What I find is that while I'm working on one project the phone rings about the
other one.  Then I see a message in it's compilation buffer, and figure I need
to grep for something.  But I had this other grep content I don't want to
lose, since I wasn't finished with it.  How can C-x ` keep track of all this,
when I can't? My colleagues are always joking that I try to set up a
do-what-I-mean interface :-)  Alas things are nowhere near perfect yet.

> > As for tmm, what shall we do?  I feel that treating hits with column
> > information and without the same way, assuming first to last column in the
> > latter case is "clean".  With an overlay it doesn't hurt at all.
> >
> > If we then however make it an option between overlay or tmm, that would
> > mean you'd get tmm for every compiler output line.  Would you find this
> > annoying?
> 
> To be able to jump to the end of the region it is enough to simply set
> the mark at the other end, but activating the region for no reason is
> too annoying for users of transient-mark-mode since they should
> deactivate the mark by typing `C-g' after every match visit in the
> source buffer.
> 
> So what is needed is to replace (push-mark end-mk nil t) with
> (push-mark end-mk) and use highlighted overlay in all cases.

I'm fine with this and let Stef decide.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

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

[Juri Linkov]

dapfy@t-online.de (Daniel Pfeiffer) writes:
> Juri Linkov <juri@jurta.org> skribis:
>> Currently I set `compilation-error-screen-columns' to nil in
>> `grep-regexp-alist', but perhaps I should use `grep-error-screen-columns'?
>
> Ah ha!  Grep inherits from compilation, so all the like-named variables get
> passed through.  As for your setting this on every match, I don't see the
> point, not even setting this once.  This is an option, which means that people
> could set it to match the understanding of whatever external prog they use.

If grep output contains at least one escape sequence used to surround
the matching string, `compilation-error-screen-columns' should be set
to nil, because the rule in `grep-regexp-alist' calculates the column
positions of matches by subtracting the position of the first character
after the file name and line number from the position of the first escape
sequence, so these calculations are based on character positions, not
on screen columns.  This means that to find correct columns in the
source buffers compilation-error-screen-columns should be nil to
interpret calculated column numbers as characters.

>> +     (4 (list 'face nil 'invisible t 'intangible t))
>> +     (5 (list 'face compilation-column-face))
>> +     (6 (list 'face nil 'invisible t 'intangible t))
>
> I've simplified these a little and made the face customizable, defaulting to
> isearch's.

isearch-lazy-highlight-face makes more sense since it is already used
to highlight multiple matches in isearch mode which will be similar to
matches in the grep buffer.

>> diff -u -r1.322 compile.el
>> --- lisp/progmodes/compile.el	18 Jun 2004 23:00:46 -0000	1.322
>> +++ lisp/progmodes/compile.el	30 Jun 2004 03:35:13 -0000
>
>> +	(overlay-put compilation-highlight-overlay 'face next-error-face))
>
> This variable is undefined.

Sorry, that face is from another opera :-)

I posted only the relevant part of a whole patch which uses a new face
`next-error-face' and a new option `next-error-highlight' whose another
part I already posted earlier.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Juri Linkov]

Juri Linkov <juri@jurta.org> writes:
> Solving the drawbacks of invisible text is a separate issue.  There is
> a `search-invisible' option in isearch.el, but it can't find a string
> with invisible text inside it.  To discard invisible text when yanking
> it's possible to implement an option like `yank-excluded-properties'.

BTW, I noticed that the first item of etc/TODO describes exactly the
same need:

* Small but important fixes needed in existing features:

** Fix the kill/yank treatment of invisible text. At the moment,
  invisible text is placed in the kill-ring, so that the contents of
  the ring may not correspond to the text as displayed to the user. It
  ought to be possible to omit text which is invisible (due to a
  text-property, overlay, or selective display) from the kill-ring.

It would be quite easy to implement: for example, to create a new
boolean option, e.g. `yank-as-displayed', and in `insert-for-yank-1'
to handle it by deleting the text with `invisible' property and
replacing the text with `display' property by the display value
(though, I don't see how overlays could be handled here since they
are not saved with the text in the kill-ring).

Is it a right way to implement this?  This could be implemented now
given that it is described as "small but important fix".

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Luc Teirlinck]

Juri Linkov wrote:

   It would be quite easy to implement: for example, to create a new
   boolean option, e.g. `yank-as-displayed', and in `insert-for-yank-1'
   to handle it by deleting the text with `invisible' property and
   replacing the text with `display' property by the display value
   (though, I don't see how overlays could be handled here since they
   are not saved with the text in the kill-ring).

   Is it a right way to implement this?  This could be implemented now
   given that it is described as "small but important fix".

I believe that it would be quite confusing to the user if invisibility
were treated differently depending on its internal implementation
(text properties, overlays or selective display).  The text probably
should be put in the right form in the kill-ring, rather than tackling
the problem at the time of yanking.  In other words `kill-as-displayed'.

Sincerely,

Luc.

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

[Richard Stallman]

    ** Fix the kill/yank treatment of invisible text. At the moment,
      invisible text is placed in the kill-ring, so that the contents of
      the ring may not correspond to the text as displayed to the user. It
      ought to be possible to omit text which is invisible (due to a
      text-property, overlay, or selective display) from the kill-ring.

    It would be quite easy to implement: for example, to create a new
    boolean option, e.g. `yank-as-displayed',

The idea is to change kill, not change yank.

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

[Richard Stallman]

    Sure, but Linux distros as well as commercial Unices like Solaris or
    Fujitsu-Siemens' Reliant Unix have it installed by default.

Please don't call them "Linux distros".  They are more GNU than Linux,
so calling them "Linux distros" is unfair to the GNU Project.
Please call them GNU/Linux distros.  It will take you one extra second
to type those four characters, and it will help the GNU Project more
than anything else you can do in one second.

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

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> Please don't call them "Linux distros".  They are more GNU than Linux,
> so calling them "Linux distros" is unfair to the GNU Project.

BTW, I remember discovering an interesting fact that the phrase

LINUX IS GOOD

is an anagram of the phrase

GNU IDOL IS OX

(PS: that was a side joke, and nothing more :-)

-- 
Juri Linkov
http://www.jurta.org/emacs/