compilation-highlight-duration

compilation-highlight-duration

[Tak Ota]

New compile.el is very nice and I particularly like the highlight
feature.  However, the hard coded duration of 0.5 second could be too
short or too long depending on the clock speed of the users' brain.
May I suggest making it configurable?

-Tak

*** ../../pure/emacs-21.3.50/lisp/progmodes/compile.el	Thu Apr 29 21:09:13 2004
--- progmodes/compile.el	Fri Apr 30 22:10:51 2004
***************
*** 370,375 ****
--- 370,379 ----
  (defvar compilation-highlight-overlay nil
    "Overlay used to temporarily highlight compilation matches.")
  
+ (defvar compilation-highlight-duration 0.5
+   "Duration in seconds for highlighting temporarily.
+ Highlighting continues for the specified time in seconds or until input is available.")
+ 
  (defcustom compilation-error-screen-columns t
    "*If non-nil, column numbers in error messages are screen columns.
  Otherwise they are interpreted as character positions, with
***************
*** 1545,1551 ****
  		  (goto-char (match-beginning 0))
  		  (move-overlay compilation-highlight-overlay (match-beginning 0) (match-end 0)))
  	      (move-overlay compilation-highlight-overlay (point) end))
! 	    (sit-for 0.5)
  	    (delete-overlay compilation-highlight-overlay)))))))
  
--- 1549,1555 ----
  		  (goto-char (match-beginning 0))
  		  (move-overlay compilation-highlight-overlay (match-beginning 0) (match-end 0)))
  	      (move-overlay compilation-highlight-overlay (point) end))
! 	    (sit-for compilation-highlight-duration)
  	    (delete-overlay compilation-highlight-overlay)))))))
  

*** ../../pure/emacs-21.3.50/lisp/ChangeLog	Fri Apr 30 21:20:12 2004
--- ChangeLog	Fri Apr 30 22:21:23 2004
***************
*** 1,3 ****
--- 1,9 ----
+ 2004-04-30  Takaaki Ota  <Takaaki.Ota@am.sony.com>
+ 
+ 	* progmodes/compile.el (compilation-highlight-duration): New
+ 	variable.
+ 	(compilation-goto-locus): Use it to `sit-for'.
+ 
  2004-04-30  Juri Linkov  <juri@jurta.org>
  
  	* cus-edit.el (custom-mode-map):

Re: compilation-highlight-duration

[Richard Stallman]

    New compile.el is very nice and I particularly like the highlight
    feature.  However, the hard coded duration of 0.5 second could be too
    short or too long depending on the clock speed of the users' brain.

What exactly is that .5 second delay used for?  The code doesn't
have many comments and I am not sure what job it is doing.

Re: compilation-highlight-duration

[Tak Ota]

Sat, 01 May 2004 13:51:05 -0400: Richard Stallman <rms@gnu.org> wrote:

>     New compile.el is very nice and I particularly like the highlight
>     feature.  However, the hard coded duration of 0.5 second could be too
>     short or too long depending on the clock speed of the users' brain.
> 
> What exactly is that .5 second delay used for?  The code doesn't
> have many comments and I am not sure what job it is doing.

When `next-error' and `next-error-no-select' are executed the subject
line is highlighted momentarily for 0.5 seconds.  The grep mode uses
`next-error-no-select' and this momentary highlighting plays important
role to inform a user where the match exists.  The doc string of
`next-error-no-select' briefly touches upon the highlighting.

-Tak

Re: compilation-highlight-duration

[Richard Stallman]

    When `next-error' and `next-error-no-select' are executed the subject
    line is highlighted momentarily for 0.5 seconds.

I am not sure what "the subject line" means.  Is that the error
message or the source code?

Re: compilation-highlight-duration

[Tak Ota]

Mon, 03 May 2004 10:03:28 -0400: Richard Stallman <rms@gnu.org> wrote:

>     When `next-error' and `next-error-no-select' are executed the subject
>     line is highlighted momentarily for 0.5 seconds.
> 
> I am not sure what "the subject line" means.  Is that the error
> message or the source code?

It is the source code.

Re: compilation-highlight-duration

[Richard Stallman]

    It is the source code.

Why is that useful, given that the cursor will be in that line?

Re: compilation-highlight-duration

[Tak Ota]

Tue, 04 May 2004 03:43:12 -0400: Richard Stallman <rms@gnu.org> wrote:

>     It is the source code.
> 
> Why is that useful, given that the cursor will be in that line?

Your question is understandable in case of `next-error' where cursor
lands directly on the subject line.  The suggested user control is
useful in case of `next-error-no-select' which is used in Grep mode.
When traveling through matched lines in *grep* buffer the
highlighting happens in the source buffer where there is no
indication is left after highlighting is gone.

-Tak

Re: compilation-highlight-duration

[Juri Linkov]

Tak Ota <Takaaki.Ota@am.sony.com> writes:
> Tue, 04 May 2004 03:43:12 -0400: Richard Stallman <rms@gnu.org> wrote:
>>     It is the source code.
>> 
>> Why is that useful, given that the cursor will be in that line?
>
> Your question is understandable in case of `next-error' where cursor
> lands directly on the subject line.  The suggested user control is
> useful in case of `next-error-no-select' which is used in Grep mode.
> When traveling through matched lines in *grep* buffer the
> highlighting happens in the source buffer where there is no
> indication is left after highlighting is gone.

Flashing the matching lines is very distracting.  And even though
there is a variable `compilation-highlight-regexp' to disable the
highlighting, when it is disabled, there is no indication at all.

So I think a better indication method is needed.  For example,
the same methods of the compilation buffer could be used: aligning
the source file window on specified context lines (though this is
not good for source buffers), or setting the fringe arrow.

Another good indication method is persistent (i.e. non-flashing!)
overlays highlighted with a special face on matching lines in
compilation output buffer and source code buffer.

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

Re: compilation-highlight-duration

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> Flashing the matching lines is very distracting.  

After all, you hit a command C-x ` and get feedback on where
that error/match is -- I don't see how that is distracting.

