bug#1452: 23.0.60; Problem with nextstep, longlines-mode,

bug#1452: 23.0.60; Problem with nextstep, longlines-mode,

[Harald Hanche-Olsen]

The following happens on mac os x, nextstep build.
It does NOT happen on freebsd, x11 build.
(Those are the only two places I have tried.)

M-x set-variable RET longlines-show-hard-newlines RET t
C-x b asdf RET
M-x longlines-mode RET
Type some text in the buffer, followed by RET
Type some more text. Bug symptom #1: Nothing happens.
M-x longlines-mode RET. Bug symptom #2:
  The longlines-show-effect string is not cleaned out right, leaving
  the buffer contents looking as follows:

----
asdf
adsf----

I expect this bug is not at all specific to longlines-mode, but that
it is a text property related bug in the nextstep implementation.

- Harald

----------------
In GNU Emacs 23.0.60.2 (powerpc-apple-darwin9.5.0, NS 
apple-appkit-949.35)
 of 2008-11-29 on macknife
Windowing system distributor `Apple', version 
97.112.112.108.101.45.97.112.112.107.105.116.45.57.52.57.46.51.53
configured using `configure  '--with-ns' '--without-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  longlines-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  use-hard-newlines: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Harald Hanche-Olsen]

It appears that I wrote

  Bug symptom #2:
   The longlines-show-effect string is not cleaned out right, leaving
   the buffer contents looking as follows:

  ----
  asdf
  adsf----

But that is misleading as it turns out; I got fooled by text
properties hiding some text. In that buffer, after enabling
longlines-mode, I had typed "asdf" RET "asdf" (without the quotes) and
then saw this in the buffer:

asdf¶

with the cursor on the second line. Then, after I turned off
longlines-mode, that changed into

asdf
¶

But if I now copy the buffer (C-x h M-w) and paste the result in a
terminal window, I get

asdf
asdf

without a final newline.

- Harald

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Harald Hanche-Olsen]

Apologies for the noise, but I'v been reading in the elisp manual how
to get the buffer contents. So here we go again: I create a new
buffer, enable longlines-mode with longlines-show-hard-newlines turned
on, and type:  asdf RET asdf

Now (buffer-string) returns

#("asdf
asdf" 4 5 (hard t rear-nonsticky (hard) display #("¶
" 0 2 (face escape-glyph))) 5 9 (display #("¶
" 0 2 (face escape-glyph))))

Disabling longlines-mode and running (buffer-string) again, I now get

#("asdf
asdf" 4 5 (hard t rear-nonsticky (hard)) 5 9 (display #("¶
" 0 2 (face escape-glyph))))

I have already described the visual appearance of the buffer in the
two circumstances.

- Harald

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Andrew Hyatt]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> Apologies for the noise, but I'v been reading in the elisp manual how
> to get the buffer contents. So here we go again: I create a new
> buffer, enable longlines-mode with longlines-show-hard-newlines turned
> on, and type:  asdf RET asdf
>
> Now (buffer-string) returns
>
> #("asdf
> asdf" 4 5 (hard t rear-nonsticky (hard) display #("¶
> " 0 2 (face escape-glyph))) 5 9 (display #("¶
> " 0 2 (face escape-glyph))))
>
> Disabling longlines-mode and running (buffer-string) again, I now get
>
> #("asdf
> asdf" 4 5 (hard t rear-nonsticky (hard)) 5 9 (display #("¶
> " 0 2 (face escape-glyph))))
>
> I have already described the visual appearance of the buffer in the
> two circumstances.
>
> - Harald

Sorry this bug has been open for so long, in fact it has the rare
privelage of being open for so long the package you are having a problem
with (longlines-mode), no longer is part of emacs.

It has been replaced with visual-line-mode.

I'll close this bug.

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Glenn Morris]

Andrew Hyatt wrote:

> Sorry this bug has been open for so long, in fact it has the rare
> privelage of being open for so long the package you are having a problem
> with (longlines-mode), no longer is part of emacs.

It's in lisp/obsolete/.
Eli thinks such things should still be fixed:

http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-01/msg00171.html

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Andrew Hyatt]

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

On Tue, Jan 5, 2016 at 12:32 PM Glenn Morris <rgm@gnu.org> wrote:

> Andrew Hyatt wrote:
>
> > Sorry this bug has been open for so long, in fact it has the rare
> > privelage of being open for so long the package you are having a problem
> > with (longlines-mode), no longer is part of emacs.
>
> It's in lisp/obsolete/.
> Eli thinks such things should still be fixed:
>
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-01/msg00171.html


Is that a widespread opinion?  I disagree, FWIW.  One of the big purposes
of obsoleting things is to reduce the number of things that must be
maintained.

[-- Attachment #2: Type: text/html, Size: 1015 bytes --]

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Harald Hanche-Olsen]

