From mboxrd@z Thu Jan  1 00:00:00 1970
Path: main.gmane.org!not-for-mail
From: "D. Goel" <deego@gnufans.org>
Newsgroups: gmane.emacs.help
Subject: Re: dabbrev-hover.el v. 0.1
Date: Mon, 24 May 2004 16:05:47 -0400
Organization: Posted via Supernews, http://www.supernews.com
Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org
Message-ID: <87brkdtwtg.fsf@gnufans.net>
References: <87oeolvjyw.fsf@gnufans.net> <wk8yfn2sg0.fsf@hotmail.com>
NNTP-Posting-Host: deer.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: sea.gmane.org 1085430598 26296 80.91.224.253 (24 May 2004 20:29:58 GMT)
X-Complaints-To: usenet@sea.gmane.org
NNTP-Posting-Date: Mon, 24 May 2004 20:29:58 +0000 (UTC)
Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 24 22:29:46 2004
Return-path: <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org>
Original-Received: from monty-python.gnu.org ([199.232.76.173])
	by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1BSM4v-0005ib-00
	for <geh-help-gnu-emacs@m.gmane.org>; Mon, 24 May 2004 22:29:45 +0200
Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
	by monty-python.gnu.org with esmtp (Exim 4.34)
	id 1BSLs9-0000Su-HJ
	for geh-help-gnu-emacs@m.gmane.org; Mon, 24 May 2004 16:16:33 -0400
Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
Original-Newsgroups: gnu.emacs.help
X-Face: #5@=vrmx5t3mZaPY8(mR.n+V#:%4NW7j5A&^}@lGp2rK;
	CQ4%iH1v'gh/^A)w5*6c&R2(P' 4+seYDq8OK'LPI/C(C^A*w|f*t+8,
	'T8b#_0~h3!A7GoVroE[cr0Fb'A0%SdU|Lk@gBV&1vA
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)
Cancel-Lock: sha1:yqPWyU7chgb+lWjGIqj6Z+Aor7s=
Original-X-Complaints-To: abuse@supernews.com
Original-Lines: 108
Original-Xref: shelby.stanford.edu gnu.emacs.help:123404
Original-To: help-gnu-emacs@gnu.org
X-BeenThere: help-gnu-emacs@gnu.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: Users list for the GNU Emacs text editor <help-gnu-emacs.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/help-gnu-emacs>,
	<mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/help-gnu-emacs>
List-Post: <mailto:help-gnu-emacs@gnu.org>
List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/help-gnu-emacs>,
	<mailto:help-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org
Xref: main.gmane.org gmane.emacs.help:18701
X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:18701

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/
--