unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* package.el, a bug ? and a UX issue ?
@ 2021-08-20 14:29 Jean-Christophe Helary
  2021-08-20 20:57 ` Stefan Kangas
  0 siblings, 1 reply; 5+ messages in thread
From: Jean-Christophe Helary @ 2021-08-20 14:29 UTC (permalink / raw)
  To: Emacs Devel

1) after filtering on marked packages, clearing the filter removes the marks

After packages-list is updated, using U marks the packages that can be upgraded and a message that looks like this is displayed:

Packages marked for upgrading: 5

When I filter the list with package-menu-filter-marked (/ m) I get the marked list of packages to upgrade.

When I clear the filter with package-menu-clear-filter (/ /) I go back to the original list *but* all the marks for upgrading are gone: when I hit x expecting to be able to install the marked packages, I get "No operations specified"...

package-menu-clear-filter is defined as follows:

(defun package-menu-clear-filter ()
  "Clear any filter currently applied to the \"*Packages*\" buffer."
  (interactive nil package-menu-mode)
  (package--ensure-package-menu-mode)
  (package-menu--generate t t))

Even when I check package-menu--generate I don't see that it is supposed to clear the marks, am I missing something ?

2) The upgrade messages are not very useful

So, the number of packages to upgrade is displayed.

This comes from package-menu--mark-upgrades-1 which has:

(message "Packages marked for upgrading: %d" (length upgrades))

"upgrades" contains a list of new packages including their new version number, but we only have the length of it.

If I hit X now, I have the list of old packages with their old version number and a "upgrade y or n" message that does not leave much room for details. The old version number 

So, I'm wondering if it would not be a better user experience to have the U command above directly display the list of packages with package-menu-filter-marked instead ?

That way, the user can still directly use X to proceed, or eventually go back to the package list and add packages (that's, if the issue 1 above did not exist).

Are the two points above reasonable issues to work on ?


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: package.el, a bug ? and a UX issue ?
  2021-08-20 14:29 package.el, a bug ? and a UX issue ? Jean-Christophe Helary
@ 2021-08-20 20:57 ` Stefan Kangas
  2021-08-20 23:55   ` Jean-Christophe Helary
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Kangas @ 2021-08-20 20:57 UTC (permalink / raw)
  To: Jean-Christophe Helary; +Cc: Emacs Devel

Jean-Christophe Helary <lists@traduction-libre.org> writes:

> 1) after filtering on marked packages, clearing the filter removes the marks
>
> After packages-list is updated, using U marks the packages that can be upgraded and a message that looks like this is displayed:
>
> Packages marked for upgrading: 5
>
> When I filter the list with package-menu-filter-marked (/ m) I get the marked list of packages to upgrade.
>
> When I clear the filter with package-menu-clear-filter (/ /) I go back to the original list *but* all the marks for upgrading are gone: when I hit x expecting to be able to install the marked packages, I get "No operations specified"...

Sounds like a bug to me.

> 2) The upgrade messages are not very useful
>
> So, the number of packages to upgrade is displayed.
>
> This comes from package-menu--mark-upgrades-1 which has:
>
> (message "Packages marked for upgrading: %d" (length upgrades))
>
> "upgrades" contains a list of new packages including their new version number, but we only have the length of it.
>
> If I hit X now, I have the list of old packages with their old version number and a "upgrade y or n" message that does not leave much room for details. The old version number
>
> So, I'm wondering if it would not be a better user experience to have the U command above directly display the list of packages with package-menu-filter-marked instead ?
>
> That way, the user can still directly use X to proceed, or eventually go back to the package list and add packages (that's, if the issue 1 above did not exist).

Makes sense to me.  I'm not sure if we could do better than
package-menu-filter-marked, but perhaps that could be good for a
start.

> Are the two points above reasonable issues to work on ?

I think so, yes.  Both sound like pretty obvious improvements, so
patches would be welcome.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: package.el, a bug ? and a UX issue ?
  2021-08-20 20:57 ` Stefan Kangas
@ 2021-08-20 23:55   ` Jean-Christophe Helary
  2021-08-23 12:33     ` Stefan Kangas
  0 siblings, 1 reply; 5+ messages in thread
From: Jean-Christophe Helary @ 2021-08-20 23:55 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs Devel



