Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Anyway, do you think it is a good idea to write some text temporarily in
>>>> a buffer?
>
> It's useful to clarify your question by mentioning that you're talking
> about a file buffer :-)
>
> It's usually not recommended to make the buffer's content different from
> the file's content, because it makes things more complicated and comes
> with various caveat and rough edges.
>
> But we do that on various occasions nevertheless.
>
> Packages that come to mind are `hexl-mode`, `archive-mode` and
> `tar-mode`, for example.  Rmail to some extent as well, I'm sure there
> are many more.
>
>>>> My experience suggests no, but if I use overlays then I can't select
>>>> and press RET on the links, and I can't scroll if the list is too
>>>> long.  WDYT?
>
> Indeed.  In `nhexl-mode` I try to make overlays work a bit like "plain
> text" works in `hexl-mode`, but it takes work and the result is
> still limited.
>
>> While saving, reverted:
>
> Which mechanism did you use for that?

'before-save-hook'.

>
>> (I don't know what happens while auto-saving :( )
>
> If you haven't done anything for that, autosaving will save the
> buffer's content as is.
>
> A good way to make the save work correctly both for `save-buffer` and
> for auto-save is to use `write-region-annotate-functions`.
> That hook doesn't directly let you remove text, but it can `set-buffer`
> to a new buffer in which case that other buffer's content will be
> written instead.
>

Seems to be an hack, but probably better.

>> Inside 'xref--collect-matches', reverted, otherwise xref doesn't match
>> correctly, since the file and buffer lines don't really match.  After
>> 'xref--collect-matches', again the text.
>
> Exactly: it comes with a lot of caveats :-(
>
> Another approach is to use *another* buffer than the file buffer.
> This is less transparent to the user but tends to come with fewer
> dark corners.

My goal is show on the file buffer.  And the list can be quite large.

>
>
>         Stefan
>

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."