4K Bugs

4K Bugs

[Lars Ingebrigtsen]

There are 4051 open bugs in the Emacs bug tracker.  Did we forget to
celebrate, or are we waiting until it reaches a rounder number, like
4096?

I shouldn't really be the one to kvetch about this since I disappear
for months on end, but is there something that we could do to make more
people do bug triage?

Move debbugs-gnu from ELPA to Emacs?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 25 Dec 2015 07:21:00 +0100
> 
> There are 4051 open bugs in the Emacs bug tracker.  Did we forget to
> celebrate, or are we waiting until it reaches a rounder number, like
> 4096?

We wait till #x1000, of course.

> Move debbugs-gnu from ELPA to Emacs?  :-)

How about listing the open bugs each time anyone starts "emacs -Q"?

A useful first step might be arranging for some job to send a message
to emacs-devel summarizing the bug situation.  XEmacs has something
like that, see the xemacs-beta list for an example.

Re: 4K Bugs

[John Wiegley]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

> I shouldn't really be the one to kvetch about this since I disappear for
> months on end, but is there something that we could do to make more people
> do bug triage?

Yesterday I put out a call on Twitter for people to come help us triage the
bugs, to determine which ones still need our attention. There's always a need
for this, and doesn't require as much ability as fixing them. Now we'll see if
any join the fray as the result.

> Move debbugs-gnu from ELPA to Emacs?  :-)

Not sure that would help...

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

Re: 4K Bugs

[Lars Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>> Move debbugs-gnu from ELPA to Emacs?  :-)
>
> Not sure that would help...

I get the feeling there's a certain resistance to using things in ELPA,
still...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[John Wiegley]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Not sure that would help...

> I get the feeling there's a certain resistance to using things in ELPA,
> still...

And *that* is what I want to fix. :)

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

Re: 4K Bugs

[Lars Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> Not sure that would help...
>
>> I get the feeling there's a certain resistance to using things in ELPA,
>> still...
>
> And *that* is what I want to fix. :)

Fix bugs or fix users?  Is that the choice?  :-)  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[John Wiegley]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

>> And *that* is what I want to fix. :)

> Fix bugs or fix users?  Is that the choice?  :-)

If moving debbugs to Emacs today will increase our bug fix rate, then let's do
that. But longer term, I'd like ELPA to be a nicer experience so that no such
invisible barrier exists.

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

Re: 4K Bugs

[jpff]

Sorry for my ignorancem but what is ELPA?

I have been an emacs user since the early 1980s but have only recently 
discovered this mailing list so am not uo to te way you do things.
I remain rather old-fashioned -- dynamic LISP, command-line etc

==John ff

On Fri, 25 Dec 2015, John Wiegley wrote:

>>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> And *that* is what I want to fix. :)
>
>> Fix bugs or fix users?  Is that the choice?  :-)
>
> If moving debbugs to Emacs today will increase our bug fix rate, then let's do
> that. But longer term, I'd like ELPA to be a nicer experience so that no such
> invisible barrier exists.
>
> -- 
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>
>

Re: 4K Bugs

[Lars Ingebrigtsen]

jpff <jpff@codemist.co.uk> writes:

> Sorry for my ignorancem but what is ELPA?

ELPA is a package repository.  It's basically what you interact with
when you use commands like `M-x package-list-packages'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Dmitry Gutov]

On 12/25/2015 07:59 PM, John Wiegley wrote:

> If moving debbugs to Emacs today will increase our bug fix rate, then let's do
> that.

How would it increase that?

I've used the debbugs package many times, and still I have no idea how 
to list, say, all bugs that block 25.1.

debbugs makes some operations a tiny bit more convenient, but the users 
can still use the web interface search.

> But longer term, I'd like ELPA to be a nicer experience so that no such
> invisible barrier exists.

Shouldn't the bug tracker be a nicer experience? I think ELPA is leaps 
and bounds ahead for its purposes already.

Re: 4K Bugs

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I've used the debbugs package many times, and still I have no idea how
> to list, say, all bugs that block 25.1.

Nobody has requested that feature, but I guess it should be trivial to
implement. 

> debbugs makes some operations a tiny bit more convenient, but the
> users can still use the web interface search.

Uhm...  tiny bit...

It lists all the bugs and allows you to zoom in on what you're
interested in.  I've just gone through all the eww-related bugs (`/
eww'), the shr-related bugs (`/ shr') and I'm now doing the URL ones (`/
URL').

I don't know how anybody does any bug triage without it.  Which is
probably why nobody looks at older bugs at all, but instead just reads
the bug-report mailing list.  (I mean, it's great that people read the
bug report mailing lists and responds to things there.  No tea no
shade!)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> I've used the debbugs package many times, and still I have no idea how
>> to list, say, all bugs that block 25.1.
>
> Nobody has requested that feature, but I guess it should be trivial to
> implement. 

Do you have an example bug report that blocks the release?  It's easier
to test when you have something to test with.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Dmitry Gutov]

On 12/25/2015 08:54 PM, Lars Ingebrigtsen wrote:

> Do you have an example bug report that blocks the release?  It's easier
> to test when you have something to test with.

The release bug is http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759, 
you can see the list of blockers there.

I guess my point is that there's no centralized list of "blocks release 
x.x" labels, so you'll at least have to update the debbugs package once 
per release. Maybe that's not so terrible, though.

Re: 4K Bugs

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> The release bug is http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759,
> you can see the list of blockers there.
>
> I guess my point is that there's no centralized list of "blocks
> release x.x" labels, so you'll at least have to update the debbugs
> package once per release. Maybe that's not so terrible, though.

I see.  You have to know what specific bug report is the one everybody
blocks on.

((found_versions) (keywords) (pending . "pending") (fixed) (summary) (location . "db-h") (blocks) (subject . "Release 25.1") (severity . "normal") (package "emacs") (tags) (unarchived) (fixed_versions) (id . 19759) (found_date) (found) (owner) (affects) (forwarded) (done) (fixed_date) (last_modified . 1450465203) (archived) (date . 1422998281) (mergedwith) (source . "unknown") (log_modified . 1450465203) (blockedby 22207 21708 21519 21874 20813 20478 20352 19407 22065 21701 21849 21243 21839 21650 20401 21054 21518 21291 20377 19826 21295 17693 21351 20326 20555 20420 21223 21724 21881 21257 22085 20441 19959 20356 20400 20332 21104 21998 21058 20475 17976 20444 21685 20355 18954 19548 20505 20247 21750 22203 18718 19479 20951 16737 21168 22147 21968 20066 21629 20445 21227 20124 21157 21797 19968 20975 20484 20201 21337 21766 20637 21862 20455 20629 20431 20382 20668 21946 20386 ...) (msgid . "<sz8ugeitj7.fsf@fencepost.gnu.org>") (bug_num . 19759) (originator . "Glenn Morris <rgm@gnu.org>"))

As you say debbugs-gnu will have to be updated each release, but that
should be OK...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[John Wiegley]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I've used the debbugs package many times, and still I have no idea how to
>> list, say, all bugs that block 25.1.

> Nobody has requested that feature, but I guess it should be trivial to
> implement.

Consider it requested. :)

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

Re: 4K Bugs

[Dmitry Gutov]

On 12/25/2015 08:40 PM, Lars Ingebrigtsen wrote:

> Nobody has requested that feature, but I guess it should be trivial to
> implement.

Thanks!

>> debbugs makes some operations a tiny bit more convenient, but the
>> users can still use the web interface search.
>
> Uhm...  tiny bit...

It's also less discoverable for less experienced users; the web page at 
least says "email your comments to ...". When using the debbugs package, 
the user must be familiar with Gnus key bindings to send a reply (as 
well as make sure to use the "wide-reply" variety).

I mean, it handy when you know all that, but simply moving it to the 
core won't make the bug tracker suddenly more accessible to the majority 
of the users.

> It lists all the bugs and allows you to zoom in on what you're
> interested in.  I've just gone through all the eww-related bugs (`/
> eww'), the shr-related bugs (`/ shr') and I'm now doing the URL ones (`/
> URL').

That's nice, but does it offer a lot of advantage over using the search 
in the web interface, or M-x debbugs-gnu-search?

Re: 4K Bugs

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 25 Dec 2015 21:56:43 +0200
> Cc: emacs-devel@gnu.org
> 
> It's also less discoverable for less experienced users; the web page at 
> least says "email your comments to ...". When using the debbugs package, 
> the user must be familiar with Gnus key bindings to send a reply (as 
> well as make sure to use the "wide-reply" variety).

Aren't these described in debbugs-ug.texi?  If not, they should be.

Re: 4K Bugs

[Lars Ingebrigtsen]

I've now added a command (`R') to list all the blocking reports.  Have
at them.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> And *that* is what I want to fix. :)
>
>> Fix bugs or fix users?  Is that the choice?  :-)
>
> If moving debbugs to Emacs today will increase our bug fix rate, then let's do
> that. But longer term, I'd like ELPA to be a nicer experience so that no such
> invisible barrier exists.

As a first step, we might give it a more prominent place in
admin/notes/bugtracker and doc/emacs/trouble.texi. Will do.

Best regards, Michael.

Re: 4K Bugs

[Andreas Röhler]

On 25.12.2015 18:00, John Wiegley wrote:
>>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> I shouldn't really be the one to kvetch about this since I disappear for
>> months on end, but is there something that we could do to make more people
>> do bug triage?
> Yesterday I put out a call on Twitter for people to come help us triage the
> bugs, to determine which ones still need our attention. There's always a need
> for this, and doesn't require as much ability as fixing them. Now we'll see if
> any join the fray as the result.
>
>> Move debbugs-gnu from ELPA to Emacs?  :-)
> Not sure that would help...
>

IMHO trying to fix these old bugs is not the best way to spend time.
Many things might have changed since - dealing with this changes resp. 
their effects makes any reasoning complex.

What about getting bugs deleted when not dealt with after some time - 
while informing the author?
So the author may renew it.

Re: 4K Bugs

[Eli Zaretskii]

> From: Andreas Röhler <andreas.roehler@online.de>
> Date: Sat, 26 Dec 2015 09:07:22 +0100
> Cc: John Wiegley <jwiegley@gmail.com>
> 
> IMHO trying to fix these old bugs is not the best way to spend time.
> Many things might have changed since - dealing with this changes resp. 
> their effects makes any reasoning complex.

But we should try doing that anyway.

> What about getting bugs deleted when not dealt with after some time - 
> while informing the author?

That's be losing information for no good reason.  Every bug report
provides information about the bug, sometimes the information is very
valuable, sometimes less so.  We shouldn't lose that information so
easily.  It hurts no one to have an old bug in the database.

> So the author may renew it.

The author may no longer be available, or care.

Re: 4K Bugs

[Andreas Röhler]

On 26.12.2015 11:29, Eli Zaretskii wrote:
>> From: Andreas Röhler <andreas.roehler@online.de>
>> Date: Sat, 26 Dec 2015 09:07:22 +0100
>> Cc: John Wiegley <jwiegley@gmail.com>
>>
>> IMHO trying to fix these old bugs is not the best way to spend time.
>> Many things might have changed since - dealing with this changes resp.
>> their effects makes any reasoning complex.
> But we should try doing that anyway.
>
>> What about getting bugs deleted when not dealt with after some time -
>> while informing the author?
> That's be losing information for no good reason.  Every bug report
> provides information about the bug, sometimes the information is very
> valuable, sometimes less so.  We shouldn't lose that information so
> easily.  It hurts no one to have an old bug in the database.

Keeping old bugs provides some burden - otherwise the question wouldn't 
show up.

When digging into old bugs don't see a no rule for all, but some 
indications: The age of the bug, the changes in the specific 
environment, the skill of the investor.

It would minimize losses if the owner of the bug may keep it alive.

Re: 4K Bugs

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, jwiegley@gmail.com
> From: Andreas Röhler <andreas.roehler@online.de>
> Date: Sat, 26 Dec 2015 16:14:21 +0100
> 
> >> What about getting bugs deleted when not dealt with after some time -
> >> while informing the author?
> > That's be losing information for no good reason.  Every bug report
> > provides information about the bug, sometimes the information is very
> > valuable, sometimes less so.  We shouldn't lose that information so
> > easily.  It hurts no one to have an old bug in the database.
> 
> Keeping old bugs provides some burden - otherwise the question wouldn't 
> show up.
> 
> When digging into old bugs don't see a no rule for all, but some 
> indications: The age of the bug, the changes in the specific 
> environment, the skill of the investor.
> 
> It would minimize losses if the owner of the bug may keep it alive.

I think the balance still tips towards retaining the information.  We
can always treat old bugs as "logically deleted", if it bothers
someone.

Re: 4K Bugs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think the balance still tips towards retaining the information.  We
> can always treat old bugs as "logically deleted", if it bothers
> someone.

Well, the bug reports are still there, even if they're closed.  :-)  It's
just part of the ranking, in a way, and says something about how hard we
think (as maintainers) that we (as maintainers) should be looking at the
bug reports.

