Hi all,
I'm not quite sure if this is a bug or a intended change in tooltip
handling, but here I go.
Supporting own tooltips in Emacs 21 was basically a matter of:
,
| (defun my-tooltip-mode (optional arg)
| ;; [snip]
| (tooltip-mode 1)
| (add-hook 'tooltip-hook
Nick Roberts [EMAIL PROTECTED] writes:
Hi Nick,
| (setq track-mouse on))
^^^ t?
Just a typo.
| (defun my-tooltip-function (event)
| (interactive e)
| ;; process event...
| (tooltip-show Huzzah!))
`
This didn't seem to work
Nick Roberts [EMAIL PROTECTED] writes:
Hi Nick,
I don't know what dictionary-el or your mode do but, if possible, its
best to add tooltips through the `help-echo' text property.
My mode [1] opens a tooltip with translations of the word you're
pointing at. The translation is done by an
Nick Roberts [EMAIL PROTECTED] writes:
It returns nil in buffers where GUD tooltips are not meant to work i.e
when the major-mode is not a member of gud-tooltip-modes.
I think thats the problem of just adding to tooltip-hook. You have a
list of functions and the last non-nil one wins.
Yeah,
Nick Roberts [EMAIL PROTECTED] writes:
Hi Nick,
It might be fine for personalising Emacs but not a general package.
Your construction above adds the function to the hook at the end. So,
for example, if that's in a buffer that I'm using for debugging, the
tooltips will display translations of
From time to time emacs starts utilizing 100% of cpu time. Sometimes it falls
back to normal usage for some seconds, but it always catches up again.
Emacs stays responsible and the only indication is that my fan is running all
the time, thus I'm not sure since when I have this problem. And I
Nick Roberts [EMAIL PROTECTED] writes:
Hi Nick,
Maybe someone can interpret your observations, but generally you need
to compile Emacs with -g so that the backtrace gives argument values
Ok, I did a fesh checkout 1 hour ago and compiled it with -g. Here's
gdb's `bt full'.
(gdb) run
Starting
Tassilo Horn [EMAIL PROTECTED] writes:
This happens automatically if you attach to emacs in the directory in
which it was built i.e using .gdbinit (also needed for xbacktrace).
Ok, now I've run gdb from emacs src build directory and made a new
backtrace. It's too large to post here (1.2 MB
Stefan Monnier [EMAIL PROTECTED] writes:
Hello Stefan,
Does (setq jit-lock-stealth-time nil) fix it?
No. If it has already started looping it has no effect at all, and if I
set in in my ~/.emacs and restart it, I can reproduce the bug again, but
it seems to happen not that fast.
If it's set
Richard Stallman [EMAIL PROTECTED] writes:
Hello Richard,
The way to find out where a program is running during a long operation
is to stop the program several times, making a backtrace each time.
When you see a pattern start to emerge, then please report it.
Ok, all backtraces have this
T. V. Raman [EMAIL PROTECTED] writes:
Hi,
did you update semantic out of CVS? the last release on the
sourceforge site appears to be from 2005
Yes, but only semantic-idle.el.
Bye,
Tassilo
___
emacs-pretest-bug mailing list
Ok, I start up Gnus. Now, if I view an article by hitting RET
(`gnus-summary-scroll-up') on it in *Summary*, I get the following
behavior:
- as long as there are visible headers (Subject, From, etc.) on top of
the buffer, pressing RET scrolls exactly one line as it should be.
- when the
Hi Fredrik,
Hey, I had the same idea about a week ago and implemented it in elisp.
--8---cut here---start-8---
(defun th-display-buffer (buffer force-other-window)
If BUFFER is visible, select it.
If it's not visible and there's only one window, split the
Mathias Dahl [EMAIL PROTECTED] writes:
Hi Matthias,
Could someone else test as well?
Here, the thumbs are displayed properly, and RET opens a
*tumme-display-image* buffer with a scaled image. (The original icon is
64x64, and the buffer shows about a 350x350 version)
When I type `f' a small,
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 mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
Hi all,
I just wanted to mention that this bug seems not to be strictly related
to (recentf-mode 1), but that triggers the bug immediately. But although
I commented out this line (and all of recentf settings), emacs crashed
with SIGABRT after about 10 hours uptime. Unfortunately it didn't run in
Katsumi Yamaoka [EMAIL PROTECTED] writes:
Hi Katsumi,
It has been solved by this change:
--- puresize.h~ 2007-01-14 03:24:37 +
+++ puresize.h2007-07-25 23:58:10 +
@@ -46 +46 @@
-#define BASE_PURESIZE (112 + SYSTEM_PURESIZE_EXTRA +
SITELOAD_PURESIZE_EXTRA)
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 mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
Katsumi Yamaoka [EMAIL PROTECTED] writes:
The value of PURESIZE needs to be increased for at least the
Fedora 7 system:
[...]
Dumping under names emacs and emacs-22.1.50.1
emacs:0:Pure Lisp storage overflow (approx. 1120140 bytes needed)
144 pure bytes used
[...]
It's the same for my
19 matches
Mail list logo
