Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

[Stefan Monnier]

> +(defun compilation-beginning-of-line (&optional n)
> +  "Like `beginning-of-line', but accounts for lines hidden by `selective-display'."
> +  (if (or (not (eq selective-display t))
> +          (null n)
> +          (= n 1))
> +      (beginning-of-line n)
> +    (re-search-forward "[\n\r]" nil 'end (1- n))
> +    (if (< n 0)
> +        (beginning-of-line))))

All this extra cruft to support an obsolete feature we should eliminate
is the reason why I didn't fix it earlier.
There are reams of other places where selective-display can cause errors
and where similar "simple" fixes could be added.

The problem is/was not in compile.el but in selective-display (which
should just die its deserved death).


        Stefan

Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 03 Jan 2016 11:02:17 -0500
> 
> > +(defun compilation-beginning-of-line (&optional n)
> > +  "Like `beginning-of-line', but accounts for lines hidden by `selective-display'."
> > +  (if (or (not (eq selective-display t))
> > +          (null n)
> > +          (= n 1))
> > +      (beginning-of-line n)
> > +    (re-search-forward "[\n\r]" nil 'end (1- n))
> > +    (if (< n 0)
> > +        (beginning-of-line))))
> 
> All this extra cruft to support an obsolete feature we should eliminate
> is the reason why I didn't fix it earlier.

I'm sorry, but I'm firmly opposed to such a "strategy" of removing
features you don't like by leaving the related bugs unsolved.  In the
reality of Emacs maintenance, where all of us are busy people with
lots of other stuff on our plates, the result will always be that the
feature stays in, and bugs stay unsolved, for years.  This bug is an
excellent example.

> There are reams of other places where selective-display can cause errors
> and where similar "simple" fixes could be added.
> 
> The problem is/was not in compile.el but in selective-display (which
> should just die its deserved death).

If you really want to remove selective-display, please submit patches
that remove it entirely, replacing it with alternative features.  Or
talk someone else into doing that.  Then we can discuss if the
replacements are good enough, and if they are, then bye-bye
selective-display.

But as long as the feature stays, it's wrong to refrain from solving
such simple problems, hoping that the issue will go away by itself
somehow.

Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

[John Wiegley]

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

> If you really want to remove selective-display, please submit patches that
> remove it entirely, replacing it with alternative features. Or talk someone
> else into doing that. Then we can discuss if the replacements are good
> enough, and if they are, then bye-bye selective-display.
> 
> But as long as the feature stays, it's wrong to refrain from solving such
> simple problems, hoping that the issue will go away by itself somehow.

+1

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

Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

[Stefan Monnier]

>> The problem is/was not in compile.el but in selective-display (which
>> should just die its deserved death).
> If you really want to remove selective-display, please submit patches
> that remove it entirely, replacing it with alternative features.  Or
> talk someone else into doing that.  Then we can discuss if the
> replacements are good enough, and if they are, then bye-bye
> selective-display.

> But as long as the feature stays, it's wrong to refrain from solving
> such simple problems, hoping that the issue will go away by itself
> somehow.

That's not the way we've usually done it in Emacs.

The way we normally do it goes something like this:
- develop some replacement (in this case overlays).
- change (and encourage such a change in external packages) Elisp code
  to use the new feature instead of the old one.
- declare the feature obsolete.
- at this point, any old bugs don't need to be fixed any more, the
  feature is in "survival mode" where we only care to keep it usable.
  At this point, bugs are just one more encouragement for external
  packages to switch to the new feature.
- when we consider that the old feature is not used any more, we finally
  remove it.

I think we're probably pretty close to this last step, but I won't
insist on taking this step now.  OTOH I clearly think that fixing
long-standing bugs with this old and obsolete feature is a bad idea.


        Stefan

Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Sun, 03 Jan 2016 20:00:02 -0500
> 
> > But as long as the feature stays, it's wrong to refrain from solving
> > such simple problems, hoping that the issue will go away by itself
> > somehow.
> 
> That's not the way we've usually done it in Emacs.
> 
> The way we normally do it goes something like this:
> - develop some replacement (in this case overlays).
> - change (and encourage such a change in external packages) Elisp code
>   to use the new feature instead of the old one.
> - declare the feature obsolete.
> - at this point, any old bugs don't need to be fixed any more, the
>   feature is in "survival mode" where we only care to keep it usable.
>   At this point, bugs are just one more encouragement for external
>   packages to switch to the new feature.
> - when we consider that the old feature is not used any more, we finally
>   remove it.
> 
> I think we're probably pretty close to this last step, but I won't
> insist on taking this step now.

We are not close to the last step.  We are somewhere between the 1st
and the 2nd steps.  To get to the last step, we need to implement
user-level replacements for selective-display (both flavors).

> OTOH I clearly think that fixing long-standing bugs with this old
> and obsolete feature is a bad idea.

Yes, we disagree about that.  I think leaving bugs unsolved for so
long makes us look bad.  When all it takes is a few lines of simple
code, there's really no excuse for that, IMO.

Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

[Stefan Monnier]

> We are not close to the last step.  We are somewhere between the 1st
> and the 2nd steps.  To get to the last step, we need to implement
> user-level replacements for selective-display (both flavors).

I don't really care about obsoleting the non-t part of
selective-display.  I thought we had already declared
selective-display=t as obsolete, but I was apparently deluded
about that.

So I guess at this point I'm just lobbying to declare
selective-display=t as obsolete.


        Stefan

Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Mon, 04 Jan 2016 23:18:01 -0500
> 
> I don't really care about obsoleting the non-t part of
> selective-display.  I thought we had already declared
> selective-display=t as obsolete, but I was apparently deluded
> about that.

You weren't dreaming: the ELisp manual tells this.

> So I guess at this point I'm just lobbying to declare
> selective-display=t as obsolete.

We already did, so your wish has been granted.

Re: [Emacs-diffs] emacs-25 1f680db: Fix compilation next-error in buffers with selective-display

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But as long as the feature stays, it's wrong to refrain from solving
  > such simple problems, hoping that the issue will go away by itself
  > somehow.

I agree.

Both of the features I attached to selective-display
were similar to features that people found useful in another editor.
The feature of hiding indented lines makes it possible to see the
overall structure of a program.

The other feature, where changing NL to ^M makes the following line
invisible, might be replaced with overlays now.  Someone could give
that a try and see how well it works.  Overlays might be much slower
in a large buffer when most of the lines are hidden.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.