From "critical" ("LOOK AT THIS!!!") via "wishlist" ("if you have the
time...") to "closed" ("I think it's rather likely that this isn't
interesting").

By putting bug reports in the last category more aggressively, one hopes
to stimulate people to focus on the rest of the reports...

I don't know how well this works for projects that auto-close bug
reports.  Anybody have experience with that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 26 Dec 2015 17:41:35 +0100
> Cc: jwiegley@gmail.com,
> 	Andreas Röhler <andreas.roehler@online.de>,
> 	emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think the balance still tips towards retaining the information.  We
> > can always treat old bugs as "logically deleted", if it bothers
> > someone.
> 
> Well, the bug reports are still there, even if they're closed.  :-)  It's
> just part of the ranking, in a way, and says something about how hard we
> think (as maintainers) that we (as maintainers) should be looking at the
> bug reports.

"moreinfo" is a euphemism for "not reproducible", so it's not
different.  I imagine people who are annoyed by these bugs can filter
those "moreinfo" out, right?

> >From "critical" ("LOOK AT THIS!!!") via "wishlist" ("if you have the
> time...") to "closed" ("I think it's rather likely that this isn't
> interesting").
> 
> By putting bug reports in the last category more aggressively, one hopes
> to stimulate people to focus on the rest of the reports...
> 
> I don't know how well this works for projects that auto-close bug
> reports.  Anybody have experience with that?

Closing bug reports tends to annoy their reporters.  More importantly,
they disappear from all kinds of listings, and you need to work hard
just to see them, even if you want to.  Debbugs also has a nasty habit
of refusing to merge bugs that have different status (thus requiring
you to send 2 separate commands, after the original one bounces).

So on balance I'd rather leave them open and in "moreinfo" category.

Thanks.

Re: 4K Bugs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> "moreinfo" is a euphemism for "not reproducible", so it's not
> different.  I imagine people who are annoyed by these bugs can filter
> those "moreinfo" out, right?

Sure, if you want to think about them that way.

> Closing bug reports tends to annoy their reporters.

It does, but only because they think "closed" means that the report is
disappeared, and "moreinfo" means that we're still thinking about it.
Both of which are wrong.  :-)

> More importantly, they disappear from all kinds of listings, and you
> need to work hard just to see them, even if you want to.

`debbugs-gnu-search' lists closed bugs by default...

> Debbugs also has a nasty habit of refusing to merge bugs that have
> different status (thus requiring you to send 2 separate commands,
> after the original one bounces).

Well, that's a UI problem.  The debbugs-gnu command functions could
handle all that if that's a problem...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Ivan Shmakov]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Eli Zaretskii <eliz@gnu.org> writes:

[…]

 >> Closing bug reports tends to annoy their reporters.

	Not only the reporters; if I’m supportive of a change requested,
	closing the respective report will hardly make me any happier –
	irrespective of who made the request.

 > It does, but only because they think "closed" means that the report
 > is disappeared, and "moreinfo" means that we're still thinking about
 > it.  Both of which are wrong.  :-)

	Semantically, “closed” means that there’s no bug (any more) –
	that is, the recipe given by the reporter does not reproduce the
	issue, or the reporter is found to be mistaken on the feature’s
	intended (and documented) behavior.  In the latter case, it may
	still make sense to review, and possibly amend, the
	documentation, so to reduce the chance of the intended behavior
	being confused for a “bug” in the future.  (Hence, a “mistaken”
	bug report may point at an actual bug in the documentation.)

	When the bug explicitly requests for the change of the behavior,
	being “closed” means that either the change was implemented,
	or a similar feature was provided, or that the assumptions the
	request’s based upon are no longer relevant (say, when the
	feature request explicitly concerns some facility that was
	removed from Emacs altogether.)

	Then, “moreinfo” means that the report lacks information
	essential to reproducing the issue (that is: its recipe is
	incomplete or missing); while “wontfix” means that the
	maintainer does not consider rectifying the issue (say,
	implementing the feature request) to be worth the effort.

	Technically, closed bugs are archived, which mean that they
	disappear from the “default” http://debbugs.gnu.org/ lists, and
	also become “immutable” – unless explicitly unarchived later.

[…]

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

Re: 4K Bugs

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> Semantically, “closed” means that there’s no bug (any more) –
> that is, the recipe given by the reporter does not reproduce the
> issue, or the reporter is found to be mistaken on the feature’s
> intended (and documented) behavior. 

I disagree that this is the semantics of "closed".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Ivan Shmakov]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >> Semantically, “closed” means that there’s no bug (any more) – that
 >> is, the recipe given by the reporter does not reproduce the issue,
 >> or the reporter is found to be mistaken on the feature’s intended
 >> (and documented) behavior.

 > I disagree that this is the semantics of "closed".

	That doesn’t sound constructive; what semantics do you suggest?

	Of course, there’s always an option of starting a “community
	fork” of the Emacs bug tracking system, so that the users can
	track the bugs the developers found to be unworthy of being
	open.

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

Re: 4K Bugs

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> That doesn’t sound constructive; what semantics do you suggest?

I think I described the semantics in the earlier message?  The one with
critical/wishlish/closed?

> Of course, there’s always an option of starting a “community
> fork” of the Emacs bug tracking system, so that the users can
> track the bugs the developers found to be unworthy of being
> open.

I don't know what this means.  All the bug reports, no matter what their
statuses, are in the bug tracker.  If you wish to follow only the bugs
that are marked all og wishlist/wontfix/unreproducible/closed, that's
just a couple of lines in debbugs-gnu.  Be my guest.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Ivan Shmakov]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >>>> Semantically, “closed” means that there’s no bug (any more) – that
 >>>> is, the recipe given by the reporter does not reproduce the issue,
 >>>> or the reporter is found to be mistaken on the feature’s intended
 >>>> (and documented) behavior.

 >>> I disagree that this is the semantics of "closed".

 >> That doesn’t sound constructive; what semantics do you suggest?

 > I think I described the semantics in the earlier message?  The one
 > with critical/wishlish/closed?

 LI> From "critical" ("LOOK AT THIS!!!") via "wishlist" ("if you have
 LI> the time...") to "closed" ("I think it's rather likely that this
 LI> isn't interesting").

	I believe that severity was made orthogonal to the (open,
	closed, archived) status (and to the tags) on purpose.

 >> Of course, there’s always an option of starting a “community fork”
 >> of the Emacs bug tracking system, so that the users can track the
 >> bugs the developers found to be unworthy of being open.

 > I don't know what this means.  All the bug reports, no matter what
 > their statuses, are in the bug tracker.  If you wish to follow only
 > the bugs that are marked all og
 > wishlist/wontfix/unreproducible/closed, that's just a couple of lines
 > in debbugs-gnu.  Be my guest.

	I wish to follow the bugs that are /extant/, per the semantics
	I’ve given earlier.  Such bugs may happen to be of any severity
	and may bear any tags; and per the semantics you suggest, they
	may also be open, closed, or archived.  That is: there’s no way
	to /omit/ the feature requests that were actually implemented
	(or became otherwise irrelevant) – and /show/ all the rest.

	The data to discern the two are simply not there.

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

Re: 4K Bugs

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> I wish to follow the bugs that are /extant/, per the semantics
> I’ve given earlier.

Given a spherical cow...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Per Starbäck]

>> I don't know how well this works for projects that auto-close bug
>> reports.  Anybody have experience with that?
>
> Closing bug reports tends to annoy their reporters.

Not only them, but anyone who is interested in that bug.

Example: I've used Fedora which used that system, and I don't know how
many times I've searched for a bug that I have encountered in it to
see that it has been reported, closed because of new Fedora version,
reported again in that version, closed when there is a new Fedora
version, reported again, etc.
Then I don't bother to report it again in the current version, because
it is probably pointless. Of course those bugs wouldn't automatically
have been fixed if the reports weren't closed all the time, but then
there would at least be somewhere I could make a comment about the bug
still being present in the latest version, without feeling like I'm
just writing for the garbage bin.

Re: 4K Bugs

[Andreas Röhler]

On 27.12.2015 23:41, Per Starbäck wrote:
>>> I don't know how well this works for projects that auto-close bug
>>> reports.  Anybody have experience with that?
>> Closing bug reports tends to annoy their reporters.
> Not only them, but anyone who is interested in that bug.
>
> Example: I've used Fedora which used that system, and I don't know how
> many times I've searched for a bug that I have encountered in it to
> see that it has been reported, closed because of new Fedora version,
> reported again in that version, closed when there is a new Fedora
> version, reported again, etc.
> Then I don't bother to report it again in the current version, because
> it is probably pointless. Of course those bugs wouldn't automatically
> have been fixed if the reports weren't closed all the time, but then
> there would at least be somewhere I could make a comment about the bug
> still being present in the latest version, without feeling like I'm
> just writing for the garbage bin.

With the proposed proceeding you would receive an alert when 
closing-by-release.

Sending an email  with "reopen BUGNUMBER resp. "unarchive BUGNUMBER" in 
body should be sufficient.

Re: 4K Bugs

[John Wiegley]

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

> So on balance I'd rather leave them open and in "moreinfo" category.

I agree. Let's keep the old bugs open until we've triaged them, since in the
end, I don't think we'd actually be saving time by pre-emptively closing them.
Then we're just playing a numbers game, which although might motivate us, I'm
not sure it saves us any real work.

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

Re: 4K Bugs

[Paul Eggert]

Lars Ingebrigtsen wrote:
> I don't know how well this works for projects that auto-close bug
> reports.  Anybody have experience with that?

I've done it both ways, and both ways work. As long as there's a sense of which 
bugs are more important and which less, and we never lose tracks of bugs even 
when fixed, the two ways are roughly equivalent. Of course one needs to have 
enough resources devoted to bug-fixing (and we should present the list of 
unfixed bugs in a non-demoralizing way :-).

One option is to tag all open bugs as "moreinfo" after a new release, while 
sending email to the bug reporters to check whether "moreinfo" the bugs are 
still applicable in the new release. We can then remove the "moreinfo" tag for 
bugs that are later reported to still be relevant. This would require some 
discipline on our part, of course.

Re: 4K Bugs

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> One option is to tag all open bugs as "moreinfo" after a new release,
> while sending email to the bug reporters to check whether "moreinfo"
> the bugs are still applicable in the new release. We can then remove
> the "moreinfo" tag for bugs that are later reported to still be
> relevant. This would require some discipline on our part, of course.

Yup...  I'm almost done with the "moreinfo" triage, and there's a
significant number of bugs that have been marked as "moreinfo", and then
more info is given, but the flag hasn't been removed.  (Which I've now
done in those cases.)

Handling bugs is, like, work.  :-)  Perhaps the FSF could hire a
full-time bug herder?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[John Wiegley]

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

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

> Handling bugs is, like, work. :-) Perhaps the FSF could hire a full-time bug
> herder?

A bug herder is the most significant piece of the Emacs Project Puzzle that is
missing, in my opinion. Eli and others (and recently Lars especially) have
made heroic efforts, but this also distracts from their primary development
work.

If we could find 2-3 people dedicated to combing through, and responding to
bugs -- even just to get them ready for more serious investigation by a core
developer -- it would help this project greatly.

It's hard to see an open bug count of 4k+ and not give up a little bit in
one's heart. And yet, I have a feeling our _true_ bugload is much smaller, if
we winnow the chaff.

-- 
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 --]

Re: 4K Bugs

[Lars Ingebrigtsen]

Andreas Röhler <andreas.roehler@online.de> writes:

> What about getting bugs deleted when not dealt with after some time - 
> while informing the author?

That is what many projects do -- when they make a new release, they
close all bug reports pertaining to older releases.  I see the
attraction, especially when there's a shortage of people to handle bug
reports, but it seems rather wasteful.

Bug reports have value.  Some more than others, of course.  :-)  If they
present a reproducible bug, then it seems odd to close the report.  If,
on the other hand, they are not reproducible, or they require more data
from the user for us to proceed with debugging (and that data doesn't
arrive within a certain period (for the Emacs bug tracker, that period
is "some years", apparently), then they should be closed, because we
can't proceed in any meaningful sense.

That's why I'm going through the bug reports marked "moreinfo" and
closing the ones that seem hopeless, and prodding the ones that seem
perhaps to be possible to proceed with.

But having a morass of bug reports, like we do now, is (I think)
discouraging to everybody.  No matter what you do, it doesn't seem to
matter, because there's just so many reports.

So unless more people step up, roll up their sleeves and do some bug
triage from time to time, I wouldn't be upset if we just closed all bugs
reports that were older than last release.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Bug reports have value.  Some more than others, of course.  :-)  If they
  > present a reproducible bug, then it seems odd to close the report.  If,
  > on the other hand, they are not reproducible, or they require more data
  > from the user for us to proceed with debugging (and that data doesn't
  > arrive within a certain period (for the Emacs bug tracker, that period
  > is "some years", apparently), then they should be closed, because we
  > can't proceed in any meaningful sense.

I agree -- but is there a way to distinguish the bug reports we close
for lack of information, from those that are closed for other reasons?

When we close bug reports because we did not get the further
information necessary to fix them, I'd say those bug reports have been
"abandoned".

Can we make a way for debbugs to distinguish abandoned bug reports?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: 4K Bugs

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I agree -- but is there a way to distinguish the bug reports we close
> for lack of information, from those that are closed for other reasons?
>
> When we close bug reports because we did not get the further
> information necessary to fix them, I'd say those bug reports have been
> "abandoned".

Yes, we mark those with "moreinfo" (usually), and say in the text of the
bug report that that's why they're closed (if we don't forget).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Phillip Lord]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There are 4051 open bugs in the Emacs bug tracker.  Did we forget to
> celebrate, or are we waiting until it reaches a rounder number, like
> 4096?
>
> I shouldn't really be the one to kvetch about this since I disappear
> for months on end, but is there something that we could do to make more
> people do bug triage?
>
> Move debbugs-gnu from ELPA to Emacs?  :-)


I'm very late to this discussion, but inspired by Lar's bug fix spree I
decided to see if I could have a go myself. I found the process a little
confusing. Here are some points:


 - After installing debbugs, there is no obvious entry point. M-x
   debugs-[tab] gives 30 different commands.

 - The two shortest commands are debbugs-org and debbugs-gnu. The former
   lists all the bugs for Org-Mode, and the latter Emacs. Why
   debbugs-gnu and not debbugs-emacs? I don't know.

 - debbugs-gnu list bugs from number 158 and upward; the entire first
   500 is about emacs 23 pre-releases. If I want to get the latest bugs,
   they are on page 5.

 - Bugs marked as "done" and "unreproducible" are displayed by default.
 
 - On none of the debbugs pages are there any obvious menu items or
   bug-related functionality.

 - I found out about hitting "C" to send a control message. Configuring
   this to "mail client" and up pops thunderbird, although I am a Gnus
   user.

 - I found "bugtracker" in admin/notes late in the day. It doesn't
   mention the debbugs package AFAICT. It's full of information, but a
   lot of it is how to manage the bug tracker. I don't know if there is
   anything better on how-to-fix a bug. It also ends with a warning that
   the database takes "well over 1Gb of space" which makes it look
   rather old.

So, I think that the process is rather harder than it needs to be.

If anyone is willing to hold-my-hand, and take me through the process of
fixing a couple of bugs (not the actual bug-hunting, which I can do),
I'll write the process up as a short tutorial as I did with for
etc/DEBUG. This way I can use my ignorance to good purpose.

Phil

Re: 4K Bugs

[Phillip Lord]

Phillip Lord <phillip.lord@russet.org.uk> writes:

> If anyone is willing to hold-my-hand, and take me through the process of
> fixing a couple of bugs (not the actual bug-hunting, which I can do),
> I'll write the process up as a short tutorial as I did with for
> etc/DEBUG. This way I can use my ignorance to good purpose.

Apologies for the spam, I've realised that this has already been done now.

Re: 4K Bugs

[Andrew Hyatt]

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

On Thu, Jan 7, 2016 at 5:38 PM Phillip Lord <phillip.lord@russet.org.uk>
wrote:

> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
> > If anyone is willing to hold-my-hand, and take me through the process of
> > fixing a couple of bugs (not the actual bug-hunting, which I can do),
> > I'll write the process up as a short tutorial as I did with for
> > etc/DEBUG. This way I can use my ignorance to good purpose.
>
> Apologies for the spam, I've realised that this has already been done now.
>

I wonder if the admin/notes/bug-triage file should be advertised in some
way in the debbugs-gnu UI.  In some sense, it's a help file that especially
new developers diving into the bug system should read.

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

Re: 4K Bugs

[Michael Albinus]

Andrew Hyatt <ahyatt@gmail.com> writes:

> I wonder if the admin/notes/bug-triage file should be advertised in
> some way in the debbugs-gnu UI. In some sense, it's a help file that
> especially new developers diving into the bug system should read.

I'm planning to add a menu to the bug reports buffer, it could be an
entry there if the bug reports are about the package "emacs". However,
debbugs comes via ELPA; older Emacsen won't carry that file.

Best regards, Michael.

Re: 4K Bugs

[John Wiegley]

>>>>> Phillip Lord <phillip.lord@russet.org.uk> writes:

> So, I think that the process is rather harder than it needs to be.

FWIW, the confusion you describe is pretty much identical to my first
experience. It's not at all what I expected when my main concern was "what
bugs should I take a look at right now?"

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

Re: 4K Bugs

[Xue Fuqiao]

On Fri, Jan 8, 2016 at 4:10 AM, Phillip Lord <phillip.lord@russet.org.uk> wrote:

>  - The two shortest commands are debbugs-org and debbugs-gnu. The former
>    lists all the bugs for Org-Mode, and the latter Emacs. Why
>    debbugs-gnu and not debbugs-emacs? I don't know.

Maybe because some other GNU projects also use debbugs.gnu.org:

* https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6056
* https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7868
* https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17355
* https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18641

Re: 4K Bugs

[Phillip Lord]

Xue Fuqiao <xfq.free@gmail.com> writes:

> On Fri, Jan 8, 2016 at 4:10 AM, Phillip Lord <phillip.lord@russet.org.uk> wrote:
>
>>  - The two shortest commands are debbugs-org and debbugs-gnu. The former
>>    lists all the bugs for Org-Mode, and the latter Emacs. Why
>>    debbugs-gnu and not debbugs-emacs? I don't know.
>
> Maybe because some other GNU projects also use debbugs.gnu.org:
>
> * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6056
> * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7868
> * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17355
> * https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18641

I maybe wrong, but AFAICT, the emacs debbugs package only shows emacs
bugs. I am confused about this anyway.

Phil

Re: 4K Bugs

[Alexis]

i've just recently installed the `debbugs` package myself, as part 
of trying to help out with bug triage. i rather like it overall, 
and find it less unwieldy than the Web UI - thanks to those who 
have put it together! Still, i too have had some issues:

Phillip Lord <phillip.lord@russet.org.uk> writes:

>  - After installing debbugs, there is no obvious entry 
>  point. M-x 
>    debugs-[tab] gives 30 different commands.

Agreed; it took me a few moments to realise that debbugs-gnu was 
probably what i wanted.

>  - debbugs-gnu list bugs from number 158 and upward; the entire 
>  first 
>    500 is about emacs 23 pre-releases. If I want to get the 
>    latest bugs, they are on page 5.

An argument could be made that the longest-outstanding issues 
should be displayed first, to try to encourage their 
resolution. Having said that, it could also be argued that their 
longevity means they're less likely to be able to be resolved soon 
than recent bugs. So i'm not sure what the best default is here.

>  - Bugs marked as "done" and "unreproducible" are displayed by 
>  default.

i would certainly prefer that "done" and "unreproducible" bugs 
were not displayed by default.

>  - On none of the debbugs pages are there any obvious menu items 
>  or 
>    bug-related functionality.

Well, as usual in these situations, i used C-h m (`describe-mode`) 
to find out what i can do; but yes, it might be useful to at least 
have one or two lines of text describing at least some of the 
possible commands (and maybe also, what the colours in the `State` 
field indicate).

>  - I found out about hitting "C" to send a control 
>  message. Configuring 
>    this to "mail client" and up pops thunderbird, although I am 
>    a Gnus user.

i'm a mu4e user, and when i try to send a control message 
.... Well, i'm not sure what happens. i get nothing to indicate a 
message was sent, but nothing to indicate it failed to be sent 
either. i can successfully use mu4e to reply to messages in the 
relevant bug thread, though.

Finally, i'd like to suggest that the `debbugs` manual be renamed 
to something like `debbugs-dev`, and the `debbugs-ug` manual be 
renamed to `debbugs`. In trying to find out what the colours in 
the `State` field indicated, i ran the `info-display-manual` 
command and specified `debbugs`; the result ("Debbugs Programmers 
Manual") surprised me, and it took me a while to realise that 
there's a `debbugs-ug` ("Debbugs User Guide") manual. My guess is 
that many more people are going to want to use the latter than the 
former; hence my rename suggestion. Perhaps it might also be 
useful to link to the User Guide from the `debbugs` UI?


Alexis.

Re: 4K Bugs

[Richard Copley]

> An argument could be made that the longest-outstanding issues should
> be displayed first, to try to encourage their resolution. Having
> said that, it could also be argued that their longevity means
> they're less likely to be able to be resolved soon than recent
> bugs. So i'm not sure what the best default is here.

This problem will go away by itself now that we're deluged with
enthusiastic triagers.

Re: 4K Bugs

[Alexis]

Richard Copley <rcopley@gmail.com> writes:

>> An argument could be made that the longest-outstanding issues 
>> should be displayed first, to try to encourage their 
>> resolution. Having said that, it could also be argued that 
>> their longevity means they're less likely to be able to be 
>> resolved soon than recent bugs. So i'm not sure what the best 
>> default is here.
>
> This problem will go away by itself now that we're deluged with 
> enthusiastic triagers.

Heh, well, i wouldn't call the (from what i can tell) 
maybe-less-than-half-a-dozen of us to be a "deluge". :-)

At any rate, i'm not sure the problem will necessarily go away by 
itself, for a few reasons:

* Looking over the longest-outstanding bugs, i noticed a number of 
  them 
  were Mac-specific. As i don't have access to a Mac - i'm on 
  Debian - i can't try to reproduce the issue. So unless triagers 
  have access to a Mac, such issues are more likely to 
  languish. (This had made me wonder whether tags like 'mac', 
  'win' etc. might be useful?)

* Even triagers who do have access to a Mac won't necessarily feel 
  competent enough to try to address /every/ long-outstanding bug; 
  and this applies more generally, regardless of OS. i've been 
  following bug-gnu-emacs for a while now, to try to help triage 
  new bugs, but i only address a small fraction of those that come 
  through: those haven't been addressed by someone more expert 
  than me, and which i understand well enough to be able to try to 
  reproduce and/or ask (hopefully) sensible questions about.

* Some of the long-outstanding bugs have a complicated history 
  that is 
  daunting to try to untangle and work out what the next step 
  might be. Particularly when the history involves a heated debate 
  which has apparently reached an uncomfortable stalemate.

Regarding the last point: maybe at least some of these sorts of 
bugs could be brought to John's attention for arbitration?


Alexis.

Re: 4K Bugs

[John Wiegley]

>>>>> Alexis  <flexibeast@gmail.com> writes:

> Some of the long-outstanding bugs have a complicated history that is
> daunting to try to untangle and work out what the next step might be.
> Particularly when the history involves a heated debate which has apparently
> reached an uncomfortable stalemate.

> Regarding the last point: maybe at least some of these sorts of bugs could
> be brought to John's attention for arbitration?

Not just for those bugs; you can summon me for arbitration on any bug, if you
feel like a decision needs to be made. I read all bug reports, so mentioning
my name should be enough to catch my attention; or Cc: johnw@gnu.org, which
causes Gnus to show a character indicating that I've been directly copied.

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

Re: 4K Bugs

[Phillip Lord]

Alexis <flexibeast@gmail.com> writes:

> i've just recently installed the `debbugs` package myself, as part of trying
> to help out with bug triage. i rather like it overall, and find it less
> unwieldy than the Web UI - thanks to those who have put it together! Still, i
> too have had some issues:
>
> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>>  - After installing debbugs, there is no obvious entry  point. M-x 
>>    debugs-[tab] gives 30 different commands.
>
> Agreed; it took me a few moments to realise that debbugs-gnu was probably what
> i wanted.

Turns out that either "-gnu" or "-org" works fine. They just produce a
different UI. I think aliasing debbugs-gnu to debbugs would help.

>>  - debbugs-gnu list bugs from number 158 and upward; the entire  first
>> 500 is about emacs 23 pre-releases. If I want to get the    latest bugs,
>> they are on page 5.
>
> An argument could be made that the longest-outstanding issues should be
> displayed first, to try to encourage their resolution. Having said that, it
> could also be argued that their longevity means they're less likely to be able
> to be resolved soon than recent bugs. So i'm not sure what the best default is
> here.

I am very suspiscious about that. Most issue trackers are "most recent first".


>
>>  - On none of the debbugs pages are there any obvious menu items  or
>> bug-related functionality.
>
> Well, as usual in these situations, i used C-h m (`describe-mode`) to find out
> what i can do; but yes, it might be useful to at least have one or two lines
> of text describing at least some of the possible commands (and maybe also,
> what the colours in the `State` field indicate).
>
>>  - I found out about hitting "C" to send a control  message. Configuring
>> this to "mail client" and up pops thunderbird, although I am    a Gnus user.
>
> i'm a mu4e user, and when i try to send a control message .... Well, i'm not
> sure what happens. i get nothing to indicate a message was sent, but nothing
> to indicate it failed to be sent either. i can successfully use mu4e to reply
> to messages in the relevant bug thread, though.

And there is no where to practice! I might create a bug report just so I
can try setting some control messages on it.

> Finally, i'd like to suggest that the `debbugs` manual be renamed to something
> like `debbugs-dev`, and the `debbugs-ug` manual be renamed to `debbugs`. In
> trying to find out what the colours in the `State` field indicated, i ran the
> `info-display-manual` command and specified `debbugs`; the result ("Debbugs
> Programmers Manual") surprised me, and it took me a while to realise that
> there's a `debbugs-ug` ("Debbugs User Guide") manual. My guess is that many
> more people are going to want to use the latter than the former; hence my
> rename suggestion. Perhaps it might also be useful to link to the User Guide
> from the `debbugs` UI?

Yes, this makes sense to me also.

Phil

Re: 4K Bugs

[Michael Albinus]

Alexis <flexibeast@gmail.com> writes:

Hi Alexis,

Thank you also for your feedback.

>>  - After installing debbugs, there is no obvious entry  point. M-x
>>    debugs-[tab] gives 30 different commands.
>
> Agreed; it took me a few moments to realise that debbugs-gnu was
> probably what i wanted.

Again, there is the README.

>>  - Bugs marked as "done" and "unreproducible" are displayed by
>> default.
>
> i would certainly prefer that "done" and "unreproducible" bugs were
> not displayed by default.

As said, for bugs marked "done" this might be the better default. Bugs
marked "unreproducible" are prominent candidates to be marked also as
"done", therefore they shouldn't be suppressed I believe.

> Well, as usual in these situations, i used C-h m (`describe-mode`) to
> find out what i can do; but yes, it might be useful to at least have
> one or two lines of text describing at least some of the possible
> commands (and maybe also, what the colours in the `State` field
> indicate).

README, again. It covers the offered commands. The states are described
in the User Guide. I wanted to show them also by example, but I have no
idea how to colorize text in texinfo. Is this possible?

> i'm a mu4e user, and when i try to send a control message .... Well,
> i'm not sure what happens. i get nothing to indicate a message was
> sent, but nothing to indicate it failed to be sent either. i can
> successfully use mu4e to reply to messages in the relevant bug thread,
> though.

Yes, a short message "Control message foo sent" might beuseful. Will do.

> Finally, i'd like to suggest that the `debbugs` manual be renamed to
> something like `debbugs-dev`, and the `debbugs-ug` manual be renamed
> to `debbugs`. In trying to find out what the colours in the `State`
> field indicated, i ran the `info-display-manual` command and specified
> `debbugs`; the result ("Debbugs Programmers Manual") surprised me, and
> it took me a while to realise that there's a `debbugs-ug` ("Debbugs
> User Guide") manual. My guess is that many more people are going to
> want to use the latter than the former; hence my rename
> suggestion. Perhaps it might also be useful to link to the User Guide
> from the `debbugs` UI?

I've mentioned the User Guide in the README now. And in the Programmer's
Guide, I've added a link to the User Guide.

> Alexis.

Best regards, Michael.

Re: 4K Bugs

[Phillip Lord]

Michael Albinus <michael.albinus@gmx.de> writes:

> Alexis <flexibeast@gmail.com> writes:
>
> Hi Alexis,
>
> Thank you also for your feedback.
>
>>>  - After installing debbugs, there is no obvious entry  point. M-x
>>>    debugs-[tab] gives 30 different commands.
>>
>> Agreed; it took me a few moments to realise that debbugs-gnu was
>> probably what i wanted.
>
> Again, there is the README.

Worth remembering that "README" for debbugs is a file buried somewhere
in ~/.emacs.d/elpa.


> Yes, a short message "Control message foo sent" might beuseful. Will do.

>> Finally, i'd like to suggest that the `debbugs` manual be renamed to
>> something like `debbugs-dev`, and the `debbugs-ug` manual be renamed
>> to `debbugs`.
>
> I've mentioned the User Guide in the README now. And in the Programmer's
> Guide, I've added a link to the User Guide.


These are both good adds, thank you!

Re: 4K Bugs

[Michael Albinus]

phillip.lord@russet.org.uk (Phillip Lord) writes:

Hi Phillip,

>>>>  - After installing debbugs, there is no obvious entry  point. M-x
>>>>    debugs-[tab] gives 30 different commands.
>>>
>>> Agreed; it took me a few moments to realise that debbugs-gnu was
>>> probably what i wanted.
>>
>> Again, there is the README.
>
> Worth remembering that "README" for debbugs is a file buried somewhere
> in ~/.emacs.d/elpa.

Yes, but there is no better place for ELPA packages. You get this
information, if you klick on the package in the Package Manager.

Best regards, Michael.

Re: 4K Bugs

[Alexis]

Hi Michael,

Thanks for your response!

Michael Albinus <michael.albinus@gmx.de> writes:

> Again, there is the README.

i didn't even think to actively look for a distinct README! i 
typically look for such information by moving point to the package 
name in the `package-list-packages` list, then pressing RET 
(`describe-package`).  For the packages i maintain, doing so opens 
a buffer showing, amongst other things, the 'Commentary' section 
of the package headers, which is where i maintain user-level 
documentation. (i use the `el2markdown` package to create a 
README.md file from this section for GitHub.) When i do that for 
the `debbugs` package, the 'Commentary' section of `debbugs.el` 
isn't displayed at all, for some reason. And although 
`debbugs-gnu.el` does have an extensive 'Commentary' section, 
that's not accessible via `describe-package`.

At any rate, thanks for the heads-up about the README; i'll 
certainly remember to look for such docs in the future.

> As said, for bugs marked "done" this might be the better 
> default. Bugs marked "unreproducible" are prominent candidates 
> to be marked also as "done", therefore they shouldn't be 
> suppressed I believe.

*nod* Okay, good point.

> Yes, a short message "Control message foo sent" might 
> beuseful. Will do.

Thanks!

> I've mentioned the User Guide in the README now. And in the 
> Programmer's Guide, I've added a link to the User Guide.

Great, thank you. :-)


Alexis.

Re: 4K Bugs

[Michael Albinus]

Alexis <flexibeast@gmail.com> writes:

> Hi Michael,

Hi Alexis,

>> Again, there is the README.
>
> i didn't even think to actively look for a distinct README! i
> typically look for such information by moving point to the package
> name in the `package-list-packages` list, then pressing RET
> (`describe-package`).  For the packages i maintain, doing so opens a
> buffer showing, amongst other things, the 'Commentary' section of the
> package headers, which is where i maintain user-level
> documentation. (i use the `el2markdown` package to create a README.md
> file from this section for GitHub.) When i do that for the `debbugs`
> package, the 'Commentary' section of `debbugs.el` isn't displayed at
> all, for some reason. And although `debbugs-gnu.el` does have an
> extensive 'Commentary' section, that's not accessible via
> `describe-package`.

In my Emacs 25.0.50, `describe-package' shows the README of debbugs.

> Alexis.

Best regards, Michael.

Re: 4K Bugs

[Alexis]

Michael Albinus <michael.albinus@gmx.de> writes:

> In my Emacs 25.0.50, `describe-package' shows the README of 
> debbugs.

Ah okay, great. i'm using 24.5. Glad this is sorted!


Alexis.

Re: 4K Bugs

[Lars Magne Ingebrigtsen]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> I'm very late to this discussion, but inspired by Lar's bug fix spree I
> decided to see if I could have a go myself. I found the process a little
> confusing. Here are some points:
>
>  - After installing debbugs, there is no obvious entry point. M-x
>    debugs-[tab] gives 30 different commands.

Yeah, the `M-x' interface for discovering commands in Emacs sucks.
We've discussed before adding mechanisms for leaving mode-specific
commands out, but I was apparently the only one enthusiastic about
it... 

>  - The two shortest commands are debbugs-org and debbugs-gnu. The former
>    lists all the bugs for Org-Mode, and the latter Emacs. Why
>    debbugs-gnu and not debbugs-emacs? I don't know.

Good question.  debbugs-emacs would be a more logical name for the
command.

>  - debbugs-gnu list bugs from number 158 and upward; the entire first
>    500 is about emacs 23 pre-releases. If I want to get the latest bugs,
>    they are on page 5.

This has been fixed in the git version of debbugs.  It loads all the
bugs.

>  - Bugs marked as "done" and "unreproducible" are displayed by default.

Yeah, done bugs should probably be hidden by default.  I don't know
about unreproducible...  

>  - On none of the debbugs pages are there any obvious menu items or
>    bug-related functionality.

I don't quite follow.  Debbugs pages?

>  - I found out about hitting "C" to send a control message. Configuring
>    this to "mail client" and up pops thunderbird, although I am a Gnus
>    user.

That sounds like a bug.  `C' just uses the normal Emacs method for
sending email.  Have you configured Emacs to use Thunderbird to send
emails? 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Phillip Lord]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>  - The two shortest commands are debbugs-org and debbugs-gnu. The former
>>    lists all the bugs for Org-Mode, and the latter Emacs. Why
>>    debbugs-gnu and not debbugs-emacs? I don't know.
>
> Good question.  debbugs-emacs would be a more logical name for the
> command.
>
>>  - debbugs-gnu list bugs from number 158 and upward; the entire first
>>    500 is about emacs 23 pre-releases. If I want to get the latest bugs,
>>    they are on page 5.
>
> This has been fixed in the git version of debbugs.  It loads all the
> bugs.

Can you switch the sort order around, by default?


>
>>  - Bugs marked as "done" and "unreproducible" are displayed by default.
>
> Yeah, done bugs should probably be hidden by default.  I don't know
> about unreproducible...  
>
>>  - On none of the debbugs pages are there any obvious menu items or
>>    bug-related functionality.
>
> I don't quite follow.  Debbugs pages?

Sorry, the buffer you get when you type "debbugs-gnu".


>
>>  - I found out about hitting "C" to send a control message. Configuring
>>    this to "mail client" and up pops thunderbird, although I am a Gnus
>>    user.
>
> That sounds like a bug.  `C' just uses the normal Emacs method for
> sending email.  Have you configured Emacs to use Thunderbird to send
> emails?

No. C is asking me how I want to send the mail. I would be expecting it
just to be use message-mode and my normal config.

No worries if this is not the expected behaviour, I will debug it and
see what is happening.

Phil

Re: 4K Bugs

[Michael Albinus]

phillip.lord@russet.org.uk (Phillip Lord) writes:

>> This has been fixed in the git version of debbugs.  It loads all the
>> bugs.
>
> Can you switch the sort order around, by default?

Will do. That's easy to implement now, since we get all bugs at once (in
several chunks, hidden to you).