>                                                   And even though
> there is a variable `compilation-highlight-regexp' to disable the
> highlighting, when it is disabled, there is no indication at all.

That's how it used to be -- the highlight is an improvement IMO.

> 
> So I think a better indication method is needed.  For example,
> the same methods of the compilation buffer could be used: aligning
> the source file window on specified context lines (though this is
> not good for source buffers), or setting the fringe arrow.

I don't think these options are any better -- 
> 
> Another good indication method is persistent (i.e. non-flashing!)
> overlays highlighted with a special face on matching lines in
> compilation output buffer and source code buffer.

IMO it would be a lot more distracting if the highlight persisted
(when should it go away?).

Re: compilation-highlight-duration

[Tak Ota]

Tue, 04 May 2004 19:55:02 +0300: Juri Linkov <juri@jurta.org> wrote:

> Tak Ota <Takaaki.Ota@am.sony.com> writes:
> > Tue, 04 May 2004 03:43:12 -0400: Richard Stallman <rms@gnu.org> wrote:
> >>     It is the source code.
> >> 
> >> Why is that useful, given that the cursor will be in that line?
> >
> > Your question is understandable in case of `next-error' where cursor
> > lands directly on the subject line.  The suggested user control is
> > useful in case of `next-error-no-select' which is used in Grep mode.
> > When traveling through matched lines in *grep* buffer the
> > highlighting happens in the source buffer where there is no
> > indication is left after highlighting is gone.
> 
> Flashing the matching lines is very distracting.  And even though
> there is a variable `compilation-highlight-regexp' to disable the
> highlighting, when it is disabled, there is no indication at all.
> 
> So I think a better indication method is needed.  For example,
> the same methods of the compilation buffer could be used: aligning
> the source file window on specified context lines (though this is
> not good for source buffers), or setting the fringe arrow.
> 
> Another good indication method is persistent (i.e. non-flashing!)
> overlays highlighted with a special face on matching lines in
> compilation output buffer and source code buffer.

I actually came to the similar idea along this line when I was writing
the previous reply.  I'd like to withdraw my original proposal and
would like to seek for better solution.

-Tak

Re: compilation-highlight-duration

[Juri Linkov]

storm@cua.dk (Kim F. Storm) writes:
> Juri Linkov <juri@jurta.org> writes:
>> Flashing the matching lines is very distracting.  
>
> After all, you hit a command C-x ` and get feedback on where
> that error/match is -- I don't see how that is distracting.

It is less noticeably when going through compilation results,
because it flashes not too often.  But during quick browsing
of the grep results, its constant blinking is unbearable.

>>                                                   And even though
>> there is a variable `compilation-highlight-regexp' to disable the
>> highlighting, when it is disabled, there is no indication at all.
>
> That's how it used to be -- the highlight is an improvement IMO.

I agree, highlight is an improvement, but not in its current
implementation.

>> So I think a better indication method is needed.  For example,
>> the same methods of the compilation buffer could be used: aligning
>> the source file window on specified context lines (though this is
>> not good for source buffers), or setting the fringe arrow.
>
> I don't think these options are any better -- 

YOU don't like the fringe arrow?! ;-)

>> Another good indication method is persistent (i.e. non-flashing!)
>> overlays highlighted with a special face on matching lines in
>> compilation output buffer and source code buffer.
>
> IMO it would be a lot more distracting if the highlight persisted
> (when should it go away?).

For example, after the key press.

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

RE: compilation-highlight-duration

[Drew Adams]

Juri Linkov <juri@jurta.org> writes:

> > Another good indication method is persistent (i.e. non-flashing!)
> > overlays highlighted with a special face on matching lines in
> > compilation output buffer and source code buffer.
>
> IMO it would be a lot more distracting if the highlight persisted
> (when should it go away?).

It should go away on user request.

FYI -

My Emacs-20 code highlighted grep regexps:

 - everywhere, in the compilation buffer
 - one by one, in source-code buffers, when next-error was called.

Highlighting the source code this way helps a user keep track of where he's
been.

The highlighting was persistent.

The compilation-buffer highlighting was done with font-lock. I did not
provide a way for a user to remove just this regexp highlighting, but that
might be useful as a toggle. I know I sometimes toggle search-page
highlighting on/off when using the Google toolbar.

