all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "D. Goel" <deego@gnufans.org>
Subject: Re: dabbrev-hover.el v. 0.1
Date: Mon, 24 May 2004 16:05:47 -0400	[thread overview]
Message-ID: <87brkdtwtg.fsf@gnufans.net> (raw)
In-Reply-To: wk8yfn2sg0.fsf@hotmail.com

Vagn Johansen <vjo@mail.tele.dk> writes:

>
>     (defun vj-tooltip-show (str)
>         (interactive)
>         (setq header-line-format (replace-regexp-in-string "\n" ", " str))) 




>
> Maybe you could detect if tooltip is possible and the fallback to my
> function.  


Thanks, I will do that. 


> It would be nice with some cleanup so that header-line-format is set
> to "" when there are no dynamic expansions possible.
>
> Is it suppossed to show only one suggestion? I would like to use
> dabbrev-expand with a prefix argument. This would make the mode even
> better.
>
> I also think i would prefer if it did not fiddle with the RET keybinding
> (customizable?).


yes, it was customizable (using the way Kevin Rodgers suggested), but
I ran into the above RET problem you mentioned myself, and made TAB
the default in 0.2.


> Being in effect while in the minibuffer with the RET keybinding is a
> bad recipe.


> Is it needed at all in the minibuffer?

Hm, on my emacs 21.2 and 21.3, it never seems to get activated in the
minibuffer in the first place for some reason, but i will go ahead and
provide something like an "expand-in-minibuffer-p" option, and disable
it by default.

>
> I wonder if dh-complete *must* be used. dabbrev-expand seems work to just
> as well and I already have it bound to a convenient key.

Ah, I don't understand dabbrev.el too well, so I was not sure if
dabbrev-expand will expand to the same completion as shown by
dabbrev-hover.el (which, of course, dh-complete does, by
construction.)  dh-complete also makes the code general enough to
allow use with other mechanisms like hippie-expand, as suggested by
Trey Jackson privately.


> And finally, correct instances of '(keymap) with (make-sparse-keymap).
> Kevin Rodgers

thanks, done in 0.2dev already, with help from Uwe Brauer.
>
> If you don't need the tooltip feature in the minibuffer, then why the
> need to redefine tooltip-show? The default implementation should use
> the minibuffer if tooltips are not supported.

It does :)

Vagn Johansen <gonz808@hotmail.com> writes:

>
> You are right. A "(require 'tooltip)" was missing in dabbrev-hover.el. It
> is odd that there was no missing function error (it failed silently).

Will add.


> Now it works in the sense that instead of showing a "real" tooltip it
> prints "Error while displaying tooltip: (void-function x-show-tip)" in
> the minibuffer for half a second and then shows the possible expansion
> (also in the minibuffer).





One thing I don't understand is why fancy dh doesn't work when in -nw
mode (emacs -nw).  Everything in the code/edebug suggests that we are
in the right mode (dh-fancy-doing-mode), yet it doesn't work..  even
when I do the following for debugging:


 
 (define-key dh-fancy-doing-mode-map (kbd "t") 'dh-complete)
 (setq dh-fancy-doing-mode-string " DEBUG")

and then try "t" for completion.  
I would be in the dh-fancy-doing-mode, yet t will
 self-insert... strange..
If anyone knows, please do share..

(manual M-x dh-complete still works)




DG                                 http://gnufans.net/
--

      parent reply	other threads:[~2004-05-24 20:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87oeolvjyw.fsf@gnufans.net>
2004-05-20 12:28 ` dabbrev-hover.el v. 0.1 Vagn Johansen
2004-05-20 15:11   ` Enila Nero
2004-05-20 15:46     ` Vagn Johansen
2004-05-20 17:02       ` Kevin Rodgers
2004-05-20 19:11       ` Jason Rumney
2004-05-20 22:56         ` Vagn Johansen
2004-06-13  5:42     ` Daniel LaBell
2004-05-20 15:21   ` Enila Nero
2004-05-20 22:10     ` Vagn Johansen
2004-05-21  4:55       ` Enila Nero
2004-05-21  7:29         ` Mathias Dahl
2004-05-21 23:44         ` Jason Rumney
2004-05-22  3:20           ` Enila Nero
2004-05-24 18:35   ` D. Goel
2004-05-24 20:05   ` D. Goel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87brkdtwtg.fsf@gnufans.net \
    --to=deego@gnufans.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.