Package installation messages

Package installation messages

[Bozhidar Batsov]

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

Hi everyone,

When I updated my Emacs from master a few days ago I noticed that  package
installation has been changed significantly:

* the process starts with the super cryptic message "Transaction started"
* you get no visual indication that something is being done
* package compilation warnings are now to visible
* the process ends with the super cryptic message "Transaction done"

Seems to me we can do a bit better than this.

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

Re: Package installation messages

[Artur Malabarba]

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

> When I updated my Emacs from master a few days ago I noticed that
 package installation has been changed significantly:
>
> * the process starts with the super cryptic message "Transaction started"
> * the process ends with the super cryptic message "Transaction done"

What do you think could make them less cryptic? I'd rather not spam the
echo area with progress reports.

> * you get no visual indication that something is being done

Yes, something should at least be added to the mode line process.

> * package compilation warnings are now to visible

That's intentional. The warnings buffer is still created, but I think it's
bad user experience to pop up a bunch of warnings that are not the user's
fault.

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

Re: Package installation messages

[Dmitry Gutov]

On 05/15/2015 12:23 AM, Bozhidar Batsov wrote:

> Seems to me we can do a bit better than this.

Yes, some of these points have been raised before. Hopefully, they'll be 
resolved before the release.

Here's another scenario:

M-x package-install slime RET.

See nothing of interest happening, try to do something else, maybe open 
a file. While navigating to it, see Emacs seemingly freeze. Press C-g 
instinctively - congrats, you've aborted the installation. Or stopped it 
in an interesting place, I've got some sort of "transfer interrupted" 
message once this way.

Re: Package installation messages

[Artur Malabarba]

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

> Here's another scenario:
>
> M-x package-install slime RET.
>
> See nothing of interest happening, try to do something else, maybe open a
file. While navigating to it, see Emacs seemingly freeze. Press C-g
instinctively - congrats, you've aborted the installation. Or stopped it in
an interesting place, I've got some sort of "transfer interrupted" message
once this way.

Yes, I've been meaning to mention that for a while now.

Now that the async features have been out for a few months, I can say I
like the async refreshing but I'm not a fan of how async installation
turned out (for the exact reasons you mention above). I see 3 options, and
I'd like to know what people think.

1. Keep the feature but disable by default. Async refreshing would still be
enabled.
2. Implement it using a background emacs process. This has been mentioned
here before, it would not cause emacs to hang during the unpacking stage,
and would not be interrupted by C-g.
3. Just revert it. This has the advantage of simplifying the logic. Async
refreshing would still be kept.

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

Re: Package installation messages

[Dmitry Gutov]

On 05/15/2015 02:15 AM, Artur Malabarba wrote:

> Now that the async features have been out for a few months, I can say I
> like the async refreshing but I'm not a fan of how async installation
> turned out (for the exact reasons you mention above). I see 3 options,
> and I'd like to know what people think.

Async refreshing has grown on me too, but it still needs to implement 
retaining the marks set by the user.

> 1. Keep the feature but disable by default. Async refreshing would still
> be enabled.

I'd rather we not keep options for behavior nobody has specifically 
asked for.

> 2. Implement it using a background emacs process. This has been
> mentioned here before, it would not cause emacs to hang during the
> unpacking stage, and would not be interrupted by C-g.

Guess that's an option, if maybe a heavy-weight one.

> 3. Just revert it. This has the advantage of simplifying the logic.
> Async refreshing would still be kept.

IIUC, async installation also performs downloads concurrently, right? 
That would be a useful trait to keep.

Re: Package installation messages

[Stefan Monnier]

>> 1. Keep the feature but disable by default. Async refreshing would still
>> be enabled.
> I'd rather we not keep options for behavior nobody has specifically
> asked for.

I asked for it.  But after using it I agree that it sucks UI-wise.
I think to make it work better, we'd need to make the download and the
install more separate.  E.g. when the download is done, rather than go
ahead and perform the install, inform the user that the download is done
and the install process can proceed, but wait for the user to
explicitly say "install now".


        Stefan

Re: Package installation messages

[Kaushal]

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

@Stefan
I actually like the hassle-free install process. If I mark stuff with `i`
or `U` followed by `x`, I mean to download and install those packages in
one go. I have been spoilt by how it is currently; would be good to at
least have an option to keep it that way.

