[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 <monnier@IRO.UMontreal.CA>
> Date: Sun, 03 Jan 2016 01:22:31 -0500
> Cc: 1092@debbugs.gnu.org
>
> > 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.
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Andrew Hyatt, 2016/01/02
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Stefan Monnier, 2016/01/03
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions,
Eli Zaretskii <=
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Stefan Monnier, 2016/01/03
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Eli Zaretskii, 2016/01/03
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Stefan Monnier, 2016/01/03
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Eli Zaretskii, 2016/01/03
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Stefan Monnier, 2016/01/03
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Eli Zaretskii, 2016/01/04
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Stefan Monnier, 2016/01/04
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Andrew Hyatt, 2016/01/04
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Eli Zaretskii, 2016/01/05
- bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions, Eli Zaretskii, 2016/01/05