The source-code regexp highlighting was not done with font-lock. A user
could remove it (without affecting font-lock highlighting) in any of several
ways:

 - font-lock-mode twice (easy, if it's bound to a key)
 - revert the buffer
 - use my command `highlight' (with negative prefix arg) on a region
 - ...

 Drew

P.S. Similarly, to help users keep track of lines they've visited, I also
highlighted visited line numbers in buffer *Occur*.

Re: compilation-highlight-duration

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> 
> YOU don't like the fringe arrow?! ;-)

I don't like a persistent fringe arrow :-)

> > IMO it would be a lot more distracting if the highlight persisted
> > (when should it go away?).
> 
> For example, after the key press.

Ok, yes, that would be a possibility.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: compilation-highlight-duration

[Tak Ota]

Tue, 04 May 2004 19:55:02 +0300: Juri Linkov <juri@jurta.org> wrote:

> So I think a better indication method is needed.  For example,
> the same methods of the compilation buffer could be used: aligning
> the source file window on specified context lines (though this is
> not good for source buffers), or setting the fringe arrow.
> 
> Another good indication method is persistent (i.e. non-flashing!)
> overlays highlighted with a special face on matching lines in
> compilation output buffer and source code buffer.

How about leaving the highlight until user takes an action so that it
does not annoyingly persist?

-Tak

*** ../../../pure/emacs-21.3.50/lisp/progmodes/compile.el	Mon May  3 07:59:11 2004
--- compile.el	Tue May  4 14:27:16 2004
***************
*** 1564,1570 ****
  		  (goto-char (match-beginning 0))
  		  (move-overlay compilation-highlight-overlay (match-beginning 0) (match-end 0)))
  	      (move-overlay compilation-highlight-overlay (point) end))
! 	    (sit-for 0.5)
  	    (delete-overlay compilation-highlight-overlay)))))))
  
--- 1564,1570 ----
  		  (goto-char (match-beginning 0))
  		  (move-overlay compilation-highlight-overlay (match-beginning 0) (match-end 0)))
  	      (move-overlay compilation-highlight-overlay (point) end))
! 	    (sit-for 268435455) ;; eight and half years or until input is available
  	    (delete-overlay compilation-highlight-overlay)))))))

Re: compilation-highlight-duration

[Stefan Monnier]

> ! 	    (sit-for 268435455)

Yuck!!  What's wrong with most-positive-fixnum?


        Stefan

Re: compilation-highlight-duration

[Tak Ota]

05 May 2004 13:33:52 -0400: Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > ! 	    (sit-for 268435455)
> 
> Yuck!!  What's wrong with most-positive-fixnum?

Sorry for being rude.  I have no problem with most-positive-fixnum.

-Tak

Re: compilation-highlight-duration

[Richard Stallman]

    Your question is understandable in case of `next-error' where cursor
    lands directly on the subject line.  The suggested user control is
    useful in case of `next-error-no-select' which is used in Grep mode.

Could you explain why and how you use next-error-no-select in Grep
mode?  I would have thought that is something useful only for programs
to call.  I don't see a use for next-error-no-select has, except as a
subroutine to build other things on.

So I tend to think that the caller of next-error-no-select should
arrange to show the user the line in question.  next-error-no-select
should not do so itself.

Re: compilation-highlight-duration

[Tak Ota]

Wed, 05 May 2004 16:20:23 -0400: Richard Stallman <rms@gnu.org> wrote:

>     Your question is understandable in case of `next-error' where cursor
>     lands directly on the subject line.  The suggested user control is
>     useful in case of `next-error-no-select' which is used in Grep mode.
> 
> Could you explain why and how you use next-error-no-select in Grep
> mode?  I would have thought that is something useful only for programs
> to call.  I don't see a use for next-error-no-select has, except as a
> subroutine to build other things on.

It is not my choice.  I use the functions by typing 'n' and 'p' in the
*grep* buffer, defined in grep-mode-map.  As long as the highlight
does not disappear too quickly I feel comfortable with this user
interface.

> So I tend to think that the caller of next-error-no-select should
> arrange to show the user the line in question.  next-error-no-select
> should not do so itself.

I don't disagree with you how it should be fixed.  I'm just suggesting
that current momentary line flashing can be annoying to some people
including myself.

-Tak

Re: compilation-highlight-duration

[Stefan Monnier]

> Could you explain why and how you use next-error-no-select in Grep
> mode?  I would have thought that is something useful only for programs
> to call.  I don't see a use for next-error-no-select has, except as a
> subroutine to build other things on.

No, it's actually a command and I've never seen it used as a function.


        Stefan

Re: compilation-highlight-duration

[Thien-Thi Nguyen]

Tak Ota <Takaaki.Ota@am.sony.com> writes:

   momentary line flashing can be annoying to
   some people including myself.

perhaps for a duration value D:
 -   (not D) => omit highlighting
 - (zerop D) => keep highlighted until user input
 -   (< 0 D) => highlight for D seconds then unhighlight
 -   (> 0 D) => like (zerop D) but wait -D seconds before starting

i personally would set D to be -2 (or thereabouts) under this scheme.
this way, stepping quickly through the hits would result in no visual
distraction whatsoever, while pausing would clearly show the hit w/o
danger of accidentally missing it (due to some other non-emacs-related
distraction ;-), as possible w/ (< 0 D).

we could get real fancy and define all keystrokes like they do on
(musical synthesizer) keyboards: attack, decay, hold, release; but
that wouldn't work on console, oh well...

thi

Re: compilation-highlight-duration

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Your question is understandable in case of `next-error' where cursor
>     lands directly on the subject line.  The suggested user control is
>     useful in case of `next-error-no-select' which is used in Grep mode.
> 
> Could you explain why and how you use next-error-no-select in Grep
> mode?  I would have thought that is something useful only for programs
> to call.  I don't see a use for next-error-no-select has, except as a
> subroutine to build other things on.

next-error-no-select is a command, not a subroutine.

It is useful in grep-mode as a way to browse the grep matches (using n
and p keys) without leaving the *grep* buffer until you actually find
some interesting match.

Re: compilation-highlight-duration

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> I think that highlighting is useful *only* in grep-mode, when
> the cursor is not displayed in non-selected source window
> (i.e. cursor-in-non-selected-windows is nil).  And highlighting
> is pretty useless in `next-error' which selects a source window,
> because in this case the location is indicated by the cursor.

I still think it is useful in the other contexts too.  YMMV.

> 
> But currently it's not possible to highlight the source buffer
> only in `next-error-no-select'.  Perhaps a new argument should be
> added to `next-error' and `compilation-next-error-function' indicating
> whether highlighting is desirable and in what fashion (overlay flashing
> delay duration, fringe arrow, etc.)

It is ok to make this more configurable, but for 21.4 (feature
freeze!) we should limit this to a new compilation-highlight-duration
variable that can be set to one of the following values:

        0 => don't highlight
        N > 0 => highlight for N seconds (N may be float)

Any other value also means don't highlight.

The remaining question is whether the default should be 0 or 0.5

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: compilation-highlight-duration

[Juri Linkov]

storm@cua.dk (Kim F. Storm) writes:
> Richard Stallman <rms@gnu.org> writes:
>
>>     Your question is understandable in case of `next-error' where cursor
>>     lands directly on the subject line.  The suggested user control is
>>     useful in case of `next-error-no-select' which is used in Grep mode.
>> 
>> Could you explain why and how you use next-error-no-select in Grep
>> mode?  I would have thought that is something useful only for programs
>> to call.  I don't see a use for next-error-no-select has, except as a
>> subroutine to build other things on.
>
> next-error-no-select is a command, not a subroutine.
>
> It is useful in grep-mode as a way to browse the grep matches (using n
> and p keys) without leaving the *grep* buffer until you actually find
> some interesting match.

I think that highlighting is useful *only* in grep-mode, when
the cursor is not displayed in non-selected source window
(i.e. cursor-in-non-selected-windows is nil).  And highlighting
is pretty useless in `next-error' which selects a source window,
because in this case the location is indicated by the cursor.

But currently it's not possible to highlight the source buffer
only in `next-error-no-select'.  Perhaps a new argument should be
added to `next-error' and `compilation-next-error-function' indicating
whether highlighting is desirable and in what fashion (overlay flashing
delay duration, fringe arrow, etc.)

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

Re: compilation-highlight-duration

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> The purpose of the feature freeze is not to release half-baked
> stuff.  If we introduce this variable in 21.4, then it should remain
> with upwards-compatible semantics also in future versions.  If we
> find that this feature is likely to be replaced by something
> different in future versions, we should leave it out completely for
> now.
> 
> There is no point in introducing a feature that will only exist for a
> single release.

My point is that the highlight is there now; some people don't like it,
some people want a different duration -- we can achieve that easily
with a new variable to tune the existing feature.

I don't think the existing feature shall go away in future releases,
but we may add different methods of highlighting, e.g. a new
compilation-highlight-method variable, and we may add extended
values for -duration (such as sticky overlay or whatever).

Also the underlaying implementation may change.

But in every case, the -duration variable in the proposed form will be
(I believe) upwards compatible with such future extensions.
Otherwise, I would not have suggested it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: compilation-highlight-duration

[David Kastrup]

no-spam@cua.dk (Kim F. Storm) writes:

> Juri Linkov <juri@jurta.org> writes:
>
> > But currently it's not possible to highlight the source buffer
> > only in `next-error-no-select'.  Perhaps a new argument should be
> > added to `next-error' and `compilation-next-error-function'
> > indicating whether highlighting is desirable and in what fashion
> > (overlay flashing delay duration, fringe arrow, etc.)
> 
> It is ok to make this more configurable, but for 21.4 (feature
> freeze!) we should limit this to a new compilation-highlight-duration
> variable that can be set to one of the following values:
> 
>         0 => don't highlight
>         N > 0 => highlight for N seconds (N may be float)
> 
> Any other value also means don't highlight.
> 
> The remaining question is whether the default should be 0 or 0.5

The purpose of the feature freeze is not to release half-baked
stuff.  If we introduce this variable in 21.4, then it should remain
with upwards-compatible semantics also in future versions.  If we
find that this feature is likely to be replaced by something
different in future versions, we should leave it out completely for
now.

There is no point in introducing a feature that will only exist for a
single release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: compilation-highlight-duration

[Richard Stallman]

    > But currently it's not possible to highlight the source buffer
    > only in `next-error-no-select'.  Perhaps a new argument should be
    > added to `next-error' and `compilation-next-error-function' indicating
    > whether highlighting is desirable and in what fashion (overlay flashing
    > delay duration, fringe arrow, etc.)

I think we should make next-error and next-error-no-select use a common
subroutine.  Then next-error-no-select would do this highlighting.
next-error would not do the highlighting.

Re: compilation-highlight-duration

[Richard Stallman]

    There is no point in introducing a feature that will only exist for a
    single release.

I completely agree.

Re: compilation-highlight-duration

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     > But currently it's not possible to highlight the source buffer
>     > only in `next-error-no-select'.  Perhaps a new argument should be
>     > added to `next-error' and `compilation-next-error-function' indicating
>     > whether highlighting is desirable and in what fashion (overlay flashing
>     > delay duration, fringe arrow, etc.)
>
> I think we should make next-error and next-error-no-select use a common
> subroutine.  Then next-error-no-select would do this highlighting.
> next-error would not do the highlighting.

This is not possible with the current implementation because
`next-error-no-select' calls the `next-error'.

However, creating two similar user options and binding one of them in
`next-error-no-select' will allow the user to specify preferred
highlighting methods separately for selected and non-selected
error visiting.

(defcustom error-highlight nil
  :type '(choice (const :tag "Persistent overlay" t)
		 (const :tag "No highlighting" nil)
		 (const :tag "Fringe arrow" 'fringe-arrow)
		 (integer :tag "Delay"))
  :group 'compilation
  :version "21.4")

(defcustom error-highlight-no-select 0.5
  :type '(choice (const :tag "Persistent overlay" t)
		 (const :tag "No highlighting" nil)
		 (const :tag "Fringe arrow" 'fringe-arrow)
		 (integer :tag "Delay"))
  :group 'compilation
  :version "21.4")

(defun next-error-no-select (n)
  (interactive "p")
  (let ((error-highlight error-highlight-no-select))
    (next-error n))
  (pop-to-buffer next-error-last-buffer))

And `compilation-goto-locus' will use the variable `error-highlight'
to perform highlighting accordingly.

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

Re: compilation-highlight-duration

[Richard Stallman]

    However, creating two similar user options and binding one of them in
    `next-error-no-select' will allow the user to specify preferred
    highlighting methods separately for selected and non-selected
    error visiting.

Does anyone actually want the highlighting after using next-error?
If we don't need that feature, I'd say just move the highlighting
code into next-error-no-select.

Re: compilation-highlight-duration

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     However, creating two similar user options and binding one of them in
>     `next-error-no-select' will allow the user to specify preferred
>     highlighting methods separately for selected and non-selected
>     error visiting.
> 
> Does anyone actually want the highlighting after using next-error?
> If we don't need that feature, I'd say just move the highlighting
> code into next-error-no-select.

FWIW, I want it!  Firstly, it is consistent behaviour.

Secondly, I like the highlighting that instantly shows me the failing line,
instead of having to look for the line containing the cursor -- blinking
the whole line is faster (for me) that having to look for the cursor.

Having two timers, one for next-error and one for -no-select would be the
most flexible solution.  Alternatively, there could be one timer which
works for both if set to a number, or if set to a cons (NO-SELECT . SELECT)
it specifies different timers for the two functions.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: compilation-highlight-duration

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 09 May 2004 21:12:40 +0200
> 
> Secondly, I like the highlighting that instantly shows me the failing line,
> instead of having to look for the line containing the cursor -- blinking
> the whole line is faster (for me) that having to look for the cursor.

Same here.  I fell in love with this feature as soon as I first saw
it at work.

Finding the cursor could be particularly hard on a text terminal.

Re: compilation-highlight-duration

[Stefan Daschek]

storm@cua.dk (Kim F. Storm) writes:

>> Does anyone actually want the highlighting after using next-error?
>> If we don't need that feature, I'd say just move the highlighting
>> code into next-error-no-select.
>
> FWIW, I want it!  Firstly, it is consistent behaviour.

I like it very much, too. Only the use of region-face for highlight
tends to be a bit confusing in the first moment.

Re: compilation-highlight-duration

[Juri Linkov]

storm@cua.dk (Kim F. Storm) writes:
> Richard Stallman <rms@gnu.org> writes:
>> Does anyone actually want the highlighting after using next-error?
>> If we don't need that feature, I'd say just move the highlighting
>> code into next-error-no-select.
>
> FWIW, I want it!  Firstly, it is consistent behaviour.
>
> Secondly, I like the highlighting that instantly shows me the failing line,
> instead of having to look for the line containing the cursor -- blinking
> the whole line is faster (for me) that having to look for the cursor.

Adding `next-error-highlight' and `next-error-highlight-no-select'
reveals one problem.  When these user options are defined by
`defcustom' it requires to specify a group name under which they
should be placed.  The current logic by using the `next-error-' prefix
suggests the group name `next-error'.  But it would be misleading for modes
other than compile.  For grep, diff and occur this name makes no sense.

There are aliases `goto-next-locus' and `next-match' for `next-error'
which suggest a better name.  Perhaps something like `follow-locus'
would be better?

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

Re: compilation-highlight-duration

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> Adding `next-error-highlight' and `next-error-highlight-no-select'
> reveals one problem.  When these user options are defined by
> `defcustom' it requires to specify a group name under which they
> should be placed.  The current logic by using the `next-error-' prefix
> suggests the group name `next-error'.  But it would be misleading for modes
> other than compile.  For grep, diff and occur this name makes no sense.
> 
> There are aliases `goto-next-locus' and `next-match' for `next-error'
> which suggest a better name.  Perhaps something like `follow-locus'
> would be better?

I would NEVER think of that name as having anything to do with this...

What about the group named "matching" (occur already uses that).


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

next-error refactoring (was: compilation-highlight-duration)

[Ted Zlatanov]

On Fri, 28 May 2004, juri@jurta.org wrote:

> Adding `next-error-highlight' and `next-error-highlight-no-select'
> reveals one problem.  When these user options are defined by
> `defcustom' it requires to specify a group name under which they
> should be placed.  The current logic by using the `next-error-' prefix
> suggests the group name `next-error'.  But it would be misleading for modes
> other than compile.  For grep, diff and occur this name makes no
> sense.

I think it makes sense to have a next-error group for other modes.

Is it time to make next-error a minor mode with its own next-error.el
file?  It seems like a useful thing, instead of manually hooking it
into all the user modes.  The minor mode could provide hooks that
would replace the current code; this would also facilitate adoption
by other modes.

Ted

Re: next-error refactoring

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> Is it time to make next-error a minor mode with its own next-error.el
> file?  It seems like a useful thing, instead of manually hooking it
> into all the user modes.  The minor mode could provide hooks that
> would replace the current code; this would also facilitate adoption
> by other modes.

Yes, making it a minor mode with its own file would be a very useful thing!

However, I think the name `next-error' is not right anymore when
applied to non-`compile' modes like `grep', `diff', `occur', and
possible future modes.

Its name should clearly constitute its essence which is to visit the
locations described in one buffer sequentially or in a user-defined
order in other buffers.

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

Re: next-error refactoring

[Ted Zlatanov]

On Fri, 28 May 2004, juri@jurta.org wrote:

> Yes, making [next-error] a minor mode with its own file would be a
> very useful thing!
> 
> However, I think the name `next-error' is not right anymore when
> applied to non-`compile' modes like `grep', `diff', `occur', and
> possible future modes.

This was already discussed, and the *-locus and *-match aliases were
proposed.

I have no preference regarding the function names, but the *minor
mode* should be called next-dwim IMO.  I can't think of any other
names that would fit the mode, as opposed to the function.

> Its name should clearly constitute its essence which is to visit the
> locations described in one buffer sequentially or in a user-defined
> order in other buffers.

Feel free to make suggestions, everyone :)

Ted

Re: compilation-highlight-duration

[Richard Stallman]

    There are aliases `goto-next-locus' and `next-match' for `next-error'
    which suggest a better name.  Perhaps something like `follow-locus'
    would be better?

I agree users would not find that name.  Perhaps it would be useful to
add a feature for aliases for custom groups, and use it here.

Re: next-error refactoring (was: compilation-highlight-duration)

[Richard Stallman]

    Is it time to make next-error a minor mode with its own next-error.el
    file?

We already have a minor mode for this: compilation-minor-mode.  What
code goes in what file is a completely separate question.

Re: next-error refactoring

[Ted Zlatanov]

On Sat, 29 May 2004, rms@gnu.org wrote:

    > Is it time to make next-error a minor mode with its own next-error.el
>     file?
> 
> We already have a minor mode for this: compilation-minor-mode.  

Yes, but the name "compilation-minor-mode" hardly addresses the DWIM
nature of next-error as it stands now, and the compilation-minor-mode
has other side effects (fontification, for instance).

> What code goes in what file is a completely separate question.

Yes, and I think maintenance will be easier if next-error
functionality is in its own file.  This is from my limited perspective
on Emacs, of course.

Ted

Re: next-error refactoring

[Richard Stallman]

    Yes, and I think maintenance will be easier if next-error
    functionality is in its own file.

Why do you think it would matter?

next-error and related functions are just 150 lines.
I don't want to split things into new files which are so small.

Re: next-error refactoring

[Richard Stallman]

	> Is it time to make next-error a minor mode with its own next-error.el
    >     file?
    > 
    > We already have a minor mode for this: compilation-minor-mode.  

    Yes, but the name "compilation-minor-mode" hardly addresses the DWIM
    nature of next-error as it stands now, and the compilation-minor-mode
    has other side effects (fontification, for instance).

Those go together because they are used together.

Introducing unnecessary levels of abstraction for small things
creates clutter.  We do not want a separate mode for next-error
parsing alone, distinct from the rest of error handling.

Re: next-error refactoring

[Ted Zlatanov]

On Wed, 02 Jun 2004, rms@gnu.org wrote:

    > Yes, and I think maintenance will be easier if next-error
>     functionality is in its own file.
> 
> Why do you think it would matter?

It's easier to maintain a file when it has a single purpose.
simple.el gets modified a lot.

It's not a big deal though.

> next-error and related functions are just 150 lines.
> I don't want to split things into new files which are so small.

Understood, disregard my suggestion then.

Ted

Re: next-error refactoring

[Ted Zlatanov]

On Wed, 02 Jun 2004, rms@gnu.org wrote:

	>> Is it time to make next-error a minor mode with its own next-error.el
>     >     file?
>     > 
>     > We already have a minor mode for this: compilation-minor-mode.
> 
>     Yes, but the name "compilation-minor-mode" hardly addresses the DWIM
>     nature of next-error as it stands now, and the compilation-minor-mode
>     has other side effects (fontification, for instance).
> 
> Those go together because they are used together.
> 
> Introducing unnecessary levels of abstraction for small things
> creates clutter.  

I'm trying to make next-error a universal "next DWIM" interface, and
being tied to compilation-minor-mode will hamper that effort.  For
instance, it would look very strange if compilation-minor-mode was on
in a mail article summary, even though next-error (or some sensibly
named alias) could make sense for moving to the next article.  It
would be easier to name hooks for next-error, as well, if it had its
own mode.  I would like to create hooks that developers can easily use
to register their next-error capability, instead of the current
situation where next-error mode has to be enabled by magically setting
a variable, and discovering next-error buffers is an error-prone
algorithm.

I'm thinking of next-error-register and next-error-unregister
functions a developer would call in a buffer; to register a
next-error-function has to be provided (plus other things, probably)
and in return the buffer is registered as a next-error capable buffer.

Also, users will be less confused if next-error has its own minor
mode.

> We do not want a separate mode for next-error parsing alone,
> distinct from the rest of error handling.

Understood.  I would like to make next-error more than that.

Ted

Re: next-error refactoring

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> I'm trying to make next-error a universal "next DWIM" interface, and

I think "next DWIM" is not the right name.  "Do What I Mean" is too
general term and doesn't describe precisely the purpose of the mode
which basically is extracting locations from the buffer contents and
visiting them in other buffers.

With all that said, I have a better suggestion: to extend the existing
`master-mode' which has a similar purpose.  It associates the current
buffer (the master) with another buffer (the slave) and allows
operating on the slave buffer from the master.  When applied to
compilation/grep/diff/occur, the master will mean the buffer with
locations, and the slave will mean the source buffers where locations
are visited.

> It would be easier to name hooks for next-error, as well, if it had
> its own mode.  I would like to create hooks

It would be very good if you will add more hooks.  I already
encountered many situations where more hooks are needed to make the
whole framework more extensible.  For example, to add a hook that will
allow grep/diff to visit files in view mode, and will kill a read-only
source buffer when another buffer is visited after subsequent invocation
of `next-error'.

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

Re: next-error refactoring

[Richard Stallman]

    I'm trying to make next-error a universal "next DWIM" interface,

I think it is better if we don't do that now; I am not sure it is
a good idea.

However, if you make a proposal and argue for it, I will think about
it.

Re: next-error refactoring

[Ted Zlatanov]

On Thu, 03 Jun 2004, rms@gnu.org wrote:

    > I'm trying to make next-error a universal "next DWIM" interface,
> 
> I think it is better if we don't do that now; I am not sure it is
> a good idea.
> 
> However, if you make a proposal and argue for it, I will think about
> it.

I've made the case several times on this mailing list.  There are two
reasons:

1) There are many modes that can benefit from a next-error (or
   whatever it's called by then) approach.  In code, for instance,
   next-error could move between functions.  In dired, it could move
   to the next file.  In W3 it could go back/forward in the history
   or between links.

2) Approaching next-error as we do now, in a haphazard fashion,
   implemented specifically in every mode that needs to use it, is
   painful for the developer.  It's much easier to provide hooks, a
   keymap, and all the other niceties of a standalone minor mode.
   Users will certainly appreciate that too.  Also, if and when
   next-error changes, developers won't have to change their code.

