While debugging these lisp changes with Edebug, I noticed that `g'
(top-level)
didn't clear Edebug's arrow.
The natural way to do that is with an unwind-protect around the code
that reads the input. Would you like to add one?
___
Emacs-devel
While debugging these lisp changes with Edebug, I noticed that `g'
(top-level) didn't clear Edebug's arrow.
The natural way to do that is with an unwind-protect around the code
that reads the input. Would you like to add one?
You will have to explain further, I don't
From: Nick Roberts [EMAIL PROTECTED]
Date: Sun, 15 May 2005 14:44:22 +1200
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
The best way to test for a left-hand fringe (absence of) seems to be:
(if (equal (car (window-fringes)) 0)...
I'd suggest to make this a function,
Please install your patch, with Eli's doc string.
Please update etc/NEWS and the Emacs Manual too.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
While debugging these lisp changes with Edebug, I noticed that `g'
(top-level) didn't clear Edebug's arrow.
The natural way to do that is with an unwind-protect around the code
that reads the input. Would you like to add one?
You will have to explain
But at this stage, if people had respected the feature freeze, the
new features in 22.1 would have stabilized by now ... it's the
constant addition of tiny things that keep messing things up
and postponing the release (e.g. the comment font lock thing).
The main cause of delay is
From: Nick Roberts [EMAIL PROTECTED]
Date: Sun, 15 May 2005 14:44:22 +1200
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
! (defcustom compilation-context-lines nil
*Display this many lines of leading context before message.
! If nil, don't scroll the compilation output
From: Richard Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
Date: Fri, 13 May 2005 20:26:10 -0400
Now is the right time to make some kinds of changes, those that correct
annoyances and wrinkles in the features we have added.
We clearly disagree on
Eli Zaretskii [EMAIL PROTECTED] writes:
From: Richard Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
Date: Fri, 13 May 2005 20:26:10 -0400
Now is the right time to make some kinds of changes, those that correct
annoyances and wrinkles in the
Richard Stallman writes:
1. New defcustom compilation-current-message-highlight.
Please don't add this option. It isn't necessary to fix a problem.
Here's a patch that will hopefully keep everyone happy ;-)
1) No new option.
1) Overlay arrow and no scrolling with left-hand fringe
From: Juri Linkov [EMAIL PROTECTED]
Date: Fri, 13 May 2005 08:03:54 +0300
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
The new option compilation-current-message-highlight will support
three values: `arrow', t for highlighting the whole current message
line, and nil to turn all indications
The new option compilation-current-message-highlight will support
three values: `arrow', t for highlighting the whole current message
line, and nil to turn all indications off.
PLEASE do not propose new options until we cut the release branch and
go into pretest. We will NEVER
Even on text terminals users might prefer not to scroll the window.
Since overlay arrows are problematic on text terminals, there should
be an alternative method of highlighting. I propose to add one of the
methods of next-error highlighting for compilation messages, i.e. a
persistent
From: Nick Roberts [EMAIL PROTECTED]
Date: Fri, 13 May 2005 19:18:37 +1200
Cc: Juri Linkov [EMAIL PROTECTED], emacs-devel@gnu.org
PLEASE do not propose new options until we cut the release branch and
go into pretest. We will NEVER release another Emacs this way!
I don't follow this
1. New defcustom compilation-current-message-highlight.
Please don't add this option. It isn't necessary to fix a problem.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
We've been through this time and again. Some recent examples include
the overlay arrow in compilation buffers, font-lock changes wrt
comment delimiters, ispell vs aspell invocation, etc. How many more
such incidents are needed before people will understand that THERE ARE
NO
I suggest adding a new option defining how to highlight lines
in compilation/grep buffers, similar to `next-error-highlight'
which defines highlighting in source buffers. It will replace
`compilation-context-lines':
(defcustom compilation-message-highlight 0
*Highlighting of
I don't like this change because its not the case that one user wants an
arrow
and another doesn't but rather one context may benefit from an arrow
(graphical display) while another may not (text terminal).
I agree.
And doesn't the current code do exactly this?
I don't like this change because its not the case that one user wants an arrow
and another doesn't but rather one context may benefit from an arrow
(graphical display) while another may not (text terminal).
Previously I have suggested a change that gives compilation-context-lines a
context
Juri Linkov [EMAIL PROTECTED] writes:
Currently simple.el has:
(put 'next-error-overlay-arrow-position 'overlay-arrow-string =)
but this could be removed as it is the default now anyway (I think
Juri disappeared again before 2005-04-08).
Sorry. I traveled to my friend. She lives 1000km
Currently simple.el has:
(put 'next-error-overlay-arrow-position 'overlay-arrow-string =)
but this could be removed as it is the default now anyway (I think Juri
disappeared again before 2005-04-08).
Sorry. I traveled to my friend. She lives 1000km from me.
I suggest this latter change
Richard installed a different change to simple.el.
(put 'next-error-overlay-arrow-position 'overlay-arrow-string )
but this is a *different* arrow that displays in the *source* buffer.
I think this change is wrong.
Which change is wrong--Richard's or
From: Richard Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-devel@gnu.org
Date: Sun, 08 May 2005 12:12:37 -0400
It looks like I changed the wrong marker, and indeed it appears not to
work. If your change does the job, please delete mine.
Done.
From: Richard Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
Date: Thu, 28 Apr 2005 07:01:00 -0400
Let me be sure I understand you correctly, Kim: are you actually
saying that this is a good feature, the way it behaves in current CVS?
So, if the next-error-overlay-arrow-position's string doesn't affect
anything but compile.el, how come text terminals started to display
the arrow as result of a discussion about GUD and Edebug? What am I
missing?
I might be losing your meaning, but the conflict was between GUD and
SM I recently realized that while the 0-context sometimes makes sense for
SM C-x `, the don't move behavior would be preferable when getting
SM to an error by using RET or mouse-2 on the actual error text.
That is true *if* we use the overlay arrow. However, as has just been
pointed
SM I recently realized that while the 0-context sometimes makes sense
for SM C-x `, the don't move behavior would be preferable when
getting SM to an error by using RET or mouse-2 on the actual error
text.
That is true *if* we use the overlay arrow. However, as has
Let me be sure I understand you correctly, Kim: are you actually
saying that this is a good feature, the way it behaves in current CVS?
No.
Why not do what was suggested?
(unless (display-graphic-p)
(put 'next-error-overlay-arrow-position 'overlay-arrow-string ))
Moreover, next-error scrolls the display to keep the current line at
the top of the window. I think it's a bit silly to mark the with an
arrow a line that is always at the top of its window; such an arrow
might make sense if we do not scroll the window except when the
current line is no
From: Richard Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-devel@gnu.org
Date: Thu, 28 Apr 2005 07:01:00 -0400
Why not do what was suggested?
(unless (display-graphic-p)
(put 'next-error-overlay-arrow-position 'overlay-arrow-string ))
Wouldn't this
I guess its a chicken and egg situation but a proper feature freeze that
lasted over a year would surely set back development.
So what are you saying? let's ignore the freeze and install anything
we want because the show must go on no matter what?
Major features like Unicode and
Why not do what was suggested?
(unless (display-graphic-p)
(put 'next-error-overlay-arrow-position 'overlay-arrow-string ))
Wouldn't this affect Edebug on text terminals?
No, I don't think so. The thread that was hardly a discussion was about
conflicts and covered this.
Eli Zaretskii [EMAIL PROTECTED] writes:
By ``bug'' in this case I meant a design bug.
Then we agree!
It's at least a bad misfeature, and surely shouldn't be on by default
in compilation buffers.
on text terminals, yes.
Also, the arrow feature is not customizable. What about users who
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Wed, 27 Apr 2005 15:10:59 +0200
Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
Eli Zaretskii [EMAIL PROTECTED] writes:
By ``bug'' in this case I meant a design bug.
Then we agree!
It's at least a bad misfeature, and surely shouldn't be on
Btw, if the intent was to highlight the current line in the
compilation buffer, we could do this with a color overlay that spans
the entire line. This would make the line stand out without obscuring
any of its text.
It is worth a try.
Notice the overlay arrow that covered part of the file name: this is a
bug, IMHO. If we want to have an arrow pointing out the current line,
we should indent the buffer text to the right as many columns as the
arrow string takes.
It might be good to do that when overlaying the
A couple of weeks ago, a change to compile.el introduced an overlay
arrow into buffers created by compile.el: the overlay arrow now marks
the current line in the compilation buffer. (Here, ``current line''
means the line whose locus is displayed in the other window;
next-error and mouse-1 change
Eli Zaretskii [EMAIL PROTECTED] writes:
=wd.c:5: warning: implicit declaration of function `bar'
Notice the overlay arrow that covered part of the file name: this is a
bug, IMHO. If we want to have an arrow pointing out the current line,
we should indent the buffer text to the right as
From: [EMAIL PROTECTED] (Kim F. Storm)
Date: Sun, 24 Apr 2005 20:42:47 +0200
Cc: Juri Linkov [EMAIL PROTECTED], emacs-devel@gnu.org
Eli Zaretskii [EMAIL PROTECTED] writes:
=wd.c:5: warning: implicit declaration of function `bar'
On text terminals, the overlay-arrow is just that ---
39 matches
Mail list logo
