* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions @ 2008-10-05 18:38 Peter Sanford 2008-10-07 1:50 ` Stefan Monnier 0 siblings, 1 reply; 24+ messages in thread From: Peter Sanford @ 2008-10-05 18:38 UTC (permalink / raw) To: bug-gnu-emacs 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2008-10-05 18:38 bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions Peter Sanford @ 2008-10-07 1:50 ` Stefan Monnier 2011-07-09 18:00 ` Glenn Morris 0 siblings, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2008-10-07 1:50 UTC (permalink / raw) To: Peter Sanford; +Cc: bug-gnu-emacs, 1092 > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2008-10-07 1:50 ` Stefan Monnier @ 2011-07-09 18:00 ` Glenn Morris 2016-01-02 21:43 ` Andrew Hyatt 0 siblings, 1 reply; 24+ messages in thread From: Glenn Morris @ 2011-07-09 18:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1092 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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2011-07-09 18:00 ` Glenn Morris @ 2016-01-02 21:43 ` Andrew Hyatt 2016-01-03 3:35 ` Eli Zaretskii 2016-01-03 6:22 ` Stefan Monnier 0 siblings, 2 replies; 24+ messages in thread From: Andrew Hyatt @ 2016-01-02 21:43 UTC (permalink / raw) To: Glenn Morris; +Cc: 1092, Stefan Monnier 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-02 21:43 ` Andrew Hyatt @ 2016-01-03 3:35 ` Eli Zaretskii 2016-01-03 4:06 ` Glenn Morris 2016-01-03 6:22 ` Stefan Monnier 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-03 3:35 UTC (permalink / raw) To: Andrew Hyatt; +Cc: 1092, monnier > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 3:35 ` Eli Zaretskii @ 2016-01-03 4:06 ` Glenn Morris 2016-01-03 15:25 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Glenn Morris @ 2016-01-03 4:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Andrew Hyatt, 1092, monnier 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 4:06 ` Glenn Morris @ 2016-01-03 15:25 ` Eli Zaretskii 2016-01-03 21:13 ` John Wiegley 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-03 15:25 UTC (permalink / raw) To: Glenn Morris; +Cc: ahyatt, 1092-done, monnier [-- 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; } ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 15:25 ` Eli Zaretskii @ 2016-01-03 21:13 ` John Wiegley 0 siblings, 0 replies; 24+ messages in thread From: John Wiegley @ 2016-01-03 21:13 UTC (permalink / raw) To: 1092; +Cc: pms.mail >>>>> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-02 21:43 ` Andrew Hyatt 2016-01-03 3:35 ` Eli Zaretskii @ 2016-01-03 6:22 ` Stefan Monnier 2016-01-03 15:31 ` Eli Zaretskii 1 sibling, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2016-01-03 6:22 UTC (permalink / raw) To: Andrew Hyatt; +Cc: 1092 > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 6:22 ` Stefan Monnier @ 2016-01-03 15:31 ` Eli Zaretskii 2016-01-03 16:06 ` Stefan Monnier 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-03 15:31 UTC (permalink / raw) To: Stefan Monnier; +Cc: ahyatt, 1092 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 15:31 ` Eli Zaretskii @ 2016-01-03 16:06 ` Stefan Monnier 2016-01-03 16:53 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2016-01-03 16:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ahyatt, 1092 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 16:06 ` Stefan Monnier @ 2016-01-03 16:53 ` Eli Zaretskii 2016-01-03 19:39 ` Stefan Monnier 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-03 16:53 UTC (permalink / raw) To: Stefan Monnier; +Cc: ahyatt, 1092 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 16:53 ` Eli Zaretskii @ 2016-01-03 19:39 ` Stefan Monnier 2016-01-03 19:49 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2016-01-03 19:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ahyatt, 1092 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 19:39 ` Stefan Monnier @ 2016-01-03 19:49 ` Eli Zaretskii 2016-01-04 0:42 ` Stefan Monnier 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-03 19:49 UTC (permalink / raw) To: Stefan Monnier; +Cc: ahyatt, 1092 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-03 19:49 ` Eli Zaretskii @ 2016-01-04 0:42 ` Stefan Monnier 2016-01-04 15:41 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2016-01-04 0:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ahyatt, 1092 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-04 0:42 ` Stefan Monnier @ 2016-01-04 15:41 ` Eli Zaretskii 2016-01-05 4:12 ` Stefan Monnier 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-04 15:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: ahyatt, 1092 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-04 15:41 ` Eli Zaretskii @ 2016-01-05 4:12 ` Stefan Monnier 2016-01-05 4:28 ` Andrew Hyatt 2016-01-05 16:52 ` Eli Zaretskii 0 siblings, 2 replies; 24+ messages in thread From: Stefan Monnier @ 2016-01-05 4:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ahyatt, 1092 > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-05 4:12 ` Stefan Monnier @ 2016-01-05 4:28 ` Andrew Hyatt 2016-01-05 16:54 ` Eli Zaretskii 2016-01-05 16:52 ` Eli Zaretskii 1 sibling, 1 reply; 24+ messages in thread From: Andrew Hyatt @ 2016-01-05 4:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: 1092 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-05 4:28 ` Andrew Hyatt @ 2016-01-05 16:54 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2016-01-05 16:54 UTC (permalink / raw) To: Andrew Hyatt; +Cc: 1092, monnier > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-05 4:12 ` Stefan Monnier 2016-01-05 4:28 ` Andrew Hyatt @ 2016-01-05 16:52 ` Eli Zaretskii 2016-01-05 17:12 ` Stefan Monnier 2016-01-05 20:00 ` John Wiegley 1 sibling, 2 replies; 24+ messages in thread From: Eli Zaretskii @ 2016-01-05 16:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: ahyatt, 1092 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-05 16:52 ` Eli Zaretskii @ 2016-01-05 17:12 ` Stefan Monnier 2016-01-05 17:27 ` Eli Zaretskii 2016-01-05 20:00 ` John Wiegley 1 sibling, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2016-01-05 17:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ahyatt, 1092 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-05 17:12 ` Stefan Monnier @ 2016-01-05 17:27 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2016-01-05 17:27 UTC (permalink / raw) To: Stefan Monnier; +Cc: ahyatt, 1092 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-05 16:52 ` Eli Zaretskii 2016-01-05 17:12 ` Stefan Monnier @ 2016-01-05 20:00 ` John Wiegley 2016-01-07 4:17 ` Stefan Monnier 1 sibling, 1 reply; 24+ messages in thread From: John Wiegley @ 2016-01-05 20:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ahyatt, 1092, Stefan Monnier [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions 2016-01-05 20:00 ` John Wiegley @ 2016-01-07 4:17 ` Stefan Monnier 0 siblings, 0 replies; 24+ messages in thread From: Stefan Monnier @ 2016-01-07 4:17 UTC (permalink / raw) To: John Wiegley; +Cc: 1092, ahyatt > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-01-07 4:17 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-10-05 18:38 bug#1092: compilation-goto-error goes to wrong location when buffer has hidden regions Peter Sanford 2008-10-07 1:50 ` Stefan Monnier 2011-07-09 18:00 ` Glenn Morris 2016-01-02 21:43 ` Andrew Hyatt 2016-01-03 3:35 ` Eli Zaretskii 2016-01-03 4:06 ` Glenn Morris 2016-01-03 15:25 ` Eli Zaretskii 2016-01-03 21:13 ` John Wiegley 2016-01-03 6:22 ` Stefan Monnier 2016-01-03 15:31 ` Eli Zaretskii 2016-01-03 16:06 ` Stefan Monnier 2016-01-03 16:53 ` Eli Zaretskii 2016-01-03 19:39 ` Stefan Monnier 2016-01-03 19:49 ` Eli Zaretskii 2016-01-04 0:42 ` Stefan Monnier 2016-01-04 15:41 ` Eli Zaretskii 2016-01-05 4:12 ` Stefan Monnier 2016-01-05 4:28 ` Andrew Hyatt 2016-01-05 16:54 ` Eli Zaretskii 2016-01-05 16:52 ` Eli Zaretskii 2016-01-05 17:12 ` Stefan Monnier 2016-01-05 17:27 ` Eli Zaretskii 2016-01-05 20:00 ` John Wiegley 2016-01-07 4:17 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.