GNU bug report logs - #1452
23.0.60; Problem with nextstep, longlines-mode,

Previous Next

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

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

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

From: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; Problem with nextstep, longlines-mode,
Date: Sat, 29 Nov 2008 14:53:47 +0100 (CET)

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

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

From: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
To: 1452 <at> debbugs.gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60; Problem with nextstep,
 longlines-mode,)
Date: Sat, 29 Nov 2008 15:52:22 +0100 (CET)

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

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

From: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
To: 1452 <at> debbugs.gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60; Problem with nextstep,
 longlines-mode,)
Date: Sat, 29 Nov 2008 16:11:26 +0100 (CET)

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

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
Cc: 1452 <at> debbugs.gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Mon, 04 Jan 2016 23:10:55 -0500

Harald Hanche-Olsen <hanche <at> 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.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, Harald Hanche-Olsen <hanche <at> math.ntnu.no>
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Tue, 05 Jan 2016 12:32:24 -0500

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

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 1452 <at> debbugs.gnu.org, Harald Hanche-Olsen <hanche <at> math.ntnu.no>
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Tue, 05 Jan 2016 17:39:48 +0000

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

On Tue, Jan 5, 2016 at 12:32 PM Glenn Morris <rgm <at> 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.

[Message part 2 (text/html, inline)]

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

From: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
To: Andrew Hyatt <ahyatt <at> gmail.com>, Glenn Morris <rgm <at> gnu.org>
Cc: "1452 <at> debbugs.gnu.org" <1452 <at> debbugs.gnu.org>
Subject: Re: bug#1452: Acknowledgement (23.0.60; Problem with nextstep,
 longlines-mode,)
Date: Tue, 5 Jan 2016 17:53:23 +0000

-----Original Message-----
From: Andrew Hyatt <ahyatt <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 1452 <at> debbugs.gnu.org, ahyatt <at> gmail.com, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Tue, 05 Jan 2016 20:29:27 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Tue, 05 Jan 2016 12:32:24 -0500
> Cc: Harald Hanche-Olsen <hanche <at> math.ntnu.no>, 1452 <at> 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...

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, rgm <at> gnu.org, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Tue, 05 Jan 2016 20:38:21 +0200

> From: Andrew Hyatt <ahyatt <at> gmail.com>
> Date: Tue, 05 Jan 2016 17:39:48 +0000
> Cc: Harald Hanche-Olsen <hanche <at> math.ntnu.no>, 1452 <at> 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.

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1452 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>, ahyatt <at> gmail.com,
 hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Tue, 05 Jan 2016 12:38:08 -0800

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, rgm <at> gnu.org, ahyatt <at> gmail.com, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Tue, 05 Jan 2016 22:46:11 +0200

> From: John Wiegley <jwiegley <at> gmail.com>
> Cc: Glenn Morris <rgm <at> gnu.org>,  hanche <at> math.ntnu.no,  ahyatt <at> gmail.com,  1452 <at> debbugs.gnu.org
> Date: Tue, 05 Jan 2016 12:38:08 -0800
> 
> >>>>> Eli Zaretskii <eliz <at> 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.

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: John Wiegley <jwiegley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 1452 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Tue, 05 Jan 2016 21:12:19 +0000

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

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

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

[Message part 2 (text/html, inline)]

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

From: Harald Hanche-Olsen <hanche <at> math.ntnu.no>
To: John Wiegley <jwiegley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "rgm <at> gnu.org" <rgm <at> gnu.org>, "ahyatt <at> gmail.com" <ahyatt <at> gmail.com>,
 "1452 <at> debbugs.gnu.org" <1452 <at> debbugs.gnu.org>
Subject: Re: bug#1452: Acknowledgement (23.0.60; Problem with nextstep,
 longlines-mode,)
Date: Tue, 5 Jan 2016 21:15:48 +0000

-----Original Message-----
From: Eli Zaretskii <eliz <at> 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

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Tue, 05 Jan 2016 13:34:35 -0800

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

>>>>> Andrew Hyatt <ahyatt <at> 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

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

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: John Wiegley <jwiegley <at> gmail.com>, Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60; Problem with nextstep,
 longlines-mode,)
Date: Tue, 5 Jan 2016 23:50:25 +0200

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.

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, John Wiegley <jwiegley <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Wed, 06 Jan 2016 01:47:41 +0000

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

On Tue, Jan 5, 2016 at 4:50 PM Dmitry Gutov <dgutov <at> 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.

[Message part 2 (text/html, inline)]

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Andrew Hyatt <ahyatt <at> gmail.com>, John Wiegley <jwiegley <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60; Problem with nextstep,
 longlines-mode,)
Date: Wed, 6 Jan 2016 03:53:29 +0200

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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, jwiegley <at> gmail.com, hanche <at> math.ntnu.no, rgm <at> gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Wed, 06 Jan 2016 05:45:52 +0200

> From: Andrew Hyatt <ahyatt <at> gmail.com>
> Date: Tue, 05 Jan 2016 21:12:19 +0000
> Cc: Glenn Morris <rgm <at> gnu.org>, hanche <at> math.ntnu.no, 1452 <at> 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.)

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

From: Xue Fuqiao <xfq.free <at> gmail.com>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, John Wiegley <jwiegley <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, hanche <at> math.ntnu.no
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Wed, 6 Jan 2016 16:28:45 +0800

On Wed, Jan 6, 2016 at 5:12 AM, Andrew Hyatt <ahyatt <at> 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

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

From: Glenn Morris <rgm <at> gnu.org>
To: 1452 <at> debbugs.gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Wed, 06 Jan 2016 13:16:49 -0500

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

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1452 <at> debbugs.gnu.org, jwiegley <at> gmail.com, hanche <at> math.ntnu.no, rgm <at> gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Thu, 07 Jan 2016 01:42:58 +0000

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

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

> > From: Andrew Hyatt <ahyatt <at> gmail.com>
> > Date: Tue, 05 Jan 2016 21:12:19 +0000
> > Cc: Glenn Morris <rgm <at> gnu.org>, hanche <at> math.ntnu.no,
> 1452 <at> 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.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, jwiegley <at> gmail.com, hanche <at> math.ntnu.no, rgm <at> gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Thu, 07 Jan 2016 05:42:29 +0200

> From: Andrew Hyatt <ahyatt <at> gmail.com>
> Date: Thu, 07 Jan 2016 01:42:58 +0000
> Cc: jwiegley <at> gmail.com, rgm <at> gnu.org, hanche <at> math.ntnu.no, 1452 <at> 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/.

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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1452 <at> debbugs.gnu.org, jwiegley <at> gmail.com, hanche <at> math.ntnu.no, rgm <at> gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Wed, 06 Jan 2016 22:54:30 -0500

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

>> From: Andrew Hyatt <ahyatt <at> gmail.com>
>> Date: Thu, 07 Jan 2016 01:42:58 +0000
>> Cc: jwiegley <at> gmail.com, rgm <at> gnu.org, hanche <at> math.ntnu.no, 1452 <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrew Hyatt <ahyatt <at> gmail.com>
Cc: 1452 <at> debbugs.gnu.org, jwiegley <at> gmail.com, hanche <at> math.ntnu.no, rgm <at> gnu.org
Subject: Re: bug#1452: Acknowledgement (23.0.60;
 Problem with nextstep, longlines-mode,)
Date: Thu, 07 Jan 2016 18:02:34 +0200

> From: Andrew Hyatt <ahyatt <at> gmail.com>
> Cc: jwiegley <at> gmail.com,  rgm <at> gnu.org,  hanche <at> math.ntnu.no,  1452 <at> 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.

Previous Next

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