bug#51809: 29.0.50; [PATCH] Support for outline default state in Diff buffers

[Juri Linkov]

>> Thanks, this is a good starting point to add just the basic functionality
>> like org-mode initial visibility supported by ‘org-startup-folded’ and
>> per-file settings:
>>
>>    #+STARTUP: fold              (or ‘overview’, this is equivalent)
>>    #+STARTUP: nofold            (or ‘showall’, this is equivalent)
>>    #+STARTUP: content
>>    #+STARTUP: show<n>levels (<n> = 2..5)
>>    #+STARTUP: showeverything
>>
>>> @@ -1058,13 +1060,16 @@ outline-show-heading
>>> -(defun outline-hide-sublevels (levels)
>>> +(defun outline-hide-sublevels (levels &optional fun)
>>
>> It seems you don't use this argument in this patch?
>
> It will be necessary for `diff-mode' to provide its own default state
> functions that decide of the visibility of each heading
> individually. You're right, it's not needed right now so I'll remove it
> and reintroduce it when working on `diff-mode'.

When we will have enough outline functions to be used as values
of `outline-default-state', then `diff-mode' doesn't need to provide
its own default state functions - `diff-mode' could just set
a suitable buffer-local value of `outline-default-state'
from the list of options provided by `outline-default-state'.

Also `outline-default-state' could support a string value
applied as a regexp on outline heading lines to decide
whether to hide or show that outline.

>>> +  (cond
>>> +   ((not outline-default-state) (outline-show-all))
>>
>> It seems this change doesn't keep the current default behavior.
>> Maybe the result will look like it currently works, maybe not.
>> Who knows what effect will have calling `outline-show-all'
>> by default in some user configurations.
>
> Good point. I can remove that line but one must be aware that calling
> `outline-apply-default-state' interactively after changing some headings
> visibility won't restore the default state. Not very intuitive...

`outline-default-state' could provide an explicit value
that will show all outlines.  Maybe even the default value
of `outline-default-state' could be changed to this explicit value.
Then calling `outline-apply-default-state' interactively
will show all outlines.  This way it will be more clear
to users what is going on.

>>> +   ((eq outline-default-state 'only-headings)
>>> +    (outline-show-all)
>>> +    (outline-hide-region-body (point-min) (point-max)))
>>> +   ((integerp outline-default-state)
>>> +    (outline-hide-sublevels outline-default-state))
>>> +   ((when (functionp outline-default-state)
>>> +      (funcall outline-default-state)))))
>>
>> Maybe some other values from org-mode could be supported too?
>
> Sure.

Ideally, there should be an outline-mode function for most values,
so there should be no need for special handling, e.g. instead of
special handling of `only-headings', an outline command should
handle this by funcall (maybe there is an existing function that does this?)

Only integer and string values should have special handling here.

> Let me first fix handling of local values. I saw that `outline-mode' is
> set *before* local variables when I visit a file whose major mode
> default to `outline-mode'.

I don't know where is the problem.  For example, in etc/compilation.txt
these lines set local variables correctly:

  ;;; outline-minor-mode-cycle: t
  ;;; outline-minor-mode-highlight: t
  ;;; mode: outline-minor

> For xref mode I am wondering whether "regexp" based outline mode is the
> right thing to use. Should there be an outline mode based on
> text-properties? The buffer content is built internally and we know
> where "headings" are inserted... But it's another topic.

Good idea.