From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) Newsgroups: gmane.emacs.devel Subject: Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions Date: Tue, 28 Apr 2015 12:41:19 +0100 Message-ID: References: <87h9s6c27z.fsf@gmail.com> <87zj5wnlyt.fsf@gmail.com> <553C285B.4070400@yandex.ru> <838udfx7rt.fsf@gnu.org> <87383kcy0u.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1430221294 7679 80.91.229.3 (28 Apr 2015 11:41:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 11:41:34 +0000 (UTC) Cc: Eli Zaretskii , dgutov@yandex.ru, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 28 13:41:33 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yn3tM-00008U-Da for ged-emacs-devel@m.gmane.org; Tue, 28 Apr 2015 13:41:32 +0200 Original-Received: from localhost ([::1]:60760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn3tL-0002Vz-N2 for ged-emacs-devel@m.gmane.org; Tue, 28 Apr 2015 07:41:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn3tH-0002Sk-KD for emacs-devel@gnu.org; Tue, 28 Apr 2015 07:41:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yn3tE-0000En-4k for emacs-devel@gnu.org; Tue, 28 Apr 2015 07:41:27 -0400 Original-Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:35615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yn3tD-0000EZ-UB; Tue, 28 Apr 2015 07:41:24 -0400 Original-Received: by widdi4 with SMTP id di4so136425968wid.0; Tue, 28 Apr 2015 04:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=3/9cZn+uuDa6bttaFN6idGoRS0HWotLgRYeSkWjC1XQ=; b=w0j5CSmpAxxzD6fXhgWPPxbqDsaNs7Zp67gIHT5g1VjhTST1XgkTIAgUZNhSDhptPq TVfaTsr4+dsuA9gCOMaHw4El94y0SrHMYiSgQm2FSDM+Grf4gEQ9vX23RNfR7Rt0kLWj BQqCnLi9BPyKqKHxNn/0yyf1POv7gPSruxSamsjuhnbLHvFQ2t/Y3SCvCWfYSkLS7zRW qago133dSKaIKpIttErsybHzjjd/dnnW2KOsrPu/52dJE8I6is2zH0Ip//cWEWcXHKnp yVP3U/+ulip7j4+ibI3k8zQgXOTU+KXjlyQSSvHakJ9su5qA9HItbifuls5uOWxstO1J 9IDg== X-Received: by 10.194.77.180 with SMTP id t20mr32113658wjw.115.1430221282594; Tue, 28 Apr 2015 04:41:22 -0700 (PDT) Original-Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id i6sm33798166wjf.29.2015.04.28.04.41.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 04:41:21 -0700 (PDT) In-Reply-To: <87383kcy0u.fsf@gmail.com> (Vitalie Spinu's message of "Tue, 28 Apr 2015 13:06:41 +0200") User-Agent: Gnus/5, (Gnus v5.13) Emacs/25.0.50 (windows-nt) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185955 Archived-At: Vitalie Spinu writes: > >>> Eli Zaretskii on Sun, 26 Apr 2015 17:51:18 +0300 wrote: > > > Beware: quite a few commands pop up *Help* buffers whose contents have > > nothing to do with Lisp. Some examples: > > > . C-u C-x =3D > > . C-h C-\ > > . M-x describe-current-coding-system RET > > > etc. > > It's because help-mode is not specialized enough. I think there should > be `elisp-help-mode`, `describe-help-mode` etc. which are derived from > `help-mode`. Maybe yes. But anyway Eli's right, some help contexts have nothing to do with elisp. I see two options: 1) I like this derived mode approach. To implement it perhaps we could make `help-mode-setup' call some `help-mode-setup-function' so that `with-help-window' does the right thing. Then we set this var in the contexts we want. If this is the chosen approach, what should `help-mode-setup-function' default to? Perhaps the mew derived `elisp-help-mode' since that minimizes the number of describe-*'s to touch. 2) Otherwise, we have to explicitly reset the backend on a per-context basis. Now, should the default for help mode be `elisp-xref-find' and we reset those three, or the other way around? Is my previous (advice-add describe-thingy :after ...) strategy acceptable for this? (BTW: the fix for apropos-mode and debugger-mode is not controversial right?) > Maybe obvious, but this struggle with the choice of the > default backend wouldn't be there if xref was able to merge backends. I don't see how. How would we remove elisp-xref-find as a backend in certain help-mode contexts without touching the code where such contexts are setup. > (FWIW, I would also like to have elisp xref in info mode.) But only for the elisp manual, right? Jo=E3o