GNU bug report logs - #1092
compilation-goto-error goes to wrong location when buffer has hidden regions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1092 in the body.
You can then email your comments to 1092 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Peter Sanford <pms.mail <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: compilation-goto-error goes to wrong location when buffer has hidden
 regions
Date: Sun, 05 Oct 2008 11:38:08 -0700

I have the copyright region at the head of my files hidden using 
selective-display and ^M. When this region is hidden functions like 
compilation-goto-error jump to the wrong location: n lines below the 
correct location where n is the number of hidden lines. If I use 
goto-line and the line number reported in the compilation buffer, emacs 
takes me to the correct line.

When the region is visible everything works as expected.

found on:
GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.14.1) of 2008-09-05 
on vernadsky, modified by Ubuntu

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Peter Sanford <pms.mail <at> gmail.com>
Cc: 1092 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions
Date: Mon, 06 Oct 2008 21:50:14 -0400

> I have the copyright region at the head of my files hidden using
> selective-display and ^M. When this region is hidden functions like
> compilation-goto-error jump to the wrong location: n lines below the correct
> location where n is the number of hidden lines. If I use goto-line and the
> line number reported in the compilation buffer, emacs takes me to the
> correct line.

For what it's worth, I'd recommend you fix this problem by not using
selective-display (replace it with an overlay).


        Stefan

Message #20 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
	buffer has hidden regions
Date: Sat, 09 Jul 2011 14:00:07 -0400

Stefan Monnier wrote:

> For what it's worth, I'd recommend you fix this problem by not using
> selective-display (replace it with an overlay).

Should `selective-display' be marked as obsolete?
(I kind of thought it was, but it does not seem to be.)
Can it do anything that other methods of making regions invisible
cannot?

Message #25 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 1092 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sat, 02 Jan 2016 16:43:00 -0500

Glenn Morris <rgm <at> gnu.org> writes:

> Stefan Monnier wrote:
>
>> For what it's worth, I'd recommend you fix this problem by not using
>> selective-display (replace it with an overlay).
>
> Should `selective-display' be marked as obsolete?
> (I kind of thought it was, but it does not seem to be.)
> Can it do anything that other methods of making regions invisible
> cannot?

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.

Glenn, do you have a quick way to reproduce this starting from a clean
emacs (emacs -Q)? This will make it easier for developers to reproduce &
fix the issue.

Message #28 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: rgm <at> gnu.org, 1092 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 05:35:38 +0200

> From: Andrew Hyatt <ahyatt <at> gmail.com>
> Date: Sat, 02 Jan 2016 16:43:00 -0500
> Cc: 1092 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
> 
> Glenn Morris <rgm <at> gnu.org> writes:
> 
> > Stefan Monnier wrote:
> >
> >> For what it's worth, I'd recommend you fix this problem by not using
> >> selective-display (replace it with an overlay).
> >
> > Should `selective-display' be marked as obsolete?
> > (I kind of thought it was, but it does not seem to be.)
> > Can it do anything that other methods of making regions invisible
> > cannot?
> 
> 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.
> 
> Glenn, do you have a quick way to reproduce this starting from a clean
> emacs (emacs -Q)? This will make it easier for developers to reproduce &
> fix the issue.

Indeed, a clear reproduction recipe will be welcome.

Thanks.

Message #31 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andrew Hyatt <ahyatt <at> gmail.com>, 1092 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sat, 02 Jan 2016 23:06:15 -0500

I'm not going to give a recipe for a bug that I marked wontfix 7 years
ago, and which has recently been closed. If no-one cares enough to
follow the original example, no one is going to fix it. Selective
display is 7 years more obsolete than it was then. Let's move on.

Message #34 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 01:22:31 -0500

> 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.
- 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.
- 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).


-- Stefan

Message #41 received at 1092-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: ahyatt <at> gmail.com, 1092-done <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 17:25:53 +0200

[Message part 1 (text/plain, inline)]

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Andrew Hyatt <ahyatt <at> gmail.com>,  1092 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Sat, 02 Jan 2016 23:06:15 -0500
> 
> I'm not going to give a recipe for a bug that I marked wontfix 7 years
> ago, and which has recently been closed. If no-one cares enough to
> follow the original example, no one is going to fix it.

(There was no example in the original report, not AFAICT.)

I think Andrew just wanted to DTRT with this bug, which is
commendable, IMO.

I came up with a simple example, see below.

> Selective display is 7 years more obsolete than it was then. Let's
> move on.

I see no reason not to fix this simple bug, so I just did it.

Here's a reproducible recipe, for the record:

 . Visit the attached file
 . Replace every C-j in the commentary block with a C-m
 . M-: (setq selective-display t) RET
 . Save the buffer (note that the file on disk has its newlines
   restored by write-region -- I wonder how many people knew we had
   this feature in write-region)
 . M-x compile RET gcc -Wall -o hello hello.c RET
 . Type "C-x `" and observe the incorrect behavior: point in the
   hello.c buffer goes to the end of the buffer, and the error
   locus is not highlighted