> Phil

Best regards, Michael.

Re: 4K Bugs

[Lars Magne Ingebrigtsen]

phillip.lord@russet.org.uk (Phillip Lord) writes:

>>>  - On none of the debbugs pages are there any obvious menu items or
>>>    bug-related functionality.
>>
>> I don't quite follow.  Debbugs pages?
>
> Sorry, the buffer you get when you type "debbugs-gnu".

Yeah, there should be a menu, as Michael said.

> No. C is asking me how I want to send the mail. I would be expecting it
> just to be use message-mode and my normal config.

If `C' is asking how to send an email, then your Emacs hasn't had its
email settings configured...

I.e., `send-mail-function' hasn't been set.  You may have configured the
`message-send-mail-function' instead if you're just sending mail from
Gnus...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Phillip Lord]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>>>>  - On none of the debbugs pages are there any obvious menu items or
>>>>    bug-related functionality.
>>>
>>> I don't quite follow.  Debbugs pages?
>>
>> Sorry, the buffer you get when you type "debbugs-gnu".
>
> Yeah, there should be a menu, as Michael said.
>
>> No. C is asking me how I want to send the mail. I would be expecting it
>> just to be use message-mode and my normal config.
>
> If `C' is asking how to send an email, then your Emacs hasn't had its
> email settings configured...
>
> I.e., `send-mail-function' hasn't been set.  You may have configured the
> `message-send-mail-function' instead if you're just sending mail from
> Gnus...

Ah, yes, that's the cause of the problem. 


Perhaps, "send-mail-query-once" should check if
message-send-mail-function is anything other than send-mail-query-once,
and signal an warning in this case.

Phil

Re: 4K Bugs

[Lars Magne Ingebrigtsen]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Perhaps, "send-mail-query-once" should check if
> message-send-mail-function is anything other than send-mail-query-once,
> and signal an warning in this case.

`send-mail-query-once' is a "lower level" function than
`message-send-mail-function' (which should be obsoleted, anyway)...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: 4K Bugs

[Stefan Monnier]

> Yeah, the `M-x' interface for discovering commands in Emacs sucks.
> We've discussed before adding mechanisms for leaving mode-specific
> commands out, but I was apparently the only one enthusiastic about
> it...

FWIW, part of the motivation to move M-x to Elisp was to make it easier
to experiment and/or provide alternate implementations as external packages.


        Stefan

Leaving out non-applicable commands on Mx (was: 4K Bugs)

[Óscar Fuentes]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>> I'm very late to this discussion, but inspired by Lar's bug fix spree I
>> decided to see if I could have a go myself. I found the process a little
>> confusing. Here are some points:
>>
>>  - After installing debbugs, there is no obvious entry point. M-x
>>    debugs-[tab] gives 30 different commands.
>
> Yeah, the `M-x' interface for discovering commands in Emacs sucks.

My experience with ido+flx is quite positive on this aspect, although it
could be made much better.

> We've discussed before adding mechanisms for leaving mode-specific
> commands out, but I was apparently the only one enthusiastic about
> it... 

You'll better run MemTest on your brain, because that is not accurate by
a long stretch. :-)

I suggested this feature and volunteered for doing the boring work
(annotating functions with their related modes). On that discussion,
others mentioned that it is an interesting idea.

You sketched a possible implementation. If you are interested on
completing the part that requires a smart hacker, I'll do the part that
requires a dumb one :-)

[snip]

Re: Leaving out non-applicable commands on Mx

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

>> We've discussed before adding mechanisms for leaving mode-specific commands
>> out, but I was apparently the only one enthusiastic about it...

> You sketched a possible implementation. If you are interested on completing
> the part that requires a smart hacker, I'll do the part that requires a dumb
> one :-)

What is this feature suggestion again?

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

Re: Leaving out non-applicable commands on Mx

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> We've discussed before adding mechanisms for leaving mode-specific commands
>>> out, but I was apparently the only one enthusiastic about it...
>
>> You sketched a possible implementation. If you are interested on completing
>> the part that requires a smart hacker, I'll do the part that requires a dumb
>> one :-)
>
> What is this feature suggestion again?

On the M-x prompt, the set of candidates is restricted to those that
make sense given the current context. Leaving out functions that are
specific to modes not enabled is a start. So if you are editing a C file
and press `M-x g' almost all gnus* functions shall not be considered as
candidates for completion.

This is important with advanced completion systems. An example: while
working on a org-mode file, if I wish to execute org-clock-report I can
use its binding: "C-c C-x C-r". With ido+flx, I can do "M-x ocr ENTER"
which, IMO, is superior on each and every aspect.

The M-x interface can be an improvement over both keybindings and the
menu on terms of usability, given the correct methods, but having
thousands of irrelevant candidates every time you invoke M-x is an
inconvenience for that goal, not to say plain dumb.

Re: Leaving out non-applicable commands on Mx

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

> On the M-x prompt, the set of candidates is restricted to those that make
> sense given the current context. Leaving out functions that are specific to
> modes not enabled is a start. So if you are editing a C file and press `M-x
> g' almost all gnus* functions shall not be considered as candidates for
> completion.

This sounds like a feature that should evolve first as a separate package in
ELPA, and after proving itself, be considered for core. But I sense ways in
which this could go wrong: expecting to find a command, failing for some
undiscovered reason X, and then the user believing no such command exists.

> The M-x interface can be an improvement over both keybindings and the menu
> on terms of usability, given the correct methods, but having thousands of
> irrelevant candidates every time you invoke M-x is an inconvenience for that
> goal, not to say plain dumb.

Core Emacs behavior doesn't need to change to demonstrate this feature, does
it? Write a new execute-extended-command and see if it works as well as you
hope.

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

Re: Leaving out non-applicable commands on Mx

[Spencer Boucher]

 
Smex (https://github.com/nonsequitur/smex/) has a similar function 
that limits to commands in the major mode 
(`smex-major-mode-commands`). 

John Wiegley writes:

>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes: 
> 
>> On the M-x prompt, the set of candidates is restricted to those 
>> that make sense given the current context. Leaving out 
>> functions that are specific to modes not enabled is a start. So 
>> if you are editing a C file and press `M-x g' almost all gnus* 
>> functions shall not be considered as candidates for completion. 
> 
> This sounds like a feature that should evolve first as a 
> separate package in ELPA, and after proving itself, be 
> considered for core. But I sense ways in which this could go 
> wrong: expecting to find a command, failing for some 
> undiscovered reason X, and then the user believing no such 
> command exists. 
> 
>> The M-x interface can be an improvement over both keybindings 
>> and the menu on terms of usability, given the correct methods, 
>> but having thousands of irrelevant candidates every time you 
>> invoke M-x is an inconvenience for that goal, not to say plain 
>> dumb. 
> 
> Core Emacs behavior doesn't need to change to demonstrate this 
> feature, does it? Write a new execute-extended-command and see 
> if it works as well as you hope.


-- Spencer Boucher

RE: Leaving out non-applicable commands on Mx

[Drew Adams]

> Smex (https://github.com/nonsequitur/smex/) has a similar function
> that limits to commands in the major mode
> (`smex-major-mode-commands`).

There you go!  Wish fulfilled, apparently.  Just use Smex to
get what you want.

Re: Leaving out non-applicable commands on Mx

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

>> Smex (https://github.com/nonsequitur/smex/) has a similar function
>> that limits to commands in the major mode
>> (`smex-major-mode-commands`).
>
> There you go!  Wish fulfilled, apparently.  Just use Smex to
> get what you want.

That's not it. I want to ignore commands that are *not* *applicable* to
the current *context*. That's quite a difference.

Re: Leaving out non-applicable commands on Mx

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> On the M-x prompt, the set of candidates is restricted to those that make
>> sense given the current context. Leaving out functions that are specific to
>> modes not enabled is a start. So if you are editing a C file and press `M-x
>> g' almost all gnus* functions shall not be considered as candidates for
>> completion.
>
> This sounds like a feature that should evolve first as a separate package in
> ELPA, and after proving itself, be considered for core. But I sense ways in
> which this could go wrong: expecting to find a command, failing for some
> undiscovered reason X, and then the user believing no such command exists.

This could ony happen if there is a mistake on how that command is
declared. A bug like any other.

>> The M-x interface can be an improvement over both keybindings and the menu
>> on terms of usability, given the correct methods, but having thousands of
>> irrelevant candidates every time you invoke M-x is an inconvenience for that
>> goal, not to say plain dumb.
>
> Core Emacs behavior doesn't need to change to demonstrate this feature, does
> it? Write a new execute-extended-command and see if it works as well as you
> hope.

It is necessary to annotate the functions with the context they are
suppossed to work on. Something like

(defun foo-something ()
  "docstring"
  (interactive)
  (declare this-applies-to-foo-mode)
  ...)

Doing that for every function is unnecessary work, so a method for
saying "all the functions defined on this .el file apply to foo-mode,
except foo-bar and foo-zoo" is a sensible enhancement. (We also could
exploit the fact that we know wich functions are autoladed. Most
autoloaded functions are context-free, while the non-autoloaded
functions on the same file are context-specific).

Maintaining all this information on an external resource is
unmanageable, it simply wont work. So yes, the Elisp source files need
to be annotated (that's the work I'm volunteering for).

For reading the annotations (and, possibly, for performance reasons,
applying the filter) modifications are required on some Emacs
infrastructure. From past discussion it seems that those modifications
are expected to be small, though.

RE: Leaving out non-applicable commands on Mx

[Drew Adams]

> It is necessary to annotate the functions with the context they are
> suppossed to work on. Something like
> 
> (defun foo-something ()
>   "docstring"
>   (interactive)
>   (declare this-applies-to-foo-mode)
>   ...)

(put 'foo-something 'applies-to-foo-mode)

Or maybe:

(put 'foo-something
     (cl-pushnew 'foo-mode (get 'foo-something 'applicable-modes)))

> Doing that for every function is unnecessary work, so a method for
> saying "all the functions defined on this .el file apply to foo-mode,
> except foo-bar and foo-zoo" is a sensible enhancement. (We also could
> exploit the fact that we know wich functions are autoladed. Most
> autoloaded functions are context-free, while the non-autoloaded
> functions on the same file are context-specific).
> 
> Maintaining all this information on an external resource is
> unmanageable, it simply wont work.

Why not?

> So yes, the Elisp source files need
> to be annotated (that's the work I'm volunteering for).

If you can annotate them then you can put those annotations
on their symbols as a property used by your new library, no?

> For reading the annotations (and, possibly, for performance reasons,
> applying the filter) modifications are required on some Emacs
> infrastructure. 

Why?  What's wrong with `(get SYMBOL 'applies-to-foo-mode)'?

