From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#71284: 30.0.50; [PATCH] Add support for outline-minor-mode to Eshell Date: Mon, 03 Jun 2024 09:45:37 +0300 Organization: LINKOV.NET Message-ID: <86o78i4j8u.fsf@mail.linkov.net> References: <048207b3-4d91-34cd-8e2d-ccf41b7bd832@gmail.com> <868qzq1n3r.fsf@mail.linkov.net> <86frtvrgtn.fsf@mail.linkov.net> <52b77c3b-f556-b436-c8c5-1f157681fa53@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37127"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: 71284@debbugs.gnu.org To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 03 09:18:15 2024 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 1sE1xO-0009TV-EV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Jun 2024 09:18:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sE1x2-0004Tz-3y; Mon, 03 Jun 2024 03:17:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sE1x0-0004TG-S9 for bug-gnu-emacs@gnu.org; Mon, 03 Jun 2024 03:17:50 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sE1wz-0003AJ-KR for bug-gnu-emacs@gnu.org; Mon, 03 Jun 2024 03:17:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sE1xC-0001B6-0f for bug-gnu-emacs@gnu.org; Mon, 03 Jun 2024 03:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Jun 2024 07:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71284 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 71284-submit@debbugs.gnu.org id=B71284.17173990594445 (code B ref 71284); Mon, 03 Jun 2024 07:18:01 +0000 Original-Received: (at 71284) by debbugs.gnu.org; 3 Jun 2024 07:17:39 +0000 Original-Received: from localhost ([127.0.0.1]:53370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sE1wo-00019c-LE for submit@debbugs.gnu.org; Mon, 03 Jun 2024 03:17:39 -0400 Original-Received: from mslow1.mail.gandi.net ([217.70.178.240]:38571) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sE1wm-00019I-1U for 71284@debbugs.gnu.org; Mon, 03 Jun 2024 03:17:37 -0400 Original-Received: from relay6-d.mail.gandi.net (unknown [IPv6:2001:4b98:dc4:8::226]) by mslow1.mail.gandi.net (Postfix) with ESMTP id A5DFFC118D for <71284@debbugs.gnu.org>; Mon, 3 Jun 2024 06:53:23 +0000 (UTC) Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id C4ED5C0003; Mon, 3 Jun 2024 06:53:02 +0000 (UTC) In-Reply-To: <52b77c3b-f556-b436-c8c5-1f157681fa53@gmail.com> (Jim Porter's message of "Sun, 2 Jun 2024 21:34:14 -0700") X-GND-Sasl: juri@linkov.net 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286424 Archived-At: > In any case, the more I think about this, the more my current patch seems > like the wrong way to go about this. Even just describing the user-facing > behavior in all scenarios is pretty complex, so I think it might be better > to keep it simple and have a single outline level. > > That said, for the multi-line prompt case, I wonder if it would make sense > for outline.el to support multi-line headers. If I could mark the entire > prompt + command input as a "header", then collapsing it would look better: > users would still see all of their input in the collapsed node. The multi-line headers have such disadvantage that the outlines are not compact anymore. Also multi-line headers might have more technial issues with displaying an ellipsis at the end. > It would look something like so: > > v /home/user/dir > $ cat some-file.txt > output > output > output > > > /home/user/dir > $ cat some-file.txt... This is a known problem. Recently I had to add a special handling in c-ts-mode--outline-predicate to put the outline heading on the line with the function name instead of the first line with types: static void v bset_mode_name (struct buffer *b, Lisp_Object val) { b->mode_name_ = val; } static void v bset_name (struct buffer *b, Lisp_Object val) { b->name_ = val; } In your case you could do something similar in eshell-outline-search to put the outline heading on the meaningful line: /home/user/dir v $ cat some-file.txt output output output This is not ideal either since the first line belongs to the previous outline. This is a known problem too. For example, in etc/NEWS, the top +++ is not part of the outline, e.g. +++ *** 'outline-minor-mode' is supported in tree-sitter major modes. It can be used in all tree-sitter major modes that set either the variable 'treesit-simple-imenu-settings' or 'treesit-outline-predicate'.