-----Original Message-----
From: Andrew Hyatt <ahyatt@gmail.com>
Date: 5 January 2016 at 18:40:02

> On Tue, Jan 5, 2016 at 12:32 PM Glenn Morris wrote:
> >
> > It's in lisp/obsolete/.
> > Eli thinks such things should still be fixed:
>  
> Is that a widespread opinion? I disagree, FWIW. One of the big purposes
> of obsoleting things is to reduce the number of things that must be
> maintained.

There isn’t necessarily a contradiction between the two viewpoints. Obsoleting a feature implies it will disappear in the future, at which point maintenance will certainly stop. The question is more about how soon maintenance should stop.

– Harald

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 05 Jan 2016 12:32:24 -0500
> Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>, 1452@debbugs.gnu.org
> 
> Andrew Hyatt wrote:
> 
> > Sorry this bug has been open for so long, in fact it has the rare
> > privelage of being open for so long the package you are having a problem
> > with (longlines-mode), no longer is part of emacs.
> 
> It's in lisp/obsolete/.
> Eli thinks such things should still be fixed:

Unless the fix is complicated or risky or...

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Eli Zaretskii]

> From: Andrew Hyatt <ahyatt@gmail.com>
> Date: Tue, 05 Jan 2016 17:39:48 +0000
> Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>, 1452@debbugs.gnu.org
> 
>     Eli thinks such things should still be fixed:
>     
>     http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-01/msg00171.html
> 
> Is that a widespread opinion? I disagree, FWIW. One of the big purposes of
> obsoleting things is to reduce the number of things that must be maintained. 

You don't have to handle bugs you think shouldn't be handled.  Just
leave them in their current state, and someone else will handle them.

Thanks.

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[John Wiegley]

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

>> It's in lisp/obsolete/.
>> Eli thinks such things should still be fixed:

> Unless the fix is complicated or risky or...

If people want to fix bugs in lisp/obselete, they are free to do so because
(a) the bug is open and (b) the code still exists in the distribution. Once
the code is gone, we can close the bug as no longer pertaining to Emacs.

Until that time, don't feel an obligation to fix bugs in obsolete code that
you aren't interested in fixing. There are higher priorities to address.

What this discussion objected to (as I read it) was establishing a policy of
ignoring bugs in obsolete code.

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

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Glenn Morris <rgm@gnu.org>,  hanche@math.ntnu.no,  ahyatt@gmail.com,  1452@debbugs.gnu.org
> Date: Tue, 05 Jan 2016 12:38:08 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It's in lisp/obsolete/.
> >> Eli thinks such things should still be fixed:
> 
> > Unless the fix is complicated or risky or...
> 
> If people want to fix bugs in lisp/obselete, they are free to do so because
> (a) the bug is open and (b) the code still exists in the distribution. Once
> the code is gone, we can close the bug as no longer pertaining to Emacs.

FWIW, I cannot reproduce this bug on my system.  Note that the OP
explicitly said that he only see this in the NS build, not on X.  So I
think this is indeed an NS specific bug related to display.  Only
someone who has access to NS can debug it.

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Andrew Hyatt]

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

On Tue, Jan 5, 2016 at 3:38 PM John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> It's in lisp/obsolete/.
> >> Eli thinks such things should still be fixed:
>
> > Unless the fix is complicated or risky or...
>
> If people want to fix bugs in lisp/obselete, they are free to do so because
> (a) the bug is open and (b) the code still exists in the distribution. Once
> the code is gone, we can close the bug as no longer pertaining to Emacs.
>

Has anyone considered putting these obsolete packages in the gnu ELPA?  I'm
not sure about the bug policy, but I'd guess that bugs shouldn't be filed
against ELPA packages.


>
> Until that time, don't feel an obligation to fix bugs in obsolete code that
> you aren't interested in fixing. There are higher priorities to address.
>

Perhaps we can lower the priority of these kinds of bug in that case to the
minimum, so it doesn't show up in the default list for debbugs?


>
> What this discussion objected to (as I read it) was establishing a policy
> of
> ignoring bugs in obsolete code.
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>

[-- Attachment #2: Type: text/html, Size: 2041 bytes --]

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Harald Hanche-Olsen]

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org>
Date: 5 January 2016 at 21:46:40

> FWIW, I cannot reproduce this bug on my system. Note that the OP
> explicitly said that he only see this in the NS build, not on X. So I
> think this is indeed an NS specific bug related to display. Only
> someone who has access to NS can debug it.

The OP stopped using longlines-mode an eternity ago. 8-)
But when I try out my recipe in a recent nextstep build, I can’t reproduce it either.
At least not the visual aspect; after I disable longlines-mode, the newlines are still “decorated” with the properties (hard t read-nonsticky (hard)). But that has no consequences visually, as far as I can tell.