Ted

Re: next-error refactoring

[Ted Zlatanov]

On Fri, 04 Jun 2004, juri@jurta.org wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I'm trying to make next-error a universal "next DWIM" interface, and
> 
> I think "next DWIM" is not the right name.  "Do What I Mean" is too
> general term and doesn't describe precisely the purpose of the mode
> which basically is extracting locations from the buffer contents and
> visiting them in other buffers.

I would like "next DWIM," not just "next place I'm supposed to visit."
I gave some examples in my reply to RMS's post.

> With all that said, I have a better suggestion: to extend the existing
> `master-mode' which has a similar purpose.  It associates the current
> buffer (the master) with another buffer (the slave) and allows
> operating on the slave buffer from the master.  When applied to
> compilation/grep/diff/occur, the master will mean the buffer with
> locations, and the slave will mean the source buffers where locations
> are visited.

This could be useful for specific cases, but I don't think
necessarily in all the useful cases :)

> It would be very good if you will add more hooks.  I already
> encountered many situations where more hooks are needed to make the
> whole framework more extensible.  For example, to add a hook that will
> allow grep/diff to visit files in view mode, and will kill a read-only
> source buffer when another buffer is visited after subsequent invocation
> of `next-error'.

I'll work on that when RMS (and others) reply to my proposal about
the future of next-error mode.  That will make a big difference in
how I implement things.

