bug#71284: 30.0.50; [PATCH] Add support for outline-minor-mode to Eshell

[Jim Porter <jporterbugs@gmail.com>]

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...