So I guess it’s okay to close the bug, with a slightly different rationale than the one given.

– Harald

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[John Wiegley]

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

>>>>> Andrew Hyatt <ahyatt@gmail.com> writes:

>     If people want to fix bugs in lisp/obselete, they are free to do so
>     because (a) the bug is open and (b) the code still exists in the
>     distribution. Once the code is gone, we can close the bug as no longer
>     pertaining to Emacs.

> Has anyone considered putting these obsolete packages in the gnu ELPA? I'm
> not sure about the bug policy, but I'd guess that bugs shouldn't be filed
> against ELPA packages.

Interesting. I'd be for such a move.

>     Until that time, don't feel an obligation to fix bugs in obsolete code
>     that you aren't interested in fixing. There are higher priorities to
>     address.

> Perhaps we can lower the priority of these kinds of bug in that case to the
> minimum, so it doesn't show up in the default list for debbugs?

Feel free.

-- 
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#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Dmitry Gutov]

On 01/05/2016 11:34 PM, John Wiegley wrote:

>> Has anyone considered putting these obsolete packages in the gnu ELPA? I'm
>> not sure about the bug policy, but I'd guess that bugs shouldn't be filed
>> against ELPA packages.
>
> Interesting. I'd be for such a move.

That usually happens when there appears a person interested in 
maintaining an obsolete package in question, in ELPA.

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Andrew Hyatt]

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

On Tue, Jan 5, 2016 at 4:50 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 01/05/2016 11:34 PM, John Wiegley wrote:
>
> >> Has anyone considered putting these obsolete packages in the gnu ELPA?
> I'm
> >> not sure about the bug policy, but I'd guess that bugs shouldn't be
> filed
> >> against ELPA packages.
> >
> > Interesting. I'd be for such a move.
>
> That usually happens when there appears a person interested in
> maintaining an obsolete package in question, in ELPA.
>

But what would it mean to maintain an obsolete package?  My guess is that
this just means putting it in ELPA, considering all bugs closed, and being
willing to accept patches to fix any issues that anyone is interested in
fixing.

[-- Attachment #2: Type: text/html, Size: 1042 bytes --]

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Dmitry Gutov]

On 01/06/2016 03:47 AM, Andrew Hyatt wrote:

> But what would it mean to maintain an obsolete package?  My guess is
> that this just means putting it in ELPA, considering all bugs closed,
> and being willing to accept patches to fix any issues that anyone is
> interested in fixing.

I believe it would mean putting it in ELPA, un-obsoleting, and 
eventually working towards fixing the known bugs, and well as any new ones.

It's okay if the new maintainer doesn't make fixing the older bugs the 
first priority, but closing them, if the package becomes maintained 
again, doesn't make sense to me.

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Eli Zaretskii]

> From: Andrew Hyatt <ahyatt@gmail.com>
> Date: Tue, 05 Jan 2016 21:12:19 +0000
> Cc: Glenn Morris <rgm@gnu.org>, hanche@math.ntnu.no, 1452@debbugs.gnu.org
> 
> Has anyone considered putting these obsolete packages in the gnu ELPA? I'm not
> sure about the bug policy, but I'd guess that bugs shouldn't be filed against
> ELPA packages.

AFAIK bugs are files against ELPA packages like they are against the
core Emacs.  So moving to ELPA will not change this aspect of obsolete
packages.

(It also feels wrong to move them to ELPA just because they are
obsolete.  ELPA is supposed to be home for new and advanced stuff, not
for obsolete stuff.  If someone steps forward wanting to maintain an
obsolete package, then a move to ELPA might make good sense, though.)

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Xue Fuqiao]

On Wed, Jan 6, 2016 at 5:12 AM, Andrew Hyatt <ahyatt@gmail.com> wrote:
>
> Has anyone considered putting these obsolete packages in the gnu ELPA?  I'm
> not sure about the bug policy, but I'd guess that bugs shouldn't be filed
> against ELPA packages.

Like landmark.el?

Ref:

* http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1a2773ac2d05c88f9c246ab9fbf0587921000d3a
* http://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=a5361bf4595b7c0136999e35b3ec32f7deb5aff9

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Glenn Morris]

Bug reports for GNU Elpa packages are accepted on bug-gnu-emacs, so
moving a package there does not mean its reports can simply be closed.

Things are moved to obsolete/ when they are believed to be no longer
useful; either because a more modern replacement exists (as in this
case), or because few to no people are believed to be using whatever it
is any more.

For me, bugs in obsolete things go to the bottom of the bug pile.
Since the bottom of the pile will never be reached, this means they are
wontfix for me.

Files in obsolete/ may be deleted from Emacs at some point in the future.

In a tiny number of cases, where someone thinks that something that
would in obsolete/ could still be useful, and is willing to maintain it,
it has been copied to GNU Elpa, where it will live on after it gets
removed from Emacs. (Personally I doubt whether such packages will ever
see any significant updates, or users.)