Re: Leaving out non-applicable commands on Mx

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

[snip]

>> Maintaining all this information on an external resource is
>> unmanageable, it simply wont work.
>
> Why not?

Do I need to explain the difficulties of maintaining information about
the characteristics of a resource outside of where the resource is
defined?

[snip]

>> For reading the annotations (and, possibly, for performance reasons,
>> applying the filter) modifications are required on some Emacs
>> infrastructure. 
>
> Why?  What's wrong with `(get SYMBOL 'applies-to-foo-mode)'?

The filtering, on its most simplified implementation, would gather the
commands which are declared to be related to any active (major|minor)
mode on the current buffer, plus the commands that are not related to
any mode. Without a perceptible delay by the user. As an Emacs session
can reach tens of thousands of available commands, my guess is that some
new infrastructure (possibly at the C level) is required.

Re: Leaving out non-applicable commands on Mx

[Stefan Monnier]

> Doing that for every function is unnecessary work, so a method for
> saying "all the functions defined on this .el file apply to foo-mode,
> except foo-bar and foo-zoo" is a sensible enhancement. (We also could

This is the crucial part, indeed.

> Maintaining all this information on an external resource is
> unmanageable, it simply wont work.

It's better if it's managed directly in the packages's sources, indeed,
but it will still work if the info is only available for some packages,
and for many packages, this info could be managed externally with fairly
little harm.

So while I agree that the right way to do it is "in core", I think it'd
still be useful if packaged as a GNU ELPA package (or a bundled package
but fully self-contained).

Also, the new package could provide some function/macro which core
packages may use conditionally.  E.g. Gnus could "declare its
mode-specific commands" using this new macro/function (if/when defined),
so that it provides support for the "filtering-m-x" package.

> So yes, the Elisp source files need to be annotated (that's the work
> I'm volunteering for).

An important part of this work is on the design of the "annotation
system" so that it's lightweight.

E.g. ideally, this same annotation system should be able to wrap the
corresponding commands so that they signal an error if you happen to
trigger them in the wrong mode (currently many commands do such a check
by hand, so the annotation system could *replace* this manual test).
Being "able to" doesn't mean that it should necessarily do so, just that
the design would probably be better if it took into account such
related-but-slightly-different use-cases.


        Stefan

RE: Leaving out non-applicable commands on Mx

[Drew Adams]

> I sense ways in which this could go wrong: expecting to find
> a command, failing for some undiscovered reason X, and then
> the user believing no such command exists.

Yes.  And from the outset the user will have only a restricted
view of what commands are currently available, because an Emacs
developer will have made a priori assumptions about which commands
are currently appropriate.

If that's really important for some specific mode then it
is easy enough to implement that for a given mode.  It should
not be imposed on all of Emacs (e.g., via `M-x').

The specific command reading input should filter as is
appropriate for it, using a predicate - as has always been
the case.  And (IMHO), no such filter is appropriate for
`M-x', which should remain general.

Of course, nothing prevents someone from defining a command
similar to `M-x' but that is more restrictive in the sense
suggested (simple to do).  Just please don't bind it by
default to `M-x'.

> Core Emacs behavior doesn't need to change to demonstrate this
> feature, does it? Write a new execute-extended-command and see
> if it works as well as you hope.

Precisely (only please don't call it `execute-extended-command' ;-)).

RE: Leaving out non-applicable commands on Mx

[Drew Adams]

> On the M-x prompt, the set of candidates is restricted to those that
> make sense given the current context.

Not if a user invokes `M-x' to see which commands are currently
available in general, i.e., as a kind of interactive `apropos'.
(Especially if s?he can hit a key to get help about the command.)

Especially if you have an "advanced completion system" that
lets you (a) match command names more flexibly and (b) narrow
the matches using a succession of patterns.

> Leaving out functions that are
> specific to modes not enabled is a start.

And that's also a feature of some "advanced completion
systems".  But it should not (except by user option) be
the default behavior. The default behavior should be all
candidates matching the input patterns and the completion
predicate - no other "helpful" filtering unless requested
by the user.

The command calling `completing-read' or `read-file-name'
(or whatever) should get first shot at specifying the
filtering.  And it does that, as usual, with a predicate.

> So if you are editing a C file and press `M-x g' almost
> all gnus* functions shall not be considered as
> candidates for completion.

Yes they should, by default - unless a user has configured
a different behavior.

Emacs is smartest when it doesn't try to outsmart the user;
when it helps the user be smart instead of trying to
second-guess her.

It's about what the user wants, not what an Emacs developer
thinks is clever or is what the user must want.

But hey, I sympathize wrt the many matches of something
like `gnus'.  I filter those out by matching & tossing
them - unless I really want to see them for some reason.

Let the specific _command_, first, and the _user_ who
invokes it, second, filter out stuff that is not appropriate.

Please don't decide ahead of time (unless it's through a
specific command) what is appropriate and what is not.

> This is important with advanced completion systems.

See above about "advanced completion systems".

> An example: while working on a org-mode file, if I wish
> to execute org-clock-report I can use its binding:
> "C-c C-x C-r".  With ido+flx, I can do "M-x ocr ENTER"
> which, IMO, is superior on each and every aspect.

And?  Are you now suggesting that users and libraries
should not bind keys because you are convinced that your
"advanced completion system" is "superior on each and
every aspect"?  I hope not.

> The M-x interface can be an improvement over both keybindings and the
> menu on terms of usability, given the correct methods, but having
> thousands of irrelevant candidates every time you invoke M-x is an
> inconvenience for that goal, not to say plain dumb.

Thousands of candidates might be just what a user wants.
But more importantly is to let the _user_ choose which
100 or which 10 of the thousands s?he really wants to
interact with.

Please don't presume to guess, in some general way, how a
user might want to filter candidates.

Specific commands already can, and do, make such judgments
(e.g. only symbols bound to commands are candidates for `M-x).

Leave it up to the command (and to the user who chooses
to use that command) to make such a preliminary judgment.

And more importantly, leave it up to the user to decide
how to subsequently filter the preliminary candidates.

What Emacs could do to help is to:

1. Provide powerful and flexible ways to match, and to
combine multiple match patterns.

2. Provide command-specific keys to use during completion,
to let the user filter in ways that are helpful in the
context of that command.

As one example (and I'm sure there are plenty of others),
Icicles lets you narrow using any number of patterns,
each of which can be a regexp or a fuzzy-match of various
kinds.  You can exclude matches as well as including them.

And for buffer-name candidates, for example, you can use
keys to keep or remove the names of buffers in a derived
mode or a given mode or that are already displayed or not.

(You can even provide a filtering predicate interactively,
on the fly, to narrow candidates any fancy way you like.)

What Icicles offers is not the only way to help users
filter.  The point is to try to do that, not try to
guess, in some general way, what kind of filtering is
good for them for all commands.

The way to do what you suggest wrt commands that make
sense for a given mode ("leaving out functions that are
specific to modes not enabled is a start") is to let the
user hit a key to do this, i.e., to ask for it on demand,
not to impose it on everyone and everywhere by default.

Re: Leaving out non-applicable commands on Mx

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

[snip]

Instead of rehashing an old discussion, please first read it:

https://lists.gnu.org/archive/html/emacs-devel/2014-12/threads.html#00775

(search for "Ordering of command completions" and start reading the
first message by Lars).

Anyways, it doesn't make sense to discuss defaults for a feature that
does not exist yet. I'm interested on implementing it, not on making it
the default. That's something for the community to discuss once enough
experience is attained.

Re: Leaving out non-applicable commands on Mx

[Yuri Khan]

On Sat, Jan 9, 2016 at 9:08 AM, Drew Adams <drew.adams@oracle.com> wrote:

> And that's also a feature of some "advanced completion
> systems".  But it should not (except by user option) be
> the default behavior. The default behavior should be all
> candidates matching the input patterns and the completion
> predicate - no other "helpful" filtering unless requested
> by the user.

Emacs already contains a feature that filters out many defined
functions from M-x. It’s called (interactive). Functions that are not
declared interactive are not offered as completion candidates, and in
fact cannot be executed with M-x.

This proposal takes (interactive) to a new level, by allowing authors
to specify conditions under which a function should be considered
interactive.

True, some authors will get it wrong and specify too strict
conditions. They will eventually be fixed. Also, M-: is still there as
an escape hatch.

RE: Leaving out non-applicable commands on Mx

[Drew Adams]

> > And that's also a feature of some "advanced completion
> > systems".  But it should not (except by user option) be
> > the default behavior. The default behavior should be all
> > candidates matching the input patterns and the completion
> > predicate - no other "helpful" filtering unless requested
> > by the user.
> 
> Emacs already contains a feature that filters out many defined
> functions from M-x. It’s called (interactive). Functions that are not
> declared interactive are not offered as completion candidates, and in
> fact cannot be executed with M-x.

You are repeating what I said.  I said that it already filters
using the predicate appropriate for `M-x' (which is `commandp').

(And in the text you responded to I explicitly said "and the
completion predicate" - which for `M-x' is `commandp'.)

> This proposal takes (interactive) to a new level, by allowing authors
> to specify conditions under which a function should be considered
> interactive.

Authors can already do that for any command they author that
reads command names using completion.  They can restrict the
candidate commands to any set they like, using an appropriate
predicate.

That's different from saying that `M-x' should restrict
candidates to only commands that an Emacs developer has
decided, a priori, are the only ones appropriate for the
current context (e.g. mode, buffer, visibility spec, phase
of moon, ... whatever).

The predicate appropriate for `M-x', which can be used in
various ways by users and in many different contexts, is
`commandp'.

But nothing prevents an author from defining a different
command name-reading command that uses a different predicate.

And nothing prevents an author from defining a minibuffer
key that filters `M-x' candidates further (letting the user
decide whether to narrow choices that way).

And nothing prevents an author from binding
`minibuffer-completion-predicate' to a predicate of choice.
Or of binding a completion key (even `TAB') to a command
like `minibuffer-complete' but that uses a different
predicate or that binds `minibuffer-completion-predicate'.

There are all kinds of ways for an author to impose a
different set of command-name completion candidates.

Making `interactive' conditional (was: Leaving out non-applicable commands on Mx)

[John Wiegley]

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

>>>>> Yuri Khan <yuri.v.khan@gmail.com> writes:

> Emacs already contains a feature that filters out many defined functions
> from M-x. It’s called (interactive). Functions that are not declared
> interactive are not offered as completion candidates, and in fact cannot be
> executed with M-x.

OK Yuri, now you've got me excited. Let's not talk about "filtering M-x";
let's talk about making `interactive' conditional. The former is a UI concern,
while the latter I consider a core API issue.

Right now, functions are interactive if declared with `interactive', and not
otherwise. The suggestion at hand is to allow `interactive' forms to become
conditional -- possibly in multiple ways. I like this concept, and think the
right place for it is indeed in core.

The question is how to declare such conditionality. We can do this rather
easily by accepting new keyword arguments to `interactive':

    (interactive "sDirectory: " [:mode foo-mode] [:when <function>])

This way, all new modes can take advantage of this support as it becomes
available. I've already tested on 24.5, and keyword arguments are silently
ignored by present-day GNU Emacs. This gives us transparent compatibility in
both directions. We could also do it with (declare); I'm open to that too, and
it also gives us such compatibility.

At first, I imagine nothing delivered with Emacs will be conditional, because
it requires annotating packages retroactively. We could alleviate some of that
by writing code to automatically consider every interactive function *without
an autoload token* as being conditional on any modes defined in the same
package (likely determined by prefix matching). The use of such automation
would be configurable and off by default, at least until we believe it's ready
for prime-time.

Thus, proper UI behavior for M-x falls out by design, and we get to make use
of conditionality for other purposes, such as better errors when command
functions are called outside their expected environment.

I'm open to a feature branch implementing such conditionality, as a candidate
for merging to master. As described above, I expect the C code impact to be
fairly minimal, and the changes to `M-x' to also be minor. The automation
logic seems like the trickiest part, as it would have to happen whenever a
feature is loaded.

-- 
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 --]

RE: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx)

[Drew Adams]

> Let's not talk about "filtering M-x"; let's talk about making
> `interactive' conditional. The former is a UI concern, while the
> latter I consider a core API issue.
> 
> Right now, functions are interactive if declared with `interactive', and
> not otherwise. The suggestion at hand is to allow `interactive' forms to
> become conditional -- possibly in multiple ways. I like this concept,
> and think the right place for it is indeed in core.
> 
> The question is how to declare such conditionality. We can do this rather
> easily by accepting new keyword arguments to `interactive':
>     (interactive "sDirectory: " [:mode foo-mode] [:when <function>])
> 
> This way, all new modes can take advantage of this support as it becomes
> available. I've already tested on 24.5, and keyword arguments are silently
> ignored by present-day GNU Emacs. This gives us transparent compatibility
> in both directions. We could also do it with (declare); I'm open to that too,
> and it also gives us such compatibility.

Is this supposed to affect `interactive' only for minibuffer
input that is read with completion?  If not then it's no longer
just about filtering completion candidates.

And in that case, just what is conditional?  And what about
interactive uses that do not read input at all?  Does it apply
to those cases also?

Are you perhaps suggesting that a given function would not be
a command (not interactive) when the given conditions are not
satisfied?

If so, does that mean that a predicate such as `commandp' would
also test the given conditions in the current context, i.e.,
generally (no matter how/where that predicate is invoked)?

What kinds of predicates (conditions) would be allowed here?

I guess:

. You've indicated (in effect) testing the current mode, which
  amounts to a predicate that accepts the mode as argument and
  tests with `eq' against the specified `:mode'.