With the current emacs-25 branch, this example works correctly.

I'm marking this bug as done (after reopening it).

[hello.c (application/octet-stream, attachment)]

Message #44 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: 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 <at> IRO.UMontreal.CA>
> Date: Sun, 03 Jan 2016 01:22:31 -0500
> Cc: 1092 <at> 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.

Message #47 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 11:06:19 -0500

>> 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?

It's not a problem in itself, no.  But it means that if you want to
obsolete only one of the two uses, you can't just mark the variable
as obsolete.

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

It's not lightweight on the Elisp side where you need to add a lot of
extra code in ever more places to handle the special meaning of \r in
that rare case.

> 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.

I think the fix is worse than the problem, personally.


        Stefan

Message #50 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 18:53:13 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
> Date: Sun, 03 Jan 2016 11:06:19 -0500
> 
> >> 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?
> 
> It's not a problem in itself, no.  But it means that if you want to
> obsolete only one of the two uses, you can't just mark the variable
> as obsolete.

We cannot declare it obsolete without replacement features in place to
which we can point.

> > I wish every rarely used display feature was so lightweight as
> > selective-display.
> 
> It's not lightweight on the Elisp side where you need to add a lot of
> extra code in ever more places to handle the special meaning of \r in
> that rare case.

I don't see any problem with that, either.  Our Lisp code is full of
special cases anyway.

> > 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.
> 
> I think the fix is worse than the problem, personally.

Yes, we disagree.

Message #53 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 14:39:44 -0500

>> It's not a problem in itself, no.  But it means that if you want to
>> obsolete only one of the two uses, you can't just mark the variable
>> as obsolete.
> We cannot declare it obsolete without replacement features in place to
> which we can point.

For the selective-display=t case, we have had replacement features in
place and in wide use for what, twenty years?
We can very definitely declare this use case obsolete and stop trying to
fix problems we bump into when it's used.


        Stefan

Message #56 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 21:49:11 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
> Date: Sun, 03 Jan 2016 14:39:44 -0500
> 
> >> It's not a problem in itself, no.  But it means that if you want to
> >> obsolete only one of the two uses, you can't just mark the variable
> >> as obsolete.
> > We cannot declare it obsolete without replacement features in place to
> > which we can point.
> 
> For the selective-display=t case, we have had replacement features in
> place and in wide use for what, twenty years?

Which replacements are those?  I mean user commands or settings, not
infrastructure on which to base them.

> We can very definitely declare this use case obsolete

We already did.  And look how well did it serve us.

Message #59 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <jwiegley <at> gmail.com>
To: 1092 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, pms.mail <at> gmail.com
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 13:13:05 -0800

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

> I think Andrew just wanted to DTRT with this bug, which is commendable, IMO.

Deserving of a second commendation, even. :) And thank you for simply
addressing the bug, Eli.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Message #62 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Sun, 03 Jan 2016 19:42:50 -0500

>> For the selective-display=t case, we have had replacement features in
>> place and in wide use for what, twenty years?
> Which replacements are those?  I mean user commands or settings, not
> infrastructure on which to base them.

selective-display=t gives no user command, so I have no idea what you're
expecting as "user command" to replace it.  There are almost no uses of 
selective-display=t around, they've almost all been replaced by uses
of overlays.

>> We can very definitely declare this use case obsolete
> We already did.  And look how well did it serve us.

Which problem did its obsolescence cause?


        Stefan

