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: Mon, 31 Aug 2020 23:48:10 +0300 Message-ID: <59d878fc-98e0-26c3-e568-239638f54962@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> 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="25129"; 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 22:49:11 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 1kCqjn-0006Pq-Pv for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 22:49:11 +0200 Original-Received: from localhost ([::1]:41984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCqjm-0002TO-PB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 16:49:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCqjf-0002SL-HX for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 16:49:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42314) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kCqjf-00063C-7e for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 16:49:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kCqjf-00037u-75 for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 16:49:03 -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 20:49:03 +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.159890690011956 (code B ref 43103); Mon, 31 Aug 2020 20:49:03 +0000 Original-Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 20:48:20 +0000 Original-Received: from localhost ([127.0.0.1]:53858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCqix-00036m-KN for submit@debbugs.gnu.org; Mon, 31 Aug 2020 16:48:19 -0400 Original-Received: from mail-lf1-f51.google.com ([209.85.167.51]:39250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCqiv-00036Y-JD for 43103@debbugs.gnu.org; Mon, 31 Aug 2020 16:48:18 -0400 Original-Received: by mail-lf1-f51.google.com with SMTP id q8so4285781lfb.6 for <43103@debbugs.gnu.org>; Mon, 31 Aug 2020 13:48:17 -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=fY+E4J4yGrztN0Uwlz1qwEiq5BkHHb9mFnb3T4cINIs=; b=HWzn8dULluDfbJF/Ken6k0vLSZCmj3Mg6asvrclZSyACiHdryRC23IMgyOuoh4WO1+ 20PqL4kY6/f6XSTG0GXz/PtJ0R7dnS6fwYlmDcQEsRslSEOzc3TvgIQB5zXvtrz97tjo xscXivC1+syIVyKryiL/c3jZTz7Lx6pHZfI5wIrslgdr/Bfi+3ZWXCA0k0H4ZYr1I6jZ KOwOXHR7DGvUmTghujekS/cprTj6BEumt6srG+7iOULGYuIMTdc1Dr7CJfCVSP4SlQ4F n11YIQqAepfeCiUzDvrlpkl6cWwuC7jOVZTSzX119MbhEJ2dFipByUSX0iJSNNtawjSp QuVA== 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=fY+E4J4yGrztN0Uwlz1qwEiq5BkHHb9mFnb3T4cINIs=; b=H9VfiGDHA1OH8p0YDifbusS6+zamqZXfp19Kto9ZFkBP5gCJRBKJrE65lDjfz9AGhO xc3Mtw4S4G7soWNlGR+oWo1o1cvw0Q7ivTsJCXL4irbf7Xf+FmxSB4GMAsczAhgeigLh j8biSoqhYM2I4FUSBO0mkCwAfJGlEStElFRhkvKXdfDW9exQH8E06XOFKCSjP6zeML9i tPg4Jg1W8LsAPVbz7rekzMOHiDGHl775AG4q7nOS0y8MP3g6WVJTTZs7Ulv/N6djTB4V GdTE63cmhXs/m6cm1XY9JCz/lYWY8Y1cizgvRgAtALoarwCwYN1QA0ufqjlb4NGWZBxo oeHw== X-Gm-Message-State: AOAM531J6L1+3JrnWa4WQqUa2WR7Pm4U4SlkXXn79RxkkniVFoHpWdMe RbkAxw/ZCzQjG/6D9z9zpg8= X-Google-Smtp-Source: ABdhPJwgWbTSVqjnGJFxfetkkNsfyRFVOlAZVn1BMVsbdgjizQJo6QTByyT0GgiyXM+YZ78qqI5Kjg== X-Received: by 2002:a05:6512:3189:: with SMTP id i9mr1459618lfe.41.1598906891788; Mon, 31 Aug 2020 13:48:11 -0700 (PDT) Original-Received: from [192.168.0.104] ([94.229.108.16]) by smtp.googlemail.com with ESMTPSA id y9sm1784066lji.106.2020.08.31.13.48.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2020 13:48:11 -0700 (PDT) In-Reply-To: <873642k1fg.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:186801 Archived-At: 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. >> Having a major mode exhibit a different behavior WRT eldoc strategy is >> bound to be confusing. E.g., why Elisp and not Python? Why not the >> rest? > > I think people are used to their major modes working in a certain way, > and changes to that way should come about incrementally. Many of us here program in multiple programming languages. Having major modes exhibit different behaviors where they don't have to is jarring. > Other modes > may have ElDoc sources that don't lend themselves to this particular > composition strategy. They don't have multiple documentation sources? One from major mode, another from Flymake, at least. >>>>> - 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? 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. >>>> This command is pretty odd in its design. But if its main purpose was >>>> to show multiple eldoc results together >>> It's similar to `help-buffer`, but also switches to the buffer when >>> called interactively. I don't see anything odd in that, in Emacs terms. >> >> It's odd to use basically the same presentation for the buffer as the >> one for the echo area. > > They don't use the same presentation. Same text contents. > If you want another example in Emacs, here's one: in Flymake (and in > Flycheck) there are diagnostics collected from multiple backends. This > information is presented in a variety of ways: in-source annotations, > tiny mode-line construct, echo area, and a constantly updated separate > buffer listing all the diagnostics in tabular form. The ElDoc buffer is > similar to the latter. I'm not saying the Eldoc buffer command is unnecessary. I'm saying the current implementation and semantics are weird. 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.