(This is all off-topic for this report; perhaps this discussion could
continue elsewhere, if there is still stuff to say.)

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Andrew Hyatt]

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

On Tue, Jan 5, 2016 at 10:46 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Andrew Hyatt <ahyatt@gmail.com>
> > Date: Tue, 05 Jan 2016 21:12:19 +0000
> > Cc: Glenn Morris <rgm@gnu.org>, hanche@math.ntnu.no,
> 1452@debbugs.gnu.org
> >
> > Has anyone considered putting these obsolete packages in the gnu ELPA?
> I'm not
> > sure about the bug policy, but I'd guess that bugs shouldn't be filed
> against
> > ELPA packages.
>
> AFAIK bugs are files against ELPA packages like they are against the
> core Emacs.  So moving to ELPA will not change this aspect of obsolete
> packages.
>

> (It also feels wrong to move them to ELPA just because they are
> obsolete.  ELPA is supposed to be home for new and advanced stuff, not
> for obsolete stuff.  If someone steps forward wanting to maintain an
> obsolete package, then a move to ELPA might make good sense, though.)
>

That's a fair point.  Maybe there could be some special ELPA repository for
obsolete packages.  But what I'm mostly trying to figure out is if there is
*any* way to get code to be completely unmaintained.  We are, after all,
trying to reduce the number of bugs (see the thread on 4k bugs) overall,
and this is one way to do that.  So the only way people would agree on
right now, is if we remove the code entirely from emacs distribution.  But
I suspect that such a change would be rejected, even from obsolete
packages, because someone might still be depending on them.

[-- Attachment #2: Type: text/html, Size: 2172 bytes --]

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Eli Zaretskii]

> From: Andrew Hyatt <ahyatt@gmail.com>
> Date: Thu, 07 Jan 2016 01:42:58 +0000
> Cc: jwiegley@gmail.com, rgm@gnu.org, hanche@math.ntnu.no, 1452@debbugs.gnu.org
> 
> what I'm mostly trying to figure out is if there is *any* way to get
> code to be completely unmaintained.

I think removing it is the only way.

> We are, after all, trying to reduce the number of bugs (see the
> thread on 4k bugs) overall, and this is one way to do that. So the
> only way people would agree on right now, is if we remove the code
> entirely from emacs distribution. But I suspect that such a change
> would be rejected, even from obsolete packages, because someone
> might still be depending on them.

It depends on how long the package was obsolete, I guess.

We could define a policy, like a package is deleted after so-and-so
many months/years in obsolete/.

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Andrew Hyatt]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrew Hyatt <ahyatt@gmail.com>
>> Date: Thu, 07 Jan 2016 01:42:58 +0000
>> Cc: jwiegley@gmail.com, rgm@gnu.org, hanche@math.ntnu.no, 1452@debbugs.gnu.org
>> 
>> what I'm mostly trying to figure out is if there is *any* way to get
>> code to be completely unmaintained.
>
> I think removing it is the only way.

Yeah, I guess that's what I suspected.  It seems reasonable, as long as
we can remove things.

>
>> We are, after all, trying to reduce the number of bugs (see the
>> thread on 4k bugs) overall, and this is one way to do that. So the
>> only way people would agree on right now, is if we remove the code
>> entirely from emacs distribution. But I suspect that such a change
>> would be rejected, even from obsolete packages, because someone
>> might still be depending on them.
>
> It depends on how long the package was obsolete, I guess.
>
> We could define a policy, like a package is deleted after so-and-so
> many months/years in obsolete/.

If you think such a policy would be possible, then I'm happy to propose
it in emacs-devel.  Maybe obsolete packages can spend one major version
in obsolete, and get deleted in the next major version?  Or, maybe we
can be more aggressive, especially if you think that we can do this over
periods of months, and obsolete and deprecate based on minor version instead.

bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,)

[Eli Zaretskii]

> From: Andrew Hyatt <ahyatt@gmail.com>
> Cc: jwiegley@gmail.com,  rgm@gnu.org,  hanche@math.ntnu.no,  1452@debbugs.gnu.org
> Date: Wed, 06 Jan 2016 22:54:30 -0500
> 
> > We could define a policy, like a package is deleted after so-and-so
> > many months/years in obsolete/.
> 
> If you think such a policy would be possible, then I'm happy to propose
> it in emacs-devel.  Maybe obsolete packages can spend one major version
> in obsolete, and get deleted in the next major version?  Or, maybe we
> can be more aggressive, especially if you think that we can do this over
> periods of months, and obsolete and deprecate based on minor version instead.

Please do propose that.  (You will have to explain what does 'spend
one major version in obsolete" means, though: suppose a package was
declared obsolete in v24.5, when will it be removed?)

Thanks.