. You've indicated that an arbitrary function could be provided
  (after `:when').  It seems this would thus not be a predicate
  that is applied to an _individual_ completion candidate.  So
  if you wanted to use it to filter candidates then it would
  presumably need to invoke `all-completions' (or equivalent)
  for null input ("") to get all of the initial candidates, and
  then explicitly filter them.

Is that what you are suggesting?  What you describe is not yet
clear, to me at least.

> At first, I imagine nothing delivered with Emacs will be conditional,
> because it requires annotating packages retroactively.

Doesn't it ("just") require changing `interactive' specs
wherever you want this?

> We could alleviate some of that by writing code to automatically
> consider every interactive function *without an autoload token* as
> being conditional on any modes defined in the same package (likely
> determined by prefix matching).

So you would take the proposal about additional `M-x' filtering
and extend it past `M-x' to all uses of interactive functions?

A priori, the arguments I cited against doing this for `M-x'
would apply a fortiori for such a general treatment.  But it's
all too vague for the moment to guess what the consequences
really might be.

In general, my view is:

. If it gives library authors more control over the behavior,
  not less, then it's likely a good thing.

. If it gives users even more control over the behavior then
  that's likely even better.

. If instead it hard-codes behavior decided ahead of time by
  Emacs Dev then it's likely not such a good thing.

> The use of such automation would be configurable

How?  By whom?  When? (user options? runtime interactively?)

> I'm open to a feature branch implementing such conditionality,

Could you please specify it first, at least in some more
detail than what you've described so far?

I'd start with the question: What is the aim?  What is the
real problem that you want to fix, or the needed missing
feature that you want to provide?  IOW, what's it for? what
good is it?

RE: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx)

[Drew Adams]

I do think that there can be some value in letting commands,
such as `M-x', that provide completion for command names,
take invocation-context information into account.

I think we should be more specific about what is involved -
how this is done.  And I think we should be more flexible
than what I've heard proposed so far.  In particular, we
should be flexible about how such invocation-context info
can be provided and used.

Let me make a hopefully more constructive contribution to
the suggestions about this than what I've written so far.

Here's how I see such a new feature.

1.  It would:

    a. Provide information about a specific command
       regarding its invocation contexts.

       This info can indicate which contexts "make sense" or
       which do not.  But it can also indicate anything else
       about a context in which one might try to invoke the
       command.

       The form of the info would be a Lisp sexp, and a
       value of nil would be equivalent to an absence (no
       context information).

       Its interpretation would be up to (1b) - no fixed
       or predefined interpretation.

    b. Use this information in `M-x', and possibly in other
       contexts.

       (I'll write `M-x' for short, but this should be
       understood as any context that uses the (1a) info.
       And even when thinking of it as `M-x, understand a
       new, `M-x'-like command.)

2.  (1a) and (1b) are two different things, and we need not
    be rigid about either their relationship or just how
    `M-x' or other contexts might use the (1a) info.

3.  The (1a) info can be a predicate that `M-x' can apply to
    each completion candidate.  It can use the resulting
    value to remove the candidate or to display it
    differently or to do something else that is specific to
    it.  Likewise for any other (1b) context: it is up to
    that context to do with info (1a) whatever it wants.

4.  The (1a) info could be something other than a predicate
    and nil.  This is left unspecified, but it should not be
    assumed that it is always a function.

5.  A predicate return value of nil, or an absence of (1a)
    info for a given candidate, would mean treat the command
    candidate normally (classically).  A non-nil return
    value would mean treat it specially in some way - see (3).

6.  The predicate can test anything.  It should be possible
    to invoke it with any number of arguments, which are
    unspecified.  It can access the target command's symbol
    as the value of variable `current-cmd' (or some better
    name).  (We could require passing the command as a first
    argument, but that would make using some existing
    predicates more cumbersome.)

7.  It should be easy to add, modify, or remove info (1a)
    from a command using Lisp at any time, and without
    modifying or otherwise accessing the source code that
    defines the command.

8.  The command's `interactive' spec is not the right place
    to provide the (1a) info (e.g. predicate).  This is not
    about interactive use in general.  It is info about
    invocation contexts.  A `declare' form is also the wrong
    place for the (1a) info.

    It should be possible to create or remove such an
    association in source code but also interactively (e.g.,
    using `M-:').

9.  I propose putting info (1a) on the command symbol as a
    property.  This is a limitation only for commands not
    associated with a name (which are not used by `M-x', at
    least).  Example:

    (put 'kill-line
         'cmd-context
         (lambda (cmd) (not buffer-read-only)))

    This association is purposely separate from the defun.

10. `execute-extended-command' (`M-x') would provide its
    usual behavior by default.  A user option would let it
    take info (1a) into account.  Later, the default
    behavior (and default option value) could be switched if
    we decide that is better.

11. We can provide a minibuffer key, when `M-x' is used, to
    toggle the option value (for (a) the `M-x' duration or
    (b) definitively, so that it effects subsequent `M-x').
    A user might do this for clarity, or to see more context
    info or more candidates, or to improve performance if
    taking (1a) info into account slows things down
    appreciably.

12. When `M-x' takes info (1a) into account, it treats a
    completion-candidate command name specially if info (1a)
    is present, according to the value of a user option
    (e.g., `cmd-context').  Possible behaviors could
    include:

    . Removing the command as a completion candidate if info
      (1a) is a predicate and invoking it returns nil.

    . Showing the (1a) info (e.g., the predicate sexp or
      symbol) next to the candidate command in
      *Completions*, as an annotation.

    . Displaying the candidate in a different face according
      to the nature of info (1a).  E.g., if a predicate and
      invoking it returns nil, then dim the candidate.

13. Since a given (1b) context such as `M-x' can do anything
    it likes with (1a) info, it could, in particular, handle
    that info differently depending on the current set of
    completion candidates.  For example, it could
    automatically turn off taking (1a) info into account
    when the number of candidates is particularly large or
    small.

14. If a (1b) context such as `M-x' wants to improve
    performance by, say, byte-compiling a (1a) predicate, it
    can do so, but it must not replace the source (1a)
    value, which should remain a Lisp sexp.  This is so we
    keep things flexible and we do not shut the door on
    possible uses of info (1a).

Re: Making `interactive' conditional

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> Right now, functions are interactive if declared with `interactive', and not
> otherwise. The suggestion at hand is to allow `interactive' forms to become
> conditional -- possibly in multiple ways. I like this concept, and think the
> right place for it is indeed in core.
>
> The question is how to declare such conditionality. We can do this rather
> easily by accepting new keyword arguments to `interactive':
>
>     (interactive "sDirectory: " [:mode foo-mode] [:when <function>])

That does sound kinda exciting.  To take a random example, `M-x
delete-matching-lines' could have a :when of `buffer-writable-p' and not
auto-complete when in a read-only buffer.  Etc.

> This way, all new modes can take advantage of this support as it becomes
> available. I've already tested on 24.5, and keyword arguments are silently
> ignored by present-day GNU Emacs. This gives us transparent compatibility in
> both directions.

Does this also work when transforming (interactive) without parameters,
or do we need to put a nil in there?

> We could also do it with (declare); I'm open to that too, and it also
> gives us such compatibility.

I think the interactive with keywords sounds nice, but both are fine by
me...

> At first, I imagine nothing delivered with Emacs will be conditional, because
> it requires annotating packages retroactively. We could alleviate some of that
> by writing code to automatically consider every interactive function *without
> an autoload token* as being conditional on any modes defined in the same
> package (likely determined by prefix matching). The use of such automation
> would be configurable and off by default, at least until we believe it's ready
> for prime-time.

Hm...  I think that sounds a bit too magical to be workable in general.
I may be wrong, but I think that would probably lead to undesirable side
effects (i.e., commands that should be available globally not being
available).

Magic is nice if you can get it to work, but explicit marking is
flexible.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making `interactive' conditional

[Clément Pit--Claudel]

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

On 01/10/2016 04:02 AM, Lars Magne Ingebrigtsen wrote:
> John Wiegley <jwiegley@gmail.com> writes:
> 
>> Right now, functions are interactive if declared with `interactive', and not
>> otherwise. The suggestion at hand is to allow `interactive' forms to become
>> conditional -- possibly in multiple ways. I like this concept, and think the
>> right place for it is indeed in core.
>>
>> The question is how to declare such conditionality. We can do this rather
>> easily by accepting new keyword arguments to `interactive':
>>
>>     (interactive "sDirectory: " [:mode foo-mode] [:when <function>])
> 
> That does sound kinda exciting.  To take a random example, `M-x
> delete-matching-lines' could have a :when of `buffer-writable-p' and not
> auto-complete when in a read-only buffer.  Etc.

I think this is converging to what Stefan pointed earlier (which I found very convincing/exciting): in its most basic form, this proposal could supersede a lot of ad-hoc checking that many many commands do (by calling `barf-if-buffer-read-only', for example).

Similarly, there are many commands that are marked interactive because they are bound to keys in certain contexts, but make no sense (and will just immediately error out if called from M-x) otherwise. I find it reasonable to think that if a command is just going to exit in error as soon as I call it I probably don't want it to feature prominently among M-x completions.

Cheers,
CLément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: Making `interactive' conditional

[Drew Adams]

> I think this is converging to what Stefan pointed earlier (which I found
> very convincing/exciting): in its most basic form, this proposal could
> supersede a lot of ad-hoc checking that many many commands do (by calling
> `barf-if-buffer-read-only', for example).

Those commands still need to do that in their bodies, for the same
reason that a command does it in the body today, even when it might
also do it in the `interactive' form (e.g., to prevent further
processing of an `interactive' form that reads multiple inputs).

Regardless of how or where or why such a function is invoked, it
needs to raise such an error and let the user know what the
invocation problem is.

Preventing a function from being calling incorrectly (in your view)
interactively does not prevent it from being called incorrectly (in
your view) non-interactively.

> Similarly, there are many commands that are marked interactive because
> they are bound to keys in certain contexts, but make no sense (and will
> just immediately error out if called from M-x) otherwise.

The way we handle that normally is for such keys to be bound in a
mode map.  If you are in that mode then they are bound to those
context-specific commands; otherwise, no.

In such a case it makes sense to not make those commands available
on key bindings outside of the mode.

That rationale is entirely absent for the case of `M-x', which is
(and should be) completely general.

Leave it to the context-defining mode to decide whether a given
command should be bound in that context.  Don't cripple `M-x'.

> I find it reasonable to think that if a command is just going to
> exit in error as soon as I call it I probably don't want it to
> feature prominently among M-x completions.

1. But the proposal now being considered goes far beyond not
   showing it as a command-name completion for `M-x'.  It is no
   longer about the possibility of _completion_ but is instead
   about the possibility of _invocation_ - in any way (IIUC).

2. Sometimes a user wants to see what commands exist (e.g. match
   a given pattern), whether or not a given command can be used
   in the current context.

   Completion lets you see what the matching command names are,
   irrespective of whether you might want to invoke a particular
   one - or any one.

   It is up to the particular _command that is completing_
   function names to match input to decide whether to remove
   some names from the outset.

   `M-x' is one particular command that completes function names.

   But it is the most general command-invoking command we have.
   It should not filter beyond `commandp' at the outset.  But a
   user could well be given minibuffer keys that let the _user_
   filter `M-x' candidates in additional ways.

3. A user might well _want_ to see the specific error message,
   in particular because it might not be obvious _why_ (in your
   view) a given command name is not available as a candidate.

   Making `M-x' filter out certain candidates beforehand tells
   the user _nothing_ about (a) whether such commands exist or
   (b) why they are currently considered unavailable.  IOW,
   less help for a user.

Re: Making `interactive' conditional

[Artur Malabarba]

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

On Jan 10, 2016 7:02 AM, "Lars Magne Ingebrigtsen" <larsi@gnus.org> wrote:
>
> John Wiegley <jwiegley@gmail.com> writes:
> >
> > The question is how to declare such conditionality. We can do this
rather
> > easily by accepting new keyword arguments to `interactive':
> >
> >     (interactive "sDirectory: " [:mode foo-mode] [:when <function>])
>
> That does sound kinda exciting.  To take a random example, `M-x
> delete-matching-lines' could have a :when of `buffer-writable-p' and not
> auto-complete when in a read-only buffer.  Etc.

I like this too.
One minor detail: I think I would invert the second keyword (i.e., use
:unless or :error-if, instead of :when). This way the return value of the
function could be used as the error message.

> > We could alleviate some of that
> > by writing code to automatically consider every interactive function
*without
> > an autoload token* as being conditional on any modes defined in the same
> > package (likely determined by prefix matching).
>
> Hm...  I think that sounds a bit too magical to be workable in general.
> I may be wrong, but I think that would probably lead to undesirable side
> effects

I agree with Lars, we shouldn't overdo this with magical guesswork. There
are plenty of commands which work outside their major mode. I think that
the point of this feature would be to remove from completion (or signal a
friendly error) commands that would be guaranteed to error out (probably in
some enigmatic way) if invoked outside the expected context.

This includes, for instance, the package-menu commands, which will
immediately barf if the current buffer doesn't contain a tabulated list of
packages.

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

Re: Making `interactive' conditional

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think it is a bad idea to make the interactive nature of a command
conditional.  If the user types a command's name after M-x,
it should always call the command.

I think it is reasonable to omit commands from M-x's completion,
but refusing to run them is going to far in imposing on the user.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Making `interactive' conditional

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I think it is reasonable to omit commands from M-x's completion,
> but refusing to run them is going to far in imposing on the user.

We could provide some sort of mechanism to allow running even if the
mode/predicate says we shouldn't, but I'm not sure that's all that
helpful.

For instance, if it's a command that doesn't run in read-only buffers
(that today has `barf-if-read-only' in the code of the command) has a
:when predicate that says the same thing, does it make sense to offer
the user to override that just because it's now been lifted up to the
`interactive' declaration?

Perhaps it does.  I'm not sure, though.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making `interactive' conditional

[Stefan Monnier]

> That does sound kinda exciting.  To take a random example, `M-x
> delete-matching-lines' could have a :when of `buffer-writable-p' and not
> auto-complete when in a read-only buffer.  Etc.

I'd be wary of going too far down that road: I often want to modify
read-only buffers 'cause I hadn't realized they're still read-only.
In that case, not finding the command in M-x would make me lose a lot
more time (looking for the damn command, under the assumption that
I just misremember it) than getting a clear "beep!  buffer is
read-only!" after which I can C-x C-q and move on.

> Hm...  I think that sounds a bit too magical to be workable in general.

That's exactly what I thought when I read the suggestion to omit
delete-matching-lines in read-only buffers.


        Stefan

Re: Making `interactive' conditional

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That does sound kinda exciting.  To take a random example, `M-x
>> delete-matching-lines' could have a :when of `buffer-writable-p' and not
>> auto-complete when in a read-only buffer.  Etc.
>
> I'd be wary of going too far down that road: I often want to modify
> read-only buffers 'cause I hadn't realized they're still read-only.
> In that case, not finding the command in M-x would make me lose a lot
> more time (looking for the damn command, under the assumption that
> I just misremember it) than getting a clear "beep!  buffer is
> read-only!" after which I can C-x C-q and move on.
>
>> Hm...  I think that sounds a bit too magical to be workable in general.
>
> That's exactly what I thought when I read the suggestion to omit
> delete-matching-lines in read-only buffers.

Your example looks quite convincing to me, and objections on that line
were made by others on previous messages. However, applying
`delete-matching-lines' to a dired buffer or a gnus summary buffer and
obtaining "beep! buffer is read only!" as an answer is not very helpful,
nor the user would consciously apply that command to that kind of
buffer, so I still think that decorating delete-matching-lines with a

(and (not read-only) visiting-file)

condition makes sense. That is, the feature is useful, but its use is
not so straightforward as with the mode-related conditions.

Apart from that, the :when key, if intended as a general predicate,
makes me worry about its performance impact.

RE: Making `interactive' conditional

[Herring, Davis]

> (and (not read-only) visiting-file)

So now you can't invoke it in *scratch*?

Of course, you can come up with another refinement to the condition (e.g., mode-class).  My point is merely that writing these predicates is very subtle when the standard is not "is this command likely to work when invoked" (in which case you wouldn't be bothering with "visiting-file") but rather "is the user plausibly looking for this command in the list".

Davis

Re: Making `interactive' conditional

[Óscar Fuentes]

"Herring, Davis" <herring@lanl.gov> writes:

>> (and (not read-only) visiting-file)
>
> So now you can't invoke it in *scratch*?

I don't expect to use Lisp predicates, no. Allowing those when the
filtering is executed has unbounded time complexity.

> Of course, you can come up with another refinement to the condition
> (e.g., mode-class). My point is merely that writing these predicates
> is very subtle when the standard is not "is this command likely to
> work when invoked" (in which case you wouldn't be bothering with
> "visiting-file") but rather "is the user plausibly looking for this
> command in the list".

Filtering out editing commands when the buffer is not meant to be edited
in any case enters into the "the user plausibly is not looking for this
command" category.

RE: Making `interactive' conditional

[Herring, Davis]

>>> (and (not read-only) visiting-file)
>>
>> So now you can't invoke it in *scratch*?
>
> I don't expect to use Lisp predicates, no. Allowing those when the
> filtering is executed has unbounded time complexity.

I didn't mean "the object that describes the applicability conditions is not a form"; I meant that a command defined with that constraint would not be usable in *scratch* because it would fail the "visiting-file" condition.

> Filtering out editing commands when the buffer is not meant to be edited
> in any case enters into the "the user plausibly is not looking for this
> command" category.

Like `kill-line', which is totally useless in a read-only buffer, right?

Again, I'm not claiming these problems are insurmountable -- just that it's very hard to get right, because the exceptional cases are numerous.

Davis

Re: Making `interactive' conditional

[Óscar Fuentes]

"Herring, Davis" <herring@lanl.gov> writes:

>>>> (and (not read-only) visiting-file)
>>>
>>> So now you can't invoke it in *scratch*?
>>
>> I don't expect to use Lisp predicates, no. Allowing those when the
>> filtering is executed has unbounded time complexity.
>
> I didn't mean "the object that describes the applicability conditions
> is not a form"; I meant that a command defined with that constraint
> would not be usable in *scratch* because it would fail the
> "visiting-file" condition.

Well, if *scratch* is read-only, then yes, the command will not appear
on the M-x list.

>> Filtering out editing commands when the buffer is not meant to be edited
>> in any case enters into the "the user plausibly is not looking for this
>> command" category.
>
> Like `kill-line', which is totally useless in a read-only buffer,
> right?

kill-line has a documented function when the buffer is read-only, so it
is not an editing command in the sense discussed above.

> Again, I'm not claiming these problems are insurmountable -- just that
> it's very hard to get right, because the exceptional cases are
> numerous.

I wouldn't say "very hard", but "requiring attention". No doubt there
will be cases with wrong annotations, but those will be eventually
corrected, like happens with every other feature. And those bugs are not
hard to fix nor critical, because the user will be able to find the
command by disabling the filtering, in case it was active.

Re: Making `interactive' conditional

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'd be wary of going too far down that road: I often want to modify
> read-only buffers 'cause I hadn't realized they're still read-only.
> In that case, not finding the command in M-x would make me lose a lot
> more time (looking for the damn command, under the assumption that
> I just misremember it) than getting a clear "beep!  buffer is
> read-only!" after which I can C-x C-q and move on.

Yes, that's true...  Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making `interactive' conditional

[Clément Pit--Claudel]

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

On 01/10/2016 04:02 AM, Lars Magne Ingebrigtsen wrote:
> John Wiegley <jwiegley@gmail.com> writes:
> 
>> Right now, functions are interactive if declared with `interactive', and not
>> otherwise. The suggestion at hand is to allow `interactive' forms to become
>> conditional -- possibly in multiple ways. I like this concept, and think the
>> right place for it is indeed in core.
>>
>> The question is how to declare such conditionality. We can do this rather
>> easily by accepting new keyword arguments to `interactive':
>>
>>     (interactive "sDirectory: " [:mode foo-mode] [:when <function>])
> 
> That does sound kinda exciting.  To take a random example, `M-x
> delete-matching-lines' could have a :when of `buffer-writable-p' and not
> auto-complete when in a read-only buffer.  Etc.

It seems interactive already has support for a limited version of this:

  > If ‘*’ appears at the beginning of the string, then an error is signaled if the buffer is read-only. 

So the annotation is already there, at least for some function that use a string-based interactive spec. But maybe everyone already had this in mind? (450 of the approx 4500 string-based interactive specs in core Emacs use that)

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx)

[Alan Mackenzie]

Hello, John.

On Sat, Jan 09, 2016 at 12:55:28PM -0800, John Wiegley wrote:
> >>>>> Yuri Khan <yuri.v.khan@gmail.com> writes:

> > Emacs already contains a feature that filters out many defined functions
> > from M-x. It’s called (interactive). Functions that are not declared
> > interactive are not offered as completion candidates, and in fact cannot be
> > executed with M-x.

> OK Yuri, now you've got me excited. Let's not talk about "filtering M-x";
> let's talk about making `interactive' conditional. The former is a UI concern,
> while the latter I consider a core API issue.

What you're proposing is exactly "filtering M-x"; censoring it, if you
will; a sort of "not in front of the children" attitude that restricts
what you can see by somebody else's criteria.  I think most people on
this list would be opposed to censorship in most areas (for example,
national authorities deciding what part of the WWW is suitable for
browsing).  Yet, here we are, talking about introducing the same sort of
thing into Emacs.

This might be OK if the only reason you every use M-x is to execute a
command.  But it's not.  People (in particular, me) use it to discover
Emacs, to find the exact name of a command which has only vaguely
embedded itself in the memory, to get this name into the kill ring to be
yanked into another source file or into documentation, and so on.  Try
M-x <tab> <prior> sometime, and explore the wealth of Emacs commands.
:-)

> Right now, functions are interactive if declared with `interactive', and not
> otherwise. The suggestion at hand is to allow `interactive' forms to become
> conditional -- possibly in multiple ways. I like this concept, and think the
> right place for it is indeed in core.

If it is to be implemented, then the right place is indeed in core.  But
just because we can implement it doesn't mean we should.  It would add,
marginally, to the complexity of Emacs, to the difficulty of learning
it.  What do we gain that would offset this loss?  What is this feature
for?

People have suggested filtering by mode, by read-onliness, and so on.
Somebody (I think it was Artur M.) even suggested removing initial
checks from commands, on the grounds that M-x filtering would render it
unneeded.  I don't think that could ever be the case.

> The question is how to declare such conditionality. We can do this rather
> easily by accepting new keyword arguments to `interactive':

>     (interactive "sDirectory: " [:mode foo-mode] [:when <function>])

> This way, all new modes can take advantage of this support as it becomes
> available. I've already tested on 24.5, and keyword arguments are silently
> ignored by present-day GNU Emacs. This gives us transparent compatibility in
> both directions. We could also do it with (declare); I'm open to that too, and
> it also gives us such compatibility.

> At first, I imagine nothing delivered with Emacs will be conditional, because
> it requires annotating packages retroactively. We could alleviate some of that
> by writing code to automatically consider every interactive function *without
> an autoload token* as being conditional on any modes defined in the same
> package (likely determined by prefix matching).

At which point I see the complexity rapidly increasing, unforeseen Bad
Things happening, and generally a lot of pain.

> The use of such automation would be configurable and off by default,
> at least until we believe it's ready for prime-time.

_ANY_ form of censorship must be optional, and not merely up to the
point where some authority decides it's acceptable to impose on the
masses.

> Thus, proper UI behavior for M-x falls out by design, and we get to make use
> of conditionality for other purposes, such as better errors when command
> functions are called outside their expected environment.

Any chance of an example of such an improvement?  How are we to improve
on, for example, "Can't execute - not in Foo mode"?

> I'm open to a feature branch implementing such conditionality, as a candidate
> for merging to master. As described above, I expect the C code impact to be
> fairly minimal, and the changes to `M-x' to also be minor. The automation
> logic seems like the trickiest part, as it would have to happen whenever a
> feature is loaded.

Again, what is this feature for?  Is it going to make editing easier for
experienced users?  Is it really going to attract new users, ones who
would be very happy in Emacs but for the huge number of commands
presented to them in an M-x?

I'm sceptical on both counts.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Making `interactive' conditional

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

>> OK Yuri, now you've got me excited. Let's not talk about "filtering M-x";
>> let's talk about making `interactive' conditional. The former is a UI concern,
>> while the latter I consider a core API issue.
>
> What you're proposing is exactly "filtering M-x"; censoring it, if you
> will; a sort of "not in front of the children" attitude that restricts
> what you can see by somebody else's criteria.  I think most people on
> this list would be opposed to censorship in most areas (for example,
> national authorities deciding what part of the WWW is suitable for
> browsing).  Yet, here we are, talking about introducing the same sort of
> thing into Emacs.

The amount of drama an hyperbole in emacs-devel never ceases to surpass
my expectations. On any other place I would read your commentary as
tongue-in-cheek, but not in emacs-devel, I'm afraid... :-)

> This might be OK if the only reason you every use M-x is to execute a
> command.  But it's not.  People (in particular, me) use it to discover
> Emacs, to find the exact name of a command which has only vaguely
> embedded itself in the memory, to get this name into the kill ring to be
> yanked into another source file or into documentation, and so on.  Try
> M-x <tab> <prior> sometime, and explore the wealth of Emacs commands.
> :-)

The current implementation of M-x is, possibly, the worst way of
exploring the wealth of Emacs commands. M-x is for *executing* commands,
not for learning about them (unless your learning method consists on
executing commands you don't know about). C-h f, the fine manual or,
better, browsing the sources is what I would do (and have done) for
exploring what Emacs has to offer.

Besides, if you insist on using M-x for learning about new commands, I
suppose that having only those that apply to your current context is
helpful, to say the least.

[snip]

> _ANY_ form of censorship must be optional, and not merely up to the
> point where some authority decides it's acceptable to impose on the
> masses.

To be on the safe side, I propose that we involve the EFF, Amnesty
International, Reporters Without Borders and the Council of Europe,
among others, as overseers of this process.

>> Thus, proper UI behavior for M-x falls out by design, and we get to make use
>> of conditionality for other purposes, such as better errors when command
>> functions are called outside their expected environment.
>
> Any chance of an example of such an improvement?  How are we to improve
> on, for example, "Can't execute - not in Foo mode"?
>
>> I'm open to a feature branch implementing such conditionality, as a candidate
>> for merging to master. As described above, I expect the C code impact to be
>> fairly minimal, and the changes to `M-x' to also be minor. The automation
>> logic seems like the trickiest part, as it would have to happen whenever a
>> feature is loaded.
>
> Again, what is this feature for?  Is it going to make editing easier for
> experienced users?  Is it really going to attract new users, ones who
> would be very happy in Emacs but for the huge number of commands
> presented to them in an M-x?

How user-friendly is to type M-x and be offered with thousands of
commands that have zero relation to the task you are performing? Some of
those commands can cause undesirable effects if you invoke them by
accident, I experienced that as a beginner and is very confusing.

Talking about discoverability and your M-x learning method, if I'm
interested on learning what can I do while editing a C file, how does
help me having to skim over thousands upon thousands of unrelated
commands that only make sense for their respective modes?

Why we hide the menus of the modes that are not active for the current
buffer? Why we have local keymaps? Where were you at the time those
repressing features were imposed on the masses?

RE: Making `interactive' conditional

[Drew Adams]

> > This might be OK if the only reason you every use M-x is to execute a
> > command.  But it's not.  People (in particular, me) use it to discover
> > Emacs, to find the exact name of a command which has only vaguely
> > embedded itself in the memory, to get this name into the kill ring to be
> > yanked into another source file or into documentation, and so on.  Try
> > M-x <tab> <prior> sometime, and explore the wealth of Emacs commands.
> > :-)
> 
> The current implementation of M-x is, possibly, the worst way of
> exploring the wealth of Emacs commands.

I disagree strongly.  With good ways to match, and especially
with the ability to narrow (e.g. what is provided by Icicles
and Helm, and possibly other completion contexts), it is far
better, not worse, than `apropos-command' - for example.

Interactive, incremental, on-demand help of different degrees.
It is a fantastic tool for _discovery_ - another
Emacs-needs-better theme that has been brought up recently.

> M-x is for *executing* commands,
> not for learning about them (unless your learning method consists on
> executing commands you don't know about).

Very wrong.  `M-x' is for lots of things.  And discovery,
even for the limited completion that vanilla Emacs offers,
is one of the most important.

Don't you ever use `C-h f' or `C-h v' to discover/explore
(even for spelling information)?

Are you going to go whole-hog on this new idea, and so
decide to limit the completion candidates for `C-h f' to
only the functions that some Emacs Dev programmer decided
are "appropriate" for the current context?

I hope not.  I would hope that you see the point of
showing a user all of the function names that match the
current input.

> C-h f, the fine manual or,
> better, browsing the sources is what I would do (and have done) for
> exploring what Emacs has to offer.

See above.  If it is such a great idea to let Emacs Dev
predetermine which commands are appropriate for the current
`M-x' context, then why limit this great feature to `M-x'?
Surely `C-h f' and `C-h v' and ... can be enhanced the same
way?

Even thinking that Emacs Dev can specify what constitutes
"the current context" for a given user is presumptuous.
Not only does it depend on many tangible factors - more
than just the current mode(s).  It depends also on intangible
factors - in particular the user's current aim/intention.

Let's not be so presumptuous.  Instead, if we provide
guesses to try to help, let a user choose our guesses,
instead of imposing them.  And even more importantly, let
users ignore our brilliant guesses and decide for
themselves what they consider the "current context" to be.

Let _users_ filter, on demand.  Provide different, useful
ways for them to quickly and powerfully filter candidates
out/in, thus shaping the set of candidates (and thus
defining the context!), _themselves_.

Icicles and Helm have tried to do exactly that, and have
succeeded to some extent.  Let's move in the direction
of giving users _more_ control, and faster and more
powerful control - not in the direction of supposing,
at code time, that we know what's good for them.

> Besides, if you insist on using M-x for learning about new commands, I
> suppose that having only those that apply to your current context is
> helpful, to say the least.

Sure.  But WHO decides just what the "current context" means,
and when?  Is it the currently invoked command that is reading
your input that decides?  Can the user decide, interactively?

Or is it some Emacs maintainer who goes over all of the commands
in a wholesale fashion, applying some simplistic rule ahead of
time, prior to even distributing Emacs to users?

No one has spoken against being able to filter `M-x' candidates
to fit the user's current context.

[Please read that again, if it's not clear.]

The question is how what constitutes the "current context" is
determined/decided, and by whom, and when.

> > Again, what is this feature for?  Is it going to make editing easier for
> > experienced users?  Is it really going to attract new users, ones who
> > would be very happy in Emacs but for the huge number of commands
> > presented to them in an M-x?
> 
> How user-friendly is to type M-x and be offered with thousands of
> commands that have zero relation to the task you are performing?

If that's what you're doing then I submit that maybe you are
not using `M-x' as well as you might.  (Unless for some reason
you want to see those thousands.)

[And aside from considering `M-x' for this, I would hope that
you would have something more specific than just `M-x' to use,
to help you carry out the "task you are performing".  If you
are using `M-x' only to invoke commands, and you are using
only or mainly `M-x' to invoke commands, then something is
missing.]

You should be able to quickly & easily filter `M-x' candidates
by pattern matching.  And hopefully you would be able to also
filter them with additional conditions/predicates.

But YOU should be able to do that, together with the invoked
command (`M-x' in this case, which already filters using
`commandp') - not just some hard-coded filtering done at
code time.

_Late binding_ is a user's friend, especially for a user of
an interactive, self-documenting, and extensible environment
such as Emacs.

Lifting such decisions to the earliest possible stage, code
time, is going backward.  Let's concentrate, instead, on
giving users _more_, not less, control over the set of
completion candidates.

Let's help users filter more powerfully, instead of
hard-coding what we think is the right filtering them.
Let users decide.

> Some of those commands can cause undesirable effects if you
> invoke them by accident,

Too vague.  If so, then fix those particular commands.
Make sure that the commands themselves take care of the
context in which they are invoked.

Let's not try to solve _that_ problem using a
one-size-fits-all, abstract, general rule, applied at
code time to a huge code base.

> I experienced that as a beginner and is very confusing.

When that happens, file a bug report so we can fix that
command.  Such a problem is particular to _that_ command
and should be fixed in a way that is appropriat to _it_.

> Talking about discoverability and your M-x learning method, if I'm
> interested on learning what can I do while editing a C file, how does
> help me having to skim over thousands upon thousands of unrelated
> commands that only make sense for their respective modes?

No one is arguing that you should need to scan thousands
of unrelated commands.  The question is _how_ to determine
which commands _you_ want to see in the _current context_.

That question needs to be answered with finesse, not just
using a sledge hammer.  And the best way to start answering
it is to give _you_, the user, great ways to filter
interactively.

_You_ should decide just how you see the current context,
what you see it to be.  Emacs should not be second-guessing
you about that.

There are many users and many use cases for something
even as simple as `M-x'.  Do not presume to guess what
is good for everyone.

> Why we hide the menus of the modes that are not active for the current
> buffer? Why we have local keymaps? Where were you at the time those
> repressing features were imposed on the masses?

Modes and buffers and such are useful ways to categorize
or define contexts.  And there are others.  We could do
with some more (IMO).  (Common Lisp "packages", i.e.,
namespaces is one.)

But looking for ways to precisely specify a context is
_opposite_ to what is being proposed here.  What is being
proposed here is to _interpret_ the absence of a context
specification as a particular context, ahead of time.

You cannot (should not) assume that the only appropriate
user context for `M-x' is the current major mode (or
that mode plus the current minor modes).

`M-x' is completely general, and it should remain so.

Nothing prevents a mode or library from defining a
different command that reads command names and invokes
one that is chosen by the user, and that imposes a
particular interpretation of the current context, i.e.,
provides only certain command names as candidates.

That's exactly what's called for - not breaking the
legs off of `M-x' to make it fit some rigid mold.

Re: Making `interactive' conditional

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

[snip]

>> M-x is for *executing* commands,
>> not for learning about them (unless your learning method consists on
>> executing commands you don't know about).
>
> Very wrong.  `M-x' is for lots of things.  And discovery,
> even for the limited completion that vanilla Emacs offers,
> is one of the most important.

The fact that M-x shows a list of candidates does not make it an
adequate tool for discovering. The fact that it lists *everything*,
regardless of what yo are doing at the moment, less so.

> Don't you ever use `C-h f' or `C-h v' to discover/explore
> (even for spelling information)?

I'm talking about M-x. `C-h *' is a different thing.

> Are you going to go whole-hog on this new idea, and so
> decide to limit the completion candidates for `C-h f' to
> only the functions that some Emacs Dev programmer decided
> are "appropriate" for the current context?

AFAIK, nobody suggested changing `C-h *', you just introduced that
topic. Please don't do that. It is not a constructive way of discussing
technical matters.

[snip]

> Even thinking that Emacs Dev can specify what constitutes
> "the current context" for a given user is presumptuous.

But it is not presumptuous to put code in the command that checks the
context and errors out if it it not the correct one. That's something
decided by the developer, right? Overriding checks that throws errors as
something beyond the reach of the ordinary user, overriding the M-x
filter is one customization change away (in case it was active, to begin
with). So I don't understand what you are worried about.

> Not only does it depend on many tangible factors - more
> than just the current mode(s).  It depends also on intangible
> factors - in particular the user's current aim/intention.

But you are not opposed to checks in the commands about its
applicability. If a command has a check that errors out on non-editable
buffers, what's wrong with not showing that command on M-x on that
circunstance? If the user expects to see the command, he can use C-h f
to check its docstring and learn about its restrictions.

> Let's not be so presumptuous.  Instead, if we provide
> guesses to try to help, let a user choose our guesses,
> instead of imposing them.  And even more importantly, let
> users ignore our brilliant guesses and decide for
> themselves what they consider the "current context" to be.
>
> Let _users_ filter, on demand.  Provide different, useful
> ways for them to quickly and powerfully filter candidates
> out/in, thus shaping the set of candidates (and thus
> defining the context!), _themselves_.

Again, you are arguing about something that you made up. As mentioned
several times, it is not decided (not even discussed, except by you) if
the feature will be activated by default.

> Icicles and Helm have tried to do exactly that, and have
> succeeded to some extent.  Let's move in the direction
> of giving users _more_ control, and faster and more
> powerful control - not in the direction of supposing,
> at code time, that we know what's good for them.

Annotating commands with information about its applicability is
something that gives users more control, because they have more
knowledge and can process it to taylor their needs. Operating solely on
the command names (prefixes that match mode names, etc) are hacks that
work on arbitrary premises.

>> Besides, if you insist on using M-x for learning about new commands, I
>> suppose that having only those that apply to your current context is
>> helpful, to say the least.
>
> Sure.  But WHO decides just what the "current context" means,
> and when?  Is it the currently invoked command that is reading
> your input that decides?  Can the user decide, interactively?
>
> Or is it some Emacs maintainer who goes over all of the commands
> in a wholesale fashion, applying some simplistic rule ahead of
> time, prior to even distributing Emacs to users?
>
> No one has spoken against being able to filter `M-x' candidates
> to fit the user's current context.

But what me (and Lars, and most people here, AFAIU) are proposing is,
precisely, making possible to filter M-x candidates!

The recent proposal about using this feature in place of tests that
error out when the context is not the expected one, is a new
development. I'm not much convinced about that, btw.

> [Please read that again, if it's not clear.]
>
> The question is how what constitutes the "current context" is
> determined/decided, and by whom, and when.

By the developer, of course. The same person who wrote the command and
knows how and when it is correct to use it.

>> How user-friendly is to type M-x and be offered with thousands of
>> commands that have zero relation to the task you are performing?
>
> If that's what you're doing then I submit that maybe you are
> not using `M-x' as well as you might.  (Unless for some reason
> you want to see those thousands.)

I'm not interested on seeing thousands of commands, not. I use M-x to
find a command on the provided list. If the list contains many commands,
it will be more difficult to find your command, no matter how smart is
your completion method. The fact that the set of available commands
grows with time, as more and more packages are `require'd by your Emacs
session, makes things worse.

> [And aside from considering `M-x' for this, I would hope that
> you would have something more specific than just `M-x' to use,
> to help you carry out the "task you are performing".  If you
> are using `M-x' only to invoke commands, and you are using
> only or mainly `M-x' to invoke commands, then something is
> missing.]

As I mentioned on other messages, M-x with the correct UI is often more
convenient than keybindings and menus on usability terms (ergonomics,
discoverability, mnemonics). On that aspect, M-x is severely handicapped
by the presence of a growing large number of irrelevant candidates.

> You should be able to quickly & easily filter `M-x' candidates
> by pattern matching.  And hopefully you would be able to also
> filter them with additional conditions/predicates.

Precisely, I use ido+flx for that, and it works great up to some extent
(see above). But ido (and helm, and Icicles, I guess) work on command
names, which is quite limiting. A hack, really.

[snip]

> Lifting such decisions to the earliest possible stage, code
> time, is going backward.  Let's concentrate, instead, on
> giving users _more_, not less, control over the set of
> completion candidates.
>
> Let's help users filter more powerfully, instead of
> hard-coding what we think is the right filtering them.
> Let users decide.

You are misunderstanding the whole issue. Annotating the commands gives
more information, hence more power, to the users. It is up to them to
how to use that information. Emacs will provide the necessary
infrastructure to filter commands on that annotations, but that's all.

Sorry for not commenting on the rest of your message. I'm bit busy now.
But this:

> You cannot (should not) assume that the only appropriate
> user context for `M-x' is the current major mode (or
> that mode plus the current minor modes).

Again, nobody said or implied what you say above. You are making that
up. Please try to understand what we are discussing here before wasting
your energies fighting something that does not exist. Same for the rest
of your message starting on that paragraph.

[snit]

RE: Making `interactive' conditional

[Drew Adams]

> >> M-x is for *executing* commands,
> >> not for learning about them (unless your learning method
> >> consists on executing commands you don't know about).
> >
> > Very wrong.  `M-x' is for lots of things.  And discovery,
> > even for the limited completion that vanilla Emacs offers,
> > is one of the most important.
> 
> The fact that M-x shows a list of candidates does not make it an
> adequate tool for discovering. The fact that it lists *everything*,
> regardless of what yo are doing at the moment, less so.
> 
> > Don't you ever use `C-h f' or `C-h v' to discover/explore
> > (even for spelling information)?
> 
> I'm talking about M-x. `C-h *' is a different thing.

Why is it different, in terms of discovery?  Why wouldn't
your same arguments ("The fact that it lists *everything*,
regardless of what yo are doing at the moment" etc.) apply
to `C-h f'?

> > Are you going to go whole-hog on this new idea, and so
> > decide to limit the completion candidates for `C-h f' to
> > only the functions that some Emacs Dev programmer decided
> > are "appropriate" for the current context?
> 
> AFAIK, nobody suggested changing `C-h *', you just introduced that
> topic. Please don't do that. It is not a constructive way of
> discussing technical matters.

Sure it is.  Don't your same arguments apply?  Why should
we stop at `M-x'?  Seems to me that the same arguments for
and against the proposal apply here as well.  Can you point
out something different in this regard?

> > Even thinking that Emacs Dev can specify what constitutes
> > "the current context" for a given user is presumptuous.
> 
> But it is not presumptuous to put code in the command that
> checks the context and errors out if it it not the correct one. 

No, it is not.  Users can pick and choose commands and key
bindings to use.  The _very general_ command
`execute-extended-command' (`M-x') has much wider scope.
Much greater damage, if your presumption is off the mark.

> > Not only does it depend on many tangible factors - more
> > than just the current mode(s).  It depends also on intangible
> > factors - in particular the user's current aim/intention.
> 
> But you are not opposed to checks in the commands about its
> applicability. If a command has a check that errors out on
> non-editable buffers, what's wrong with not showing that
> command on M-x on that circunstance?

I already answered that.  (1) The command needs to raise
that error anyway - it won't necessarily be invoked by `M-x'.
(2) Such a particular command does not have as part of its
mission to show users which commands have names matching
given input.  `M-x' does.  And I gave additional reasons.
Feel free to read what I've already written.

> > Let _users_ filter, on demand.  Provide different, useful
> > ways for them to quickly and powerfully filter candidates
> > out/in, thus shaping the set of candidates (and thus
> > defining the context!), _themselves_.
> 
> Again, you are arguing about something that you made up. As mentioned
> several times, it is not decided (not even discussed, except by you) if
> the feature will be activated by default.

Oh, so the talk about binding this behavior to `M-x' does not
apply?  I made that up?  Great to hear.  We can all forget
about that then.

Let me clear: (1) It should not be activated by default.
(2) If Emacs Dev is convinced that this is a great idea then
it can create a _new) command that implements it.  There is
no reason to hijack `execute-extended-command' for this.

And there is certainly no reason to hijack `M-x' for it.
Provide the new and wonderful behavior in a new command, and
let users come to love it on their own and bind it to whatever
keys they like.

In a decade or two we can decide whether it should become
the new norm.  Just like other innovations (and some of them
have been left by the wayside).  Perhaps, as an Ido user, you
are desirous for Ido to become the new norm for minibuffer
input, and perhaps someday it will.  But you'll notice that
we didn't just switch the default behavior to it the day it
rolled off the press.

This new behavior hasn't rolled off the press.  It hasn't
even been described clearly yet.  But we do seem to be
talking about changing `execute-extended-command' (`M-x'),
AFAICS.  (Yes, John asked that this be done in a sandbox,
for now.  That's one good thing, at least.)

> > Icicles and Helm have tried to do exactly that, and have
> > succeeded to some extent.  Let's move in the direction
> > of giving users _more_ control, and faster and more
> > powerful control - not in the direction of supposing,
> > at code time, that we know what's good for them.
> 
> Annotating commands with information about its applicability is
> something that gives users more control, because they have more
> knowledge and can process it to taylor their needs.

I have not objected to associating any such info with commands.
I might have something to say about how that is done, but I
don't object to our doing so, as long as this is open to users
as well: to add, subtract, and modify such associations.

> Operating solely on the command names (prefixes that match
> mode names, etc) are hacks that work on arbitrary premises.

I described a lot more in the way of interactive filtering
than filtering by mode name.  Please read what I wrote.
And beyond the examples I gave or other examples that may
already be realized here or there, the possibilities are
endless.  The point is to let _users_ filter easily, in
various ways.

> > No one has spoken against being able to filter `M-x'
> > candidates to fit the user's current context.
> 
> But what me (and Lars, and most people here, AFAIU) are
> proposing is, precisely, making possible to filter M-x candidates!

As I understand it, the proposal is not about _users_
filtering the candidates, especially interactively.

The proposal is for, in effect, a code-time filtering
by Emacs Dev.

There's a world of difference between the two.  And again,
I'm not against Emacs Dev coming up with its best behavior
in this regard, and then _letting users choose_ to experiment
with the resulting _new_ command.  But I am not in favor of
it hijacking `M-x' for this new (and so far vaguely specified)
pie in the sky.

> The recent proposal about using this feature in place of tests that
> error out when the context is not the expected one, is a new
> development. I'm not much convinced about that, btw.

As I stated:

1. You cannot, in any case, do without the error-raising code
   in the command bodies (and it was argued that you would be
   able to, as if that would be a great savings).  Commands
   can be invoked in various ways, and such errors need to be
   raised.

2. It is not always an improvement to prevent a user from
   raising an error.  It can be helpful for a user to see an
   error message.  When a given command is _not_ present as a
   completion candidate you have no way of knowing why (or
   even whether the command exists).

   [FWIW, I argued something similar against the sequential
   fall-through behavior of `completion-styles', with no user
   feedback as to which completion styles failed and which
   style ultimately succeeded.  Learning that something does
   _not_ work can be helpful.]

> > The question is how what constitutes the "current context" is
> > determined/decided, and by whom, and when.
> 
> By the developer, of course. The same person who wrote the command and
> knows how and when it is correct to use it.

User first, command-developer second, Emacs Dev last.

No one has objected to the developer of a command defining
it so that it reads input with completion and so that the
completion candidates are limited to whatever the developer
thinks is appropriate.

Developers already do that, using a predicate with
`completing-read' or `read-file-name'.

But why should a developer of command `foo' decide whether
a user can see the command _name_ `foo' as an `M-x'
candidate?  Let the user decide what command names to show -
just as s?he does using pattern-matching.

> As I mentioned on other messages, M-x with the correct UI is often more
> convenient than keybindings and menus on usability terms (ergonomics,
> discoverability, mnemonics). On that aspect, M-x is severely handicapped
> by the presence of a growing large number of irrelevant candidates.

That seems to be what is behind your use case, indeed.
If you use only `M-x' to invoke commands then yes, I can
see why you might regard it as too blunt a hammer.  Most
users use additional key bindings to invoke commands, not
just `M-x'.

You can use `M-x' for nearly everything, if you are so
inclined (but you still need at least some keys bound to
a command such as `self-insert-command', even just to
enter input for `M-x'.)

[You could be even more ascetic, and limit yourself to only
Icicles key completion - only key `S-TAB'.  That lets you
invoke any command, including character-insertion.
http://www.emacswiki.org/emacs/Icicles_-_Key_Completion#ThreeKeyEmacs]

But why would you, when you can make use of multiple keys?

Your answer is that, in your setup, `M-x' lets you abbreviate
command names radically, and using abbreviated command names
is handier than using multiple keys.  That's to be counted
as one user's interesting preference, but it is hardly a
common one.

> > You should be able to quickly & easily filter `M-x' candidates
> > by pattern matching.  And hopefully you would be able to also
> > filter them with additional conditions/predicates.
> 
> Precisely, I use ido+flx for that, and it works great up to
> some extent (see above).  But ido (and helm, and Icicles, I
> guess) work on command names, which is quite limiting.
> A hack, really.

I can't speak for Helm, but I've already said that Icicles
does _not_ limit you to pattern-matching (for command names
or anything else).  You can filter, on the fly, using
arbitrary predicates.

But the point is not what is available today but where Emacs
could head.  Instead of what is currently being proposed,
I'd sooner see making it easy for _users_ to be able to
filter powerfully and flexibly.  And no, I'm not talking
only about matching candidate names.

> > Lifting such decisions to the earliest possible stage, code
> > time, is going backward.  Let's concentrate, instead, on
> > giving users _more_, not less, control over the set of
> > completion candidates.
> >
> > Let's help users filter more powerfully, instead of
> > hard-coding what we think is the right filtering them.
> > Let users decide.
> 
> You are misunderstanding the whole issue. Annotating the commands gives
> more information, hence more power, to the users. It is up to them to
> how to use that information. Emacs will provide the necessary
> infrastructure to filter commands on that annotations, but that's all.

I'll be glad to find that I have misunderstood, but so far
I don't think so.  If the only change is to "annotate"
existing functions (and why stop with just commands?) with
additional information about contexts where Emacs Dev thinks
their invocation might be especially useful, I have nothing
against that.

But note the qualifiers: "might be especially useful".
This can only be a code-time developer guess, at best.

That's a far cry from making `M-x' obey such annotations,
treating them as restrictions: hard, predefined filtering.

And I do think I understand the current proposal when I
think that it is about predefined `M-x' filtering, and
not just annotating functions with suggestive context info.

> > You cannot (should not) assume that the only appropriate
> > user context for `M-x' is the current major mode (or
> > that mode plus the current minor modes).
> 
> Again, nobody said or implied what you say above. You are making that
> up. Please try to understand what we are discussing here before wasting
> your energies fighting something that does not exist. Same for the rest
> of your message starting on that paragraph.

We disagree.  It seems pretty clear to me that the proposal
is about `M-x' filtering, not just about annotating functions
with suggested context information.

But it also seems clear that the proposal is, so far, quite
vague.

Just what kind of annotation and how it will be specified
(associated with commands), and what kind of `M-x'
filtering and how it will (or won't) be controlled by users -
such things have not been specified clearly, if at all.

Re: Making `interactive' conditional

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

[snip]

> We disagree.  It seems pretty clear to me that the proposal
> is about `M-x' filtering, not just about annotating functions
> with suggested context information.

The M-x filtering will be optional. Without activating the filtering,
M-x will behave exactly as it does now.

Given this premise, it is obvious that your worries are unfounded.

> But it also seems clear that the proposal is, so far, quite
> vague.
>
> Just what kind of annotation and how it will be specified
> (associated with commands), and what kind of `M-x'
> filtering and how it will (or won't) be controlled by users -
> such things have not been specified clearly, if at all.

The proposal, as far as I'm concerned, and as Lars stated it, is about
M-x (optionally!) displaying only those commands that are associated to
the active major/minor modes on the current buffer, plus the "global"
commands (`dired', etc). I extended the proposal to cover other
qualities, such as if the buffer is read-only, if it is visiting a file,
etc. For achieving that it is necessary to annotate the commands with
the required info.

What's not clear about that proposal?

Others proposed to use the scheme for doing others things, but that's
not the original proposal which I (and Lars, AFAIU) plan to implement.

RE: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx)

[Drew Adams]

> This might be OK if the only reason you every use M-x is to execute a
> command.  But it's not.  People (in particular, me) use it to discover
> Emacs, to find the exact name of a command which has only vaguely
> embedded itself in the memory, to get this name into the kill ring to be
> yanked into another source file or into documentation, and so on.  Try
> M-x <tab> <prior> sometime, and explore the wealth of Emacs commands.
> :-)

Precisely.

(It sounds to me like those who now want to remake/cripple
`M-x' might not even be using it to its ordinary potential.)

> What do we gain that would offset this loss?  What is this
> feature for?

Indeed, there has been no spec of what it is for, what
requirement/need it is hoping to satisfy.

> People have suggested filtering by mode, by read-onliness, and so on.
> Somebody (I think it was Artur M.) even suggested removing initial
> checks from commands, on the grounds that M-x filtering would render it
> unneeded.  I don't think that could ever be the case.

Indeed.  It seems like some people do not see why we raise
an argument error in the function body, and not just in the
`interactive' spec.
 
> > writing code to automatically consider every interactive function
> > *without an autoload token* as being conditional on any modes
> > defined in the same package (likely determined by prefix matching).
> 
> At which point I see the complexity rapidly increasing, unforeseen Bad
> Things happening, and generally a lot of pain.

Ditto.  And not only because of corner cases or things that
are not obvious.  Mainly because it is a coarse rule - a
hammer, not tweezers or a needle.  One size does not fit all.

> > Thus, proper UI behavior for M-x falls out by design, and we
> > get to make use of conditionality for other purposes, such as
> > better errors when command functions are called outside their
> > expected environment.
> 
> Any chance of an example of such an improvement?  How are we to
> improve on, for example, "Can't execute - not in Foo mode"?

IOW, please specify the dreamt-of feature in some detail.
Hand-waving solicits only "Great idea!" or "Hell no!" -
more noise than light.

> > I'm open to a feature branch implementing such conditionality,
> > as a candidate for merging to master...

Before calling immediately for a pilot implementation,
how about a bit more of a spec of just what is intended?

> Again, what is this feature for?

Yup.

> Is it going to make editing easier for experienced users?
> Is it really going to attract new users, ones who would be
> very happy in Emacs but for the huge number of commands
> presented to them in an M-x?
> 
> I'm sceptical on both counts.

And are there perhaps better ways, even perhaps existing
ways, to accomplish the goals?  But first, just what are
those goals?

Re: Making `interactive' conditional

[Stefan Monnier]

> Indeed, there has been no spec of what it is for, what
> requirement/need it is hoping to satisfy.

My interest in tweaking M-x is the following:

   To rely less on key-bindings, and more on running commands by name, you
   want M-x's completion to be more efficient.

Furthermore, there are many cases where I can't remember the exact name
of the command I want to use, and I think that in some significant cases
stripping away currently-invalid commands can help noticeably in
trying to find the right command.

Indeed, that would be an impediment when you want to just explore the
wealth of commands (not to run it right now, but for some other purpose,
in which case you don't want to filter out currently-invalid commands).
Maybe we should/could add a `describe-command' for that use case.

In any case, this discussion is not about changing the default M-x, but
about experimenting with a new M-x, probably offered as a GNU
ELPA package.


        Stefan

RE: Making `interactive' conditional

[Drew Adams]

> In any case, this discussion is not about changing the default M-x,
> but about experimenting with a new M-x, probably offered as a GNU
> ELPA package.

That's good.  Thanks for clarifying that.

So we can keep that in mind from now on: Unless stated otherwise,
when we write `M-x' in this discussion we really mean an
experimental new, alternate `M-x'-like command.

Re: Making `interactive' conditional

[Clément Pit--Claudel]

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

On 01/10/2016 10:27 AM, Alan Mackenzie wrote:
> This might be OK if the only reason you every use M-x is to execute a
> command.  But it's not.  People (in particular, me) use it to discover
> Emacs, to find the exact name of a command which has only vaguely
> embedded itself in the memory, to get this name into the kill ring to be
> yanked into another source file or into documentation, and so on.  Try
> M-x <tab> <prior> sometime, and explore the wealth of Emacs commands.
> :-)

Funny, that doesn't work at all for me. In particular because M-x already heavily "censors" its results by only proposing interactive candidates. So I use C-h f instead. And even then that doesn't work great, because often it's in a package that isn't loaded (see my recent thread about pulse.el :/)
When I'm specifically looking for a command, I use M-x; and it works well right after starting Emacs (I get only autoloaded commands plus a few already loaded things). After a few hours, the M-x list becomes huge and cluttered.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx)

[Marcin Borkowski]

On 2016-01-10, at 16:27, Alan Mackenzie <acm@muc.de> wrote:

> [...]  I think most people on
> this list would be opposed to censorship in most areas [...]

For the record, maybe most people, but definitely not all.  There are
a few cases when I'm fine with (and in fact, I'm really for) censorship.

> [...]  Try
> M-x <tab> <prior> sometime, and explore the wealth of Emacs commands.
> :-)

Wow, that was cool!  Thanks!

> Again, what is this feature for?  Is it going to make editing easier for
> experienced users?  [...]

Yes (though marginally, I admit) - by enabling one to select the needed
command faster.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Making `interactive' conditional

[Stefan Monnier]

> Right now, functions are interactive if declared with `interactive', and not
> otherwise.  The suggestion at hand is to allow `interactive' forms to become
> conditional -- possibly in multiple ways. I like this concept, and think the
> right place for it is indeed in core.

Note that it turns `commandp' from a pure function to an impure one.

I think that pretending that "foo" is not interactive just because you're
not in the right context is going too far.


        Stefan

Re: Making `interactive' conditional

[John Wiegley]

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

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think that pretending that "foo" is not interactive just because you're
> not in the right context is going too far.

Lots of great discussion on this feature while I was away for a few days!
After reading the comments, it does seem that changing core to get a smarter
M-x isn't the best plan right now.

While some may want a more narrow and efficient M-x, others just don't, for
discovery purposes. Also, it's hard to properly define a "context" for when
commands should appear, since for some, that notion varies.

And, well, Stefan's argument about impurity sold me. I have a feeling he knew
it would, too. :)

I'd still love to see a faster, more apropos M-x develop in ELPA, if anyone is
interested in making that happen.

-- 
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 --]

Re: Making `interactive' conditional

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> While some may want a more narrow and efficient M-x, others just don't, for
> discovery purposes. Also, it's hard to properly define a "context" for when
> commands should appear, since for some, that notion varies.

Stefan's arguments against not being able to discover commands for
not-read-only-buffers in read-only buffers were good, but that was,
after all, not the original proposal.

The proposal was to not make `M-x TAB' list mode-specific commands.  So
that `M-x di TAB' in a Message mode buffer doesn't list
`diary-hebrew-insert-entry', which is a pretty useless thing to do.

Are anybody against that idea?

> I'd still love to see a faster, more apropos M-x develop in ELPA, if anyone is
> interested in making that happen.

The commands need instrumentation, one way or another, and that has to
happen in Emacs, not in ELPA.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making `interactive' conditional

[Lars Magne Ingebrigtsen]

And to sum up the (basically) two proposals to make `M-x di TAB' not
list `diary-chinese-insert-entry', first there is Stefan's "add a global
directive and then mark exceptions".

This would mean that a mode like diary would say something like

(new-magic-declare (mode "diary-" diary-mode))

at (top-level?) somewhere.  The few actual non-diary-mode commands would
then say

   (declare (mode nil))

in the command definition.  This means that a typical mode would have
two lines added to them.  This is very attractive.


My proposal was to mark all mode-specific commands explicitly:

  (declare (mode diary-mode))

  or

  (command 'diary-mode "p")

This is because I kinda have a distaste for "magic" global settings, and
would prefer things to be explicit.  The advantage here is that nothing
would change except for things that have explicitly been changed.  For
instance, if I (as a user) has defined a command called `diary-lars',
then it would be removed from TAB completion until the user adds a
declaration to it.

So either minimal churn, but possibly some unexpected fall-out for some
users, or more churn, but no unexpected fall-out for anybody.


I'm fine with either.  I just want my `M-x' to be useful, because I can
never remember what keys commands are on, or what they're called,
precisely.

`M-x diTAB' in my Emacs today lists 180 commands.  Eyeballing them, I
would say about six of them are things that `M-x diTAB' should be
listing, and you'd be able to discover nice commands like `dict',
`diary', `dig' and `diff'.

(I kinda think the discussion took the normal "one simple functionality
improvement" to "let's do ALL THE THINGS" to "well, ALL THE THINGS isn't
really practical or what we want" to "well, then LET'S DO NOTHING" turn.
:-))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making `interactive' conditional

[Stefan Monnier]

> Stefan's arguments against not being able to discover commands for
> not-read-only-buffers in read-only buffers were good, but that was,
> after all, not the original proposal.

Indeed.

> Are anybody against that idea?

Not me.

>> I'd still love to see a faster, more apropos M-x develop in ELPA, if
>> anyone is interested in making that happen.
> The commands need instrumentation, one way or another, and that has to
> happen in Emacs, not in ELPA.

Of course, for a proof of concept, the new package could come with
(lots of) things like

   (newMx-describe-package "smerge-"
     smerge-mode
     smerge-makeup-conflict)

And then those "instrumentations" could be moved/added to core as
a second step.


        Stefan

RE: Making `interactive' conditional

[Drew Adams]

> The proposal was to not make `M-x TAB' list mode-specific commands.

You mean not allow `M-x TAB' to list commands that are not specific
to the current mode, I imagine.  Or perhaps not allow it to list
commands that are defined for other modes.

> So that `M-x di TAB' in a Message mode buffer doesn't list
> `diary-hebrew-insert-entry', which is a pretty useless thing to do.
> 
> Are anybody against that idea?

Yes.  Please read the thread for the reasons.

Re: Making `interactive' conditional

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I think that pretending that "foo" is not interactive just because you're
>> not in the right context is going too far.
>
> Lots of great discussion on this feature while I was away for a few days!
> After reading the comments, it does seem that changing core to get a smarter
> M-x isn't the best plan right now.
>
> While some may want a more narrow and efficient M-x, others just
> don't,

Nobody proposed to force people to use the feature. What you have seen
is the usual drama and hysteria display typical of emacs-devel.

> for discovery purposes.

Anyone is free to refrain from using the feature for whatever reason.
But having the commands that apply to the current buffer (plus the
global ones) listed on M-x is something that enhances discovery, unless
you are interested on *all* of Emacs *all* the time.

> Also, it's hard to properly define a "context" for when
> commands should appear, since for some, that notion varies.
>
> And, well, Stefan's argument about impurity sold me. I have a feeling he knew
> it would, too. :)
>
> I'd still love to see a faster, more apropos M-x develop in ELPA, if anyone is
> interested in making that happen.

As Lars said, instrumentalization is required.

Re: Making `interactive' conditional

[Lars Magne Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Nobody proposed to force people to use the feature. What you have seen
> is the usual drama and hysteria display typical of emacs-devel.

Hm?  I've seen no drama...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making `interactive' conditional

[Óscar Fuentes]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Nobody proposed to force people to use the feature. What you have seen
>> is the usual drama and hysteria display typical of emacs-devel.
>
> Hm?  I've seen no drama...

A comedy then? You're an optimist.

:-)

Re: Making `interactive' conditional

[John Wiegley]

>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:

>> I'd still love to see a faster, more apropos M-x develop in ELPA, if anyone
>> is interested in making that happen.

> As Lars said, instrumentalization is required.

A demonstrative implementation of this feature can be done without
instrumentation. Instrumentation is the "right" way, but is not a necessary
way. We shouldn't think core needs to be changed before we can try out a
fancier M-x.

I'm not against a smarter M-x; I'd like to use it for the same reasons others
have stated (my own completion list right now is massive, slow, and at times,
confusingly over-populated).

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

Re: Making `interactive' conditional

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> A demonstrative implementation of this feature can be done without
> instrumentation. Instrumentation is the "right" way, but is not a necessary
> way. We shouldn't think core needs to be changed before we can try out a
> fancier M-x.

The implementation of the stuff in `M-x' is trivial: Don't complete to
commands that are/aren't marked in a certain way.  What will take real
work is instrumenting the commands.  (One way or the other.)

Making changes and then seeing improvements in Emacs immediately would
be a great motivating factor, I think, to get people to do this stuff.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making `interactive' conditional

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The implementation of the stuff in `M-x' is trivial: Don't complete to
> commands that are/aren't marked in a certain way. What will take real work
> is instrumenting the commands. (One way or the other.)

Yes, although "classifying functions" can be done in a very large number of
ways, not all of which require instrumentation.

> Making changes and then seeing improvements in Emacs immediately would be a
> great motivating factor, I think, to get people to do this stuff.

I didn't quite follow what this was suggesting... :)

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

Re: Making `interactive' conditional

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>> Making changes and then seeing improvements in Emacs immediately would be a
>> great motivating factor, I think, to get people to do this stuff.
>
> I didn't quite follow what this was suggesting... :)

If you instrument diary.el, you (and everybody else who uses the trunk)
who does `M-x diTAB' sees a usability improvement.  I think that's a
motivating factor to getting all this janitorial work done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making `interactive' conditional

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> I'd still love to see a faster, more apropos M-x develop in ELPA, if anyone
>>> is interested in making that happen.
>
>> As Lars said, instrumentalization is required.
>
> A demonstrative implementation of this feature can be done without
> instrumentation. Instrumentation is the "right" way, but is not a necessary
> way. We shouldn't think core needs to be changed before we can try out a
> fancier M-x.

A demonstrative implementation can be done on a branch. This has the
advantage that you see the real implementation and hence you have a
solid basis for measuring its implications, maintenance-wise. And when
it receives the ok, a simple merge is enough, instead of having to
instrumentalize the Elisp sources.

Besides, an implementation on ELPA not only causes much more work, but
it is mostly invisible to the developers (see Lars' post).

[snip]

Re: Leaving out non-applicable commands on Mx

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> We've discussed before adding mechanisms for leaving mode-specific commands
>>> out, but I was apparently the only one enthusiastic about it...
>
>> You sketched a possible implementation. If you are interested on completing
>> the part that requires a smart hacker, I'll do the part that requires a dumb
>> one :-)
>
> What is this feature suggestion again?

Marking commands as applicable to a mode (or a set of modes) so that
completion doesn't list them outside of those modes.

This requires instrumentation of all interactive commands.  :-)  But for
virtually all modes, it's just a search and replace action.

