Re: bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column

Re: bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column

[Eli Zaretskii]

> Date: Wed, 17 Nov 2010 17:35:14 +0100
> From: Gregor Zattler <telegraph@gmx.net>
> Cc: emacs-devel@gnu.org
> 
> Hi Eli,
> * Eli Zaretskii <eliz@gnu.org> [17. Nov. 2010]:
> >> Date: Wed, 17 Nov 2010 11:59:47 +0100
> >> From: Gregor Zattler <telegraph@gmx.net>
> >> Cc: 
> >> 
> >> Do emacs-snapshot -Q -nw with the attached file "nuk" in an xterm with
> >> TERM=xterm: emacs does not place the cursor on the leftmost position in
> >> empty lines but one charakter to the right.
> > 
> > This is a duplicate of bug#7417.
> 
> 
> Thanks for pointing this out.  
> 
> 
> I did search the bug reports but did not find Tassilo's bug
> report.  Can you tell me what I'm doing wrong?  In this list:
> 
> http://debbugs.gnu.org/cgi/pkgreport.cgi?ordering=age;package=Emacs
> 
> 
> Tassilo's bug report does not show up.  Do you know why?

I have no idea.  Glenn, cab you help?

FWIW, I tried the "100 newest bugs", and 7417 did show up.

Re: bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column

[Glenn Morris]

(There is a help-debbugs mailing list.)

>> http://debbugs.gnu.org/cgi/pkgreport.cgi?ordering=age;package=Emacs
>> 
>> Tassilo's bug report does not show up.  Do you know why?

Well, it's merged now, and the merged bug shows up, so who knows.

I'd guess any issues are due to the hack I put in to limit the max
number of displayed bugs. There are too many Emacs bugs for them all
to be listed on a single page.

May I suggest searching for subject keywords before filing a bug?
Or looking at the N newest bugs.

Searching bugs before filing new ones (was: Re: bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column)

[Tassilo Horn]

On Wednesday 17 November 2010 20:41:28 Glenn Morris wrote:

Hi Glenn,

> May I suggest searching for subject keywords before filing a bug?  Or
> looking at the N newest bugs.

Yes, you may, but as long as checking related/duplicate bugs is not a
part of the usual bug filing procedure (aka M-x report-emacs-bug), it
won't have an effect, I guess.

It would be great if M-x report-emacs-bug would query for "Bug keywords"
first (e.g., tty cursor column), then somehow query the bug database and
show a buffer with possibly related bug subjects including links to the
bugtracker.  Then a user should be able to either say "nope, I have a
different bug" and file a new one, or attach to one of the listed bugs.

I don't know if debbugs has some interface for querying the database, or
a better output format than the result html page.  But even that doesn't
look awfully hard to parse to rip out the link to the bug and its
subject...

Bye,
Tassilo

Re: Searching bugs before filing new ones

[Glenn Morris]

Cross-post and follow-up to help-debbugs.

Tassilo Horn wrote:

>> May I suggest searching for subject keywords before filing a bug?  Or
>> looking at the N newest bugs.
>
> Yes, you may, but as long as checking related/duplicate bugs is not a
> part of the usual bug filing procedure (aka M-x report-emacs-bug), it
> won't have an effect, I guess.

I thought it was basic courtesy to do a search before reporting a bug.
But this seems to have disappeared, along with "report your bug to the
right address", and "give a complete, self-contained description of
the problem".

> It would be great if M-x report-emacs-bug would query for "Bug keywords"
> first (e.g., tty cursor column), then somehow query the bug database and
> show a buffer with possibly related bug subjects including links to the
> bugtracker.  Then a user should be able to either say "nope, I have a
> different bug" and file a new one, or attach to one of the listed bugs.

If you think that would be great, maybe you would like to write it.

> I don't know if debbugs has some interface for querying the database, or
> a better output format than the result html page.  But even that doesn't
> look awfully hard to parse to rip out the link to the bug and its
> subject...

Great, so it won't be long before someone writes this feature then.

Re: Searching bugs before filing new ones (was: Re: bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column)

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Thu, 18 Nov 2010 08:48:18 +0100
> 
> It would be great if M-x report-emacs-bug would query for "Bug keywords"
> first (e.g., tty cursor column), then somehow query the bug database and
> show a buffer with possibly related bug subjects including links to the
> bugtracker.  Then a user should be able to either say "nope, I have a
> different bug" and file a new one, or attach to one of the listed bugs.

Yes, it would be nice to have such a feature.

Re: Searching bugs before filing new ones (was: Re: bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column)

[Andrew W. Nosenko]

On Thu, Nov 18, 2010 at 12:14, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Tassilo Horn <tassilo@member.fsf.org>
>> Date: Thu, 18 Nov 2010 08:48:18 +0100
>>
>> It would be great if M-x report-emacs-bug would query for "Bug keywords"
>> first (e.g., tty cursor column), then somehow query the bug database and
>> show a buffer with possibly related bug subjects including links to the
>> bugtracker.  Then a user should be able to either say "nope, I have a
>> different bug" and file a new one, or attach to one of the listed bugs.
>
> Yes, it would be nice to have such a feature.

