From: Jim Porter <jporterbugs@gmail.com>
To: Juri Linkov <juri@linkov.net>
Cc: 71284@debbugs.gnu.org
Subject: bug#71284: 30.0.50; [PATCH] Add support for outline-minor-mode to Eshell
Date: Sun, 2 Jun 2024 21:34:14 -0700 [thread overview]
Message-ID: <52b77c3b-f556-b436-c8c5-1f157681fa53@gmail.com> (raw)
In-Reply-To: <86frtvrgtn.fsf@mail.linkov.net>
On 6/1/2024 11:37 PM, Juri Linkov wrote:
> Sorry, I still don't understand why do you need two levels.
> Is it because in Eshell prompts are often multi-line?
I'm not sure if Eshell prompts are *often* multi-line, but personally I
use multi-line prompts everywhere I can. Maybe I'm just over-optimizing
for my own personal preferences here.
> IIUC, with two levels, the case when the output is empty has such problems
> that one line will contain two outline headers, that also means
> two conflicting margin arrows on the same line?
The way I implemented this, this problem wouldn't come up: if the output
is completely empty, there's no second-level node in the outline for
that command.
>> For prompts, this isn't as important, since a single-line prompt should
>> always have some visible text. For multi-line prompts, it would be possible
>> to treat the heading as the first non-empty line, but that would be
>> additional work on the Eshell side, and I think we'd still need the
>> outline.el changes to handle collapsing the command output. (Improving
>> heading-detection for multi-line prompts could always be done in a later
>> bug, too.)
>
> So the outline.el changes are required only to handle empty output lines?
> That essentially means adding support for two outline headers
> on the same line?
To be more precise, the outline.el changes would be required to handle
the case where a command's output *begins* with one or more newlines. So
the total output isn't empty, but the first *line* of it is.
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. It would look something like so:
v /home/user/dir
$ cat some-file.txt
output
output
output
> /home/user/dir
$ cat some-file.txt...
next prev parent reply other threads:[~2024-06-03 4:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 5:18 bug#71284: 30.0.50; [PATCH] Add support for outline-minor-mode to Eshell Jim Porter
2024-05-31 6:05 ` Eli Zaretskii
2024-05-31 19:33 ` Jim Porter
2024-06-01 5:58 ` Eli Zaretskii
2024-05-31 6:51 ` Juri Linkov
2024-05-31 20:02 ` Jim Porter
2024-06-02 6:37 ` Juri Linkov
2024-06-03 4:34 ` Jim Porter [this message]
2024-06-03 6:45 ` Juri Linkov
2024-06-06 1:52 ` Jim Porter
2024-06-06 6:19 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52b77c3b-f556-b436-c8c5-1f157681fa53@gmail.com \
--to=jporterbugs@gmail.com \
--cc=71284@debbugs.gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.