@Dmitry
I have never needed to do `C-g` while an installation is going on.  But I
can understand how that can cause problem.

@Bozhidar
I also like the clutter-free installation process, without the compilaiton
buffer popping up.
If the "Transaction started" message is cryptic, it can probably be
replaced with something that indicates that package(s) are being installed;
or something like below?

    Package Manager: In progress [upgrade(<num>), install(<num>),
delete(<num>)] ...

Once everything is done,

    Package Manager: Done [Upgraded(<num>), Installed(<num>),
Deleted(<num>)].
@Artur
Regarding the 3 options:
1. I wouldn't mind that as I can always enable that in my emacs config
2. Can't comment on this as I don't understand the how-to or implications
of using a "background process"
3. I believe that people who have the Paradox package installed wouldn't be
affected by this right?


--
Kaushal Modi

On Thu, May 14, 2015 at 10:00 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> 1. Keep the feature but disable by default. Async refreshing would still
> >> be enabled.
> > I'd rather we not keep options for behavior nobody has specifically
> > asked for.
>
> I asked for it.  But after using it I agree that it sucks UI-wise.
> I think to make it work better, we'd need to make the download and the
> install more separate.  E.g. when the download is done, rather than go
> ahead and perform the install, inform the user that the download is done
> and the install process can proceed, but wait for the user to
> explicitly say "install now".
>
>
>         Stefan
>
>

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

Re: Package installation messages

[Bozhidar Batsov]

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

While I can live without the compilation warnings (and many users are
scared by them) I've found and fixed a ton of compilation warnings in
various packages, because they we're displayed so prominently. Maybe this
should be an optional behaviour or they should simply be dumped into
**Messages*.

As for the messages themselves - yeah, anything featuring a summary of the
operation that started and ended would do IMO. Some progress indicator
would be awesome (maybe counting down the operations that are remaining or
something).

On 15 May 2015 at 05:24, Kaushal <kaushal.modi@gmail.com> wrote:

> @Stefan
> I actually like the hassle-free install process. If I mark stuff with `i`
> or `U` followed by `x`, I mean to download and install those packages in
> one go. I have been spoilt by how it is currently; would be good to at
> least have an option to keep it that way.
>
> @Dmitry
> I have never needed to do `C-g` while an installation is going on.  But I
> can understand how that can cause problem.
>
> @Bozhidar
> I also like the clutter-free installation process, without the compilaiton
> buffer popping up.
> If the "Transaction started" message is cryptic, it can probably be
> replaced with something that indicates that package(s) are being installed;
> or something like below?
>
>     Package Manager: In progress [upgrade(<num>), install(<num>),
> delete(<num>)] ...
>
> Once everything is done,
>
>     Package Manager: Done [Upgraded(<num>), Installed(<num>),
> Deleted(<num>)].
> @Artur
> Regarding the 3 options:
> 1. I wouldn't mind that as I can always enable that in my emacs config
> 2. Can't comment on this as I don't understand the how-to or implications
> of using a "background process"
> 3. I believe that people who have the Paradox package installed wouldn't
> be affected by this right?
>
>
> --
> Kaushal Modi
>
> On Thu, May 14, 2015 at 10:00 PM, Stefan Monnier <monnier@iro.umontreal.ca
> > wrote:
>
>> >> 1. Keep the feature but disable by default. Async refreshing would
>> still
>> >> be enabled.
>> > I'd rather we not keep options for behavior nobody has specifically
>> > asked for.
>>
>> I asked for it.  But after using it I agree that it sucks UI-wise.
>> I think to make it work better, we'd need to make the download and the
>> install more separate.  E.g. when the download is done, rather than go
>> ahead and perform the install, inform the user that the download is done
>> and the install process can proceed, but wait for the user to
>> explicitly say "install now".
>>
>>
>>         Stefan
>>
>>
>

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

Re: Package installation messages

[Thierry Volpiatto]

Bozhidar Batsov <bozhidar@batsov.com> writes:

> While I can live without the compilation warnings (and many users are
> scared by them) I've found and fixed a ton of compilation warnings in
> various packages, because they we're displayed so prominently. Maybe this
> should be an optional behaviour or they should simply be dumped into
> **Messages*.

