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

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

[Peter Sanford]

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

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

[Stefan Monnier]

> 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

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

[Glenn Morris]

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?

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

[Andrew Hyatt]

Glenn Morris <rgm@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.

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

[Eli Zaretskii]

> From: Andrew Hyatt <ahyatt@gmail.com>
> Date: Sat, 02 Jan 2016 16:43:00 -0500
> Cc: 1092@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> Glenn Morris <rgm@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.

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

[Glenn Morris]

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.

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

[Stefan Monnier]

> 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

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

[Eli Zaretskii]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Andrew Hyatt <ahyatt@gmail.com>,  1092@debbugs.gnu.org,  monnier@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).


[-- Attachment #2: hello.c --]
[-- Type: application/octet-stream, Size: 970 bytes --]

/* Display generation from window structure and buffer text.

	 Copyright (C) 1985-1988, 1993-1995, 1997-2015 Free Software Foundation,
	 Inc.

	 This file is part of GNU Emacs.

	 GNU Emacs is free software: you can redistribute it and/or modify
	 it under the terms of the GNU General Public License as published by
	 the Free Software Foundation, either version 3 of the License, or
	 (at your option) any later version.

	 GNU Emacs is distributed in the hope that it will be useful,
	 but WITHOUT ANY WARRANTY; without even the implied warranty of
	 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
	 GNU General Public License for more details.

	 You should have received a copy of the GNU General Public License
	 along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */

#include <stdio.h>

int
main (int argc, char *argv[])
{
  iprintfi ("Hello, world of %d %s\n", argc, argv[0]);

  return argcf + 5;
}

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

[Eli Zaretskii]

> 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

[Stefan Monnier]

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: ahyatt@gmail.com, 1092@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.

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

[Stefan Monnier]

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: ahyatt@gmail.com, 1092@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.

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

[John Wiegley]

>>>>> Eli Zaretskii <eliz@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

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

[Stefan Monnier]

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: ahyatt@gmail.com, 1092@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.

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

[Stefan Monnier]

> 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

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

[Andrew Hyatt]

Stefan Monnier <monnier@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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: ahyatt@gmail.com, 1092@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.

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

[Eli Zaretskii]

> From: Andrew Hyatt <ahyatt@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  1092@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.

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

[Stefan Monnier]

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: ahyatt@gmail.com, 1092@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.

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

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

>>>>> Eli Zaretskii <eliz@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

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

[Stefan Monnier]

> 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