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) time
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-move
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
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
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
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
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
,
| 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
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
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 global
'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 a
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
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-option'
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
14 matches
Mail list logo
