From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy) Date: Tue, 1 Sep 2020 00:20:59 +0300 Message-ID: <84b1d158-8f97-3b79-91cf-22ab2cb58e9c@yandex.ru> References: <87h7sla2gc.fsf@gmail.com> <83wo1hxx4c.fsf@gnu.org> <87r1rpigff.fsf@gmail.com> <83tuwlxqow.fsf@gnu.org> <87k0xhi51w.fsf@gmail.com> <83blisxl9o.fsf@gnu.org> <878sdwi2ra.fsf@gmail.com> <87sgc3gqh0.fsf@gmail.com> <60560e93-40e8-b7bf-1339-fbd48c792588@yandex.ru> <873642k1fg.fsf@gmail.com> <59d878fc-98e0-26c3-e568-239638f54962@yandex.ru> <87wo1eikpi.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33347"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: 43103@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 31 23:37:22 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 1kCrUQ-0008az-F9 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 23:37:22 +0200 Original-Received: from localhost ([::1]:51380 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCrUP-0005an-Cg for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 17:37:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48026) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCrFb-0006N2-HQ for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 17:22:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42408) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kCrFa-0001sE-2P for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 17:22:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kCrFZ-0006BF-UX for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 17:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2020 21:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43103 X-GNU-PR-Package: emacs Original-Received: via spool by 43103-submit@debbugs.gnu.org id=B43103.159890887223697 (code B ref 43103); Mon, 31 Aug 2020 21:22:01 +0000 Original-Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 21:21:12 +0000 Original-Received: from localhost ([127.0.0.1]:53954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCrEl-0006A9-Ms for submit@debbugs.gnu.org; Mon, 31 Aug 2020 17:21:11 -0400 Original-Received: from mail-lj1-f196.google.com ([209.85.208.196]:41420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCrEg-000699-H7 for 43103@debbugs.gnu.org; Mon, 31 Aug 2020 17:21:09 -0400 Original-Received: by mail-lj1-f196.google.com with SMTP id y4so7328291ljk.8 for <43103@debbugs.gnu.org>; Mon, 31 Aug 2020 14:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SSv7U0U6y+tHiOTsKEtC9hVk8br6+fvvdu5vbKinnf4=; b=OC3eWTw2CEWzP6E5G+P48P6DykNPBk4qtU1x+NoTPRa9jLZjCExr27RKT1rEO1clyl K3F77D8Q/S1RM2ImdZZpqg8+dH3dsJyK88OKnFFO0nJ+SxzjrFnm/sNO6LELe3VJggHD qAYhNFLJ7y4am8yeZ4H9CNE2S5NziO6gfdEL9GTSl+AzBvXDM79Y6d1mo2VELy7t3CyM RkWvyCimqRF21PPVTWwkHy7YD6uFojvjHmZfJK9uiWZWI3yH1pG9IxUDuilo2rk0PTHK fSEgG7YMIrFbu40F0duBfNAseZ6wTj2F47qdqs+OnLxrBw4K/o91uAizdgx/wqgfrvX+ 18pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SSv7U0U6y+tHiOTsKEtC9hVk8br6+fvvdu5vbKinnf4=; b=t3QQLvlmZvHvIMvuGttH/N8O44O3UOmWXnOEOzaT0yCpJz/s1vqGfDxNnORvRlRBuL RKuhJ6U8X/ucLJB4EIEvoEQ7qISBtLo+/r1bGdlHu9wA/f5Beoc/g27jFiyIlWysFe2E uPcw3nCsnERfPKIz+aWjFfRAaialiJqUCfrp+oUl/H4fklESvGPeInRGfBXR1My8ft8F 1O+NocabpubdXRCALAo2N1GaldL96Ne+8wz+03+gV44fVZcEXRnQ+GTPtYhZ5gp2QoTr aFW/LWTa16xJSvshqk1qNx+33j+m7PVGYZxn2YOYoLxUUWUZkMryv7s6egh1+mUOlDsS tCBw== X-Gm-Message-State: AOAM532pAhAQJi+wP1W6NHpZhjaYb83nbfnz1GI7Uu1JTsGOJ8g+RxDw iQafZ9R3JVN0NBYutPjG+cM= X-Google-Smtp-Source: ABdhPJxcvUAEynBewA4Ujz8RewxaZ0NjvPwaU3vGXKLohG22x7FKyn7zV2g2esSMLNsZSs2ftPspZA== X-Received: by 2002:a2e:6f17:: with SMTP id k23mr1526045ljc.245.1598908860445; Mon, 31 Aug 2020 14:21:00 -0700 (PDT) Original-Received: from [192.168.0.104] ([94.229.108.16]) by smtp.googlemail.com with ESMTPSA id g63sm2225600lfd.28.2020.08.31.14.20.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2020 14:20:59 -0700 (PDT) In-Reply-To: <87wo1eikpi.fsf@gmail.com> Content-Language: en-US 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:186806 Archived-At: On 01.09.2020 00:12, João Távora wrote: > Dmitry Gutov writes: > >> On 31.08.2020 23:25, João Távora wrote: >> >>>>>> These is definite wisdom in that. >>>>> I see only signs of rudimentary intial design which predates >>>>> eldoc-...-multiline-p, composition, Flymake... >>>> That doesn't mean the initial design didn't get something right. >>>> If it didn't, this aspect would have likely changed by now. >>> It couldn't change because there weren't the tools for it to change. >>> There are now. >> >> I don't think so. It still uses the echo area. > > The echo area is not one of the new tools. You're making my point here. >> Many of us here program in multiple programming languages. >> >> Having major modes exhibit different behaviors where they don't have >> to is jarring. > > Shall I enumerate variables that are set differently per major-mode? > Your argument is very odd: every major mode has different behaviours, > including for example the shape and form of the elements of > eldoc-documentation-functions. One reason we create minor modes, unified bindings, and so on, is to make the behavior in general more predictable and uniform. So that one doesn't need to re-learn Emacs entirely when editing a file in a different format. >> They don't have multiple documentation sources? One from major mode, >> another from Flymake, at least. > > But you don't know in general the form of each of those, or if there may > be more, or other characteristics. That looks like a drawback of your latest redesign (which I pointed out previously, but who cares about that). The strategy is a global variable, and it's user-customizable. And yet, somehow, now you're getting worried that different strategies might only suit some major modes? >>>>>>> - even if eldoc-echo-area-use-multiline-p is set to nil, users can still >>>>>>> get to all the info collecte by ElDoc with the new >>>>>>> `eldoc-documentation-compose` strategy by pressing M-x eldoc-doc-buffer >>>>>> >>>>>> Is that the only benefit? >>>>> No. >>>> >>>> Any others? >>> For example, it can be used to have ElDoc information permanently >>> visible in another frame. >> >> In the default configuration? > > Yes. The command. Not the strategy? >> You're proposing to change the default configuration. >> >> To clarify, I was asking whether this was the only benefit of changing >> the strategy if we also set eldoc-echo-area-use-multiline-p to nil. > > Hopefully you understand now. I've told you all I know. You seem to have been answering a different question. >> One particular way it's unfortunate, is I actually *would* like a >> generic "show documentation" feature with an existing key >> binding. Shame it doesn't really work for that purpose. > > Try M-x eldoc and global-set-key and tell us what's missing. Already told you. I'm not sure how many different ways I can explain things, if you keep snipping those explanations out.