Juri Linkov <[EMAIL PROTECTED]> writes:
>> (defvar next-error-overlay-arrow-position nil)
>> (put 'next-error-overlay-arrow-position 'overlay-arrow-string "=>")
>
> Thanks for the suggestion to put "=>" on the overlay-arrow-string
> property. But I wonder why Emacs can't use "=>" by default
> on
$B!{!,!,!#(B $B(,(,(,(,(,(,(,(,(,(,!{(B $B(,(,(,(,(,!{(,(,(,(,(,(,(,(,(,(B
$B!,!!#o!!!#!!(B $B#o!!(B
$B!!(B $B(B $B#o!,!E!D(,!!=P!!2q!!$$!!(BPC$B!!(B
$B(,!D!E!!(B
$B!!(B $B!{#o!,#o(B $B!!
I have no idea. I usually expect Emacs to stop the search if I press
a cursor key. But then, I've never had search-exit-option set to
anything but t before.
One thing I'm sure of, however, is that it shouldn't print an ugly
error message, like it currently does.
I wasn't aware that setting sear
> If I evaluate this:
>
> (setq search-exit-option nil)
>
> then hit C-s (which runs the command isearch-forward) and then press a
> cursor key, I see an error:
What do you expect Emacs to do when you press cursor keys?
Maybe it should call `(isearch-edit-string)' as it does
when `search-exit-op
> I think the motive is quite clear but perhaps it would be too inconvenient.
> At the moment Gnus and Edebug use the global value for overlay-arrow-position
> which presumably makes debugging Gnus with Edebug a bit awkward.
Not only debugging Gnus with Edebug is awkward, but what is worse
is debu
> 'b' would do for `help-go-back', and doesn't appear to conflict with
> anything in help/view mode.
>
> Also consider adding 'f' for forward
I think it's better to make key bindings more similar to Info mode,
i.e. `l' to go back, and `r' to go forward.
> (requires maintaining a future as well as
>> I see no problem with the fringe arrow in the compilation buffer,
>> because other packages don't try to set their own arrows here,
>> so there are no conflicts in the compilation buffer.
>
> and:
>
>> Perhaps Edebug should be fixed too in the same way as you fixed GUD?
>> Edebug currently uses
The use of custom-current-group seems like a bad practice to me.
It is unreliable to make one defun depend on whatever was lying around
from a previous defun in this way. It has the result that moving
code from one place in a file to another changes its meaning.
So I think it would be better to d
This seems like a good change, but wouldn't it be cleaner to do the
add-to-list call be done where next-error-overlay-arrow is defined?
As for the next-error arrow, the patch below uses its own arrow
for next-error highlighting:
Index: lisp/progmodes/compile.el
==
,
| Help mode:
| Major mode for viewing help text and navigating references in it.
| Entry to this mode runs the normal hook `help-mode-hook'.
| Commands:
| key binding
| --- ---
|
| RET help-follow (binding currently shadowed)
| C-c Prefix
Title: Untitled Document
As part of our security measures, we regularly screen activity
in the PayPal system. We recently noticed the following issue on your account:
We recently received a report of unauthorized credit card use associated
If I evaluate this:
(setq search-exit-option nil)
then hit C-s (which runs the command isearch-forward) and then press a
cursor key, I see an error:
Debugger entered--Lisp error: (wrong-type-argument integerp right)
concat("" [right])
(setq isearch-string (concat isearch-string strin
Peter Seibel <[EMAIL PROTECTED]> writes:
> So lately I've been doing a lot of ediffing and this crash is still
> biting me from time to time. I'm running a build from the 22nd which,
> as far as I recall, I built right after doing a CVS update.
>
> I do have #if 1 in lisp.h. Here's some GDB output
> Compilation mode uses local variables but I see that Gnus uses the
> global value. It might be a good idea (after the release?) to remove
> the variable overlay-arrow-position and initialise
> overlay-arrow-variable-list to nil. That way everyone would be forced
> to cre
Dear PayPal Member,
PayPal is committed to maintaining a safe environment for its community of
buyers and sellers. To protect the security of your account, PayPal employs
some of the most advanced security systems in the world and our anti-fraud
teams regularly screen the PayPal system for un
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I got the following crash while Emacs was idle:
--8<---cut here---start->8---
(gdb) r -name Gnus -xrm 'Emacs.toolBar:1' -f gnus
Starting program: [...]/x86_64/src/emacs
Compilation mode uses local variables but I see that Gnus uses the global
value. It might be a good idea (after the release?) to remove the variable
overlay-arrow-position and initialise overlay-arrow-variable-list to nil.
That way everyone would be forced to create their own overla
I made the following patch which seems to work better. WDYT?
You changed the code quite a bit, so I can't quickly see what the
user-level behavior is. Would you please describe what has changed at
that level?
___
Emacs-pretest-bug mailing list
Em
While the coding system is set to chinese-gbk or chinese-gb18030,
auto-fill-mode won't work properly.
The `nospace-between-words' property does not put on
chinese-gbk/chinese-gb18030 charsets properly to eliminate the "extra
SPACE" problem when refilling.
And the "fill-find-break-point-function
> It doesn't bother me this much :-), I've been using
> mouse-autoselect-window for a quite a while now and 2 days ago was the
> first time, that I noticed this behavior. But then again I'm hardly using
> the menu bar (and I've never used the tool bar).
That's the problem: with the "select on no-m
On Mon, Feb 14 2005, Robert Marshall wrote:
> When I use gnus (which I use to read news) with a recent build of emacs and
> then load vm (I use this to read email) and then go back to the news
> groups I have lost all the different faces that gnus gives me.
>
> If I then run list-faces-display -
> "Stefan" == Stefan Monnier <[EMAIL PROTECTED]> writes:
Stefan>
Stefan> Do you have a suggestion for how to avoid the problem?
I think either the window selection should happen once the mouse isn't moved
anymore (like Kim suggested, that'd be my choice) or after a short
(customizable
> which is evaluated at compile-time. custom-current-group uses
> load-file-name, which is nil at compile-time, so custom-current-group
> returns nil at compile-time too. This doesn't seem the intended
> behavior. What about the patch below?
Looks good, please install,
Stefan
__
Peter Dyballa <[EMAIL PROTECTED]> writes:
> Am 31.03.2005 um 07:35 schrieb Kenichi Handa:
>
>> As mule-cmds.el in CVS repository doesn't contain such a
>> line as "<<<", it seems that you had a locally modified
>> version of mule-cmds.el and "cvs update" couldn't apply a
>> new patch because o
Am 31.03.2005 um 07:35 schrieb Kenichi Handa:
As mule-cmds.el in CVS repository doesn't contain such a
line as "<<<", it seems that you had a locally modified
version of mule-cmds.el and "cvs update" couldn't apply a
new patch because of confliction. If your local
modification is not important
On Mar 30, 2005 7:40 AM, Dave Love <[EMAIL PROTECTED]> wrote:
> >> > I've no idea why non-breaking characters should be displayed like
> >> > this, but U+00AD isn't one -- it's SOFT HYPHEN.
> >
> > I think the same distinction used for NBSP applies:
>
> Why? It isn't a no-break character.
The po
Hi,
Here is a new simpler patch which works well most of the time.
However in some case, when doing M-TAB to complete the face field, I
got this error:
Debugger entered--Lisp error: (args-out-of-range 1094 1094)
get-char-property(1094 field #)
widget-field-end(...)
widget-field-find(1229)
In define-minor-mode and easy-mmode-define-global-mode, the default
:group value for defcustom calls is calculated by means of
(or (custom-current-group)
(intern (replace-regexp-in-string
"-mode\\'" "" mode-name)))
which is evaluated at compile-time. custom-current-grou
You say (separate e-mails):
> I see no problem with the fringe arrow in the compilation buffer,
> because other packages don't try to set their own arrows here,
> so there are no conflicts in the compilation buffer.
and:
> Perhaps Edebug should be fixed too in the same way as you fixed GUD?
> E
29 matches
Mail list logo