FYI you can compile your packages async and have the compile buffer showing
warnings and errors as normal using async package.
Don't know though what emacs-25 is using actually.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Package installation messages

[Artur Malabarba]

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

>> Now that the async features have been out for a few months, I can say I
>> like the async refreshing but I'm not a fan of how async installation
>> turned out (for the exact reasons you mention above). I see 3 options,
>> and I'd like to know what people think.
>
> Async refreshing has grown on me too, but it still needs to implement
retaining the marks set by the user.

Yes, it needs to be done, and it's on my "next time I have time" list.

>> 3. Just revert it. This has the advantage of simplifying the logic.
>> Async refreshing would still be kept.
>
> IIUC, async installation also performs downloads concurrently, right?
That would be a useful trait to keep.

No, it performs the downloads in sequence. It would be nice if someone made
it concurrent (with or without async).

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

Re: Package installation messages

[Artur Malabarba]

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

On May 15, 2015 3:00 AM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
>
> >> 1. Keep the feature but disable by default. Async refreshing would
still
> >> be enabled.
> > I'd rather we not keep options for behavior nobody has specifically
> > asked for.
>
> I asked for it.  But after using it I agree that it sucks UI-wise.
> I think to make it work better, we'd need to make the download and the
> install more separate. E.g. when the download is done, rather than go
> ahead and perform the install, inform the user that the download is done
> and the install process can proceed, but wait for the user to
> explicitly say "install now".

It'd be nice if someone did this, but that's a non trivial effort atm.
package.el just unpacks the package as soon as it's downloaded, so this
needs to be changed before we can have a prompt between download and
install.

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

Re: Package installation messages

[Artur Malabarba]

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

> @Stefan
> I actually like the hassle-free install process. If I mark stuff with `i`
or `U` followed by `x`, I mean to download and install those packages in
one go. I have been spoilt by how it is currently; would be good to at
least have an option to keep it that way.

Don't worry. Having the opinion to skip a prompt is the easy part.

> @Artur
> 3. I believe that people who have the Paradox package installed wouldn't
be affected by this right?

You are correct. Paradox relies on package.el for async refreshing, but it
does its own thing for async installation, so you wouldn't lose that.

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

Re: Package installation messages

[Dmitry Gutov]

On 05/15/2015 05:00 AM, Stefan Monnier wrote:

> I asked for it.  But after using it I agree that it sucks UI-wise.

I didn't mean to imply that Arthur implemented something entirely unwanted.

> I think to make it work better, we'd need to make the download and the
> install more separate.  E.g. when the download is done, rather than go
> ahead and perform the install, inform the user that the download is done
> and the install process can proceed, but wait for the user to
> explicitly say "install now".

When that happens, will the user still be in the list-packages buffer? 
Or will they have an opportunity to quit and then be surprised by the 
yes-no install prompt?

What you're describing, looking at other applications, sounds more like 
an automated system to download *updates*, so that when the user does 
M-x list-packages, they can immediately install the updates. However, 
that might not be the best idea for us - the MELPA packages, for 
instance, update *very* often.

Re: Package installation messages

[Artur Malabarba]

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

On May 15, 2015 5:49 AM, "Bozhidar Batsov" <bozhidar@batsov.com> wrote:
>
> While I can live without the compilation warnings (and many users are
scared by them) I've found and fixed a ton of compilation warnings in
various packages, because they we're displayed so prominently. Maybe this
should be an optional behaviour or they should simply be dumped into
**Messages*.

Once the whole thing is done, we could say how many warnings occurred along
with the finished message. Not sure what's the appropriate way to count
them though, since they happen between bytecomp and warnings.el.

> As for the messages themselves - yeah, anything featuring a summary of
the operation that started and ended would do IMO. Some progress indicator
would be awesome (maybe counting down the operations that are remaining or
something).

A progress indicator is certainly doable, though its implementation will
have to wait until we decide how to do the installation process.

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

Re: Package installation messages

[Artur Malabarba]

Alright, I think I'll just undo all of the async installation stuff.
I agree with Stefan that download and installation should be more
separate, but (1) I'm unlikely to have time for that before 25.1, and
(2) make transactions synchronous only makes this easier anyway.

After that, I can add a user option to display compilation warnings
again, and I can make the transaction messages more descriptive (as
suggested above (maybe even with progress report)).

