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