Ted

Re: next-error refactoring

[Tak Ota]

I agree.  I'm often irritated the difference in user interface
between compilation, grep and occur.

-Tak

Mon, 07 Jun 2004 12:11:47 -0400: Ted Zlatanov <tzz@lifelogs.com> wrote:

> On Thu, 03 Jun 2004, rms@gnu.org wrote:
> 
>     > I'm trying to make next-error a universal "next DWIM" interface,
> > 
> > I think it is better if we don't do that now; I am not sure it is
> > a good idea.
> > 
> > However, if you make a proposal and argue for it, I will think about
> > it.
> 
> I've made the case several times on this mailing list.  There are two
> reasons:
> 
> 1) There are many modes that can benefit from a next-error (or
>    whatever it's called by then) approach.  In code, for instance,
>    next-error could move between functions.  In dired, it could move
>    to the next file.  In W3 it could go back/forward in the history
>    or between links.
> 
> 2) Approaching next-error as we do now, in a haphazard fashion,
>    implemented specifically in every mode that needs to use it, is
>    painful for the developer.  It's much easier to provide hooks, a
>    keymap, and all the other niceties of a standalone minor mode.
>    Users will certainly appreciate that too.  Also, if and when
>    next-error changes, developers won't have to change their code.
> 
> Ted
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: next-error refactoring

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     Yes, and I think maintenance will be easier if next-error
>     functionality is in its own file.
>
> Why do you think it would matter?
>
> next-error and related functions are just 150 lines.
> I don't want to split things into new files which are so small.