Re: Package installation messages

[raman]

Actually it would be sad to see the async package bits go -- it's
*almost* working. Can we live with silenced messages as at present, and
a slightly more descriptive message for "transaction ..." rather than
losing the async goodness?
-- 

Re: Package installation messages

[Bozhidar Batsov]

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

I'm fine with Artur's proposal.

"Almost working" is the same as not working. :-)

On 20 May 2015 at 18:36, raman <raman@google.com> wrote:

> Actually it would be sad to see the async package bits go -- it's
> *almost* working. Can we live with silenced messages as at present, and
> a slightly more descriptive message for "transaction ..." rather than
> losing the async goodness?
> --
>

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

Re: Package installation messages

[Artur Malabarba]

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

On May 20, 2015 4:36 PM, "raman" <raman@google.com> wrote:
>
> Actually it would be sad to see the async package bits go -- it's
> *almost* working. Can we live with silenced messages as at present, and
> a slightly more descriptive message for "transaction ..." rather than
> losing the async goodness?

The messaging stuff is mostly independent of this. The problem is the fact
that it's not really async. After the download is done emacs hangs between
0.5 and 5 seconds while the installation is happening. And that happens for
each download. So it's essentially not really achieving anything, but it
carries the coat of code complexity.

But just to be clear. This is just for package installation. Async
refreshing is much smoother and won't be removed (though it's still due for
a bit of polishing).

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

Re: Package installation messages

[T.V Raman]

thanks for the clarification. Perhaps we should off-load the async
installation to a perl/python/shell script and not let emacs
participate in that dance?
-- 

-- 

Re: Package installation messages

[Artur Malabarba]

2015-05-20 17:39 GMT+01:00 T.V Raman <raman@google.com>:
> thanks for the clarification. Perhaps we should off-load the async
> installation to a perl/python/shell script and not let emacs
> participate in that dance?

