From: Juri Linkov <juri@linkov.net>
To: Matthias Meulien <orontee@gmail.com>
Cc: 51809@debbugs.gnu.org
Subject: bug#51809: 29.0.50; [PATCH] Support for outline default state in Diff buffers
Date: Mon, 13 Dec 2021 10:58:42 +0200 [thread overview]
Message-ID: <86fsqwc01d.fsf@mail.linkov.net> (raw)
In-Reply-To: <871r2hc51a.fsf@gmail.com> (Matthias Meulien's message of "Mon, 13 Dec 2021 08:55:45 +0100")
>> 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.
next prev parent reply other threads:[~2021-12-13 8:58 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-13 13:04 bug#51809: 29.0.50; [PATCH] Support for outline default state in Diff buffers Matthias Meulien
2021-11-13 17:45 ` Juri Linkov
2021-11-13 18:08 ` Matthias Meulien
2021-11-13 18:27 ` Juri Linkov
2021-11-13 18:41 ` Matthias Meulien
2021-11-13 19:29 ` Juri Linkov
2021-11-13 21:27 ` Matthias Meulien
2021-11-13 23:29 ` Matthias Meulien
2021-11-29 17:06 ` Juri Linkov
2021-11-30 19:33 ` Matthias Meulien
2021-12-11 18:18 ` Matthias Meulien
2021-12-12 8:43 ` Juri Linkov
2021-12-13 7:55 ` Matthias Meulien
2021-12-13 8:58 ` Juri Linkov [this message]
2021-12-26 16:05 ` Matthias Meulien
2021-12-26 16:21 ` Eli Zaretskii
2021-12-26 19:19 ` Matthias Meulien
2021-12-26 20:32 ` Matthias Meulien
2021-12-26 20:55 ` Matthias Meulien
2021-12-27 19:52 ` Juri Linkov
2021-12-28 18:37 ` Juri Linkov
2021-12-28 21:46 ` Matthias Meulien
2021-12-28 22:28 ` Matthias Meulien
2022-01-11 17:46 ` Juri Linkov
2022-01-14 16:41 ` Matthias Meulien
2022-01-16 18:14 ` Juri Linkov
2022-01-17 21:10 ` Matthias Meulien
2022-01-29 19:12 ` Juri Linkov
2022-02-05 18:45 ` Juri Linkov
2022-02-05 22:00 ` Lars Ingebrigtsen
2022-02-12 17:09 ` Juri Linkov
2022-02-12 17:26 ` Matthias Meulien
2022-02-14 21:07 ` Matthias Meulien
2022-02-14 21:13 ` Matthias Meulien
2022-02-14 21:33 ` Matthias Meulien
2022-02-14 21:39 ` Matthias Meulien
2022-02-16 19:20 ` Juri Linkov
2021-12-28 18:32 ` Juri Linkov
2021-12-28 21:45 ` Matthias Meulien
2021-11-14 18:25 ` Juri Linkov
2021-11-14 19:35 ` Matthias Meulien
2021-11-14 19:46 ` Juri Linkov
2021-11-14 19:54 ` Matthias Meulien
2021-11-14 20:31 ` Juri Linkov
2021-12-28 8:09 ` Matthias Meulien
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86fsqwc01d.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=51809@debbugs.gnu.org \
--cc=orontee@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).