It has a big potential to grow.  I have about 40 lines uninstalled
(next-error-highlight related code), because of unresolved issues
regarding the right name of the whole framework.  Plus Dan Nicolaescu
proposed the code for next-error-follow-minor-mode (50 lines) which
should go into the same file.  So even without Ted's plans to
extend it, this gives enough lines to split it into a new file.

BTW, replace.el should be split too.  All occur related functions
should be moved from replace.el into a separate file occur.el, because
they are already 460 lines.  This is big enough to justify its
refactoring.  Moreover, occur absolutely don't fit into replace.el
neither by its name nor by description which is according to the first
line of replace.el is "replace.el --- replace commands for Emacs".

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

Re: next-error refactoring

[Richard Stallman]

    1) There are many modes that can benefit from a next-error (or
       whatever it's called by then) approach.  In code, for instance,
       next-error could move between functions.

There is already an easy way to move between functions: C-M-a and
C-M-e.  However, I see no resemblance between that and next-error.

						 In dired, it could move
       to the next file.

I do see the resemblance between that and next-error.  However, it
would probably be simpler to define the same keys (more or less) with
parallel meanings but completely different code.

			  In W3 it could go back/forward in the history
       or between links.

I think that could perhaps be implemented using the existing
next-error mechanism, if that is useful.

    2) Approaching next-error as we do now, in a haphazard fashion,
       implemented specifically in every mode that needs to use it, is
       painful for the developer.  It's much easier to provide hooks, a
       keymap, and all the other niceties of a standalone minor mode.

To use a single set of key bindings, defined in just one place, would
be desirable.  I don't know whether it is possible.  Making each of
these modes have good key bindings is the first priority.  If it turns
out that a single set if bindings will work well for all of them, we
could easily write a subroutine to make those bindings in whatever
keymap.  That would achieve the simplification you are looking for.

The rest of the minor mode mechanism would be unnecessary, perhaps
even counterproductive.  We certainly do not want it to appear *to the
user* as a separate minor mode.  That would only be clutter, and suggest
to the user that he might want to consider turning the minor mode off,
which would always be a mistake.

Re: next-error refactoring

[Stefan Monnier]