Using a background process is certainly possible (though I'd prefer an
elisp script, as I mentioned here before), but it's not likely that
I'll have the time for that. If anyone wants to try, I should be able
to offer helpul guidance because that is what I use on Paradox (it's
not trivial to transfer to package.el because Paradox uses the `async'
package and it's a little hacky).

Re: Package installation messages

[Artur Malabarba]

Here is the patch that I'm about to push. Is it OK that it removes
some arguments from some functions? I think it is, since it was never
on a stable build, but I'm asking anyway.

Subject: [PATCH] * lisp/emacs-lisp/package.el: Revert async package
 transactions

(package-menu-async): Update doc.
(package-install-from-archive, package-download-transaction)
(package-install, package-menu--perform-transaction)
(package-menu-execute): Remove asynchronous functionality.
---
 lisp/emacs-lisp/package.el | 93 ++++++++++++++++------------------------------
 1 file changed, 32 insertions(+), 61 deletions(-)

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 1ab1b4b..faab5c9 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -350,8 +350,9 @@ a sane initial value."

 (defcustom package-menu-async t
   "If non-nil, package-menu will use async operations when possible.
-This includes refreshing archive contents as well as installing
-packages."
+Currently, only the refreshing of archive contents supports
+asynchronous operations.  Package transactions are still done
+synchronously."
   :type 'boolean
   :version "25.1")

@@ -1712,31 +1713,26 @@ if all the in-between dependencies are also in
PACKAGE-LIST."
   "Return the archive containing the package NAME."
   (cdr (assoc (package-desc-archive desc) package-archives)))

-(defun package-install-from-archive (pkg-desc &optional async callback)
-  "Download and install a tar package.
-If ASYNC is non-nil, perform the download asynchronously.
-If CALLBACK is non-nil, call it with no arguments once the
-operation is done."
+(defun package-install-from-archive (pkg-desc)
+  "Download and install a tar package."
   ;; This won't happen, unless the archive is doing something wrong.
   (when (eq (package-desc-kind pkg-desc) 'dir)
     (error "Can't install directory package from archive"))
   (let* ((location (package-archive-base pkg-desc))
          (file (concat (package-desc-full-name pkg-desc)
                        (package-desc-suffix pkg-desc))))
-    (package--with-work-buffer-async location file async
+    (package--with-work-buffer location file
       (if (or (not package-check-signature)
               (member (package-desc-archive pkg-desc)
                       package-unsigned-archives))
           ;; If we don't care about the signature, unpack and we're
           ;; done.
-          (progn (let ((save-silently    async)
-                       (inhibit-message  async))
-                   (package-unpack pkg-desc))
-                 (funcall callback))
+          (let ((save-silently t))
+            (package-unpack pkg-desc))
         ;; If we care, check it and *then* write the file.
         (let ((content (buffer-string)))
           (package--check-signature
-           location file content async
+           location file content nil
            ;; This function will be called after signature checking.
            (lambda (&optional good-sigs)
              (unless (or good-sigs (eq package-check-signature
'allow-unsigned))
@@ -1746,8 +1742,7 @@ operation is done."
                  (package-desc-name pkg-desc)))
              ;; Signature checked, unpack now.
              (with-temp-buffer (insert content)
-                               (let ((save-silently    async)
-                                     (inhibit-message  async))
+                               (let ((save-silently t))
                                  (package-unpack pkg-desc)))
              ;; Here the package has been installed successfully, mark it as
              ;; signed if appropriate.
@@ -1763,9 +1758,7 @@ operation is done."
                (setf (package-desc-signed pkg-desc) t)
                ;; Update the new (activated) pkg-desc as well.
                (when-let ((pkg-descs (cdr (assq (package-desc-name
pkg-desc) package-alist))))
-                 (setf (package-desc-signed (car pkg-descs)) t)))
-             (when (functionp callback)
-               (funcall callback)))))))))
+                 (setf (package-desc-signed (car pkg-descs)) t))))))))))

 (defun package-installed-p (package &optional min-version)
   "Return true if PACKAGE, of MIN-VERSION or newer, is installed.
@@ -1786,25 +1779,13 @@ If PACKAGE is a package-desc object,
MIN-VERSION is ignored."
      ;; Also check built-in packages.
      (package-built-in-p package min-version))))

-(defun package-download-transaction (packages &optional async callback)
+(defun package-download-transaction (packages)
   "Download and install all the packages in PACKAGES.
 PACKAGES should be a list of package-desc.
-If ASYNC is non-nil, perform the downloads asynchronously.
-If CALLBACK is non-nil, call it with no arguments once the
-entire operation is done.
-
 This function assumes that all package requirements in
 PACKAGES are satisfied, i.e. that PACKAGES is computed
 using `package-compute-transaction'."
-  (cond
-   (packages (package-install-from-archive
-              (car packages)
-              async
-              (lambda ()
-                (package-download-transaction (cdr packages))
-                (when (functionp callback)
-                  (funcall callback)))))
-   (callback (funcall callback))))
+  (mapc #'package-install-from-archive packages))

 (defun package--ensure-init-file ()
   "Ensure that the user's init file has `package-initialize'.
@@ -1857,16 +1838,13 @@ add a call to it along with some explanatory comments."
   (setq package--init-file-ensured t))

 ;;;###autoload
-(defun package-install (pkg &optional dont-select async callback)
+(defun package-install (pkg &optional dont-select)
   "Install the package PKG.
 PKG can be a package-desc or the package name of one the available packages
 in an archive in `package-archives'.  Interactively, prompt for its name.

 If called interactively or if DONT-SELECT nil, add PKG to
 `package-selected-packages'.
-If ASYNC is non-nil, perform the downloads asynchronously.
-If CALLBACK is non-nil, call it with no arguments once the
-entire operation is done.

 If PKG is a package-desc and it is already installed, don't try
 to install it but still mark it as selected."
@@ -1899,9 +1877,8 @@ to install it but still mark it as selected."
                   (package-compute-transaction (list pkg)
                                                (package-desc-reqs pkg)))
               (package-compute-transaction () (list (list pkg))))))
-      (package-download-transaction transaction async callback)
-    (message "`%s' is already installed" (package-desc-full-name pkg))
-    (funcall callback)))
+      (package-download-transaction transaction)
+    (message "`%s' is already installed" (package-desc-full-name pkg))))

 (defun package-strip-rcs-id (str)
   "Strip RCS version ID from the version string STR.
@@ -2938,30 +2915,25 @@ nil, but not both."
       (package-menu--list-to-prompt upg)
       "? "))))