Message #65 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Mon, 04 Jan 2016 17:41:47 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
> Date: Sun, 03 Jan 2016 19:42:50 -0500
> 
> >> For the selective-display=t case, we have had replacement features in
> >> place and in wide use for what, twenty years?
> > Which replacements are those?  I mean user commands or settings, not
> > infrastructure on which to base them.
> 
> selective-display=t gives no user command, so I have no idea what you're
> expecting as "user command" to replace it.

Setting a variable is a user-level feature.

And I did mean _both_ uses of selective-display, not only that single
one.  If and when there are replacements for both of them, we can
declare the variable obsolete and perhaps also remove its current
handling from the sources, if the replacement features allow to
emulate the variable's effect.

> There are almost no uses of selective-display=t around, they've
> almost all been replaced by uses of overlays.

We have no idea of how many uses of this are out there.  We only know
what's in Emacs and in ELPA, which is just a fraction of what's out
there.

> >> We can very definitely declare this use case obsolete
> > We already did.  And look how well did it serve us.
> 
> Which problem did its obsolescence cause?

This one, for example.  More importantly, it didn't resolve any
problem.

Anyway, I don't see where this discussion is going.  The original bug
is fixed and closed.  If you or someone else have a patch to replace
selective-display with alternative user features, let's see those
patches (preferably in another thread).

Thanks.

Message #68 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Mon, 04 Jan 2016 23:12:29 -0500

> Setting a variable is a user-level feature.

I've never ever heard of a user setting selective-display manually
to t.  It's always done from some Elisp package.  And it's no wonder:
setting selective-display=t has about zero effect.  It only starts to do
something when you start turning \n into \r (which is also when the
problems start to come up).

>> >> For the selective-display=t case, we have had replacement features in
>> >> place and in wide use for what, twenty years?
>> > Which replacements are those?  I mean user commands or settings, not
>> > infrastructure on which to base them.
>> selective-display=t gives no user command, so I have no idea what you're
>> expecting as "user command" to replace it.
> And I did mean _both_ uses of selective-display, not only that single
> one.

As you can see above in the text you quoted, I was specifically
referring to the selective-display=t case.

> If and when there are replacements for both of them, we can
> declare the variable obsolete and perhaps also remove its current
> handling from the sources, if the replacement features allow to
> emulate the variable's effect.

The problem is that nobody really cares about the non-t part of
selective-display: it doesn't cause any serious problems (contrary to
the use of \r for "kind of end-of-line" in selective-display=t which
requires special handling all over the place), isn't use very widely
either, and is only a user-level feature (I don't know of any Elisp
package making use of it).

>> There are almost no uses of selective-display=t around, they've
>> almost all been replaced by uses of overlays.
> We have no idea of how many uses of this are out there.

Of course we do have some idea.

> We only know what's in Emacs and in ELPA, which is just a fraction of
> what's out there.

If you never look further than those, I hope you're an exception.
I have a fairly extensive list of random packages I've bumped into over
the years.

And I can even tell you why there are very few uses of
selective-display=t left: because it's a pain in the rear to use and is
very limited.  It's much simpler and more flexible to use overlays, so
most packages have been rewritten over time to use overlays instead.

>> >> We can very definitely declare this use case obsolete
>> > We already did.  And look how well did it serve us.
>> Which problem did its obsolescence cause?
> This one, for example.

How did declaring the feature obsolete cause this bug?
AFAICT this bug has been around since long before we declared the
feature obsolete.

> More importantly, it didn't resolve any problem.

Declaring a feature obsolete doesn't resolve any problem.
It just expresses our intent not to resolve those problems.

> Anyway, I don't see where this discussion is going.  The original bug
> is fixed and closed.  If you or someone else have a patch to replace
> selective-display with alternative user features, let's see those
> patches (preferably in another thread).

Again, I have no clue what kind of user feature you're expecting.
selective-display=t is 100% obsolete, with overlays as replacements
available for so many years it's not even funny.

My only intention in this discussion is to try and saves us from someone
else ever trying to "fix" such bugs like you did.  Instead we should
always reply with something like "if it hurts when you use
selective-display=t, then don't use it".  Same applies for any other
obsoleted feature.


        Stefan

