Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
No Direct Delete of Messages in Newsgroups
79 views
Skip to first unread message
Don
Feb 13, 2012, 5:33:17 PM2/13/12
to
Thunderbird 10.0.1, Win7 Professional, Both New as of 2-12-12
No delete option for Newsgroup messages.
Wife's Thunderbird 9.x doesn't have this affliction.
No problem with email.
What am I overlooking?
Don
No delete option for Newsgroup messages.
Wife's Thunderbird 9.x doesn't have this affliction.
No problem with email.
What am I overlooking?
Don
Beauregard T. Shagnasty
Feb 13, 2012, 5:50:46 PM2/13/12
to
exist on thousands of news servers around the planet. All you can do is
hide them from view. You could also try to cancel your own posts, but
many servers ignore a cancel message.
Your best solution is probably to "Hide Read Messages."
--
-bts
-This space for rent, but the price is high
WLS
Feb 13, 2012, 6:08:14 PM2/13/12
to
Where do I find that option?
I have the news.allow_delete_with_no_undo preference set to "true" in Config Editor. This allows me to delete (or hide from view) newsgroup messages from Thunderbird. Yes, they will be on the servers all over the world, and download again if I repair a folder.
Haven't deleted any in awhile because I want Thunderbird to grow, and grow, and grow, until I see how many emails, posts and RSS feeds it takes to crash.. May not happen in my lifetime, or I may get bored with the experiment. Only 1186 posts in m.s.thunderbird.
-- Thunderbird Beta | openSUSE 11.4 Linux Get openSUSE: http://software.opensuse.org/121/en Humans aren't a color of skin, a religion, a sex, a sexual orientation, or a flag. We are human beings and that is how we need to see and treat each other. - Justin Sane
Lynn McGuire
Feb 13, 2012, 7:16:14 PM2/13/12
to
in your thrunderbird:
http://ilias.ca/blog/2011/07/deleting-individual-newsgroup-messages-in-thunderbird/
Lynn
John H Meyers
Feb 13, 2012, 7:44:08 PM2/13/12
to
On 2/13/2012 4:50 PM
> ..the fact that you can't delete newsgroup posts. Once sent, they soon
> exist on thousands of news servers around the planet. All you can do is
> hide them from view. You could also try to cancel your own posts, but
> many servers ignore a cancel message.
>
> Your best solution is probably to "Hide Read Messages."
For someone who has been active for so many years in this newsgroup,
how can you remain so uninformed about the distinction between
Cancel (from servers) and Delete (from your own computer) after all this time?
TB bug 250141 was retired a fair number of versions ago;
that bug was about the fact that TB had, going all the way back
to when it was part of Netscape, tried to perform _both_
Cancel _and_ Delete (in that order) when _either_
Cancel _or_ Delete was requested by a user,
and this is the only thing that prevented Delete
from working as it should have.
This gross blunder was rationalized for years
by arguments of your sort, despite the fact that if your argument
had any merit, it would have had to apply equally
to other comparable clients, e.g. even to Outlook Express.
Yet even Outlook Express is perfectly able
to delete anything it has locally stored on disk,
without attempting to send any corresponding "cancel" to any server,
which suffices to prove the specious nature of any such argument
that had long been proffered as an excuse for TB's bug,
over the entire six years that it remained unfixed.
The way in which that bug was retired was lame, however,
in that "Delete" was left crippled by default from being invoked at all.
Where developers sensitive to the needs of a user interface might have
had a dialog box inform a user of the "no undo" consequence of a "Delete"
and ask permission to perform it,
and might even have added a "don't ask me again" optional check box,
this "bug fix" instead leaves the "Delete" function totally crippled
(and grayed out), with the only clue in existence about how to un-cripple it
being buried in the 42nd comment to the original bug report:
<https://bugzilla.mozilla.org/show_bug.cgi?id=250141#c42>
Since a benefit whose existence is kept secret is no benefit at all,
the "fix" to bug 250141 has benefited only the scant few people
who may have found their way here to ask and then got an answer
from someone who can still point the way to how to
free that "fix" from being bound and shackled.
Your nearest religious cleric can probably explain why so much in this world
that is possible remains so out of reach -- it's because "God's will"
is against it, not that human beings are just so thoughtless towards others.
--
> ..the fact that you can't delete newsgroup posts. Once sent, they soon
> exist on thousands of news servers around the planet. All you can do is
> hide them from view. You could also try to cancel your own posts, but
> many servers ignore a cancel message.
>
> Your best solution is probably to "Hide Read Messages."
how can you remain so uninformed about the distinction between
Cancel (from servers) and Delete (from your own computer) after all this time?
TB bug 250141 was retired a fair number of versions ago;
that bug was about the fact that TB had, going all the way back
to when it was part of Netscape, tried to perform _both_
Cancel _and_ Delete (in that order) when _either_
Cancel _or_ Delete was requested by a user,
and this is the only thing that prevented Delete
from working as it should have.
This gross blunder was rationalized for years
by arguments of your sort, despite the fact that if your argument
had any merit, it would have had to apply equally
to other comparable clients, e.g. even to Outlook Express.
Yet even Outlook Express is perfectly able
to delete anything it has locally stored on disk,
without attempting to send any corresponding "cancel" to any server,
which suffices to prove the specious nature of any such argument
that had long been proffered as an excuse for TB's bug,
over the entire six years that it remained unfixed.
The way in which that bug was retired was lame, however,
in that "Delete" was left crippled by default from being invoked at all.
Where developers sensitive to the needs of a user interface might have
had a dialog box inform a user of the "no undo" consequence of a "Delete"
and ask permission to perform it,
and might even have added a "don't ask me again" optional check box,
this "bug fix" instead leaves the "Delete" function totally crippled
(and grayed out), with the only clue in existence about how to un-cripple it
being buried in the 42nd comment to the original bug report:
<https://bugzilla.mozilla.org/show_bug.cgi?id=250141#c42>
Since a benefit whose existence is kept secret is no benefit at all,
the "fix" to bug 250141 has benefited only the scant few people
who may have found their way here to ask and then got an answer
from someone who can still point the way to how to
free that "fix" from being bound and shackled.
Your nearest religious cleric can probably explain why so much in this world
that is possible remains so out of reach -- it's because "God's will"
is against it, not that human beings are just so thoughtless towards others.
--
Mike Easter
Feb 13, 2012, 8:12:52 PM2/13/12
to
John H Meyers wrote:
> Yet even Outlook Express is perfectly able
> to delete anything it has locally stored on disk,
> without attempting to send any corresponding "cancel" to any server,
> which suffices to prove the specious nature of any such argument
> that had long been proffered as an excuse for TB's bug,
> over the entire six years that it remained unfixed.
The default OE handles news messages it has accessed differently than
> Yet even Outlook Express is perfectly able
> to delete anything it has locally stored on disk,
> without attempting to send any corresponding "cancel" to any server,
> which suffices to prove the specious nature of any such argument
> that had long been proffered as an excuse for TB's bug,
> over the entire six years that it remained unfixed.
the default Tb does.
OE stores the news message bodies and their headers locally in a
proprietary format, whereas Tb does not so store in any format except
its cache. So the message (per se, like a stored email body + header)
which the user wants to 'delete' (make disappear) isn't actually even
'there' in the same way that OE's news message is there. In the case of
Tb, the thread pane listed message is only acquired when the user wants
to access it by selecting it for display either in the message pane or
'opening' in a separate window, unless it happens to currently be in the
cache.
--
Mike Easter
Don
Feb 13, 2012, 9:19:40 PM2/13/12
to
for Newsgroup messages was a bit confusing. I will make the change in
the config editor.
Don
John H Meyers
Feb 13, 2012, 10:43:32 PM2/13/12
to
On 2/13/2012 7:12 PM, Mike Easter wrote:
JHM:
to the argument which a glance at Outlook Express proves to be specious.
You have a list of newsgroup posts in front of your face,
and you want to delete some from that list.
You can do that in Outlook Express, but not in Thunderbird.
The misguided argument would have applied just as well to Outlook Express,
as a (false) rationale that deleting articles from your list should not be possible,
while the fact that OE properly deletes them shows that the argument is specious.
For six years that was impossible only in Netscape and Thunderbird,
not because there is any logical reason why it should not be possible,
but only because any attempt to Delete items from a list of posts
would first wrongly call the "Cancel" function, which would balk,
but the "Cancel" function has nothing whatsoever in common with "Delete,"
should be completely independent, and should have been invoked only by
the explicit "Cancel" item in a menu, not also by any "Delete" item, button, or key.
Now that the Thunderbird bug is "fixed,"
you still can't get rid of unwanted posts from your list,
this time because "Delete" in any menu, button, or keyboard key
is either grayed out or clicking/pressing it is ignored.
The "fix" to bug 250141 therefore merely replaces one bug with another,
leaving you no closer to what you want to accomplish -- indeed,
to some people, it looks even worse, because it's grayed out etc.
In the rare event that what you wanted to delete was a post of your own
(or that you temporarily changed the email address in your news account
to match that of the article's author), the older TB versions actually let you
delete the post from your list (after also wrongly sending a "cancel message" to your
NNTP server) but now, with "Delete" grayed out, you can not even delete
your own items (nor those which you pretend to own), as formerly was possible,
so clearly the problem is even worse now than before the bug was "fixed."
Before you wander off to say that a server receiving a "cancel" might ignore it,
this doesn't in any way fix the problem that you still can't delete lines
from your list of posts on your own computer in the current "fixed" version of TB,
which remains the thing that has always been broken, which the OP of this thread
is complaining about, and no distractions about anything else
either "explain away" or mitigate that fact.
If you are lucky enough to have had someone tell you about a hidden internal setting
which un-grays the "Delete" function and finally lets it work, then, and only then,
have you received relief from the basic original bug.
Just like those who posted more comments after #42 to bug 250141,
I say that nothing is actually "fixed" until the user can actually use it,
and if the product doesn't come with everything needed "in the box,"
ready to use as-is, then it's not fixed at all.
To be considered a "fix," the menu item for "Delete" should _never_ be grayed out.
If "Delete" is requested but the secret internal setting is not yet "true,"
then a pop-up should appear and ask permission to perform the request.
Lastly, the pop-up should also offer a "don't ask me again" option,
and if that option is marked, the secret internal setting should be set now,
so that the user will not have to respond again to such pop-ups.
Only if this extra interaction is added could the original bug be finally considered "fixed,"
other than for members of a select group which happens to know a secret setting
(note that when the pop-up is added as just specified, no user knowledge of that
secret setting would be necessary, because the pop-up itself would take care of it).
As far as I'm concerned, it would be just as well to have never even bothered
to care about this "no undo" point (which was never cared about during the
preceding six years, so why suddenly now?), because all it has done thus far
to care about it is to make the original bug worse. It reminds me of the surreal logic
by which powerful pain relief has been denied even to dying patients by out-of-control
drug enforcers, on the grounds that the dying might become addicted to the pain-killers.
Really? Did they mean that the dying would arrive in Heaven as addicts, and not be admitted?
A survey of such follies should suffice to convince anyone that any claim by the human race
to be guided by reason is laughable. Mark Twain already made that point very well,
over a hundred years ago, and nothing has changed at all in the interim.
--
JHM:
> Yet even Outlook Express is perfectly able
> to delete anything it has locally stored on disk,
> without attempting to send any corresponding "cancel" to any server,
> which suffices to prove the specious nature of any such argument
> that had long been proffered as an excuse for TB's bug,
> over the entire six years that it remained unfixed.
Mike Easter:
> to delete anything it has locally stored on disk,
> without attempting to send any corresponding "cancel" to any server,
> which suffices to prove the specious nature of any such argument
> that had long been proffered as an excuse for TB's bug,
> over the entire six years that it remained unfixed.
> The default OE handles news messages it has accessed differently than the default Tb does.
The storage mechanics don't make a bit of difference
to the argument which a glance at Outlook Express proves to be specious.
You have a list of newsgroup posts in front of your face,
and you want to delete some from that list.
You can do that in Outlook Express, but not in Thunderbird.
The misguided argument would have applied just as well to Outlook Express,
as a (false) rationale that deleting articles from your list should not be possible,
while the fact that OE properly deletes them shows that the argument is specious.
For six years that was impossible only in Netscape and Thunderbird,
not because there is any logical reason why it should not be possible,
but only because any attempt to Delete items from a list of posts
would first wrongly call the "Cancel" function, which would balk,
but the "Cancel" function has nothing whatsoever in common with "Delete,"
should be completely independent, and should have been invoked only by
the explicit "Cancel" item in a menu, not also by any "Delete" item, button, or key.
Now that the Thunderbird bug is "fixed,"
you still can't get rid of unwanted posts from your list,
this time because "Delete" in any menu, button, or keyboard key
is either grayed out or clicking/pressing it is ignored.
The "fix" to bug 250141 therefore merely replaces one bug with another,
leaving you no closer to what you want to accomplish -- indeed,
to some people, it looks even worse, because it's grayed out etc.
In the rare event that what you wanted to delete was a post of your own
(or that you temporarily changed the email address in your news account
to match that of the article's author), the older TB versions actually let you
delete the post from your list (after also wrongly sending a "cancel message" to your
NNTP server) but now, with "Delete" grayed out, you can not even delete
your own items (nor those which you pretend to own), as formerly was possible,
so clearly the problem is even worse now than before the bug was "fixed."
Before you wander off to say that a server receiving a "cancel" might ignore it,
this doesn't in any way fix the problem that you still can't delete lines
from your list of posts on your own computer in the current "fixed" version of TB,
which remains the thing that has always been broken, which the OP of this thread
is complaining about, and no distractions about anything else
either "explain away" or mitigate that fact.
If you are lucky enough to have had someone tell you about a hidden internal setting
which un-grays the "Delete" function and finally lets it work, then, and only then,
have you received relief from the basic original bug.
Just like those who posted more comments after #42 to bug 250141,
I say that nothing is actually "fixed" until the user can actually use it,
and if the product doesn't come with everything needed "in the box,"
ready to use as-is, then it's not fixed at all.
To be considered a "fix," the menu item for "Delete" should _never_ be grayed out.
If "Delete" is requested but the secret internal setting is not yet "true,"
then a pop-up should appear and ask permission to perform the request.
Lastly, the pop-up should also offer a "don't ask me again" option,
and if that option is marked, the secret internal setting should be set now,
so that the user will not have to respond again to such pop-ups.
Only if this extra interaction is added could the original bug be finally considered "fixed,"
other than for members of a select group which happens to know a secret setting
(note that when the pop-up is added as just specified, no user knowledge of that
secret setting would be necessary, because the pop-up itself would take care of it).
As far as I'm concerned, it would be just as well to have never even bothered
to care about this "no undo" point (which was never cared about during the
preceding six years, so why suddenly now?), because all it has done thus far
to care about it is to make the original bug worse. It reminds me of the surreal logic
by which powerful pain relief has been denied even to dying patients by out-of-control
drug enforcers, on the grounds that the dying might become addicted to the pain-killers.
Really? Did they mean that the dying would arrive in Heaven as addicts, and not be admitted?
A survey of such follies should suffice to convince anyone that any claim by the human race
to be guided by reason is laughable. Mark Twain already made that point very well,
over a hundred years ago, and nothing has changed at all in the interim.
--
John H Meyers
Feb 13, 2012, 10:46:39 PM2/13/12
to
On 2/13/2012 4:33 PM, Don wrote:
(other posts in this thread elaborate a bit further)
--
Anthony Buckland
Feb 15, 2012, 1:50:17 PM2/15/12
to
I'd been seriously thinking of unsubscribing and then starting
over with the most recent default number of messages.
Lynn McGuire
Feb 15, 2012, 3:19:29 PM2/15/12
to
There is a difference between "cancel" and
"delete" in the newsgroups and most people
know it.
Lynn
John H Meyers
Feb 15, 2012, 6:45:42 PM2/15/12
to
On 2/13/2012 6:16 PM, Lynn McGuire wrote:
> Implement Chris Ilias's great delete function
> in your thrunderbird:
> http://ilias.ca/blog/2011/07/deleting-individual-newsgroup-messages-in-thunderbird/
Chris Ilias' function?
> Implement Chris Ilias's great delete function
> in your thrunderbird:
> http://ilias.ca/blog/2011/07/deleting-individual-newsgroup-messages-in-thunderbird/
As a blogger, perhaps -- now, if he could only influence
_developers_ to complete the original job via these steps:
o "Delete" always enabled.
o Proceed automatically if "secret setting" is already enabled.
o Ask for approval if secret setting is not yet enabled.
o Offer a "don't ask me again" check box while asking for approval.
o Set the secret flag if "don't ask me again" is okayed.
This is the only way that most users would ever gain the actual use
of a "delete" function, which is still effectively non-existent
for most users, simply because of the otherwise well kept secret
that it can be enabled -- that is not the way to offer
_standard_ functionality which should be present in the product
in a completely obvious and functional way,
right "out of the box."
--
John H Meyers
Feb 15, 2012, 7:41:43 PM2/15/12
to
On 2/15/2012 2:19 PM, Lynn McGuire wrote:
> I think that TB should turn it on by default.
Yes, one would have expected that,
> I think that TB should turn it on by default.
given that "Delete" was always earlier available by default,
but instead had tripped over a mistake whenever trying to delete
an entry credited to the email address of someone else
(the mistake was that "Delete" always first called "Cancel"
and then bailed out when "Cancel" objected,
whereas "Cancel" should never have been called at all).
While correcting that basic error of wrongly entangling
"Delete" (from local data) and "Cancel" (send a message to servers),
developers suddenly perceived that some user might be surprised
that "Deleted" items were not simply shifted to a "Trash" folder,
and then could not be recovered via an "Undo."
However minor an issue that might be, the same developers now decided
to "protect" against this perceived hazard by leaving the
"Delete" function totally crippled and totally unavailable,
as if "NO DO" wasn't a far worse thing than "No Undo"
to most all of the users who expect any sane product
to be able to delete any items that they don't want to see.
If it's considered so important to secure the user's approval
that (s)he accepts having "no undo," then a sensible way
to do that is to have a pop-up ask the user, at least once,
and also offer the user a "don't ask me again" for
automatic future acceptance. I consider it opposite to
all sense and sensibility to instead completely disable "Delete"
and require all users to discover the 42nd comment to a bug report
as the only way in existence to find out how to enable "Delete,"
which is what this bug was all about doing,
yet it still leaves "Delete" even more disabled than it used to be!
I perceive as many as _three_ different ways to correct this surreal situation:
o Just enable "Delete" as Lynn suggests (least effort for any developer).
o Enable "Delete" and use a pop-up as described above and elsewhere,
to test and set the now secret setting that leaves "Delete" disabled.
o Move deleted "news" items to an actual "Trash" folder, like other deleted items.
I think that the "middle way" of the above three should completely satisfy
all users and all developers, and should not be difficult to complete.
It seems that nothing happens, however, without bug reports, comments,
and "votes," so here I am, holding a "caucus" to see whether enough people
might gather around this idea, support and "vote" for it,
or suggest what alternative would better serve your needs and those of
all your fellow users, including the majority who don't even join this caucus.
If you want to be heard and counted, please speak up, and/or
file bug reports and/or comments (hopefully well reasoned and well stated),
and finally _vote_
--
Don
Feb 15, 2012, 7:48:45 PM2/15/12
to
I really hate to admit this but I set up my wife's new Win 7 laptop and
installed T-Bird myself back in October. After going through my TB
notes I found the change needed in config editor which I had done and
forgotten - classic senior moment! Lesson learned and I certainly
enjoyed the groups speedy help in this regard.
Don
Jim
Feb 15, 2012, 7:52:05 PM2/15/12
to
On 02/15/2012 06:41 PM, John H Meyers wrote:
> If it's considered so important to secure the user's approval
> that (s)he accepts having "no undo," then a sensible way
> to do that is to have a pop-up ask the user, at least once,
> and also offer the user a "don't ask me again" for
> automatic future acceptance.
Patches are welcome for the above.
> If it's considered so important to secure the user's approval
> that (s)he accepts having "no undo," then a sensible way
> to do that is to have a pop-up ask the user, at least once,
> and also offer the user a "don't ask me again" for
> automatic future acceptance.
- Jim
John H Meyers
Feb 16, 2012, 2:06:27 AM2/16/12
to
On 2/15/2012 6:48 PM, Don wrote:
> I really hate to admit this but I set up my wife's new Win 7 laptop
> and installed T-Bird myself back in October.
> After going through my TB notes I found the change needed in config editor
> which I had done and forgotten - classic senior moment! Lesson learned.
> I really hate to admit this but I set up my wife's new Win 7 laptop
> and installed T-Bird myself back in October.
> After going through my TB notes I found the change needed in config editor
I don't think you needed a lesson -- I think that your experience
serves instead as a lesson in _usability_ which Thunderbird needs to learn,
which is that functions which can not be used without very hard to obtain
knowledge, particularly when they convincingly appear to be absent,
are as good as absolutely missing from the product.
The original bug report was for a function clearly offered but not working,
and the result of the action taken was a function now totally disabled,
which any normal-thinking person would take to have resulted from
a decision to _remove_ the function, rather than to _fix_ it.
A company based near my university has trained many high tech companies
and developers in the art and science of Human Factors engineering,
particularly in GUI design. They use many bad examples from Microsoft
in their course, and they could well add this one from Thunderbird
to the list of things to do everything possible to avoid.
Like a salesman never asking for the order, this function
has disabled itself, rather than ask the user to okay going ahead,
with the result being the same "no sale" to most users.
Your frustration, together with all the time you've spent on it,
plus others having exactly the same difficult experience,
proves what's the matter with the unfinished job done.
The developer(s) who separated the "conjoined twins" of Delete vs. Cancel
did a good job, as far as that part of the job goes,
but then they killed one of the twins,
as far as most any user will ever know,
by locking it in an unknown room and hiding the key
where almost no one will ever find it, turning a potential success
which would otherwise earn wide appreciation
into a public relations failure.
_That's_ the real lesson to be learned, in my opinion,
and the completion of the original goal,
to actually offer the working function back to all users,
in a manner which no one could escape noticing and appreciating,
would be the only thing indicating that the lesson was truly learned.
--
John H Meyers
Feb 16, 2012, 2:39:06 AM2/16/12
to
On 2/15/2012 6:52 PM, Jim Porter wrote:
JHM:
or are you telling me that instead of using discussions,
then bug reports with comments and votes,
the route to fixing a more or less still present bug
(due to lack of solution's accessibility to all users)
is that someone writing in this newsgroup
should be told to go learn everything necessary
to build and correct TB for himself,
then submit a patch? (and get blasted for whatever
stylistic convention he doesn't follow when doing so? ;-)
If you ever use software which I produce,
and tell me about the need for something to be fixed,
or a previously half fixed item to get completely fixed,
can I count on you to fix it for yourself?
Since you've spoken up, may I ask you how to best proceed
with moving the bugzilla procedure along, for a bug
that has already been marked "fixed" but may need something added?
Should this best be done via a new bug report,
or is it better to add comments to the old report?
What about collecting "votes" for the further improvement?
I can see how votes for a new bug report can be counted, provided that
a new report is not marked "duplicate of [already fixed] 250141,"
but how do votes count for an old bug report already marked "fixed,"
or how can the original status of Bug 250141 be changed back
to something that can still get further attention?
Should some of this discussion be posted (or cross-posted)
to the dev's forum?
Your wise advice on this would also be quite welcome, thanks.
By the way, do you have an opinion on my suggestions
that more is needed to actually complete this old bug's fix,
and on the possible direction(s) suggested for doing that?
--
JHM:
>> If it's considered so important to secure the user's approval
>> that (s)he accepts having "no undo," then a sensible way
>> to do that is to have a pop-up ask the user, at least once,
>> and also offer the user a "don't ask me again" for
>> automatic future acceptance.
Jim:
>> that (s)he accepts having "no undo," then a sensible way
>> to do that is to have a pop-up ask the user, at least once,
>> and also offer the user a "don't ask me again" for
>> automatic future acceptance.
> Patches are welcome for the above.
Are you addressing this to fellow developers,
or are you telling me that instead of using discussions,
then bug reports with comments and votes,
the route to fixing a more or less still present bug
(due to lack of solution's accessibility to all users)
is that someone writing in this newsgroup
should be told to go learn everything necessary
to build and correct TB for himself,
then submit a patch? (and get blasted for whatever
stylistic convention he doesn't follow when doing so? ;-)
If you ever use software which I produce,
and tell me about the need for something to be fixed,
or a previously half fixed item to get completely fixed,
can I count on you to fix it for yourself?
Since you've spoken up, may I ask you how to best proceed
with moving the bugzilla procedure along, for a bug
that has already been marked "fixed" but may need something added?
Should this best be done via a new bug report,
or is it better to add comments to the old report?
What about collecting "votes" for the further improvement?
I can see how votes for a new bug report can be counted, provided that
a new report is not marked "duplicate of [already fixed] 250141,"
but how do votes count for an old bug report already marked "fixed,"
or how can the original status of Bug 250141 be changed back
to something that can still get further attention?
Should some of this discussion be posted (or cross-posted)
to the dev's forum?
Your wise advice on this would also be quite welcome, thanks.
By the way, do you have an opinion on my suggestions
that more is needed to actually complete this old bug's fix,
and on the possible direction(s) suggested for doing that?
--
Jim
Feb 16, 2012, 3:00:28 AM2/16/12
to
On 02/16/2012 01:39 AM, John H Meyers wrote:
> Jim:
>> Patches are welcome for the above.
>
> Are you addressing this to fellow developers,
> or are you telling me that instead of using discussions,
> then bug reports with comments and votes,
> the route to fixing a more or less still present bug
> (due to lack of solution's accessibility to all users)
> is that someone writing in this newsgroup
> should be told to go learn everything necessary
> to build and correct TB for himself,
> then submit a patch? (and get blasted for whatever
> stylistic convention he doesn't follow when doing so? ;-)
While I can't speak for everyone, I know there are at least a few
> Jim:
>> Patches are welcome for the above.
>
> Are you addressing this to fellow developers,
> or are you telling me that instead of using discussions,
> then bug reports with comments and votes,
> the route to fixing a more or less still present bug
> (due to lack of solution's accessibility to all users)
> is that someone writing in this newsgroup
> should be told to go learn everything necessary
> to build and correct TB for himself,
> then submit a patch? (and get blasted for whatever
> stylistic convention he doesn't follow when doing so? ;-)
Thunderbird developers who'd be happy to mentor new contributors.
Unfortunately, there are just plain more bugs on Bugzilla than there is
time to work on all of them, so we have to prioritize things. Since mail
is used more frequently than news, sometimes newsgroup fixes fall by the
wayside (it's even worse for RSS, though alta88 has been helping out a
lot there).
> If you ever use software which I produce,
> and tell me about the need for something to be fixed,
> or a previously half fixed item to get completely fixed,
> can I count on you to fix it for yourself?
patches, I'd (hypothetically) be happy to do so. In fact, that's my
general procedure for fixing things in open source software that I'd
like to see fixed, and it's how I got involved with Mozilla in the first
place.
> Since you've spoken up, may I ask you how to best proceed
> with moving the bugzilla procedure along, for a bug
> that has already been marked "fixed" but may need something added?
Bugzilla yet. You could probably expand this to "prompt users upon
deletion-without-undo" (e.g. when shift-deleting mail, or
regular-deleting news).
> Should this best be done via a new bug report,
> or is it better to add comments to the old report?
with the change, except to forward people to the new bug. The goal is
one issue/change per bug, since that's easier to track.
> What about collecting "votes" for the further improvement?
skewed (e.g. if it gets posted on Slashdot or Reddit or what-have-you).
> Should some of this discussion be posted (or cross-posted)
> to the dev's forum?
> By the way, do you have an opinion on my suggestions
> that more is needed to actually complete this old bug's fix,
> and on the possible direction(s) suggested for doing that?
deletion that can't be undone is about to happen (e.g. shift-delete,
delete from trash, delete from a newsgroup).
This is something I'd work on myself, but my time is limited, and I
already have 20 patches currently in my queue, to say nothing of other
bugs I'd like to fix but haven't started.
- Jim
Cy Burnot
Feb 16, 2012, 3:12:49 PM2/16/12
to
John H Meyers has written on 2/13/2012 10:43 PM:
> On 2/13/2012 7:12 PM, Mike Easter wrote:
>
> JHM:
>> Yet even Outlook Express is perfectly able
>> to delete anything it has locally stored on disk,
>> without attempting to send any corresponding "cancel" to any server,
>> which suffices to prove the specious nature of any such argument
>> that had long been proffered as an excuse for TB's bug,
>> over the entire six years that it remained unfixed.
>
> Mike Easter:
>> The default OE handles news messages it has accessed differently than the default Tb does.
>
> The storage mechanics don't make a bit of difference
> to the argument which a glance at Outlook Express proves to be specious.
>
> You have a list of newsgroup posts in front of your face,
> and you want to delete some from that list.
>
> You can do that in Outlook Express, but not in Thunderbird.
My TB does that.
>
> JHM:
>> Yet even Outlook Express is perfectly able
>> to delete anything it has locally stored on disk,
>> without attempting to send any corresponding "cancel" to any server,
>> which suffices to prove the specious nature of any such argument
>> that had long been proffered as an excuse for TB's bug,
>> over the entire six years that it remained unfixed.
>
> Mike Easter:
>> The default OE handles news messages it has accessed differently than the default Tb does.
>
> The storage mechanics don't make a bit of difference
> to the argument which a glance at Outlook Express proves to be specious.
>
> You have a list of newsgroup posts in front of your face,
> and you want to delete some from that list.
>
> You can do that in Outlook Express, but not in Thunderbird.
Cy Burnot
Feb 16, 2012, 3:13:53 PM2/16/12
to
Lynn McGuire has written on 2/15/2012 3:19 PM:
With delete enables, how does one cancel?
Jim
Feb 16, 2012, 3:22:46 PM2/16/12
to
On 02/16/2012 02:13 PM, Cy Burnot wrote:
> With delete enables, how does one cancel?
The same way you always do it: Message -> Cancel Message.
> With delete enables, how does one cancel?
Cy Burnot
Feb 16, 2012, 3:41:20 PM2/16/12
to
Jim has written on 2/16/2012 3:22 PM:
> On 02/16/2012 02:13 PM, Cy Burnot wrote:
>> With delete enables, how does one cancel?
>
> The same way you always do it: Message -> Cancel Message.
Oh, really? The way I always do it is to hit Delete. :-)
>> With delete enables, how does one cancel?
>
> The same way you always do it: Message -> Cancel Message.
Jim
Feb 16, 2012, 3:45:24 PM2/16/12
to
have an add-on changing things or are using an old version of
Thunderbird, that's not the case.
Cy Burnot
Feb 16, 2012, 4:13:17 PM2/16/12
to
Jim has written on 2/16/2012 3:45 PM:
I could swear that before I did the config thing, when I hit Delete, I
got a pop-up telling me I could not cancel someone else's message.
got a pop-up telling me I could not cancel someone else's message.
Ron Hunter
Feb 16, 2012, 5:34:04 PM2/16/12
to
computer. That is, you won't see it again unless you redownload the
message headers for that group. It doesn't delete anything on the
server, however.
Ron Hunter
Feb 16, 2012, 5:36:33 PM2/16/12
to
message will work, but the the delete will make the message header go away.
Cy Burnot
Feb 16, 2012, 7:19:10 PM2/16/12
to
Ron Hunter has written on 2/16/2012 5:34 PM:
Don't believe anyone mentioned removing things from a server.
Keith Nuttle
Feb 16, 2012, 9:59:35 PM2/16/12
to
in very rare occasions.
Cy Burnot
Feb 17, 2012, 11:27:52 AM2/17/12
to
Keith Nuttle has written on 2/16/2012 9:59 PM:
I wonder why Ron mentioned removing things from the server.
John H Meyers
Feb 18, 2012, 9:08:17 AM2/18/12
to
On 2/16/2012 4:34 PM, Ron Hunter wrote:
> Current version of TB will let you delete a newsgroup message from your computer.
Try to convince anyone installing the current version that this is true,
> Current version of TB will let you delete a newsgroup message from your computer.
given that "Delete" in the menu is GRAYED OUT, and the keyboard key is IGNORED.
Most users will never discover the secret process necessary
to change the fact that as delivered to the user,
there is NO SUCH CAPABILITY in Thunderbird.
Suppose you tried to pawn off a new model of cell phone,
assuring purchasers that of course it does text messaging,
but unbeknownst to any purchaser, they would have to open the unit
and solder an extra wire to the circuit to enable texting?
What idiot would try to market anything so utterly stupid?
Well, here it is, in the form of a newsgroups client
that can't delete listed items until similar internal surgery is performed!
I owe one more response to Jim Porter, who has now convinced me
that simply un-graying "Delete" is the best way to proceed quickly,
to liberate an "imprisoned" function which will otherwise never be updated
to add a dialog box, and you have yourself just re-confirmed
why worrying about "no undo" (which is NOT worried about anywhere else
where it's also the case, as Jim pointed out) was quite a foolish cause
for leaving "Delete" totally crippled:
> That is, you won't see it again
That very fact provides an "undo" for news messages!
Tweaking the "RC" file might even be another way (I haven't had time to test it).
This is just another case where the "cure" was worse than the original disease :)
--
John H Meyers
Feb 18, 2012, 9:26:25 AM2/18/12
to
On 2/16/2012 3:13 PM, Cy Burnot wrote:
> I could swear that before I did the config thing, when I hit Delete,
> I got a pop-up telling me I could not cancel someone else's message.
Yes, that was the very heart of bug 250141,
> I could swear that before I did the config thing, when I hit Delete,
> I got a pop-up telling me I could not cancel someone else's message.
which was caused by the original mistake in Netscape,
wherein any attempt to perform _either_
Delete (from computer) _or_ Cancel (from server)
would instead perform _both_ Cancel _and_ Delete,
in that order, causing Cancel to abort most of the time,
thus blocking Delete from being performed at all.
Any pointing this out was met, in this newsgroup,
by shout-downs defending Netscape's mistake,
never by anyone acknowledging that Emperor Netscape
was only parading his ugly butt in public ;-)
--
Jay Garcia
Feb 18, 2012, 9:36:21 AM2/18/12
to
On 18.02.2012 08:26, John H Meyers wrote:
There was a lot to be learned and discovered in the Netscape era.
Programmers were paid employees and there was no "open-source", etc.
There were no contributors to speak of. There was, however, a coporate
base of selected users that had somewhat of a voice in development but
nowhere near today's group numbers.
--
Jay Garcia - www.ufaq.org - Netscape - Firefox - SeaMonkey - Thunderbird
Mozilla Contribute Coordinator Team - www.mozilla.org/contribute/
Mozilla Mozillian Member - www.mozillians.org
Mozilla Contributor Member - www.mozilla.org/credits/
Programmers were paid employees and there was no "open-source", etc.
There were no contributors to speak of. There was, however, a coporate
base of selected users that had somewhat of a voice in development but
nowhere near today's group numbers.
--
Jay Garcia - www.ufaq.org - Netscape - Firefox - SeaMonkey - Thunderbird
Mozilla Contribute Coordinator Team - www.mozilla.org/contribute/
Mozilla Mozillian Member - www.mozillians.org
Mozilla Contributor Member - www.mozilla.org/credits/
John H Meyers
Feb 18, 2012, 10:06:33 AM2/18/12
to
On 2/16/2012 2:45 PM, Jim wrote:
> The delete key isn't hooked up to the Cancel operation
Not since Mr. Cranmer (and Mr. Bienvenu ?)
> The delete key isn't hooked up to the Cancel operation
kindly chose to work on Bug 250141,
and untangled Delete from Cancel,
at least in one direction
(I think that Cancel still proceeds
to also Delete, which it should not,
but it's hard to get anyone to appreciate the valid reason).
However, motivated by what I think was also a mistake,
they also left Delete grayed out and the Delete key ignored,
with an internal surgery that no one would figure out
required to un-gray it, which has left a situation
("there is no Delete at all") just as blocking as original bug 250141
in place for most users.
--
Ron K.
Feb 18, 2012, 2:25:47 PM2/18/12
to
John H Meyers on 2/18/2012 9:26 AM, keyboarded a reply:
John there is one bit in your comment that is not factually correct. While
the Mozilla code my have behaved in a similar manner to Netscape
communicator 4.xx, the code doing it was not Netscape code. From sources,
about 98% of the code for Moz5 that Netscape released to open source on
March 28, 1998 was dumped and the Mozilla.Org project started fresh.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
the Mozilla code my have behaved in a similar manner to Netscape
communicator 4.xx, the code doing it was not Netscape code. From sources,
about 98% of the code for Moz5 that Netscape released to open source on
March 28, 1998 was dumped and the Mozilla.Org project started fresh.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Jim
Feb 18, 2012, 3:43:30 PM2/18/12
to
On 02/18/2012 08:08 AM, John H Meyers wrote:
> I owe one more response to Jim Porter, who has now convinced me
> that simply un-graying "Delete" is the best way to proceed quickly,
> to liberate an "imprisoned" function which will otherwise never be updated
> to add a dialog box, and you have yourself just re-confirmed
> why worrying about "no undo" (which is NOT worried about anywhere else
> where it's also the case, as Jim pointed out) was quite a foolish cause
> for leaving "Delete" totally crippled:
>
>> That is, you won't see it again
>> unless you re-download the message headers for that group.
>
> That very fact provides an "undo" for news messages!
I refuse to put in UI that requires you to redownload headers as some
> I owe one more response to Jim Porter, who has now convinced me
> that simply un-graying "Delete" is the best way to proceed quickly,
> to liberate an "imprisoned" function which will otherwise never be updated
> to add a dialog box, and you have yourself just re-confirmed
> why worrying about "no undo" (which is NOT worried about anywhere else
> where it's also the case, as Jim pointed out) was quite a foolish cause
> for leaving "Delete" totally crippled:
>
>> That is, you won't see it again
>> unless you re-download the message headers for that group.
>
> That very fact provides an "undo" for news messages!
workaround for allowing "undo". That's a clear violation of
ux-error-prevention: "interfaces should proactively try to prevent
errors from happening".
As I've already mentioned, if this is an issue you care about, you could
move the process forward by filing a bug in Bugzilla. Bear in mind that
very few developers frequent this newsgroup, so complaining about an
issue here generally won't do much good. (I only read through this group
when I'm bored, since there's frankly an awful lot of noise on this list.)
- Jim
Cy Burnot
Feb 18, 2012, 3:55:16 PM2/18/12
to
John H Meyers has written on 2/18/2012 9:08 AM:
> Well, here it is, in the form of a newsgroups client
> that can't delete listed items until similar internal surgery is performed!
Clicking a line is internal surgery???
Methinks thou protesteth too much!
> On 2/16/2012 4:34 PM, Ron Hunter wrote:
>
>> Current version of TB will let you delete a newsgroup message from your computer.
>
> Try to convince anyone installing the current version that this is true,
> given that "Delete" in the menu is GRAYED OUT, and the keyboard key is IGNORED.
>
> Most users will never discover the secret process necessary
> to change the fact that as delivered to the user,
> there is NO SUCH CAPABILITY in Thunderbird.
All I had to do is ask!
>
>> Current version of TB will let you delete a newsgroup message from your computer.
>
> Try to convince anyone installing the current version that this is true,
> given that "Delete" in the menu is GRAYED OUT, and the keyboard key is IGNORED.
>
> Most users will never discover the secret process necessary
> to change the fact that as delivered to the user,
> there is NO SUCH CAPABILITY in Thunderbird.
> Well, here it is, in the form of a newsgroups client
> that can't delete listed items until similar internal surgery is performed!
Methinks thou protesteth too much!
John H Meyers
Feb 21, 2012, 1:51:19 AM2/21/12
to
On 2/18/2012 2:55 PM, Cy Burnot wrote:
>> Most users will never discover the secret process necessary
>> to change the fact that as delivered to the user,
>> there is NO SUCH CAPABILITY in Thunderbird.
> All I had to do is ask!
You had to:
>> Most users will never discover the secret process necessary
>> to change the fact that as delivered to the user,
>> there is NO SUCH CAPABILITY in Thunderbird.
> All I had to do is ask!
(a) Assume that a grayed out menu item had any chance of being activated
[most people would take such an item to represent a function simply not available]
(b) Know that this newsgroup existed.
(c) Set up access to this newsgroup, using a server (the only server) which carries it.
(d) Ask whether there is any way to use a grayed out function.
(e) Read wrong responses which tell you that it can not be done,
that you'd be better off marking items "read" to make them disappear,
and know enough not to believe that this was the right answer.
(f) If using Config Editor is suggested before you walk away, learn how to use it,
and don't be deterred by its own built-in warning that it's dangerous to use.
(g) Finally locate the essential setting and change it.
> Clicking a line is internal surgery???
and use an "internal configuration editor"
before being able to do the most commonly expected ordinary operation
_is_ internal surgery!
> Methinks thou protesteth too much!
and should be the last person to be asked to design any
(or even judge any) for general use by ordinary people,
whose job or life has nothing to do with being a computer geek.
Usability or "user friendliness" is that which enables you to
easily find and do all that you could want to accomplish,
rather than block your path and leave you gnashing your teeth in frustration,
as this particular thing has done for seven years,
no closer to satisfaction after "being fixed" than before.
--
John H Meyers
Feb 21, 2012, 1:58:54 AM2/21/12
to
On 2/18/2012 1:25 PM, Ron K. wrote:
> While the Mozilla code my have behaved in a similar manner
> to Netscape communicator 4.xx, the code doing it was not Netscape code.
> From sources, about 98% of the code for Moz5 that Netscape released to open source
> on March 28, 1998 was dumped and the Mozilla.Org project started fresh.
Not fresh enough, in this case ;-)
> While the Mozilla code my have behaved in a similar manner
> to Netscape communicator 4.xx, the code doing it was not Netscape code.
> From sources, about 98% of the code for Moz5 that Netscape released to open source
> on March 28, 1998 was dumped and the Mozilla.Org project started fresh.
Or perhaps this was the other 2% of the original code :)
--
John H Meyers
Feb 21, 2012, 4:04:10 AM2/21/12
to
On 2/18/2012 2:43 PM, Jim wrote:
> I refuse to put in UI that requires you to redownload headers as some workaround for allowing
> "undo". That's a clear violation of ux-error-prevention: "interfaces should proactively try to
> prevent errors from happening".
Have you a sense of proportion?
> I refuse to put in UI that requires you to redownload headers as some workaround for allowing
> "undo". That's a clear violation of ux-error-prevention: "interfaces should proactively try to
> prevent errors from happening".
I have an idea -- let's prevent all automobile injuries and fatalities,
by making driving illegal! No driving -- no crashes!
That's what has been done to date on bug 250141 -- "fixed"
by totally disabling the very function
which the bug report asks to be made to work!
Although it would be nicer to have a pop-up announce every time
that it's not easy to undo it (not impossible, just not easy),
there is obviously no "Trash" in any news server account,
so if no developer wants to proceed further in the direction
of adding a dialog box, at least just leave the "Delete" function DOABLE!
As you pointed out, there are _several already existing places_
where deleting an item would not currently be undoable
(except by a simple "re-index" function already provided for newsgroups, which works):
I already _rely on_ the ability to select all messages in Trash and delete them,
for example, as my fastest way to empty trash!
I also _rely on_ shift+delete, as you pointed out,
to get rid of a message without saving it to Trash.
If knowledge posted only in this newsgroup should suffice,
then here's a sufficient notice:
HEY, DELETING A LINE FROM A NEWSGROUP SUMMARY IS UNDOABLE,
the same as deleting it from Trash or Shift+Deleting it from anywhere,
both of which all users have fortunately always been allowed to do.
There, we have done enough that everyone who visits here will know all about it,
so how about now enabling "Delete" so that the "fix" to 250141 actually exists for everyone?
After all, once a user has set the internal option, now (s)he _has_ a UI
that is exactly in that state anyway, even if you don't like it --
a state in which something necessary can be done,
rather than making NOTHING DOABLE AT ALL,
lest anyone ever once do anything by mistake,
which has as much good sense and proportion of values
as making driving illegal until all auto mishaps can be "undone."
If you can embellish things later to add a built-in dialog, then fine,
but meanwhile, _don't leave a "cure" that's worse than the original disease_ --
that is, a completely disabled function in place of one which used to only produce errors.
--
John H Meyers
Feb 21, 2012, 7:34:22 AM2/21/12
to
On 2/16/2012 2:00 AM, Jim Porter kindly wrote:
> While I can't speak for everyone, I know there are at least a few Thunderbird developers who'd be
> happy to mentor new contributors. Unfortunately, there are just plain more bugs on Bugzilla than
> there is time to work on all of them, so we have to prioritize things. Since mail is used more
> frequently than news, sometimes newsgroup fixes fall by the wayside (it's even worse for RSS,
> though alta88 has been helping out a lot there).
My own mentoring experiences have always been that it takes much less time
> While I can't speak for everyone, I know there are at least a few Thunderbird developers who'd be
> happy to mentor new contributors. Unfortunately, there are just plain more bugs on Bugzilla than
> there is time to work on all of them, so we have to prioritize things. Since mail is used more
> frequently than news, sometimes newsgroup fixes fall by the wayside (it's even worse for RSS,
> though alta88 has been helping out a lot there).
for me to just do something than to train someone else to be able to do it,
so unless it were to bring someone else on board more permanently,
why would I invest more time on one bug, to get someone else to do it,
than to take a useful idea and just make the change myself?
If you are suggesting that I start coding, forget it;
I had enough, and quit that end of this business long ago :)
> Filing a bug would probably help, since there doesn't seem to be one on Bugzilla yet.
> You could probably expand this to "prompt users upon deletion-without-undo"
> (e.g. when shift-deleting mail, or regular-deleting news)
in several places, without any resistance, where the deletion is final, permanent,
and can't be undone -- you can delete items from any Trash folder itself with no objection,
and you can delete mail from any folder at all with no objection, by using the shift key.
It's obvious that news accounts have no Trash folders,
so why can't we do exactly the same thing with newsgroups,
putting this on a par with the other places just mentioned,
where we already trust all users to understand that
there is no "second trash" where items deleted from the "first trash" go,
and there is no place where items go
when we deliberately use the shift key to skip moving to Trash at all,
so why can't we trust users to understand that the non-existence of any Trash
for a news account is no different from the other two cases?
Do we make it impossible to delete selected messages from Trash, without first
having to set an internal hidden value that no one normally knows about? No.
Do we make it impossible to deliberately delete and bypass Trash, without first
having to set an internal hidden value that no one normally knows about? No.
Do we make it impossible to delete newsgroup items, which obviously have no Trash,
without having to set an internal hidden value that no one normally knows about? Yes!
Why so, particularly since this case is actually _not even undoable_, given that either
an index rebuild or an RC edit will actually refresh deleted items from the news server?
If someone finds the time to add internal dialog boxes (with or without
a "don't ask me again" option) to each one of these situations,
to get the user to agree and "sign off" that (s)he has understood that
these three cases are permanent deletions, then that would be fine window-dressing,
but in no case will it change the fact that each deletion will remain permanent anyway,
_except_ the last case, where we actually can _refresh_ news postings, even now,
from the original server, any time we want -- this last fact seems to me
to be a compelling reason why we should meanwhile remove the current block,
which requires the user to know an internal hidden setting to remove,
which neither of the _really undoable_ cases has ever been burdened by.
--
Cecil Westerhof
Feb 22, 2012, 9:10:04 AM2/22/12
to
Op 21-2-2012 7:51, John H Meyers schreef:
I have to agree with John. I needed to have the ability to delete
articles because of porn spam. It was not to much work because of this
thread. But I think it is requiring to much for an average user.
articles because of porn spam. It was not to much work because of this
thread. But I think it is requiring to much for an average user.
Lynn McGuire
Feb 22, 2012, 12:31:25 PM2/22/12
to
user. And drug spam also. The two types of spam
are insidious.
Lynn
Chris Ilias
Feb 22, 2012, 5:05:34 PM2/22/12
to
On 12-02-22 12:31 PM, _Lynn McGuire_ spoke thusly:
This really isn't the place to voice opinions about development. Try
posting in <https://getsatisfaction.com/mozilla_messaging> to send
feebback. If you'd like to get into an actual discussion about
Thunderbird development, that's what the mozilla.dev.apps.thunderbird
newsgroup is for. And design-specific issues can be discussed in
mozilla.dev.usability.
If there's a change that you want to know why it was made, asking in
here should be fine. But be wary of those whose answers are based on
speculation.
--
Chris Ilias <http://ilias.ca>
Mailing list/Newsgroup moderator
posting in <https://getsatisfaction.com/mozilla_messaging> to send
feebback. If you'd like to get into an actual discussion about
Thunderbird development, that's what the mozilla.dev.apps.thunderbird
newsgroup is for. And design-specific issues can be discussed in
mozilla.dev.usability.
If there's a change that you want to know why it was made, asking in
here should be fine. But be wary of those whose answers are based on
speculation.
--
Chris Ilias <http://ilias.ca>
Mailing list/Newsgroup moderator
0 new messages