-(defun package-menu--perform-transaction (install-list delete-list
&optional async)
-  "Install packages in INSTALL-LIST and delete DELETE-LIST.
-If ASYNC is non-nil, perform the installation downloads
-asynchronously."
+(defun package-menu--perform-transaction (install-list delete-list)
+  "Install packages in INSTALL-LIST and delete DELETE-LIST."
   ;; While there are packages to install, call `package-install' on
   ;; the next one and defer deletion to the callback function.
   (if install-list
-      (let* ((pkg (car install-list))
-             (rest (cdr install-list))
-             ;; Don't mark as selected if it's a new version of an
-             ;; installed package.
-             (dont-mark (and (not (package-installed-p pkg))
-                             (package-installed-p
-                              (package-desc-name pkg)))))
+      (dolist (pkg install-list)
         (package-install
-         pkg dont-mark async
-         (lambda () (package-menu--perform-transaction rest
delete-list async))))
-    (let ((inhibit-message async))
-      ;; Once there are no more packages to install, proceed to
-      ;; deletion.
-      (dolist (elt (package--sort-by-dependence delete-list))
-        (condition-case-unless-debug err
-            (package-delete elt)
-          (error (message (cadr err))))))
+         ;; Don't mark as selected if it's a new version of an
+         ;; installed package.
+         pkg (and (not (package-installed-p pkg))
+                  (package-installed-p
+                   (package-desc-name pkg)))))
+    ;; Once there are no more packages to install, proceed to
+    ;; deletion.
+    (dolist (elt (package--sort-by-dependence delete-list))
+      (condition-case-unless-debug err
+          (let ((inhibit-message t))
+            (package-delete elt))
+        (error (message (cadr err)))))
     (message "Transaction done")
     (when package-selected-packages
       (when-let ((removable (package--removable-packages)))
@@ -2997,8 +2969,7 @@ Optional argument NOQUERY non-nil means do not
ask the user to confirm."
               (package-menu--prompt-transaction-p install-list delete-list))
       (message "Transaction started")
       ;; This calls `package-menu--generate' after everything's done.
-      (package-menu--perform-transaction
-       install-list delete-list package-menu-async))))
+      (package-menu--perform-transaction install-list delete-list))))

 (defun package-menu--version-predicate (A B)
   (let ((vA (or (aref (cadr A) 1)  '(0)))
-- 
2.4.1

Re: Package installation messages

[Dmitry Gutov]

On 05/20/2015 11:02 PM, Artur Malabarba wrote:
> Here is the patch that I'm about to push. Is it OK that it removes
> some arguments from some functions? I think it is, since it was never
> on a stable build, but I'm asking anyway.

"Never was in a stable build" is a good criterion.

Re: Package installation messages

[Kaushal]

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

I thought some more about this. I think that more than the async install
and download, I like the fact that once I hit `x` in the package manager
after choosing what to install/delete,  I can just sit back and wait for
the process to complete neatly by itself without needing any more input and
without popping up any compilation windows and such. It's good to see a
nice summary message at the end to know what the package manager did.

On Wed, May 20, 2015, 4:05 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05/20/2015 11:02 PM, Artur Malabarba wrote:
> > Here is the patch that I'm about to push. Is it OK that it removes
> > some arguments from some functions? I think it is, since it was never
> > on a stable build, but I'm asking anyway.
>
> "Never was in a stable build" is a good criterion.
>
>

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

Re: Package installation messages

[Artur Malabarba]

Alright, pushed.
Just for future record, in case anyone ever tries this again, the
commit that removed async transactions was:
    Commit 0060c0d7b15ed1510583eb738baa0c9bf9f02721
And the one before that is
    Commit 6f4b0e8153c8e83d03ed1c3c37065e5bf56685f1

Re: Package installation messages

[Kaushal]

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

I just updated to the latest commit on emacs master and tried out
package-autoremove.

That suggested removing 3 packages (symon, minibuffer-line,
git-timemachine), out of which I actually use 2: minibuffer-line,
git-timemachine.

For example, I have this in my init:

;; Display date+time in the minibuffer instead of in the mode-line
(use-package minibuffer-line
  :if (null modi/show-date-time-in-mode-line)
  :defer 1 ; to prevent 'Invalid face reference: minibuffer-line'
                                        ; when launching emacsclient
  :init
  (progn
    (setq minibuffer-line-format '((:eval (format-time-string "%l:%M %b %d
%a")))))
  :config
  (progn
    (set-face-attribute 'minibuffer-line nil :inherit font-lock-type-face)
    (minibuffer-line-mode)))


On Thu, May 21, 2015 at 5:03 AM Artur Malabarba <bruce.connor.am@gmail.com>
wrote:

> Alright, pushed.
> Just for future record, in case anyone ever tries this again, the
> commit that removed async transactions was:
>     Commit 0060c0d7b15ed1510583eb738baa0c9bf9f02721
> And the one before that is
>     Commit 6f4b0e8153c8e83d03ed1c3c37065e5bf56685f1
>
>

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

Re: Package installation messages

[Kaushal]

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

Looks like some how those 3 packages did not get added to
package-selected-packages when I installed them. Or they did not get saved
to custom.el.

On Thu, May 21, 2015 at 10:35 AM Kaushal <kaushal.modi@gmail.com> wrote:

> I just updated to the latest commit on emacs master and tried out
> package-autoremove.
>
> That suggested removing 3 packages (symon, minibuffer-line,
> git-timemachine), out of which I actually use 2: minibuffer-line,
> git-timemachine.
>
> For example, I have this in my init:
>
> ;; Display date+time in the minibuffer instead of in the mode-line
> (use-package minibuffer-line
>   :if (null modi/show-date-time-in-mode-line)
>   :defer 1 ; to prevent 'Invalid face reference: minibuffer-line'
>                                         ; when launching emacsclient
>   :init
>   (progn
>     (setq minibuffer-line-format '((:eval (format-time-string "%l:%M %b %d
> %a")))))
>   :config
>   (progn
>     (set-face-attribute 'minibuffer-line nil :inherit font-lock-type-face)
>     (minibuffer-line-mode)))
>
>
> On Thu, May 21, 2015 at 5:03 AM Artur Malabarba <bruce.connor.am@gmail.com>
> wrote:
>
>> Alright, pushed.
>> Just for future record, in case anyone ever tries this again, the
>> commit that removed async transactions was:
>>     Commit 0060c0d7b15ed1510583eb738baa0c9bf9f02721
>> And the one before that is
>>     Commit 6f4b0e8153c8e83d03ed1c3c37065e5bf56685f1
>>
>>

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

Re: Package installation messages

[Kaushal]

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

Also all 3 of those packages have the status as "dependency" even when no
other package requires them. I had installed those packages using the
package manager; they did not get auto installed.

On Thu, May 21, 2015 at 10:46 AM Kaushal <kaushal.modi@gmail.com> wrote:

> Looks like some how those 3 packages did not get added to
> package-selected-packages when I installed them. Or they did not get saved
> to custom.el.
>
> On Thu, May 21, 2015 at 10:35 AM Kaushal <kaushal.modi@gmail.com> wrote:
>
>> I just updated to the latest commit on emacs master and tried out
>> package-autoremove.
>>
>> That suggested removing 3 packages (symon, minibuffer-line,
>> git-timemachine), out of which I actually use 2: minibuffer-line,
>> git-timemachine.
>>
>> For example, I have this in my init:
>>
>> ;; Display date+time in the minibuffer instead of in the mode-line
>> (use-package minibuffer-line
>>   :if (null modi/show-date-time-in-mode-line)
>>   :defer 1 ; to prevent 'Invalid face reference: minibuffer-line'
>>                                         ; when launching emacsclient
>>   :init
>>   (progn
>>     (setq minibuffer-line-format '((:eval (format-time-string "%l:%M %b
>> %d %a")))))
>>   :config
>>   (progn
>>     (set-face-attribute 'minibuffer-line nil :inherit font-lock-type-face)
>>     (minibuffer-line-mode)))
>>
>>
>> On Thu, May 21, 2015 at 5:03 AM Artur Malabarba <
>> bruce.connor.am@gmail.com> wrote:
>>
>>> Alright, pushed.
>>> Just for future record, in case anyone ever tries this again, the
>>> commit that removed async transactions was:
>>>     Commit 0060c0d7b15ed1510583eb738baa0c9bf9f02721
>>> And the one before that is
>>>     Commit 6f4b0e8153c8e83d03ed1c3c37065e5bf56685f1
>>>
>>>

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