From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#44885: 28.0.50; [PATCH] ElDoc buffer mode and separator Date: Sat, 28 Nov 2020 23:54:36 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4441"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin) Cc: 44885@debbugs.gnu.org To: Andrii Kolomoiets Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 29 00:55:18 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjA3i-000148-Hn for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Nov 2020 00:55:18 +0100 Original-Received: from localhost ([::1]:42704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjA3h-0005VJ-0r for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Nov 2020 18:55:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjA3S-0005VC-Iu for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 18:55:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37813) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjA3S-00051X-BL for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 18:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kjA3S-00080T-9M for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 18:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Nov 2020 23:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44885 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 44885-submit@debbugs.gnu.org id=B44885.160660768930753 (code B ref 44885); Sat, 28 Nov 2020 23:55:02 +0000 Original-Received: (at 44885) by debbugs.gnu.org; 28 Nov 2020 23:54:49 +0000 Original-Received: from localhost ([127.0.0.1]:49359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjA3F-0007zx-02 for submit@debbugs.gnu.org; Sat, 28 Nov 2020 18:54:49 -0500 Original-Received: from mail-wr1-f45.google.com ([209.85.221.45]:38560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjA3B-0007zi-Af for 44885@debbugs.gnu.org; Sat, 28 Nov 2020 18:54:47 -0500 Original-Received: by mail-wr1-f45.google.com with SMTP id p8so9896454wrx.5 for <44885@debbugs.gnu.org>; Sat, 28 Nov 2020 15:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=R+mDLsASloNks+U6WNABbMOCKQsLotJchr/vNzkbEg0=; b=GPboNzIFkzht+2WD0BAdb7o20BSAaMXPO24O0NQr9DD+Y8gScHTdW7UouEcZPG6VAW jQraZX0A6sCEXbg2jw1wG96NpL9aN5jILE4cYduJovT2oCGPnkWITyBzpM8d0rPFMZJk uuxTAhAI8Rb95cif4IwKErzb0EdKUH4I/Ei7yloxcmIIPJd+TVXBUFiSwqY+9twWRnOb hhzZ8SYelwZFh0RQDYGh2D14YDMNaOWVKbAmSv3sc7lnPLiTRk80TM7N4nhouxAkWlMi s3xqaOb473o0n/bqWdrTSH0Kp+QJbfM32xU9wGy/TwM+83gp7tUOjysvZrfdNRxf//lB Vs8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=R+mDLsASloNks+U6WNABbMOCKQsLotJchr/vNzkbEg0=; b=t5pVJ9quzNd+bhAQvTOyK9O1I4YeIVfFWHi/EZBetoHW2ALZa+7iXZyl5U+WppHds1 D4BM12/M4dCHvQneOro+Pw8vecZcVuc3qwGtoSrtGEH77d7eMAohKPIsl0S25xuo4dTN JXP0CtEFPATUmbmpaB/x8FhNM9q/e1TVuG7BCOJPWaDO/5oS4e+ml6joALWyrjK4ZXSp zn/BRyDeNdAaoaKzkKatAXMbnN7d8T7mXelWuHMSaCzTl3aZMdF+1wGUhDiCvToQhI7S zp0gFavGhHaGjaAt9K2BP4Z+0JqTe+UQRFzL07SQ5EqC8mJs2DokZaHVqn7X/rA/iJmL PKFQ== X-Gm-Message-State: AOAM531jvdOpR7C12zy536szfwDUJ4zojlZvAI3NoBwC9XMwIt/Dwp3e 6nmWPek03zkGD2f7aztDKGbgZrdNKg8= X-Google-Smtp-Source: ABdhPJylpdAi7t3Vis+QCKmjzqCLvIaSnrnOGse9RJPs77CNGjfUN52aMgZmeoQsBYYYVsztY70aPA== X-Received: by 2002:adf:a198:: with SMTP id u24mr19854725wru.219.1606607678799; Sat, 28 Nov 2020 15:54:38 -0800 (PST) Original-Received: from Joaos-MBP (95.116.108.93.rev.vodafone.pt. [93.108.116.95]) by smtp.gmail.com with ESMTPSA id 90sm21901925wrl.60.2020.11.28.15.54.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Nov 2020 15:54:38 -0800 (PST) In-Reply-To: (Andrii Kolomoiets's message of "Thu, 26 Nov 2020 14:42:47 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194518 Archived-At: Andrii Kolomoiets writes: > Hi, > > Patch attached. > > The configurable separator will make it possible to show multiple docs > in user pleasant way. Thanks. The patch looks generally good but it has an important flaw that can be fixed. See comments below. > The mode will allow tweak ElDoc doc buffer appearance by adding hooks. Yes. I also have some ideas about how to sophisticate this buffer. One of them involves having some backends, like the Elisp backends, transmit a special key on the side -- much like :thing or :face -- that specifies a function that fills in the whole buffer. Thus, M-x eldoc in a symbol of the Elisp buffer could eventually format this Eldoc doc buffer much in the same way that currently M-x describe-symbol does. And thus the Elisp disconnect between M-x eldoc and M-x describe-* would be bridged. The only incompatibility I see between my idea and your current proposal is the major mode that you picked for the Eldoc doc buffer. I wonder if you could make it inherit from Help mode? Then it would glue better with my idea. > With little customization and custom display function in > display-buffer-alist 'M-x eldoc-doc-buffer' can show the ElDoc buffer > like some kind of tooltip. Very interesting. Can you share the display-buffer-alist hack that allowed you to do this? I didn't think about the possibility of tweaking it like this, but it's certainly "legal". I wonder if you cann't do the same by adding a different function to eldoc-display-functions, which was how I intented it to work. > +(defvar eldoc-doc-mode-map > + (let ((map (make-sparse-keymap))) > + (suppress-keymap map) > + (define-key map "q" 'quit-window) > + (define-key map " " 'scroll-up-command) > + (define-key map [?\S-\ ] 'scroll-down-command) > + (define-key map "\C-?" 'scroll-down-command) > + (define-key map "?" 'describe-mode) > + (define-key map "h" 'describe-mode) > + (define-key map ">" 'end-of-buffer) > + (define-key map "<" 'beginning-of-buffer) > + map) > + "Keymap used in ElDoc documentation buffer.") > + > +(define-derived-mode eldoc-doc-mode fundamental-mode "ElDoc doc" > + "Major mode for ElDoc documentation buffer." > + (setq buffer-read-only t)) As I said above, I wonder if inheriting from help-mode wouldn't give us most of this for free. Maybe it would bring us _too much_ though... So some inheritance snipping would be needed. > do (insert this-doc) > - when rest do (insert "\n") > + when rest do (insert eldoc-doc-buffer-separator) I like this and I like the separator, however, notice that the current implementation of the eldoc-display-in-echo-area also uses this buffer as an implementation detail. So this would break eldoc-display-in-echo area. The solution would be for eldoc-display-in-echo-area to use its own "hidden" buffer and then eldoc-display-in-buffer would be free to format the buffer as it sees fit. So you could extract the buffer-formatting code to a common helper, use it in eldoc-display-in-echo-area with a "\n" separator and in eldoc-display-in-buffer with an arbitrary user-chosen separator. The performance hit of formatting two buffers would likely be negligible. Jo=C3=A3o