Usually, in general case, an user that reports a bug has not enough
skills and knowledge in the area for be sure that a bug, which he
going to report, and a bug, which found by pre-submit query, are
duplicates indeed.  Therefore, request he to make such decition is
just unfair (and ineffective).

If finding of potencial duplicates may be automated indeed, then I
would to create crontab job (for example) with this automated
searching and then publish the report somewhere (through www or
e-mail, for example) for following review by people with appropriate
knowledge.

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: Searching bugs before filing new ones (was: Re: bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column)

[Stephen J. Turnbull]

Andrew W. Nosenko writes:

 > Usually, in general case, an user that reports a bug has not enough
 > skills and knowledge in the area for be sure that a bug, which he
 > going to report, and a bug, which found by pre-submit query, are
 > duplicates indeed.  Therefore, request he to make such decition is
 > just unfair (and ineffective).

The point is not to group exact dupes with extreme accuracy.  The
point is to group similar bugs so they get worked on at the same time
in hopes they are the same bug.  If there are actually several bugs,
then some don't get fixed, the users say "hey, you say it's fixed but
it's not!", and the remaining bugs get fixed.  With some luck, they'll
even be bugs "near" the one that got fixed and the developer will have
an easier time fixing them since the code is fresh in his mind.

If the bugs are not grouped, then the the users who report dupes
probably will *not* receive notice that their bugs are fixed.  If in
fact their bugs are dupes, they may wait longer to try a new version
(always risky for the non-tech user).  That's bad.  Also, if the bugs
are the same, but the developer looks at them at different points in
time, it may take longer and be more annoying for the developer to
triage them and properly label them as dupes.

I conclude that in dupe detection, false positives are not as big a
problem as false negatives.  The problem is to communicate to the
users that good guesses are good enough; don't be shy.

Re: Searching bugs before filing new ones

[Glenn Morris]

"Andrew W. Nosenko" wrote:

> Usually, in general case, an user that reports a bug has not enough
> skills and knowledge in the area for be sure that a bug, which he
> going to report, and a bug, which found by pre-submit query, are
> duplicates indeed.  Therefore, request he to make such decition is
> just unfair (and ineffective).

If I were reporting a bug with Emacs going to the wrong column, I
think the minimum effort I should put in is to search for reports with
"column" in the subject. I personally think that's a fair expectation,
but if you disagree with that I'm not going to be able to change your
mind.

For an obvious problem with the development version, then personally I
would also wait a couple of days before making a report.

Clearly duplicates will still occur and will need to be merged; it's
not a big deal and I certainly don't want to discourage people from
making bug reports.

Re: Searching bugs before filing new ones

[Stefan Monnier]

> If I were reporting a bug with Emacs going to the wrong column, I
> think the minimum effort I should put in is to search for reports with
> "column" in the subject. I personally think that's a fair expectation,
> but if you disagree with that I'm not going to be able to change your
> mind.

I don't think this issue deserves as much attention as it's getting.
FWIW, I find debbugs's search functionality pretty poor, so even if you
try and search for a matching bug, it's likely you'll miss it.


        Stefan

Re: Searching bugs before filing new ones

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Nov 18, 2010 at 04:22:50PM -0500, Glenn Morris wrote:

[...]

> If I were reporting a bug with Emacs going to the wrong column, I
> think the minimum effort I should put in is to search for reports with
> "column" in the subject [...]

Don't underestimate the diverse language[1] barriers here. Whatever it is
natural for you to call "column" others won't call by that name.

Emacs poses a special burden here by having its very own terminology in
many places. 

I concur with you that a bug submitter should *try* finding possible
duplicates, but we should expect him/her to fail pretty often.

- ---------------
[1] "language" meaning native tongue and "local computerese"

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFM5mS1Bcgs9XrR2kYRAjxpAJ43UDr170L60scYCBEfF1I5ECZTWACeLWOJ
Q7LPQthswxPZWgCXpRRW49M=
=85Ok
-----END PGP SIGNATURE-----

Re: Searching bugs before filing new ones

[Glenn Morris]

tomas@tuxteam.de wrote:

>> If I were reporting a bug with Emacs going to the wrong column, I
>> think the minimum effort I should put in is to search for reports with
>> "column" in the subject [...]
>
> Don't underestimate the diverse language[1] barriers here. Whatever it is
> natural for you to call "column" others won't call by that name.

Yes, that is why I said that is the "minimum" effort that I personally
would try to put in. If that failed I would generally try a more
thorough search. Of the 4 (so far) reportings of this bug, every
single one had "column" in the subject though, so the minimum
suffices in this case.

Re: Searching bugs before filing new ones

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Nov 19, 2010 at 03:29:37PM -0500, Glenn Morris wrote:
> tomas@tuxteam.de wrote:

[...]

> > Don't underestimate the diverse language[1] barriers [...]

> Yes, that is why I said that is the "minimum" effort that I personally
> would try to put in [...]

We are in violent agreement here: I mean: I'd try to put that amount of
effort myself in there too.

Now -- how do we motivate others to do the same?

Regards
- - tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFM6XzBBcgs9XrR2kYRAjJjAJ9jjOAK6fcAyVCcDkBR7pLx5C0OvwCfTzGL
/eksgyW5FXUaB9Az9HxcmT8=
=PtXP
-----END PGP SIGNATURE-----