emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs master + org Wrong type argument: number-or-marker-p


From: Eli Zaretskii
Subject: Re: emacs master + org Wrong type argument: number-or-marker-p
Date: Thu, 04 Aug 2022 08:51:46 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Po Lu <luangruo@yahoo.com>,  acm@muc.de,  gregory@heytings.org,
>   mattiase@acm.org,  philipk@posteo.net,  silent2600@gmail.com,
>   emacs-devel@gnu.org
> Date: Wed, 03 Aug 2022 16:47:17 -0400
> 
> >> Then wouldn't it be better to fix the font-locking code to not widen
> >> outside bounds explictly specified by redisplay, instead of making
> >> `widen' and `narrow-to-region' in effect inoperable in those
> >> circumstances?
> > How would that work in practice?  Font-locking code uses functions and
> > regexps provided by the major modes, so it cannot by itself prevent
> > widening.
> 
> I don't understand what you're talking about.
> 
> AFAIK in 99% of the cases, font-lock.el itself widens, then uses the
> regexps (which can't widen) and the functions provided by the major mode
> almost none of which (with rare exceptions, of course, most of them
> historical) will widen since font-lock already did it for them (and
> since widening will lead to bugs when used within something like
> mmm-mode or mhtml-mode).

What will we do with the "rare" exceptions, such as CC Mode, for
example?

And what will we do with (I expect) the much larger group which
becomes broken when font-lock stops widening, and their assumptions
about being always able to access any buffer position become false?

IOW, I'd love to see the brave new world where font-lock doesn't widen
and none of the major modes we care about do, and fontifications still
work reasonably well.  Then we can revisit the strategy of handling
long lines, and perhaps change the defaults as result.  But for now,
this is purely academic, with too many "ifs" and "whens" and too
little actual development in that direction.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]