Óscar mentioned one syntax suggestion for this:

(defun foo-something (bar)
  "docstring"
  (interactive "p")
  (declare (mode foo))
  ...)

This would be backwards compatible.  The other one is to introduce a new
form `command':

(defun foo-something (bar)
  "docstring"
  (command 'foo "p")
  ...)

where the first element is a mode name, or a list of mode names, where
the command applies.

So, three things need to be done:

1) Decide what syntax we want for this (and implement it in Emacs),

2) Alter `M-x' to react to this new data (which will probably be
something in the symbol list, I guess?) to complete only over commands
that are either available globally, or in the current local mode(s).

and then people can calmly

3) Convert all packages in Emacs (mostly with a replace-string) to use
the new syntax, and `M-x' will slowly grow better and better as a tool
to discover commands.

I favour the `command' solution.  It looks cleaner as a language
element, especially since virtually (well beyond 90%) every command in
Emacs will have one of these.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Leaving out non-applicable commands on Mx

[Óscar Fuentes]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Wiegley <jwiegley@gmail.com> writes:
>
>>>>>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>>> We've discussed before adding mechanisms for leaving mode-specific commands
>>>> out, but I was apparently the only one enthusiastic about it...
>>
>>> You sketched a possible implementation. If you are interested on completing
>>> the part that requires a smart hacker, I'll do the part that requires a dumb
>>> one :-)
>>
>> What is this feature suggestion again?
>
> Marking commands as applicable to a mode (or a set of modes) so that
> completion doesn't list them outside of those modes.