> 1) There are many modes that can benefit from a next-error (or
>    whatever it's called by then) approach.  In code, for instance,
>    next-error could move between functions.  In dired, it could move
>    to the next file.  In W3 it could go back/forward in the history
>    or between links.

To me the concept of "next-error" refers to something that has the
following properties:
- every entry in the list of things to step through refers to a location
  in another buffer.
- you want to step through the locations referred to rather than only
  stepping through the entries themselves.
So I don´t see how it can usefully be applied to functions in a file.

I see that it can be handy to C-x ` through a list of files in dired in
some particular cases, tho.  But we then need to design some way to
distinguish between buffers where this is common and those where it is not,
otherwise people will be annoyed that C-x ` is always captured by their
dired buffer instead of compile, or things like that.  We´ve already seen
such problems with my adding C-x ` support to diff-mode.

> 2) Approaching next-error as we do now, in a haphazard fashion,
>    implemented specifically in every mode that needs to use it, is
>    painful for the developer.  It's much easier to provide hooks, a
>    keymap, and all the other niceties of a standalone minor mode.
>    Users will certainly appreciate that too.  Also, if and when
>    next-error changes, developers won't have to change their code.

I agree that more of the next-error code should be in the generic part of
the code (all the window-management comes to mind), but I also think this
is better done post-21.4.  Especially since we still don´t have any sample
code to try and we´re not sure what the new behavior should be.


        Stefan

Re: next-error refactoring

[Richard Stallman]

    It has a big potential to grow.  I have about 40 lines uninstalled
    (next-error-highlight related code), because of unresolved issues
    regarding the right name of the whole framework.

Please assume that the name will not change.

      Plus Dan Nicolaescu
    proposed the code for next-error-follow-minor-mode (50 lines) which
    should go into the same file.  So even without Ted's plans to
    extend it, this gives enough lines to split it into a new file.

That is still way too small for a new file to be desirable.

    BTW, replace.el should be split too.  All occur related functions
    should be moved from replace.el into a separate file occur.el, because
    they are already 460 lines.

I see no reason to split them.  Please assume the files will
stay the same for now, and focus on issues of how to change the code.


occur has been in replace.el since the file was first written, along
with the commands how-many, keep-lines, and flush-lines, which it
is traditionally grouped with.

Re: next-error refactoring

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> To me the concept of "next-error" refers to something that has the
> following properties:
> - every entry in the list of things to step through refers to a location
>   in another buffer.
> - you want to step through the locations referred to rather than only
>   stepping through the entries themselves.

I completely agree on the purpose of the "next-error" framework.

> So I don´t see how it can usefully be applied to functions in a file.

This can be applied to functions when their locations are listed in
another buffer by commands that operate on function names, for example,
`list-tags' (which is not "next-error" capable now), `list-imenu',
`list-outlines' (there are no such functions yet, but they would be useful).

> I see that it can be handy to C-x ` through a list of files in dired in
> some particular cases, tho.  But we then need to design some way to
> distinguish between buffers where this is common and those where it is not,
> otherwise people will be annoyed that C-x ` is always captured by their
> dired buffer instead of compile, or things like that.

I agree.  This should be done only when requested specially by users
in dired buffers or in buffers created by `find-dired' or `locate'.

> I agree that more of the next-error code should be in the generic part of
> the code (all the window-management comes to mind), but I also think this
> is better done post-21.4.  Especially since we still don´t have any sample
> code to try and we´re not sure what the new behavior should be.

I think it's better at least to establish the infrastructure before the next
Emacs release than to release it in the current incomplete (though, usable)
state, if possible.  That means to continue its development at an unhurried pace,
and include it if it will be completely ready before the next release.

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

Re: next-error refactoring

[Richard Stallman]

    This can be applied to functions when their locations are listed in
    another buffer by commands that operate on function names, for example,
    `list-tags' (which is not "next-error" capable now),

That is a good idea.  However, I don't see a need to change frameworks
based on that.

							 `list-imenu',
    `list-outlines' (there are no such functions yet, but they would be useful).

I am not sure that a list-imenu command would make sense.  But
we can add connections to next-error in other places where that
does make sense.

Re: next-error refactoring

[Ted Zlatanov]

On Tue, 08 Jun 2004, rms@gnu.org wrote:

> To use a single set of key bindings, defined in just one place, would
> be desirable.  I don't know whether it is possible.  Making each of
> these modes have good key bindings is the first priority.  If it turns
> out that a single set if bindings will work well for all of them, we
> could easily write a subroutine to make those bindings in whatever
> keymap.  That would achieve the simplification you are looking for.
> 
> The rest of the minor mode mechanism would be unnecessary, perhaps
> even counterproductive.  We certainly do not want it to appear *to the
> user* as a separate minor mode.  That would only be clutter, and suggest
> to the user that he might want to consider turning the minor mode off,
> which would always be a mistake.

I see.  That makes sense.  As long as we can achieve the two goals
of

1) a unified user interface

2) a simple API for developers to use next-error

I'm happy without a minor mode, especially considering the reasons
you mention against it.

Has this (API to install keybindings) been done for another
package, so I don't start from scratch?

Thanks
Ted

Re: next-error refactoring

[Richard Stallman]

    Has this (API to install keybindings) been done for another
    package, so I don't start from scratch?

That part is trivial.  The real job is to make a common set of
bindings for these various modes.  I suggest you focus on that task.

Re: next-error refactoring

[Ted Zlatanov]

On Sat, 12 Jun 2004, rms@gnu.org wrote:

    > Has this (API to install keybindings) been done for another
>     package, so I don't start from scratch?
> 
> That part is trivial.  The real job is to make a common set of
> bindings for these various modes.  I suggest you focus on that task.

Can I get a list of suggested modes that might benefit from next-error
support?  Everyone, please send me your suggestions.

So far we have:

compilation-mode
grep (which uses compilation-mode)
occur-mode

Other possibilities:

emerge
diff-mode
(please add your suggestions)

When I have a list of modes I can look at the key binding problems
between them all.

Thanks
Ted

Re: next-error refactoring

[Juri Linkov]

Ted Zlatanov <tzz@lifelogs.com> writes:
> Can I get a list of suggested modes that might benefit from next-error
> support?  Everyone, please send me your suggestions.
>
> So far we have:
>
> compilation-mode
> grep (which uses compilation-mode)
> occur-mode
>
> Other possibilities:
>
> emerge
> diff-mode

AFAICS, diff-mode belongs to the "what we have" category since it
already supports `next-error'.

> (please add your suggestions)

I think existing modes are enough to create an unified set of key
bindings. These modes are quite heterogeneous by their functionality,
so you can get good coverage of needs for key bindings.

If you want to add next-error support for more modes, you might consider
etags, dired-do-search, find-grep-dired.

> When I have a list of modes I can look at the key binding problems
> between them all.

Please take into account conclusions from the discussion started from
http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg01452.html
http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00023.html

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

Re: next-error refactoring

[Ted Zlatanov]

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

On Thu, 01 Jul 2004, juri@jurta.org wrote:

> If you want to add next-error support for more modes, you might consider
> etags, dired-do-search, find-grep-dired.

I haven't looked at etags, but here's a patch for dired.el that will
add next-error support.  That will support find-grep-dired,
dired-do-search, and all other dired-mode usages.  There's two issues:

1) by default, most users will probably not want this next-error
   support so I added a variable dired-next-error-support that's nil
   by default.  This is my conjecture so I may be wrong.

