bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#1092: compilation-goto-error goes to wrong location when buffer has


From: Eli Zaretskii
Subject: bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions
Date: Sun, 03 Jan 2016 17:31:39 +0200

> From: Stefan Monnier <address@hidden>
> Date: Sun, 03 Jan 2016 01:22:31 -0500
> Cc: address@hidden
> 
> > I'd agree that either selective-display should be marked as deprecated,
> > or the problem should be fixed. I don't know what the status of
> > selective-display is, though - it might be worth bringing this up in
> > emacs-devel.
> 
> There are several problems with selective-display:
> - first and foremost, the variable provides 2 different features:
>   - when set to t, it makes CR behave specially (it's a special
>     line-separator that makes the next line invisible).
>   - when set to a number, it makes all lines indented deeper than this
>     number invisible.

Why is that a problem?  From my POV, it's the same feature in 2
flavors.  We have similar stuff all over the place.

> - The first use should be declared obsolete because overlays provide
>   a much better way to do the same thing.  There might still be a few
>   packages out there using this old selective-display thingy but they
>   really need to move on.

I see no reason whatsoever to obsolete this.  (We already did, but I
think that was a mistake.)  It is a much more lightweight feature than
overlays (certainly performance-wise, but also in other aspects).  The
fact that selective-display affects the display engine code in just 3
places, and with almost trivial code, while overlays do that in about
20 places (and need a much heavier and trickier support code) alone
speaks volumes, I think.

I wish every rarely used display feature was so lightweight as
selective-display.

> - The second use should be replaced by a minor mode which provides the
>   same feature using overlays, but nobody bothered to do so.
>   Maybe because this second use is very rarely useful at all.
>   So maybe this second use should be just dropped (i.e. made obsolete
>   without providing an alternative).

I would object to dropping it without a good alternative.

Anyway, I don't see how this report of a minor bug should trigger such
far-reaching conclusions.  It took me all of 5 minutes to fix it; we
should have done this 7 years ago.  I'm sorry we didn't, but better
late than never.





reply via email to

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