> On Aug 21, 2021, at 5:57, Stefan Kangas <stefan@marxist.se> wrote:
> 
> Jean-Christophe Helary <lists@traduction-libre.org> writes:
> 
>> 1) after filtering on marked packages, clearing the filter removes the marks
>> 
>> After packages-list is updated, using U marks the packages that can be upgraded and a message that looks like this is displayed:
>> 
>> Packages marked for upgrading: 5
>> 
>> When I filter the list with package-menu-filter-marked (/ m) I get the marked list of packages to upgrade.
>> 
>> When I clear the filter with package-menu-clear-filter (/ /) I go back to the original list *but* all the marks for upgrading are gone: when I hit x expecting to be able to install the marked packages, I get "No operations specified"...
> 
> Sounds like a bug to me.
> 
>> 2) The upgrade messages are not very useful
>> 
>> So, the number of packages to upgrade is displayed.
>> 
>> This comes from package-menu--mark-upgrades-1 which has:
>> 
>> (message "Packages marked for upgrading: %d" (length upgrades))
>> 
>> "upgrades" contains a list of new packages including their new version number, but we only have the length of it.
>> 
>> If I hit X now, I have the list of old packages with their old version number and a "upgrade y or n" message that does not leave much room for details. The old version number
>> 
>> So, I'm wondering if it would not be a better user experience to have the U command above directly display the list of packages with package-menu-filter-marked instead ?
>> 
>> That way, the user can still directly use X to proceed, or eventually go back to the package list and add packages (that's, if the issue 1 above did not exist).
> 
> Makes sense to me.  I'm not sure if we could do better than
> package-menu-filter-marked, but perhaps that could be good for a
> start.
> 
>> Are the two points above reasonable issues to work on ?
> 
> I think so, yes.  Both sound like pretty obvious improvements, so
> patches would be welcome.

Thank you Stephan, I'll try to produce something in a reasonable time frame. Is it better to file a bug report to make sure the issues are registered somewhere?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: package.el, a bug ? and a UX issue ?
  2021-08-20 23:55   ` Jean-Christophe Helary
@ 2021-08-23 12:33     ` Stefan Kangas
  2021-08-23 13:11       ` Jean-Christophe Helary
  0 siblings, 1 reply; 5+ messages in thread
From: Stefan Kangas @ 2021-08-23 12:33 UTC (permalink / raw)
  To: Jean-Christophe Helary; +Cc: Emacs Devel

Jean-Christophe Helary <lists@traduction-libre.org> writes:

> Thank you Stephan, I'll try to produce something in a reasonable time frame.

Looking forward to see what you come up with.

> Is it better to file a bug report to make sure the issues are registered somewhere?

Yes, it would be useful so that we don't lose track of this and also
record any discussion in any easy to find place.

I'd recommend filing two separate reports to bug-gnu-emacs@gnu.org for
these two issues, and then follow up with the patches there when you
have them.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: package.el, a bug ? and a UX issue ?
  2021-08-23 12:33     ` Stefan Kangas
@ 2021-08-23 13:11       ` Jean-Christophe Helary
  0 siblings, 0 replies; 5+ messages in thread
From: Jean-Christophe Helary @ 2021-08-23 13:11 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Emacs Devel



> On Aug 23, 2021, at 21:33, Stefan Kangas <stefan@marxist.se> wrote:
> 
> Jean-Christophe Helary <lists@traduction-libre.org> writes:
> 
>> Thank you Stephan, I'll try to produce something in a reasonable time frame.
> 
> Looking forward to see what you come up with.
> 
>> Is it better to file a bug report to make sure the issues are registered somewhere?
> 
> Yes, it would be useful so that we don't lose track of this and also
> record any discussion in any easy to find place.
> 
> I'd recommend filing two separate reports to bug-gnu-emacs@gnu.org for
> these two issues, and then follow up with the patches there when you
> have them.

Thank you. I will.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-08-23 13:11 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-20 14:29 package.el, a bug ? and a UX issue ? Jean-Christophe Helary
2021-08-20 20:57 ` Stefan Kangas
2021-08-20 23:55   ` Jean-Christophe Helary
2021-08-23 12:33     ` Stefan Kangas
2021-08-23 13:11       ` Jean-Christophe Helary

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).