I envision a somewhat more generic system, where the command can state
that it operates only on read-only buffers, or on buffers that are
visiting a file, or on buffers that are visiting a versioned file. Using
the syntax proposed by Lars:

(declare (type versioned))

or

(command 'versioned "p")

[snip]

Re: Leaving out non-applicable commands on Mx

[Stefan Monnier]

> (defun foo-something (bar)
>   "docstring"
>   (command 'foo "p")
>   ...)

I think having to tweak every mode-specific command is going to be
too heavy.  We should be able to cut that down drastically by having
a way to say "commands with prefix foo- all all mode-specific except for
those that are marked as being global".

So if we have N local command and M global commands, we replace
N modifications with M+1 modifications.  If M>>N that's a big win.


        Stefan

Re: Leaving out non-applicable commands on Mx

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think having to tweak every mode-specific command is going to be
> too heavy.  We should be able to cut that down drastically by having
> a way to say "commands with prefix foo- all all mode-specific except for
> those that are marked as being global".

That would certainly help with discoverability of the global
commands, but would it also allow completing over the commands that are
applicable to the current mode(s)?  For instance, there are often
commands that apply to similar modes (for instance in the cc-mode
family) that aren't necessarily named what you might think, I think...

One could offer to complete over the keys that are bound in the local
maps, of course.

If one can get this to work, that would be very nice, but I'm not sure
that that it's flexible enough.

> So if we have N local command and M global commands, we replace
> N modifications with M+1 modifications.  If M>>N that's a big win.

Sure.  But I think this sort of "janitorial" fix-up is something that
appeals to (some) people: They can do something that can be
semi-automated, and have real noticeable progressive impact on Emacs
usability.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Leaving out non-applicable commands on Mx

[Stefan Monnier]

> That would certainly help with discoverability of the global
> commands, but would it also allow completing over the commands that are
> applicable to the current mode(s)?

I don't see why not.  Basically

   (new-magic-declare "foo-" <decls>)

would be equivalent to adding

   (declare (mode-specific <decls>))

to all commands whose name start with "foo-" and which don't yet have
a (mode-specific ...) declaration.

> For instance, there are often commands that apply to similar modes
> (for instance in the cc-mode family) that aren't necessarily named
> what you might think, I think...

Of course you can have several calls to (new-magic-declare "foo-"
<decls>) for different prefixes, and of course you don't have to use it
(e.g. if there are more exceptions than cases which follow the rule).


        Stefan

Re: Leaving out non-applicable commands on Mx

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> For instance, there are often commands that apply to similar modes
>> (for instance in the cc-mode family) that aren't necessarily named
>> what you might think, I think...
>
> Of course you can have several calls to (new-magic-declare "foo-"
> <decls>) for different prefixes, and of course you don't have to use it
> (e.g. if there are more exceptions than cases which follow the rule).

Yeah, that's true.  I agree that having these global declarations is
probably a better idea than sprinkling them in all the commands.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Leaving out non-applicable commands on Mx

[Stefan Monnier]

> Sure.  But I think this sort of "janitorial" fix-up is something that
> appeals to (some) people: They can do something that can be
> semi-automated, and have real noticeable progressive impact on Emacs
> usability.  

But if the same rule applies to all N commands, repeating it for every
one of those commands introduces the same old maintainability problem as
copy&paste.

And having to annotate every Emacs package is "janitorial
enough", methinks.  There's no need to make it even more tedious.


        Stefan

Re: Leaving out non-applicable commands on Mx

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But if the same rule applies to all N commands, repeating it for every
> one of those commands introduces the same old maintainability problem as
> copy&paste.
>
> And having to annotate every Emacs package is "janitorial
> enough", methinks.  There's no need to make it even more tedious.

+1

Óscar, the would-be janitor.

Re: 4K Bugs

[Michael Albinus]

phillip.lord@russet.org.uk (Phillip Lord) writes:

Hi Philipp,

Since the debbugs package is used until now mainly by people who know
the code, your feedback is very appreciated! Lars did answer already to
some points, I'll add from my pov.

>  - After installing debbugs, there is no obvious entry point. M-x
>    debugs-[tab] gives 30 different commands.

Yes, unfortunately there was a need to mark some functions as
interactive which are not intended to be called directly. I'll go
through the code whether this can be fixed.

However, the file README of the debbugs package should give you a short
overview. Please let me know if this is still confusing.

>  - The two shortest commands are debbugs-org and debbugs-gnu. The former
>    lists all the bugs for Org-Mode, and the latter Emacs. Why
>    debbugs-gnu and not debbugs-emacs? I don't know.

`debbugs-gnu' is meant to access the bug tracker on http://debbugs.gnu.org.
The underlying library debbugs.el is able to access also the Debian bug
tracker on http://bugs.debian.org. Maybe there will be a
`debbugs-debian' one day.

`debbugs-emacs' would be misleading, because http://debbugs.gnu.org is
also the bug tracker for other GNU projects.

>  - debbugs-gnu list bugs from number 158 and upward; the entire first
>    500 is about emacs 23 pre-releases. If I want to get the latest bugs,
>    they are on page 5.

Yep, maybe it is better to sort by default latest first. As Lars said,
in the next debbugs release 0.9 you will get all bugs on one page. You
can sort as you like, pressing the title of a column with your mouse.

>  - Bugs marked as "done" and "unreproducible" are displayed by default.

"Done" bugs are displayed until they are archived (28 days after being
marjed "done"). You can toggle this behaviour by typing "x". For
"unreproducible" bugs nothing is available, maybe they shall be
suppressed also by typing "x".

>  - On none of the debbugs pages are there any obvious menu items or
>    bug-related functionality.

Good point. Will add this.

>  - I found out about hitting "C" to send a control message. Configuring
>    this to "mail client" and up pops thunderbird, although I am a Gnus
>    user.

As Lars said, this must be a bug. If you cannot fix it yourself (start
with "emacs -Q"), write a bug report.

>  - I found "bugtracker" in admin/notes late in the day. It doesn't
>    mention the debbugs package AFAICT. It's full of information, but a
>    lot of it is how to manage the bug tracker. I don't know if there is
>    anything better on how-to-fix a bug. It also ends with a warning that
>    the database takes "well over 1Gb of space" which makes it look
>    rather old.

Adding some words about the debbugs package into relevant files is on my todo.

> So, I think that the process is rather harder than it needs to be.
>
> If anyone is willing to hold-my-hand, and take me through the process of
> fixing a couple of bugs (not the actual bug-hunting, which I can do),
> I'll write the process up as a short tutorial as I did with for
> etc/DEBUG. This way I can use my ignorance to good purpose.

Please start reading README and debbugs-ug.info. Ping me, if you find
annoyances there. ASk also for new features :-)

Since I'm just changing several things in the debbugs package, it might
be closer to the state-of-art if you use the version from git. If this
is applicable to you.

> Phil

Best regards, Michael.

Re: 4K Bugs

[Phillip Lord]

Michael Albinus <michael.albinus@gmx.de> writes:

>>  - The two shortest commands are debbugs-org and debbugs-gnu. The former
>>    lists all the bugs for Org-Mode, and the latter Emacs. Why
>>    debbugs-gnu and not debbugs-emacs? I don't know.
>
> `debbugs-gnu' is meant to access the bug tracker on http://debbugs.gnu.org.
> The underlying library debbugs.el is able to access also the Debian bug
> tracker on http://bugs.debian.org. Maybe there will be a
> `debbugs-debian' one day.
>
> `debbugs-emacs' would be misleading, because http://debbugs.gnu.org is
> also the bug tracker for other GNU projects.

Yeah. But if I type M-x debbugs-gnu, I just get emacs bugs right?

>>  - debbugs-gnu list bugs from number 158 and upward; the entire first
>>    500 is about emacs 23 pre-releases. If I want to get the latest bugs,
>>    they are on page 5.
>
> Yep, maybe it is better to sort by default latest first. As Lars said,
> in the next debbugs release 0.9 you will get all bugs on one page. You
> can sort as you like, pressing the title of a column with your mouse.

Indeed.


>
>>  - Bugs marked as "done" and "unreproducible" are displayed by default.
>
> "Done" bugs are displayed until they are archived (28 days after being
> marjed "done"). You can toggle this behaviour by typing "x". For
> "unreproducible" bugs nothing is available, maybe they shall be
> suppressed also by typing "x".

Ah, okay, it's not all "done" bugs. I was wondering why there were so
few. Again, I would toggle the default here. Power users will work it
out.


>>  - On none of the debbugs pages are there any obvious menu items or
>>    bug-related functionality.
>
> Good point. Will add this.
>
>>  - I found out about hitting "C" to send a control message. Configuring
>>    this to "mail client" and up pops thunderbird, although I am a Gnus
>>    user.
>
> As Lars said, this must be a bug. If you cannot fix it yourself (start
> with "emacs -Q"), write a bug report.
>
>>  - I found "bugtracker" in admin/notes late in the day. It doesn't
>>    mention the debbugs package AFAICT. It's full of information, but a
>>    lot of it is how to manage the bug tracker. I don't know if there is
>>    anything better on how-to-fix a bug. It also ends with a warning that
>>    the database takes "well over 1Gb of space" which makes it look
>>    rather old.
>
> Adding some words about the debbugs package into relevant files is on my todo.
>
>> So, I think that the process is rather harder than it needs to be.
>>
>> If anyone is willing to hold-my-hand, and take me through the process of
>> fixing a couple of bugs (not the actual bug-hunting, which I can do),
>> I'll write the process up as a short tutorial as I did with for
>> etc/DEBUG. This way I can use my ignorance to good purpose.
>
> Please start reading README and debbugs-ug.info. Ping me, if you find
> annoyances there. ASk also for new features :-)

Oh, I will!

One document which I think is missing is a "what all the tags" mean.


>
> Since I'm just changing several things in the debbugs package, it might
> be closer to the state-of-art if you use the version from git. If this
> is applicable to you.


No worries I can do that.

Phil

Re: 4K Bugs

[Michael Albinus]

phillip.lord@russet.org.uk (Phillip Lord) writes:

>> `debbugs-emacs' would be misleading, because http://debbugs.gnu.org is
>> also the bug tracker for other GNU projects.
>
> Yeah. But if I type M-x debbugs-gnu, I just get emacs bugs right?

Emacs is the default package. You can change this by customizing
`debbugs-gnu-default-packages'. Or you call interactively
"C-u M-x debbugs-gnu".

(For all what I claim here: pls blame me if it isn't documented in the
User Guide)

> Ah, okay, it's not all "done" bugs. I was wondering why there were so
> few. Again, I would toggle the default here. Power users will work it
> out.

Noted. Will be done.

> One document which I think is missing is a "what all the tags" mean.

I believe it is covered in the User Guide. If not sufficient, ask for
clarification.

> Phil

Best regards, Michael.

Re: 4K Bugs

[Phillip Lord]

Michael Albinus <michael.albinus@gmx.de> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>>> `debbugs-emacs' would be misleading, because http://debbugs.gnu.org is
>>> also the bug tracker for other GNU projects.
>>
>> Yeah. But if I type M-x debbugs-gnu, I just get emacs bugs right?
>
> Emacs is the default package. You can change this by customizing
> `debbugs-gnu-default-packages'. Or you call interactively
> "C-u M-x debbugs-gnu".
>
> (For all what I claim here: pls blame me if it isn't documented in the
> User Guide)

I would add a shorter "debbugs". I would be intereted to know how many
enter via "-org" and how many via "-gnu".



>> One document which I think is missing is a "what all the tags" mean.
>
> I believe it is covered in the User Guide. If not sufficient, ask for
> clarification.

invalid? Different from notabug, wontfix, unreproducible?

pending? Pending what? Different from moreinfo?

patch? It includes one? Covers a bug report with a pull request?

And important, minor, normal, serious, wishlist. Is serious more
important than important? Or Important more serious than serious? What
criterion?

security? valid only for bugs? or wishlists, RFE also?

Phil

Re: 4K Bugs

[Andrew Hyatt]

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

On Fri, Jan 8, 2016 at 9:08 AM Phillip Lord <phillip.lord@russet.org.uk>
wrote:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
> > phillip.lord@russet.org.uk (Phillip Lord) writes:
> >
> >>> `debbugs-emacs' would be misleading, because http://debbugs.gnu.org is
> >>> also the bug tracker for other GNU projects.
> >>
> >> Yeah. But if I type M-x debbugs-gnu, I just get emacs bugs right?
> >
> > Emacs is the default package. You can change this by customizing
> > `debbugs-gnu-default-packages'. Or you call interactively
> > "C-u M-x debbugs-gnu".
> >
> > (For all what I claim here: pls blame me if it isn't documented in the
> > User Guide)
>
> I would add a shorter "debbugs". I would be intereted to know how many
> enter via "-org" and how many via "-gnu".
>

FWIW, I found debbugs-org to be a bit buggy after I entered control
messages for what I thought was the bug under the cursor only to find it
sent control messages to a completely different bug.  I'll... uh... file a
bug on it or perhaps just fix it once I can reproduce it again.

>
>
>
> >> One document which I think is missing is a "what all the tags" mean.
> >
> > I believe it is covered in the User Guide. If not sufficient, ask for
> > clarification.
>
> invalid? Different from notabug, wontfix, unreproducible?
>
> pending? Pending what? Different from moreinfo?
>
> patch? It includes one? Covers a bug report with a pull request?
>

> And important, minor, normal, serious, wishlist. Is serious more
> important than important? Or Important more serious than serious? What
> criterion?
>

Pretty sure it must go, in order of decreasing severity: serious,
important, normal.  Serious probably is reserved for things like emacs
crashing bugs, security vulnerabilities and the like.  I don't know whether
there is a rule about this, but I'd guess that new emacs versions shouldn't
be released if any serious bugs are opened against it.  Important is a bit
unknown to me, I'm guessing just a bit scarier than the "normal" bugs.


>
> security? valid only for bugs? or wishlists, RFE also?
>

Great questions, and once someone sheds light on the things like invalid
and pending (I have no clue, personally), I'll write up the info in the
bug-triage file.


>
> Phil
>
>

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

Re: 4K Bugs

[Michael Albinus]

Andrew Hyatt <ahyatt@gmail.com> writes:

Hi Andrew,

> FWIW, I found debbugs-org to be a bit buggy after I entered control
> messages for what I thought was the bug under the cursor only to find
> it sent control messages to a completely different bug. I'll... uh...
> file a bug on it or perhaps just fix it once I can reproduce it again.

Do you use the git checkout of debbugs? Note that I concentrate these
days on debbugs.el and debbugs-gnu.el. It might be that debbugs-org.el
is a little bit outdated in the repo. Will fix it before releasing 0.9.

>     >> One document which I think is missing is a "what all the tags"
>     mean.
>     >
>     > I believe it is covered in the User Guide. If not sufficient,
>     ask for
>     > clarification.
>
>     invalid? Different from notabug, wontfix, unreproducible?
>
>     pending? Pending what? Different from moreinfo?
>
>     patch? It includes one? Covers a bug report with a pull request?

Emacs has no special meaning on them. Check the debbugs doc:

<http://debbugs.gnu.org/Developer.html#tags>

"invalid" is declared in debbugs-*.el only. It sets the tags notabug and
wontfix, and closes the bug. See the User Guide.

>     And important, minor, normal, serious, wishlist. Is serious more
>     important than important? Or Important more serious than serious?
>     What
>     criterion?

> Pretty sure it must go, in order of decreasing severity: serious,
> important, normal.

Sure.

> Serious probably is reserved for things like emacs
> crashing bugs, security vulnerabilities and the like. I don't know
> whether there is a rule about this, but I'd guess that new emacs
> versions shouldn't be released if any serious bugs are opened against
> it. Important is a bit unknown to me, I'm guessing just a bit scarier
> than the "normal" bugs. 

<http://debbugs.gnu.org/Developer.html#severities>

We don't use critical and grave, 'tho.

>     security? valid only for bugs? or wishlists, RFE also?

No rule exist yet.

> Great questions, and once someone sheds light on the things like
> invalid and pending (I have no clue, personally), I'll write up the
> info in the bug-triage file.

>     Phil

Best regards, Michael.

Re: 4K Bugs

[Phillip Lord]

Michael Albinus <michael.albinus@gmx.de> writes:

> Andrew Hyatt <ahyatt@gmail.com> writes:
>>     >> One document which I think is missing is a "what all the tags"
>>     mean.
>>     >
>>     > I believe it is covered in the User Guide. If not sufficient,
>>     ask for
>>     > clarification.
>>
>>     invalid? Different from notabug, wontfix, unreproducible?
>>
>>     pending? Pending what? Different from moreinfo?
>>
>>     patch? It includes one? Covers a bug report with a pull request?
>
> Emacs has no special meaning on them. Check the debbugs doc:
>
> <http://debbugs.gnu.org/Developer.html#tags>
>
> "invalid" is declared in debbugs-*.el only. It sets the tags notabug and
> wontfix, and closes the bug. See the User Guide.

Ah, that is useful.

Phil

Re: 4K Bugs

[Stephen Leake]

Michael Albinus <michael.albinus@gmx.de> writes:

>>> "Done" bugs are displayed until they are archived (28 days after being
>>> marjed "done"). You can toggle this behaviour by typing "x". For
>>> "unreproducible" bugs nothing is available, maybe they shall be
>>> suppressed also by typing "x".

>> Ah, okay, it's not all "done" bugs. I was wondering why there were so
>> few. Again, I would toggle the default here. Power users will work it
>> out.
>
> Noted. Will be done.

I think it makes sense for bugs recently changed to "done" to still be
listed.

For example, if I'm interested in a bug, but not subscribed to it, I
will want to notice that it's been marked "done".

That also makes it easier to reactivate it if the status change was in
error.

As long as this is documented, it's a nice feature.

I suspect this is actually a bug manager feature, not a debbugs.el
feature, so it's probably best to briefly mention this in the debbugs
UG, with a link to the bug manager docs that fully describe it.

-- 
-- Stephe

Re: 4K Bugs

[Michael Albinus]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> I think it makes sense for bugs recently changed to "done" to still be
> listed.

They are still retrieved. You can toggle their visibility by hitting "x".

What I will change is that they are suppressed initially. This seems to
be the better default.

> For example, if I'm interested in a bug, but not subscribed to it, I
> will want to notice that it's been marked "done".

Use `debbugs-gnu-bugs' for exactly this bug. Or tag it locally, and see
it when you retrieve those tagged bugs.

Best regards, Michael.