2) I am not sure of the right way to move negative distances in
   dired-mode, since not every line is a file.  I reuse the
   dired-goto-next-nontrivial-file function for forward motion and
   ignore negative distances for now.  I could write my own, but was
   wondering if something already existed for negative motion.

Please comment and I hope this can make it in Emacs eventually (it's
not ready as it is).  I am attaching a context patch.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dired-next-error.patch --]
[-- Type: text/x-patch, Size: 2069 bytes --]

*** /usr/src/emacs/lisp/dired.el	Wed Jul 14 18:59:08 2004
--- /home/tzz/emacs/mine/dired.el	Mon Sep 13 15:09:54 2004
***************
*** 215,220 ****
--- 215,227 ----
    :type '(alist :key-type regexp :value-type string)
    :version "21.4")
  
+ ;; should we use next-error support?
+ (defcustom dired-next-error-support nil
+   "Specifies whether Dired should support the next-error
+   framework."
+   :group 'dired
+   :type 'boolean)
+ 
  ;; Internal variables
  
  (defvar dired-marker-char ?*		; the answer is 42
***************
*** 1397,1402 ****
--- 1404,1411 ----
  	selective-display t		; for subdirectory hiding
  	mode-line-buffer-identification
  	(propertized-buffer-identification "%17b"))
+   (when dired-next-error-support
+     (setq next-error-function 'dired-next-error))
    (set (make-local-variable 'revert-buffer-function)
         (function dired-revert))
    (set (make-local-variable 'buffer-stale-function)
***************
*** 1450,1455 ****
--- 1459,1490 ----
    (message "Change in Dired buffer undone.
  Actual changes in files cannot be undone by Emacs."))
  
+ (defun dired-next-error (&optional argp reset)
+   "Move to the ARGP (default 1) next match in an Dired mode buffer.
+ When RESET is given, starts from the beginning.
+ Compatibility function for \\[next-error] invocations."
+   (interactive "p")
+ 
+   (when reset
+     ;; go to beginning of buffer
+     (goto-char (point-min)))
+   
+   (dired-next-error-move-n-file-lines 
+    (prefix-numeric-value argp))
+ 
+   ;; visit file if possible
+   (when (dired-get-filename nil t)
+     (dired-find-file)))
+ 
+ (defun dired-next-error-move-n-file-lines (argp)
+   "Move ARGP file lines from the current line.
+ File lines are lines with a file listed in them.
+ ONLY SUPPORT POSITIVE MOTION FOR NOW"
+   (when (> argp 0)
+     (dotimes (n argp)
+       (forward-line 1)
+       (dired-goto-next-nontrivial-file))))
+ 
  (defun dired-next-line (arg)
    "Move down lines then position at filename.
  Optional prefix ARG says how many lines to move; default is one line."

[-- 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: next-error refactoring

[Kim F. Storm]

Ted Zlatanov <tzz@lifelogs.com> writes:
> + ;; should we use next-error support?
> + (defcustom dired-next-error-support nil
> +   "Specifies whether Dired should support the next-error
> +   framework."
> +   :group 'dired
> +   :type 'boolean)
> + 

I think dired-use-next-error would be a better name.

First line of doc string should be on one line.
Here is an improved doc string.

(defcustom dired-use-next-error nil
  "Non-nil means to enable `next-error' in dired buffers.
You can then use \\[next-error] to visit the matches
found by `grep-find-dired', `dired-do-search', etc."
  :group 'dired
  :type 'boolean)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: next-error refactoring

[Ted Zlatanov]

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

On Tue, 14 Sep 2004, storm@cua.dk wrote:

> I think dired-use-next-error would be a better name.
> 
> First line of doc string should be on one line.

Here's the corrected version of the patch. Thank you for the help.

In case anyone is wondering, this is generally useful for visiting the
next/previous file listed in dired (only next works now).

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dired-next-error.patch --]
[-- Type: text/x-patch, Size: 2160 bytes --]

*** /usr/src/emacs/lisp/dired.el	Wed Jul 14 18:59:08 2004
--- /home/tzz/emacs/mine/dired.el	Wed Sep 15 14:13:25 2004
***************
*** 215,220 ****
--- 215,228 ----
    :type '(alist :key-type regexp :value-type string)
    :version "21.4")
  
+ ;; should we use next-error support?
+ (defcustom dired-use-next-error nil
+   "Non-nil means to enable `next-error' in dired buffers.
+ You can then use \\[next-error] to visit the matches
+ found by `grep-find-dired', `dired-do-search', etc."
+   :group 'dired
+   :type 'boolean)
+ 
  ;; Internal variables
  
  (defvar dired-marker-char ?*		; the answer is 42
***************
*** 1397,1402 ****
--- 1405,1412 ----
  	selective-display t		; for subdirectory hiding
  	mode-line-buffer-identification
  	(propertized-buffer-identification "%17b"))
+   (when dired-next-error-support
+     (setq next-error-function 'dired-next-error))
    (set (make-local-variable 'revert-buffer-function)
         (function dired-revert))
    (set (make-local-variable 'buffer-stale-function)
***************
*** 1450,1455 ****
--- 1460,1491 ----
    (message "Change in Dired buffer undone.
  Actual changes in files cannot be undone by Emacs."))
  
+ (defun dired-next-error (&optional argp reset)
+   "Move to the ARGP (default 1) next match in an Dired mode buffer.
+ When RESET is given, starts from the beginning.
+ Compatibility function for \\[next-error] invocations."
+   (interactive "p")
+ 
+   (when reset
+     ;; go to beginning of buffer
+     (goto-char (point-min)))
+   
+   (dired-next-error-move-n-file-lines 
+    (prefix-numeric-value argp))
+ 
+   ;; visit file if possible
+   (when (dired-get-filename nil t)
+     (dired-find-file)))
+ 
+ (defun dired-next-error-move-n-file-lines (argp)
+   "Move ARGP file lines from the current line.
+ File lines are lines with a file listed in them.
+ ONLY SUPPORT POSITIVE MOTION FOR NOW"
+   (when (> argp 0)
+     (dotimes (n argp)
+       (forward-line 1)
+       (dired-goto-next-nontrivial-file))))
+ 
  (defun dired-next-line (arg)
    "Move down lines then position at filename.
  Optional prefix ARG says how many lines to move; default is one line."

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

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