* bug#1452: 23.0.60; Problem with nextstep, longlines-mode,
@ 2008-11-29 13:53 Harald Hanche-Olsen
[not found] ` <handler.1452.B.122796683914175.ack@emacsbugs.donarmstrong.com>
0 siblings, 1 reply; 24+ messages in thread
From: Harald Hanche-Olsen @ 2008-11-29 13:53 UTC (permalink / raw)
To: emacs-pretest-bug
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
^ permalink raw reply [flat|nested] 24+ messages in thread[parent not found: <handler.1452.B.122796683914175.ack@emacsbugs.donarmstrong.com>]
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) [not found] ` <handler.1452.B.122796683914175.ack@emacsbugs.donarmstrong.com> @ 2008-11-29 14:52 ` Harald Hanche-Olsen 2008-11-29 15:11 ` Harald Hanche-Olsen 0 siblings, 1 reply; 24+ messages in thread From: Harald Hanche-Olsen @ 2008-11-29 14:52 UTC (permalink / raw) To: 1452 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2008-11-29 14:52 ` bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) Harald Hanche-Olsen @ 2008-11-29 15:11 ` Harald Hanche-Olsen 2016-01-05 4:10 ` Andrew Hyatt 0 siblings, 1 reply; 24+ messages in thread From: Harald Hanche-Olsen @ 2008-11-29 15:11 UTC (permalink / raw) To: 1452 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2008-11-29 15:11 ` Harald Hanche-Olsen @ 2016-01-05 4:10 ` Andrew Hyatt 2016-01-05 17:32 ` Glenn Morris 0 siblings, 1 reply; 24+ messages in thread From: Andrew Hyatt @ 2016-01-05 4:10 UTC (permalink / raw) To: Harald Hanche-Olsen; +Cc: 1452 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 4:10 ` Andrew Hyatt @ 2016-01-05 17:32 ` Glenn Morris 2016-01-05 17:39 ` Andrew Hyatt 2016-01-05 18:29 ` Eli Zaretskii 0 siblings, 2 replies; 24+ messages in thread From: Glenn Morris @ 2016-01-05 17:32 UTC (permalink / raw) To: Andrew Hyatt; +Cc: Harald Hanche-Olsen, 1452 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 17:32 ` Glenn Morris @ 2016-01-05 17:39 ` Andrew Hyatt 2016-01-05 17:53 ` Harald Hanche-Olsen 2016-01-05 18:38 ` Eli Zaretskii 2016-01-05 18:29 ` Eli Zaretskii 1 sibling, 2 replies; 24+ messages in thread From: Andrew Hyatt @ 2016-01-05 17:39 UTC (permalink / raw) To: Glenn Morris; +Cc: Harald Hanche-Olsen, 1452 [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 17:39 ` Andrew Hyatt @ 2016-01-05 17:53 ` Harald Hanche-Olsen 2016-01-05 18:38 ` Eli Zaretskii 1 sibling, 0 replies; 24+ messages in thread From: Harald Hanche-Olsen @ 2016-01-05 17:53 UTC (permalink / raw) To: Andrew Hyatt, Glenn Morris; +Cc: 1452@debbugs.gnu.org -----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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 17:39 ` Andrew Hyatt 2016-01-05 17:53 ` Harald Hanche-Olsen @ 2016-01-05 18:38 ` Eli Zaretskii 1 sibling, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2016-01-05 18:38 UTC (permalink / raw) To: Andrew Hyatt; +Cc: hanche, 1452 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 17:32 ` Glenn Morris 2016-01-05 17:39 ` Andrew Hyatt @ 2016-01-05 18:29 ` Eli Zaretskii 2016-01-05 20:38 ` John Wiegley 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-05 18:29 UTC (permalink / raw) To: Glenn Morris; +Cc: hanche, ahyatt, 1452 > 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... ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 18:29 ` Eli Zaretskii @ 2016-01-05 20:38 ` John Wiegley 2016-01-05 20:46 ` Eli Zaretskii 2016-01-05 21:12 ` Andrew Hyatt 0 siblings, 2 replies; 24+ messages in thread From: John Wiegley @ 2016-01-05 20:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: hanche, ahyatt, 1452 >>>>> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 20:38 ` John Wiegley @ 2016-01-05 20:46 ` Eli Zaretskii 2016-01-05 21:15 ` Harald Hanche-Olsen 2016-01-05 21:12 ` Andrew Hyatt 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-05 20:46 UTC (permalink / raw) To: John Wiegley; +Cc: hanche, ahyatt, 1452 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 20:46 ` Eli Zaretskii @ 2016-01-05 21:15 ` Harald Hanche-Olsen 0 siblings, 0 replies; 24+ messages in thread From: Harald Hanche-Olsen @ 2016-01-05 21:15 UTC (permalink / raw) To: John Wiegley, Eli Zaretskii; +Cc: ahyatt@gmail.com, 1452@debbugs.gnu.org -----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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 20:38 ` John Wiegley 2016-01-05 20:46 ` Eli Zaretskii @ 2016-01-05 21:12 ` Andrew Hyatt 2016-01-05 21:34 ` John Wiegley ` (2 more replies) 1 sibling, 3 replies; 24+ messages in thread From: Andrew Hyatt @ 2016-01-05 21:12 UTC (permalink / raw) To: John Wiegley, Eli Zaretskii; +Cc: hanche, 1452 [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 21:12 ` Andrew Hyatt @ 2016-01-05 21:34 ` John Wiegley 2016-01-05 21:50 ` Dmitry Gutov 2016-01-06 3:45 ` Eli Zaretskii 2016-01-06 8:28 ` Xue Fuqiao 2 siblings, 1 reply; 24+ messages in thread From: John Wiegley @ 2016-01-05 21:34 UTC (permalink / raw) To: Andrew Hyatt; +Cc: hanche, 1452 [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 21:34 ` John Wiegley @ 2016-01-05 21:50 ` Dmitry Gutov 2016-01-06 1:47 ` Andrew Hyatt 0 siblings, 1 reply; 24+ messages in thread From: Dmitry Gutov @ 2016-01-05 21:50 UTC (permalink / raw) To: John Wiegley, Andrew Hyatt; +Cc: hanche, 1452 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 21:50 ` Dmitry Gutov @ 2016-01-06 1:47 ` Andrew Hyatt 2016-01-06 1:53 ` Dmitry Gutov 0 siblings, 1 reply; 24+ messages in thread From: Andrew Hyatt @ 2016-01-06 1:47 UTC (permalink / raw) To: Dmitry Gutov, John Wiegley; +Cc: hanche, 1452 [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-06 1:47 ` Andrew Hyatt @ 2016-01-06 1:53 ` Dmitry Gutov 0 siblings, 0 replies; 24+ messages in thread From: Dmitry Gutov @ 2016-01-06 1:53 UTC (permalink / raw) To: Andrew Hyatt, John Wiegley; +Cc: hanche, 1452 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 21:12 ` Andrew Hyatt 2016-01-05 21:34 ` John Wiegley @ 2016-01-06 3:45 ` Eli Zaretskii 2016-01-07 1:42 ` Andrew Hyatt 2016-01-06 8:28 ` Xue Fuqiao 2 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-06 3:45 UTC (permalink / raw) To: Andrew Hyatt; +Cc: hanche, jwiegley, 1452 > 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.) ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-06 3:45 ` Eli Zaretskii @ 2016-01-07 1:42 ` Andrew Hyatt 2016-01-07 3:42 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Andrew Hyatt @ 2016-01-07 1:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: hanche, jwiegley, 1452 [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-07 1:42 ` Andrew Hyatt @ 2016-01-07 3:42 ` Eli Zaretskii 2016-01-07 3:54 ` Andrew Hyatt 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-01-07 3:42 UTC (permalink / raw) To: Andrew Hyatt; +Cc: hanche, jwiegley, 1452 > 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/. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-07 3:42 ` Eli Zaretskii @ 2016-01-07 3:54 ` Andrew Hyatt 2016-01-07 16:02 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Andrew Hyatt @ 2016-01-07 3:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: hanche, jwiegley, 1452 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-07 3:54 ` Andrew Hyatt @ 2016-01-07 16:02 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2016-01-07 16:02 UTC (permalink / raw) To: Andrew Hyatt; +Cc: hanche, jwiegley, 1452 > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-05 21:12 ` Andrew Hyatt 2016-01-05 21:34 ` John Wiegley 2016-01-06 3:45 ` Eli Zaretskii @ 2016-01-06 8:28 ` Xue Fuqiao 2016-01-06 18:16 ` Glenn Morris 2 siblings, 1 reply; 24+ messages in thread From: Xue Fuqiao @ 2016-01-06 8:28 UTC (permalink / raw) To: Andrew Hyatt; +Cc: hanche, John Wiegley, 1452 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) 2016-01-06 8:28 ` Xue Fuqiao @ 2016-01-06 18:16 ` Glenn Morris 0 siblings, 0 replies; 24+ messages in thread From: Glenn Morris @ 2016-01-06 18:16 UTC (permalink / raw) To: 1452 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.) ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-01-07 16:02 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-29 13:53 bug#1452: 23.0.60; Problem with nextstep, longlines-mode, Harald Hanche-Olsen
[not found] ` <handler.1452.B.122796683914175.ack@emacsbugs.donarmstrong.com>
2008-11-29 14:52 ` bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) Harald Hanche-Olsen
2008-11-29 15:11 ` Harald Hanche-Olsen
2016-01-05 4:10 ` Andrew Hyatt
2016-01-05 17:32 ` Glenn Morris
2016-01-05 17:39 ` Andrew Hyatt
2016-01-05 17:53 ` Harald Hanche-Olsen
2016-01-05 18:38 ` Eli Zaretskii
2016-01-05 18:29 ` Eli Zaretskii
2016-01-05 20:38 ` John Wiegley
2016-01-05 20:46 ` Eli Zaretskii
2016-01-05 21:15 ` Harald Hanche-Olsen
2016-01-05 21:12 ` Andrew Hyatt
2016-01-05 21:34 ` John Wiegley
2016-01-05 21:50 ` Dmitry Gutov
2016-01-06 1:47 ` Andrew Hyatt
2016-01-06 1:53 ` Dmitry Gutov
2016-01-06 3:45 ` Eli Zaretskii
2016-01-07 1:42 ` Andrew Hyatt
2016-01-07 3:42 ` Eli Zaretskii
2016-01-07 3:54 ` Andrew Hyatt
2016-01-07 16:02 ` Eli Zaretskii
2016-01-06 8:28 ` Xue Fuqiao
2016-01-06 18:16 ` Glenn Morris
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).