> > I don't know why, this is a hypothetical, but fairly realistic
> > situation, right?
>
> Discussing hypothetical issues leads nowhere, according to my experience.
> Let's focus on actual issues.

I have shown you a simple way how your supposed can break things. Yes,
it's not an everyday occurence, but if I could think of one easily,
this or something else to this effect will be used in reality. As a
reminder, Emacs self-advertises itself as "advanced, extensible"
editor. You are making some extensions illegal, because maybe
something somewhere might become slow. You are sacrificing
functionality in the name of performance.

> It is for example possible to parse the buffer outside of
> fontification-functions

You are ignoring that this is not only about fontification. It can
happen anywhere, because I may need full access to the buffer at any
time.

> and to use the result of that parsing inside
> fontification-functions.

Parsing is done lazily. You are saying I need to prepare parsing
results everywhere in the whole buffer at once (which easily can be 10
MB - I have seen logs 250 MB in size, but not ones with lines longer
than ~50 K characters), because I don't know in advance where
fontification (or whatever else) might be needed.

> Yet another method would be to use a simpler fontification method in
> buffers with too long lines.  Yet another method would be to turn
> font locking off in buffers with too long lines.

I don't want to lose fontification in a 10 MB buffer because one line
somewhere there is over 10000 characters.

> Yet another method would be to truncate too long lines.

Eh? And corrupt the log? Otherwise, even if it is invisible it stays
in the buffer.

> I also cannot understand why it is necessary, in log files in
> which all lines are independent

No they are not. Typically Java exceptions are logged like this:

    2022-09-15 23:11:00.014 ERROR [some.Class] (some-thread) bla-bla-bla
    exception.Class: bla-bla-bla
          at some.Class

and so on. Exceptions are not the only multiline entries.

I have already complained about this often-seen-here "I also cannot
understand", which implies "therefore no-one will ever need", but you
said it was bad attitude from me.

> > Will I be able to lift locked narrowing restrictions without knowing the
> > tag?
>
> This is akin to a security mechanism, there is no reason to make it
> possible to turn it off "too easily".

Security against what, for fuck's sake? By trying to prevent "making
it too easily", you are preventing this at all in general case. And
what are the gains?

Paul

On Fri, 16 Sept 2022 at 00:16, Gregory Heytings <gregory@heytings.org>
wrote:

>
> >
> > I don't know why, this is a hypothetical, but fairly realistic
> > situation, right?
> >
>
> Discussing hypothetical issues leads nowhere, according to my experience.
> Let's focus on actual issues.
>
> >
> > Now, let's say function `logview-do-bla-bla-bla' cannot work with
> > narrowed buffer (half of functions in Logview cannot).
> >
>
> You said I'm not allowed to tell you that your code could do things
> differently, but that doesn't mean it isn't true.  It is for example
> possible to parse the buffer outside of fontification-functions and to use
> the result of that parsing inside fontification-functions.  Yet another
> method would be to use a simpler fontification method in buffers with too
> long lines.  Yet another method would be to turn font locking off in
> buffers with too long lines.  Yet another method would be to truncate too
> long lines.  I also cannot understand why it is necessary, in log files in
> which all lines are independent, to move beyond the beginning and end of a
> line to decide how it must be fontified.
>
> >
> > Will I be able to lift locked narrowing restrictions without knowing the
> > tag?
> >
>
> This is akin to a security mechanism, there is no reason to make it
> possible to turn it off "too easily".
>