Subject: bug#67161: 30.0.50; [PATCH] Add option `dired-filename-display-length'

From: Eli Zaretskii <[email-masked]>
Date: Tue, 21 Nov 2023 13:55:08 +0200

> From: Juri Linkov <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  Liu Hui <[email-masked]>,
>   [email-masked],  [email-masked]
> Date: Tue, 21 Nov 2023 09:52:02 +0200
> 
> > I think the idea is that matching invisible text is somewhat
> > inconvenient, so it's better to temporarily reveal/open that text.
> > But I think it points to an bug in Isearch: when `isearch-invisible` is
> > `open` we should match text inside invisible text, regardless if we can
> > reveal/open that invisible text or not.  IOW `open` should find the
> > same matches as `t`, the only difference being that it additionally
> > (tries to) reveal/open the text.
> 
> This could be a new value like `open-or-match` with a trivial change:
> 
> @@ -3899,6 +3899,9 @@ isearch-filter-visible
>  of what `isearch-range-invisible' says."
>    (and (not (text-property-not-all beg end 'inhibit-isearch nil))
>         (or (eq search-invisible t)
> +           (when (eq search-invisible 'open-or-match)
> +             (isearch-range-invisible beg end)
> +             t)
>             (not (isearch-range-invisible beg end)))))
> 
> But I doubt that it could be enabled by default because in many cases
> it's too confusing for users to stop at a match that is not visible.

Isn't it possible to unhide the invisible text by temporarily
manipulating buffer-invisibility-spec?