Message #71 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Mon, 04 Jan 2016 23:28:33 -0500

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>> Setting a variable is a user-level feature.
>
> I've never ever heard of a user setting selective-display manually
> to t.  It's always done from some Elisp package.  And it's no wonder:
> setting selective-display=t has about zero effect.  It only starts to do
> something when you start turning \n into \r (which is also when the
> problems start to come up).
>
>>> >> For the selective-display=t case, we have had replacement features in
>>> >> place and in wide use for what, twenty years?
>>> > Which replacements are those?  I mean user commands or settings, not
>>> > infrastructure on which to base them.
>>> selective-display=t gives no user command, so I have no idea what you're
>>> expecting as "user command" to replace it.
>> And I did mean _both_ uses of selective-display, not only that single
>> one.
>
> As you can see above in the text you quoted, I was specifically
> referring to the selective-display=t case.
>
>> If and when there are replacements for both of them, we can
>> declare the variable obsolete and perhaps also remove its current
>> handling from the sources, if the replacement features allow to
>> emulate the variable's effect.
>
> The problem is that nobody really cares about the non-t part of
> selective-display: it doesn't cause any serious problems (contrary to
> the use of \r for "kind of end-of-line" in selective-display=t which
> requires special handling all over the place), isn't use very widely
> either, and is only a user-level feature (I don't know of any Elisp
> package making use of it).
>
>>> There are almost no uses of selective-display=t around, they've
>>> almost all been replaced by uses of overlays.
>> We have no idea of how many uses of this are out there.
>
> Of course we do have some idea.
>
>> We only know what's in Emacs and in ELPA, which is just a fraction of
>> what's out there.
>
> If you never look further than those, I hope you're an exception.
> I have a fairly extensive list of random packages I've bumped into over
> the years.
>
> And I can even tell you why there are very few uses of
> selective-display=t left: because it's a pain in the rear to use and is
> very limited.  It's much simpler and more flexible to use overlays, so
> most packages have been rewritten over time to use overlays instead.
>
>>> >> We can very definitely declare this use case obsolete
>>> > We already did.  And look how well did it serve us.
>>> Which problem did its obsolescence cause?
>> This one, for example.
>
> How did declaring the feature obsolete cause this bug?
> AFAICT this bug has been around since long before we declared the
> feature obsolete.
>
>> More importantly, it didn't resolve any problem.
>
> Declaring a feature obsolete doesn't resolve any problem.
> It just expresses our intent not to resolve those problems.
>
>> Anyway, I don't see where this discussion is going.  The original bug
>> is fixed and closed.  If you or someone else have a patch to replace
>> selective-display with alternative user features, let's see those
>> patches (preferably in another thread).
>
> Again, I have no clue what kind of user feature you're expecting.
> selective-display=t is 100% obsolete, with overlays as replacements
> available for so many years it's not even funny.
>
> My only intention in this discussion is to try and saves us from someone
> else ever trying to "fix" such bugs like you did.  Instead we should
> always reply with something like "if it hurts when you use
> selective-display=t, then don't use it".  Same applies for any other
> obsoleted feature.

I just was looking at selective-display, and noticed that we still have
documentation for the setting of "t" on the variable (it doesn't seem to
be mentioned in the emacs manual). If this really is obsolete, should
that documentation be removed?

>
>
>         Stefan

Message #74 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Tue, 05 Jan 2016 18:52:26 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
> Date: Mon, 04 Jan 2016 23:12:29 -0500
> 
> Declaring a feature obsolete doesn't resolve any problem.
> It just expresses our intent not to resolve those problems.

I think it expresses our intent to remove the feature at some point.
It doesn't necessarily follow that we will let it bitrot until then.

> My only intention in this discussion is to try and saves us from someone
> else ever trying to "fix" such bugs like you did.  Instead we should
> always reply with something like "if it hurts when you use
> selective-display=t, then don't use it".  Same applies for any other
> obsoleted feature.

I understand your intention very well, but I don't agree with such a
policy.  I think as long as the feature is not deleted, we ought to
fix bugs in it, unless the fix is very complex or could adversely
affect other packages, or could cause some other complication.  Bugs
are not a vehicle for telling users not to use an obsolete feature.
If we really want to remove a feature, we should just do that, after
making sure there's a usable replacement.

