The following change seems to have removed the important variable
tooltip-use-echo-area, with no apparent replacement.
Besides breaking lisp code that was written for 21.1, I don't recall any
discussion about why this feature should be deprecated.
2005-04-20 Nick Roberts <[EMAIL PROTECTED]>
Quoting martin rudalics <[EMAIL PROTECTED]>:
> Jason Rumney wrote:
>
> >
> > Rather than patch the source, can you please try to debug the startup
> > code at the bottom of w32menu.c that decides whether to use Unicode
> > menu names. Does Windows ME have a stubbed out version of
> > unicode_
> The following change seems to have removed the important variable
> tooltip-use-echo-area, with no apparent replacement.
> Besides breaking lisp code that was written for 21.1, I don't recall any
> discussion about why this feature should be deprecated.
>
>
>
> 2005-04-20 Nick Robe
Richard Stallman <[EMAIL PROTECTED]> writes:
> If I repeat the above process, but issue a build command that repeats
> 6 times, and then I hit `f4' *again* during compilation, the point
> moves to the 2nd error in the source window and then after only a very
> brief pause, jumps to
When ClearType
(http://www.microsoft.com/typography/cleartype/tuner/Step1.aspx) is
enabled on an NT build of Emacs, it's very common for emacs to "slice
off" a few antialiased pixels on either side of a character's vertical
member. It happens especially in lines that are being typed. You can
see
NEW.FIRST TIME OFFERED IN THE INDUSTRY.
NEVER BEFORE AVAILABLE. INTRODUCTORY OFFER.
The 2006 American Hospital Email Directory. 174,000
Email Addresses for hospital executives. ($247.00).
In response to numerous requests for email addresses
for hospital executives, the New 2006 American Hospital
It appears to have been moved from tooltip.el where it was preloaded, to gud.el,
so if gud is not loaded it has as good as disappeared.
I don't understand this decision. Why is this now considered a gud specific
feature? It was formerly a user option to have messages appear in the echo area
rather
[EMAIL PROTECTED] writes:
> It appears to have been moved from tooltip.el where it was preloaded, to
> gud.el, so if gud is not loaded it has as good as disappeared.
>
> I don't understand this decision. Why is this now considered a gud specific
> feature? It was formerly a user option to ha
There's a bit of code in src/mac.c which sets the environment variable
INFOPATH if it's not already set, when Emacs is installed as a
self-contained application bundle.
Normally, Info-directory-list should be initialised based on
Info-default-directory-list. But because INFOPATH gets set behin
[ I guess this is going to start a useless preference-war, but who knows,
maybe we're sufficiently clever not to go down that path. ]
I just wanted to mention that I didn't like the default RoyalBlue4/white
appearance of the mode-line-highlight. It doesn't bother me, but I just
found it loud an
Stefan Monnier <[EMAIL PROTECTED]> writes:
> > Maybe other users have a different experience, but for me 99% of the
> > time I would like undo info after a revert is when revert was invoked
> > by VC/pcl-cvs after a commit.
> > So from this users point of view if VC/pcl-cvs were not to rev
Richard Stallman <[EMAIL PROTECTED]> wrote:
> If this switch comes to pass, would the Emacs developers mind if I added
> the following line to CVSROOT/loginfo?
>
> lisp/mh-e $CVSROOT/CVSROOT/syncmail -u %{sVv} [EMAIL PROTECTED]
>
> Would you please explain what this would do? I don
> :background "RoyalBlue4" :foreground "white")
I've just tried your setting and I agree with you; I've found
your definition is better than mine obviously.
New definition fits well with mode-line face.
Masatake YAMATO
___
Emacs-devel mailing list
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailin
I bumped into some funny duplication of code (one for Emacs and the other
for XEmacs) in flyspell.el and while trying to get rid of it, I noticed some
discrepencies between the two. Could someone help me resolve
the differences?
See the questions I added in the patch.
Stefan
--- orig/
Just a very wild guess, just in case: is there any possibility for a
timer to run during that code and mess up the match data? I do not
know the code well enough to check whether it allows timers to run and
whether it uses the match data at some time after that. The
unpredictability, combined wit
Is gnus-start-date-timer running when your problem occurs?
It runs article-update-date-lapsed which conducts a regexp search
without saving and restoring the match data, as it should.
I believe that the patch below is necessary, _regardless_ of whether
it solves your problem. Does it? There may
>From my previous message:
Is gnus-start-date-timer running when your problem occurs?
It runs article-update-date-lapsed which conducts a regexp search
without saving and restoring the match data, as it should.
THe first sentence should have been:
Is article-lapsed-timer running...
Sin
On 6/3/05, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Is article-lapsed-timer running...
I don't know, but the variable `article-lapsed-timer' is nil. Also
this error often happens before any article has been fetched (e.g.,
when entering a group for the first time).
-Miles
--
Do not taunt Happy
I forgot to look at at:
In GNU Emacs 22.0.50.23 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
of 2005-05-26
I fixed Auto Revert mode 28 hours ago. Do you use Auto Revert? Then
the problem _might_ go away with updating your CVS. Although, _if_ Auto
Revert can do it, then the gnus timer I referenced
Well, I could have checked from your minor mode list that you do not
use Auto Revert. Of course there is no guarantee that your problem
has anything to do with timers. It may still be worth while to check
timer-list and timer-idle-list when the problem occur. If none of
these timers can mess up
> I believe that the patch below is necessary, _regardless_ of whether
> it solves your problem. Does it? There may be other similar problems
> in gnus or elsewhere. I could install the patch, if desired. An
> alternative is to automatically restore the match data around _all_
> timers, but Ric
22 matches
Mail list logo