Message #77 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1092 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Tue, 05 Jan 2016 18:54:34 +0200

> From: Andrew Hyatt <ahyatt <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  1092 <at> debbugs.gnu.org
> Date: Mon, 04 Jan 2016 23:28:33 -0500
> 
> I just was looking at selective-display, and noticed that we still have
> documentation for the setting of "t" on the variable (it doesn't seem to
> be mentioned in the emacs manual). If this really is obsolete, should
> that documentation be removed?

The ELisp manual mentions it and says it's obsolete.  I think the doc
string should say the same, so I just made that change.

Message #80 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Tue, 05 Jan 2016 12:12:51 -0500

>> Declaring a feature obsolete doesn't resolve any problem.
>> It just expresses our intent not to resolve those problems.
> I think it expresses our intent to remove the feature at some point.

That's also true.

> It doesn't necessarily follow that we will let it bitrot until then.

Usually we try to keep it working, i.e. we try to fix *new* bugs.
But we normally stop trying to improve it, so there's no need to fix
bugs that existed long before.

> I understand your intention very well, but I don't agree with such a
> policy.  I think as long as the feature is not deleted, we ought to
> fix bugs in it, unless the fix is very complex or could adversely
> affect other packages, or could cause some other complication.  Bugs
> are not a vehicle for telling users not to use an obsolete feature.
> If we really want to remove a feature, we should just do that, after
> making sure there's a usable replacement.

The code you changed fixed just one of hundreds of similar cases all
over the Elisp code base.  Basically any use of forward-line,
beginning-of-line, line-end-position, ... needs to be adjusted to
account for selective-display=t.

This need to change every package to accommodate the possible use of
selective-display=t is one of the main reasons why we don't want to
support it any more, i.e. why we want to declare it obsolete.


        Stefan

Message #83 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Tue, 05 Jan 2016 19:27:55 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org
> Date: Tue, 05 Jan 2016 12:12:51 -0500
> 
> The code you changed fixed just one of hundreds of similar cases all
> over the Elisp code base.  Basically any use of forward-line,
> beginning-of-line, line-end-position, ... needs to be adjusted to
> account for selective-display=t.
> 
> This need to change every package to accommodate the possible use of
> selective-display=t is one of the main reasons why we don't want to
> support it any more, i.e. why we want to declare it obsolete.

I didn't say we should fix all of the potential bugs, only those which
were reported, i.e. those which actually bother someone.

Message #86 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <jwiegley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ahyatt <at> gmail.com, 1092 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Tue, 05 Jan 2016 12:00:55 -0800

[Message part 1 (text/plain, inline)]

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

>> My only intention in this discussion is to try and saves us from someone
>> else ever trying to "fix" such bugs like you did. Instead we should always
>> reply with something like "if it hurts when you use selective-display=t,
>> then don't use it". Same applies for any other obsoleted feature.

> I understand your intention very well, but I don't agree with such a policy.
> I think as long as the feature is not deleted, we ought to fix bugs in it,
> unless the fix is very complex or could adversely affect other packages, or
> could cause some other complication. Bugs are not a vehicle for telling
> users not to use an obsolete feature. If we really want to remove a feature,
> we should just do that, after making sure there's a usable replacement.

I have to say I'm in complete agreement with Eli on this point. If it's code
that we'll ship, it deserves to be fixed like any other functionality we
deliver. If it's no longer to be fixed or maintained, it should be removed.
Delivering buggy code is not a sound deprecation strategy.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[signature.asc (application/pgp-signature, inline)]

Message #89 received at 1092 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1092 <at> debbugs.gnu.org, ahyatt <at> gmail.com
Subject: Re: bug#1092: compilation-goto-error goes to wrong location when
 buffer has hidden regions
Date: Wed, 06 Jan 2016 23:17:09 -0500

> I have to say I'm in complete agreement with Eli on this point. If it's code
> that we'll ship, it deserves to be fixed like any other functionality we
> deliver.  If it's no longer to be fixed or maintained, it should be removed.
> Delivering buggy code is not a sound deprecation strategy.

We're talking a bout bugs we've shipped long before they were
reported.  And where removing the feature would piss off many
more people.

Anyway, it's not really my problem any more, luckily,


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.