Re: using use-package

Re: using use-package

[Rusi]

On Tuesday, August 4, 2015 at 8:31:52 PM UTC+5:30, Sharon Kimble wrote:
> I am having great difficulty in getting "use-package" to work
> successfully.

Just adding one more voice here:
use-package seems like a wonderful tool to clean up one's init.
But we need many more recipes.

I find something like that here https://github.com/edvorg/req-package
which seems to have gone further than use-package but has its own limitations.

Also it would be good to have something like these in emacs-core --- Please!

I will be teaching programming again. I would really appreciate if I can 
'hand-out' pieces of config that are shorter, neater, less-interdependent
than my higgledy-piggledy init-mess

Re: using use-package

[Ian Zimmerman]

On 2015-08-04 22:35 -0700, Rusi wrote:

> I will be teaching programming again. I would really appreciate if I
> can 'hand-out' pieces of config that are shorter, neater,
> less-interdependent than my higgledy-piggledy init-mess

That way lies Ubuntu - an ancient African word meaning "much simpler
than the simplest possible".

:-P

-- 
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

Re: using use-package

[Rusi]

On Wednesday, August 5, 2015 at 11:27:57 AM UTC+5:30, Ian Zimmerman wrote:
> On 2015-08-04 22:35 -0700, Rusi wrote:
> 
> > I will be teaching programming again. I would really appreciate if I
> > can 'hand-out' pieces of config that are shorter, neater,
> > less-interdependent than my higgledy-piggledy init-mess
> 
> That way lies Ubuntu - an ancient African word meaning "much simpler
> than the simplest possible".
> 
> :-P

I get that you are making a joke... But I dont get it :-(
Is it that...
 - Using use-package oversimplifies?
 - Inits can only be higgledy-piggledy messes?
 - Just use the emacs packages from ubuntu and to hell with emacs-packages (from emacs)?
 - More interdependent is better? [Yeah some out here prefer let* to let ]

Re: using use-package

[Ian Zimmerman]

On 2015-08-05 09:34 -0700, Rusi wrote:

> > That way lies Ubuntu - an ancient African word meaning "much simpler
> > than the simplest possible".

> I get that you are making a joke... But I dont get it :-(
> Is it that...
>  - Using use-package oversimplifies?

Maybe not right now, but promoting it as the one and true way of
configuring emacs would eventually lead to a state where some things are
no longer possible, or (and this is the Ubuntu way) they are _officially
supposed_ to be possible, but because hardly anybody does them they're
untested and unsupported by the developers.

Emacs is full of interdependencies by its nature.  Things like adaptive
fill, global font lock, imenu, work slightly differently in each mode
depending on configuration of that mode.  There's a plausible argument
that this is a misdesign, but it is far too deeply ingrained now to
change, IMO.

Also the use of dynamic scoping plays into this.  Much code was
intentionally written so that the way to change its behavior (sometimes
the only way) is to let-bind a global variable.  case-fold is a classic
example.  It is not clear to me how partitioning configuration into
packages can deal with this.

-- 
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

Re: using use-package

[Rusi]

On Wednesday, August 5, 2015 at 10:54:33 PM UTC+5:30, Ian Zimmerman wrote:
> On 2015-08-05 09:34 -0700, Rusi wrote:
> 
> > > That way lies Ubuntu - an ancient African word meaning "much simpler
> > > than the simplest possible".
> 
> > I get that you are making a joke... But I dont get it :-(
> > Is it that...
> >  - Using use-package oversimplifies?
> 
> Maybe not right now, but promoting it as the one and true way of
> configuring emacs would eventually lead to a state where some things are
> no longer possible, or (and this is the Ubuntu way) they are _officially
> supposed_ to be possible, but because hardly anybody does them they're
> untested and unsupported by the developers.

Strange logic.
Putting in the core is rather some distance from promoting as the "one true
way" 

Analogy: Some ifs can be shortened to when/unless/and etc but not all.
Should when/unless/and be banned since people forget how to use if?

> 
> Emacs is full of interdependencies by its nature.  Things like adaptive
> fill, global font lock, imenu, work slightly differently in each mode
> depending on configuration of that mode.  There's a plausible argument
> that this is a misdesign, but it is far too deeply ingrained now to
> change, IMO.
> 
> Also the use of dynamic scoping plays into this.  Much code was
> intentionally written so that the way to change its behavior (sometimes
> the only way) is to let-bind a global variable.  case-fold is a classic
> example.  It is not clear to me how partitioning configuration into
> packages can deal with this.

Old users of emacs forget that many potential new users never cross
the potential barrier to becoming actual users because of initial (includes
 init!) complexity

Re: using use-package

[Ian Zimmerman]

On 2015-08-05 18:34 -0700, Rusi wrote:

> Putting in the core is rather some distance from promoting as the "one
> true way"

Ok, so please specify what you mean by "putting in the core".

The kinds of things that you need to manually change when starting to
use a new package (and so the things for which use-package is useful, I
guess) are twofold: autoloads of functions, and items in global lists
such as auto-mode-alist and compilation-error-regexp-alist.  But you
don't need to add either for modules in the core, both are already set
up for you.

Everything else can be done with customizable options.  Or do I forget
something? 

> Analogy: Some ifs can be shortened to when/unless/and etc but not all.
> Should when/unless/and be banned since people forget how to use if?

:-) Actually it's if that I would ban, it's asymmetric and ugly.  Use
cond when when/unless don't fit.

> Old users of emacs forget that many potential new users never cross
> the potential barrier to becoming actual users because of initial
> (includes init!) complexity

I don't buy this "new users" argument in the context of free software,
and there are good counterexamples (Gnome).

-- 
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

Re: using use-package

[Rusi]

On Thursday, August 6, 2015 at 7:25:06 AM UTC+5:30, Ian Zimmerman wrote:
> On 2015-08-05 18:34 -0700, Rusi wrote:
> 
> > Putting in the core is rather some distance from promoting as the "one
> > true way"
> 
> Ok, so please specify what you mean by "putting in the core".

After apt-get install emacs
use-package should be available
Likewise in windows after downloading and unzipping

Re: using use-package

[Grant Rettke]

When you add MELPA it is available via `list-packages' which is very nice.
Grant Rettke
--
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
“All creativity is an extended form of a joke.” --Kay
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson


On Thu, Aug 6, 2015 at 12:06 AM, Rusi <rustompmody@gmail.com> wrote:
> On Thursday, August 6, 2015 at 7:25:06 AM UTC+5:30, Ian Zimmerman wrote:
>> On 2015-08-05 18:34 -0700, Rusi wrote:
>>
>> > Putting in the core is rather some distance from promoting as the "one
>> > true way"
>>
>> Ok, so please specify what you mean by "putting in the core".
>
> After apt-get install emacs
> use-package should be available
> Likewise in windows after downloading and unzipping

Re: using use-package

[Rusi]

> On Thu, Aug 6, 2015 at 12:06 AM, Rusi  wrote:
> > On Thursday, August 6, 2015 at 7:25:06 AM UTC+5:30, Ian Zimmerman wrote:
> >> On 2015-08-05 18:34 -0700, Rusi wrote:
> >>
> >> > Putting in the core is rather some distance from promoting as the "one
> >> > true way"
> >>
> >> Ok, so please specify what you mean by "putting in the core".
> >
> > After apt-get install emacs
> > use-package should be available
> > Likewise in windows after downloading and unzipping


On Saturday, August 8, 2015 at 1:41:23 AM UTC+5:30, Grant Rettke wrote:
> When you add MELPA it is available via `list-packages' which is very nice.
> Grant Rettke

Thanks Grant

Can you share (the relevant pieces of) your init??

I tried use-package
Then found req-package via looking for recipes for use-package.
Which seems/claims to have to have superceded use-package.
Except that it has 'recursion' problems...
Viz. req-package requires dash, log4e
So one has either
- handle it outside the package system
- do it once by hand and then point to the
  ~/.emacs.d/elpa/dash-major.minor.patch
  And expect it will break when the version-numbers change

Personally I can handle this
However for my completely beginner students this would just add to the 
overwhelming nature of emacs
So for now I think I put aside req-package and stick to use-package
[And would appreciate tips]

Re: using use-package

[Stefan Monnier]

> Putting in the core is rather some distance from promoting as the "one
> true way"

FWIW, lots of use-package is designed to work around flaws in packages.

E.g. the :load-path thingy should never be necessary since the package's
own autoloads should already take care of that.

Or to take another example from https://github.com/jwiegley/use-package:

   (use-package foo
     :init
     (setq foo-variable t)
     :config
     (foo-mode 1))

For any properly written foo-mode, the above can be replaced with

     (setq foo-variable t)
     (foo-mode 1)

and it should work just as well.


IOW, in many cases, it would be better for people to report the problem
as a bug rather than to reach for use-package.


        Stefan

Re: using use-package

[Grant Rettke]

On Sat, Aug 8, 2015 at 6:24 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> FWIW, lots of use-package is designed to work around flaws in packages.

In my configuration it works around flaws in my understanding of how
best to use EMACS and packages. Not confessing here, but use-packages
forces me to question how I am doing it. Usually I see that I was
doing it wrong. Knowing that it is a macro, and that is uses `package'
underneath, you know that you can do it all without using
`use-package'.

Today I used `use-package' to create an autoload for `pp-display-expression'.

Re: using use-package

[Phillip Lord]

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

>> Putting in the core is rather some distance from promoting as the "one
>> true way"
>
> FWIW, lots of use-package is designed to work around flaws in packages.
>
> E.g. the :load-path thingy should never be necessary since the package's
> own autoloads should already take care of that.

You are correct about the :load-path thingy, although I use this for my
own packages which I run "straight from source" as it where, rather than
install as a ELPA package proper.


> Or to take another example from https://github.com/jwiegley/use-package:
>
>    (use-package foo
>      :init
>      (setq foo-variable t)
>      :config
>      (foo-mode 1))
>
> For any properly written foo-mode, the above can be replaced with
>
>      (setq foo-variable t)
>      (foo-mode 1)
>
> and it should work just as well.


No, you are missing (several) points of use-package. First (and
trivially) the use-package statement groups everything syntactically.
So, it's more like:

(progn
  (setq foo-variable t)
  (foo-mode 1))

This is nicer because it groups all the configuration together, so you
can move, comment, delete or eval it all together. Of course, `progn'
achieves the same thing.

However, `use-package' also gives you configurable feedback on load
times. So if (require 'foo) takes a long time, use-package tells you,
and tells you how long it takes.

In your example,

(foo-mode 1)

will force an autoload. With use-package, also I can do

(use-package foo
  :defer t
  ;;;etc
  )

which will achieve the same. Or

(use-package foo
  :defer 10)

will load foo in the idle cycle.

Or

(use-package foo
  :ensure t)

will install from ELPA if `foo' is not present.

Or

(use-package foo
  :if window-system)

will only load foo (and run the configuration) conditionally.

use-package is entirely complementary to existing package system. But,
it suffers from bootstrap. It's obviously not possible to do

(use-package use-package
  :ensure t)

or configure use-package in any other way with use-package. Instead, you
have to do:

(require 'package)

(add-to-list 'package-archives
             '("melpa-stable" . "http://stable.melpa.org/packages/") t)

(when (not (package-installed-p 'use-package))
    (package-install 'use-package))

Re: using use-package

[Stefan Monnier]

> No, you are missing (several) points of use-package.

I didn't miss those points.  I was just pointing out that use-package
won't make it into core as is because too much of it provides ways to do
things which should be done some other way.


        Stefan

Re: using use-package

[Phillip Lord]

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

>> No, you are missing (several) points of use-package.
>
> I didn't miss those points.

Apologies.

> I was just pointing out that use-package won't make it into core as is
> because too much of it provides ways to do things which should be done
> some other way.

So, :load-path, you have a valid point, although this is still useful.
Maybe :mode also (although it is hard for some modes to be exhaustive
about extensions). And :command. I think I only use these when I use my
own packages.

But :config, :init, :defer, :disabled and :ensure are really fantastic.
And with use-package the way that it is now, if these were in core, it
would be a big boon. The others could be separated into a secondary
package if necessary and ELPA'd. This could be loaded by use-package
without bootstrap issues, I think. This would also work for req-package
users.

As always, am willing to help if you and the use-package devs are
interested in this.

Phil

Re: using use-package

[Rusi]

On Tuesday, August 11, 2015 at 2:55:50 AM UTC+5:30, Stefan Monnier wrote:
> > No, you are missing (several) points of use-package.
> 
> I didn't miss those points.  I was just pointing out that use-package
> won't make it into core as is because too much of it provides ways to do
> things which should be done some other way.
> 
> 
>         Stefan

Returning to this old thread:
I was trying to do:

(global-set-key (kbd "C-x C-b") 'electric-buffer-list)
(define-key electric-buffer-menu-mode-map (kbd "X") 'save-buffers-kill-emacs)

1st line -- ok
2nd naturally gives an error on startup

Symbol's value as variable is void: ...

I finally came to:

(use-package ebuff-menu
  :bind (("C-x C-b" . electric-buffer-list)
	 :map electric-buffer-menu-mode-map
	 ("X" . save-buffers-kill-emacs)))


So what's the correct non-use-package way of doing this?

Re: using use-package

[Phillip Lord]

On Tue, June 28, 2016 2:02 pm, Rusi wrote:
> On Tuesday, August 11, 2015 at 2:55:50 AM UTC+5:30, Stefan Monnier wrote:

>
> Returning to this old thread:
> I was trying to do:
>
>
> (global-set-key (kbd "C-x C-b") 'electric-buffer-list)
> (define-key electric-buffer-menu-mode-map (kbd "X")
> 'save-buffers-kill-emacs)
>
>
> 1st line -- ok
> 2nd naturally gives an error on startup
>

`eval-after-load' or `with-eval-after-load'.

use-package does this nicely, though. I've reduced my eval-after-load
usage substantially for use-package.

Re: using use-package

[Rusi]

On Tuesday, June 28, 2016 at 6:40:47 PM UTC+5:30, Phil Lord wrote:
> On Tue, June 28, 2016 2:02 pm, Rusi wrote:
> > On Tuesday, August 11, 2015 at 2:55:50 AM UTC+5:30, Stefan Monnier wrote:
> 
> >
> > Returning to this old thread:
> > I was trying to do:
> >
> >
> > (global-set-key (kbd "C-x C-b") 'electric-buffer-list)
> > (define-key electric-buffer-menu-mode-map (kbd "X")
> > 'save-buffers-kill-emacs)
> >
> >
> > 1st line -- ok
> > 2nd naturally gives an error on startup
> >
> 
> `eval-after-load' or `with-eval-after-load'.
> 
> use-package does this nicely, though. I've reduced my eval-after-load
> usage substantially for use-package.

Well I would have thought that needing eval-after-load and relatives
is evidence of a badly written (in Stefan's sense) package

For myself (as you seem to say) if use-package reduces all that imperative
gunk I guess I'll use it

Re: using use-package

[Phillip Lord]

On Tue, June 28, 2016 2:14 pm, Rusi wrote:
> On Tuesday, June 28, 2016 at 6:40:47 PM UTC+5:30, Phil Lord wrote:
>
>> On Tue, June 28, 2016 2:02 pm, Rusi wrote:
>>
>>> On Tuesday, August 11, 2015 at 2:55:50 AM UTC+5:30, Stefan Monnier
>>> wrote:
>>>
>>
>>>
>>> Returning to this old thread:
>>> I was trying to do:
>>>
>>>
>>>
>>> (global-set-key (kbd "C-x C-b") 'electric-buffer-list)
>>> (define-key electric-buffer-menu-mode-map (kbd "X")
>>> 'save-buffers-kill-emacs)
>>>
> Well I would have thought that needing eval-after-load and relatives
> is evidence of a badly written (in Stefan's sense) package

AFAICT, the error here is happening because electirc-buffer-menu-mode-map
has not been loaded?

The package could autoload it, but if all packages do this, then it would
slow autoloads somewhat. So, I am not clear here that this is a problem
with the package. Perhaps there is a better solution.


> For myself (as you seem to say) if use-package reduces all that
> imperative gunk I guess I'll use it

I've listened to Stefan's criticism of use-package, and they are valid. I
still use use-package, but I have promised myself that everytime I find
myself using it to fix a package, I submit a bug report, or patch to the
package.

Re: using use-package

[Stefan Monnier]

>> Well I would have thought that needing eval-after-load and relatives
>> is evidence of a badly written (in Stefan's sense) package

I do think it's a problem, but admittedly, the way keymaps are normally
setup there's no standard&easy way for the package to "do the right thing".

IOW it's a failure of the general infrastructure offered by Emacs to
define and modify keymaps.  I'd encourage anyone to try and come up with
a good solution to this problem (it'll probably require changing "all"
packages to use a new way to declare keymaps, but I think it's a price
worth paying).

>> For myself (as you seem to say) if use-package reduces all that
>> imperative gunk I guess I'll use it

As for me, I don't think

    (global-set-key (kbd "C-x C-b") 'electric-buffer-list)
    (with-eval-after-load 'buff-menu
      (define-key electric-buffer-menu-mode-map
                  (kbd "X") 'save-buffers-kill-emacs))

is really worse than

    (use-package ebuff-menu
      :bind (("C-x C-b" . electric-buffer-list)
             :map electric-buffer-menu-mode-map
             ("X" . save-buffers-kill-emacs)))

especially if you consider that the former uses functions and syntax
which is used throughout Emacs, whereas the latter uses a syntax that's
defined in an ad-hoc manner for use-package and isn't used elsewhere.

It's also unclear how/why one of the bindings is available immediately
while the other is only activated later (i.e. there's a bit too much
ad-hoc magic for my taste).  If the "X" binding could be auto-activated
when the electric-buffer-menu-mode-map keymap is defined it would be
much better but that would require getting away from using
eval-after-load internally.


        Stefan

Re: using use-package

[Phillip Lord]

On Tue, June 28, 2016 11:05 pm, Stefan Monnier wrote:
>>> Well I would have thought that needing eval-after-load and relatives
>>> is evidence of a badly written (in Stefan's sense) package

Yeah, I missed the "not" in this paragraph.

> I do think it's a problem, but admittedly, the way keymaps are normally
> setup there's no standard&easy way for the package to "do the right
> thing".

But not evidence of a badly written package:-)

> IOW it's a failure of the general infrastructure offered by Emacs to
> define and modify keymaps.  I'd encourage anyone to try and come up with a
> good solution to this problem (it'll probably require changing "all"
> packages to use a new way to declare keymaps, but I think it's a price
> worth paying).



>>> For myself (as you seem to say) if use-package reduces all that
>>> imperative gunk I guess I'll use it
>
> As for me, I don't think
>
>
> (global-set-key (kbd "C-x C-b") 'electric-buffer-list)
> (with-eval-after-load 'buff-menu
> (define-key electric-buffer-menu-mode-map
> (kbd "X") 'save-buffers-kill-emacs))
>
>
> is really worse than
>
> (use-package ebuff-menu
> :bind (("C-x C-b" . electric-buffer-list)
> :map electric-buffer-menu-mode-map
> ("X" . save-buffers-kill-emacs)))


> especially if you consider that the former uses functions and syntax which
> is used throughout Emacs, whereas the latter uses a syntax that's defined
> in an ad-hoc manner for use-package and isn't used elsewhere.



use-package adds a bit of functionality (M-x
describe-personal-keybindings). Of course, this only works because the
latter is not used elsewhere.

I agree it's marginal here.

Phil

Re: using use-package

[Stefan Monnier]

>>>> Well I would have thought that needing eval-after-load and relatives
>>>> is evidence of a badly written (in Stefan's sense) package
> Yeah, I missed the "not" in this paragraph.
>> I do think it's a problem, but admittedly, the way keymaps are normally
>> setup there's no standard&easy way for the package to "do the right
>> thing".
> But not evidence of a badly written package:-)

Not until "the right thing to do" is designed and implemented, no.


        Stefan

Re: using use-package

[Phillip Lord]

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

>>>>> Well I would have thought that needing eval-after-load and relatives
>>>>> is evidence of a badly written (in Stefan's sense) package
>> Yeah, I missed the "not" in this paragraph.
>>> I do think it's a problem, but admittedly, the way keymaps are normally
>>> setup there's no standard&easy way for the package to "do the right
>>> thing".
>> But not evidence of a badly written package:-)
>
> Not until "the right thing to do" is designed and implemented, no.

What about something like this below? We can now do something like:

(extend-key 'fake-feature-map "\C-f" 'foward-char)

It has the same syntax as define-key but works whether fake-feature-map
has been defined or not. Could be macro'd to remove the quote, of course.

Phil


(defvar extend-key--pending-definitions nil
  "Key definitions to occur on load")

(defun extend-key--define-now (keymap-symbol key def)
  "In KEYMAP-SYMBOL define KEY with definition DEF."
  (define-key (symbol-value keymap-symbol) key def))

(defun extend-key--define-later (keymap-symbol key def)
  "In KEYMAP-SYMBOL define KEY with definition DEF, once
KEYMAP-SYMBOL has been defined."
  (setq
   extend-key--pending-definitions
   (cons
    (list keymap-symbol key def)
    extend-key--pending-definitions)))

(defun extend-key--after-load-function (_)
  (setq extend-key--pending-definitions
        (seq-filter
         (lambda (n)
           (seq-let
               [keymap-symbol key def] n
             (when (extend-key--boundp keymap-symbol)
               (extend-key--define-now keymap-symbol key def))))
         extend-key--pending-definitions)))

(add-hook 'after-load-functions
          'extend-key--after-load-function)

(defun extend-key--boundp (keymap-symbol)
  (or (boundp keymap-symbol)
      (fboundp keymap-symbol)))

(defun extend-key (keymap-symbol key def)
  "When KEYMAP-SYMBOL is defined, define key sequence KEY as DEF."
  (if (extend-key--boundp keymap-symbol)
      (extend-key--define-now keymap-symbol key def)
    (extend-key--define-later keymap-symbol key def)))

RE: using use-package

[Drew Adams]

> What about something like this below? We can now do something like:
> (extend-key 'fake-feature-map "\C-f" 'foward-char)
> It has the same syntax as define-key

Not really.  The first arg to `define-key' is a keymap.
The first arg to your `extend-key' is a symbol.

RE: using use-package

[Phillip Lord]

On Wed, June 29, 2016 6:15 pm, Drew Adams wrote:
>> What about something like this below? We can now do something like:
>> (extend-key 'fake-feature-map "\C-f" 'foward-char)
>> It has the same syntax as define-key
>>
>
> Not really.  The first arg to `define-key' is a keymap.
> The first arg to your `extend-key' is a symbol.

Yes, of course. It has to be macro'd to avoid that. Easily done.

Just a starter for 10, alternatives welcome.

Phil

Re: using use-package

[Stefan Monnier]

> What about something like this below? We can now do something like:
[...]
> (add-hook 'after-load-functions
>           'extend-key--after-load-function)

Still relies basically on eval-after-load, which I think is brittle
(and ugly).  I think a cleaner way would be to introduce
a `define-keymap'.


        Stefan

Re: using use-package

[Stefan Monnier]

> Still relies basically on eval-after-load, which I think is brittle
> (and ugly).  I think a cleaner way would be to introduce
> a `define-keymap'.

Or (defcustom ... :type 'keymap)


        Stefan

Re: using use-package

[Phillip Lord]

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

>> What about something like this below? We can now do something like:
> [...]
>> (add-hook 'after-load-functions
>>           'extend-key--after-load-function)
>
> Still relies basically on eval-after-load, which I think is brittle
> (and ugly).


Oh, sure. But it requires no support at the other end -- it will work
with existing packages. I think we need something that has this
capability. I can see no way of achieving this wit 


> I think a cleaner way would be to introduce a `define-keymap'.


I'd agree with this. It would be simple to get this to work with
something like extend-key so that

(extend-key my-mode-map "e" 'excellent)

(define-keymap my-mode-map)

would work, without the use of the after-load-functions hook.

Phil
     
               

Re: using use-package

[Stefan Monnier]

> Oh, sure. But it requires no support at the other end -- it will work
> with existing packages. I think we need something that has this
> capability. I can see no way of achieving this wit 

I agree that it would be difficult to make it work right without
changing the packages's source code.  But I'd rather make it work right.

>> I think a cleaner way would be to introduce a `define-keymap'.
> I'd agree with this.  It would be simple to get this to work with
> something like extend-key so that
>
> (extend-key my-mode-map "e" 'excellent)
>
> (define-keymap my-mode-map)
>
> would work, without the use of the after-load-functions hook.

Yes, that sounds good.


        Stefan

Re: using use-package

[Andreas Röhler]

On 29.06.2016 00:05, Stefan Monnier wrote:
>>> Well I would have thought that needing eval-after-load and relatives
>>> is evidence of a badly written (in Stefan's sense) package
> I do think it's a problem, but admittedly, the way keymaps are normally
> setup there's no standard&easy way for the package to "do the right thing".
>
> IOW it's a failure of the general infrastructure offered by Emacs to
> define and modify keymaps.  I'd encourage anyone to try and come up with
> a good solution to this problem (it'll probably require changing "all"
> packages to use a new way to declare keymaps, but I think it's a price
> worth paying).

Started a project "general-key"

https://github.com/andreas-roehler/werkstatt/tree/master/general-key

designed to deliver just one key for all related commands in all modes.

This permits to change a key at a single place for all.

Still pre-alpha in many parts, but working as far as written.

The backside: it requires to link the keys of the modes at least once.
But still better than learning different keys/commands for common 
navigations like statement, block or expression.

Re: using use-package

[John Wiegley]

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

> FWIW, lots of use-package is designed to work around flaws in packages.

Hi Stefan,

use-package was designed to offer sane and fast Emacs configurations. I did
not think of other packages as being flawed when I wrote it; I simply asked
myself how I wanted Emacs to behave when configuring packages.

For example, I can say ":disabled t" and everything about a package will be
dropped from my configuration. It won't be on my load-path, or available as an
autoload, nothing. Nor do I have to delete the package, or move it out of the
way, for this exclusion to happen: the decision is based entirely on my
use-package configuration.

And because of the modularity in 2.0 (i.e., keywords and related support can
be added or dropped as desired), it's not fixed in the design space. If
inclusion into core meant moving :load-path support to an ELPA add-on, that's
entirely possible.

> E.g. the :load-path thingy should never be necessary since the package's own
> autoloads should already take care of that.

I happen to prefer :load-path, since relying on Emacs' automated discovery
takes longer than loading my entire init.el now. I have tons of Emacs software
in my .emacs.d, and only use a fraction of it on any given system. One thing
use-package does is to confine load-time configuration to just those packages
I'm using for the machine I'm starting Emacs on, even though I've cloned the
same set of packages everywhere.

> IOW, in many cases, it would be better for people to report the problem as a
> bug rather than to reach for use-package.

The idea that use-package will never make it into core because "package
authors should do things a better way" strikes me as a very odd argument.
use-package lets me write modular code to solve every configuration problem I
run into; am I really supposed to not do this, because things should ideally
be better than they are? That's a bit like saying we shouldn't have locks on
our doors, because it downplays a deeper issue: that we should convince people
not to steal.

John

p.s. Side note to others: req-package does not supercede use-package. In fact,
     use-package's design post-2.0 could easily support req-package's
     functionality as an add-on. req-package is a pre-2.0 effort to integrate
     a core design change.

Re: using use-package

[Stefan Monnier]

> I happen to prefer :load-path, since relying on Emacs' automated discovery
> takes longer than loading my entire init.el now.

If you use ELPA and package-initialize to install your packages,
the load-path and the autoloads are already set and that time is
already "wasted".

So are you saying that use-package is designed for the case where you
don't use ELPA?  It is the impression I got when I looked at
use-package, but it seems like an odd position nowadays.

[ Note: if the time to run package-initialize is too high, it could be
  improved by caching.  I haven't heard any complaint about its speed
  so far, tho.  ]

>> IOW, in many cases, it would be better for people to report the problem as a
>> bug rather than to reach for use-package.
> The idea that use-package will never make it into core because "package
> authors should do things a better way" strikes me as a very odd argument.

To be more precise, I don't think those problems in packages are
particularly frequent, so it's perfectly OK to report them in those rare
remaining cases.


        Stefan

Re: using use-package

[Phillip Lord]

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

>> I happen to prefer :load-path, since relying on Emacs' automated discovery
>> takes longer than loading my entire init.el now.
>
> If you use ELPA and package-initialize to install your packages,
> the load-path and the autoloads are already set and that time is
> already "wasted".
>
> So are you saying that use-package is designed for the case where you
> don't use ELPA?  It is the impression I got when I looked at
> use-package, but it seems like an odd position nowadays.

I think a few examples might help.

I do use use-package for that reason. For example this is my
configuration for pabbrev.

(use-my-package pabbrev
  :diminish (pabbrev-mode . "pab")
  :defer 5
  :commands global-pabbrev-mode
  ;; pabbrev is useless until first idle anyway, and it's quite slow to load,
  ;; so might as well defer and init it later
  :config (progn
	    (global-pabbrev-mode)
	    ;; till we get org mode sorted out!
            (define-key pabbrev-mode-map [tab] 'pabbrev-expand-maybe)
            (setq pabbrev-idle-timer-verbose t)
            ;;(setq pabbrev-debug-display t)
            ;; the default anyway
            (setq pabbrev-debug-display nil)
            (setq pabbrev-read-only-error nil)))


`use-my-package' is my own macro which expands to a valid `use-package'
call with load-path set (based on the package name). I run my own
packages without installing them via ELPA.

This is good practice, because I can change the source, and test
everything works. It's also poor practice because it means that I, as
the author of the package, is not testing the environment that other
people are getting. The recently fixed missing autoloads in omn-mode.el
were a victim of this.

But the rest of the config is valid.


But this form of use is the exception. Here is a more normal example,
for a well behaved package (with slightly less well behaved
configuration).

(use-package tex-site
  :ensure auctex
  :init
  ;; after latex because we add stuff to latex-mode-map
  (eval-after-load "latex"
    '(load "philtex.el")))

Here, we integrate tightly with ELPA. I synchronize my .emacs to several
machines, and I do not want to have to install auctex by hand on all of
them. `:ensure' achieves this. Other people use pallet or cask to achieve
the same thing, but I like being able to embed the requirement for a
package with the init statements ("philtex.el" will get moved into this
form -- it's a hangover from my pre ELPA days).


>>> IOW, in many cases, it would be better for people to report the problem as a
>>> bug rather than to reach for use-package.
>> The idea that use-package will never make it into core because "package
>> authors should do things a better way" strikes me as a very odd argument.
>
> To be more precise, I don't think those problems in packages are
> particularly frequent, so it's perfectly OK to report them in those rare
> remaining cases.


I would like to ask a more specific question. use-package is nice, but
is more of a PITA to use than it should because because of a bootstrap
problem which can only be fixed by putting it in core.

What changes would you want to see before to it to make it acceptible in
core? Obviously, this is assuming the authors agree, and copyright
assignment, and all that jazz.

Phil

Re: using use-package

[John Wiegley]

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

> So are you saying that use-package is designed for the case where you don't
> use ELPA? It is the impression I got when I looked at use-package, but it
> seems like an odd position nowadays.

It may be! I don't use ELPA. I have a hand-crafted set of packages that are
all in Git (using git-subtree, to ensure cloning always succeeds), which gives
me an extremely stable environment. It may well be a one-off use pattern, but
it has worked well for me for many years.

> To be more precise, I don't think those problems in packages are
> particularly frequent, so it's perfectly OK to report them in those rare
> remaining cases.

I guess the frequency would require at least a poll to determine.  You and I
may be outliers on the spectrum...

John

Re: using use-package

[Rusi]

On Monday, August 10, 2015 at 3:22:28 PM UTC+5:30, Phillip Lord wrote:
> Stefan Monnier  writes:
> 
> >> Putting in the core is rather some distance from promoting as the "one
> >> true way"
> >
> > FWIW, lots of use-package is designed to work around flaws in packages.
> >
> > E.g. the :load-path thingy should never be necessary since the package's
> > own autoloads should already take care of that.
> 
> You are correct about the :load-path thingy, although I use this for my
> own packages which I run "straight from source" as it where, rather than
> install as a ELPA package proper.
> 
> 
> > Or to take another example from https://github.com/jwiegley/use-package:
> >
> >    (use-package foo
> >      :init
> >      (setq foo-variable t)
> >      :config
> >      (foo-mode 1))
> >
> > For any properly written foo-mode, the above can be replaced with
> >
> >      (setq foo-variable t)
> >      (foo-mode 1)
> >
> > and it should work just as well.
> 
> 
> No, you are missing (several) points of use-package. First (and
> trivially) the use-package statement groups everything syntactically.
> So, it's more like:
> 
> (progn
>   (setq foo-variable t)
>   (foo-mode 1))
> 
> This is nicer because it groups all the configuration together, so you
> can move, comment, delete or eval it all together. Of course, `progn'
> achieves the same thing.

Yeah  :disabled 
is so much neater than commenting out/deleting/moving large blocks of code

Likewise
(use-package foo ... )

is like a docstring ie the '...' is docstringed by the foo

Re: using use-package

[Sebastien Vauban]

phillip.lord-WS8JpuUeUJXe9xe1eoZjHA@public.gmane.org (Phillip Lord) writes:
> Stefan Monnier <monnier-CRDzTM1onBSWkKpYnGOUKg@public.gmane.org> writes:
>> Or to take another example from https://github.com/jwiegley/use-package:
>>
>>    (use-package foo
>>      :init
>>      (setq foo-variable t)
>>      :config
>>      (foo-mode 1))
>>
>> For any properly written foo-mode, the above can be replaced with
>>
>>      (setq foo-variable t)
>>      (foo-mode 1)
>>
>> and it should work just as well.
>
> No, you are missing (several) points of use-package. First (and
> trivially) the use-package statement groups everything syntactically.
> So, it's more like:
>
> (progn
>   (setq foo-variable t)
>   (foo-mode 1))
>
> This is nicer because it groups all the configuration together, so you
> can move, comment, delete or eval it all together. Of course, `progn'
> achieves the same thing.
>
> However, `use-package' also gives you configurable feedback on load
> times. So if (require 'foo) takes a long time, use-package tells you,
> and tells you how long it takes.
>
> In your example,
>
> (foo-mode 1)
>
> will force an autoload. With use-package, also I can do
>
> (use-package foo
>   :defer t
>   ;;;etc
>   )
>
> which will achieve the same.

Just wanted to share how I do *some* of the above points in my config
file. Here an example for `diff-hl', which indicates changes in the
fringe:

--8<---------------cut here---------------start------------->8---
  (with-eval-after-load "diff-hl-autoloads"
  
    (idle-require 'diff-hl))

  (with-eval-after-load "diff-hl"

    (global-diff-hl-mode)

    (define-key diff-hl-mode-map (kbd "C-x v >") 'diff-hl-next-hunk)
    (define-key diff-hl-mode-map (kbd "C-x v <") 'diff-hl-previous-hunk))
--8<---------------cut here---------------end--------------->8---

This is somehow trying to achieve (part of) the same goals as
`use-package', but with standard Emacs (more or less, as `idle-require'
is not in core).

You see:

- Differed load via the idle-require' package (otherwise, I just write
  "require")

- Nice grouping of all customizations at the same place,

To disable it, I'll edit the code and add "-XXX" in the first
`with-eval-after-load':

--8<---------------cut here---------------start------------->8---
  (with-eval-after-load "diff-hl-autoloads-XXX" ; Diff-hl won't be req'ed

    (idle-require 'diff-hl))
--8<---------------cut here---------------end--------------->8---

Of course, I miss, for example, the real execution time of that block,
once executed/loaded (and you can't advice a macro such as
`with-eval-after-load', right, to add timings?).

And I do have all ELPA paths in `load-path' unlike John (IIUC), though
I don't understand yet how it works (differently) with `use-package'.

Interested by comments...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: using use-package

[Nicolas Richard]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> And I do have all ELPA paths in `load-path' unlike John (IIUC), though
> I don't understand yet how it works (differently) with `use-package'.

use-package makes it possible to use packages that are not ELPA
packages. e.g. I start org-mode and many others from their source dir (a
git checkout).

Nico.

Re: using use-package

[Alexis]

Nicolas Richard <youngfrog@members.fsf.org> writes:

> use-package makes it possible to use packages that are not ELPA 
> packages. e.g. I start org-mode and many others from their 
> source dir (a git checkout).

Well, one doesn't need `use-package` for this specifically; i 
don't use `use-package`, but nevertheless have the 
`org-plus-contrib` package installed from the orgmode.org ELPA.

(i here use "ELPA" to mean an Emacs Lisp Package Archive in 
general, not the GNU ELPA in particular, which i refer to either 
as such, or as GELPA.)


Alexis.

Re: using use-package

[Nicolas Richard]

Alexis <flexibeast@gmail.com> writes:

> Nicolas Richard <youngfrog@members.fsf.org> writes:
>
>> use-package makes it possible to use packages that are not ELPA
>> packages. e.g. I start org-mode and many others from their source
>> dir (a git checkout).
>
> Well, one doesn't need `use-package` for this specifically;

Sorry for the bad phrasing, the point is that I do use use-package for
this kind of thing, and that is one of the reason :load-path is useful
to me (i.e. it doesn't help loading ELPA packages, but also helps
loading libraries in a non-packaged form).

> i don't
> use `use-package`, but nevertheless have the `org-plus-contrib`
> package installed from the orgmode.org ELPA.

That's not from the git checkout though.

-- 
Nico

Re: using use-package

[Alexis]

Nicolas Richard <youngfrog@members.fsf.org> writes:

>> i don't use `use-package`, but nevertheless have the 
>> `org-plus-contrib` package installed from the orgmode.org ELPA.
>
> That's not from the git checkout though.

Fair point! However, i use MELPA, and most of the 200+ packages 
i've installed from there are indeed based on git checkouts. :-)


Alexis.

Re: using use-package

[Phillip Lord]

Sebastien Vauban <sva-news@mygooglest.com> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
> Just wanted to share how I do *some* of the above points in my config
> file. Here an example for `diff-hl', which indicates changes in the
> fringe:
>
>
>   (with-eval-after-load "diff-hl-autoloads"
>   
>     (idle-require 'diff-hl))
>
>   (with-eval-after-load "diff-hl"
>
>     (global-diff-hl-mode)
>
>     (define-key diff-hl-mode-map (kbd "C-x v >") 'diff-hl-next-hunk)
>     (define-key diff-hl-mode-map (kbd "C-x v <") 'diff-hl-previous-hunk))

This is pretty much what use-package does actually. It's an odd package,
in that the main entry point is a macro. Nowadays, it's even needed at
runtime iff you compile your .emacs.


>
>   (with-eval-after-load "diff-hl-autoloads-XXX" ; Diff-hl won't be req'ed
>
>     (idle-require 'diff-hl))
>
>
> Of course, I miss, for example, the real execution time of that block,
> once executed/loaded (and you can't advice a macro such as
> `with-eval-after-load', right, to add timings?).

I don't think so, no. It's easy to write a new macro which adds these
timings and expands to `with-eval-after-load'

> And I do have all ELPA paths in `load-path' unlike John (IIUC), though
> I don't understand yet how it works (differently) with `use-package'.

I haven't checked how ELPA load-paths work. Unlike John, though, I don't
sync my ELPA directory; actually I tend to delete it periodically. My
.emacs auto-installs any packages I need.

Phil

Re: using use-package

[Rusi]

On Tuesday, August 11, 2015 at 11:20:15 AM UTC+5:30, John Wiegley wrote:
> >>>>> Stefan Monnier  writes:
> > IOW, in many cases, it would be better for people to report the problem as a
> > bug rather than to reach for use-package.
> 
> The idea that use-package will never make it into core because "package
> authors should do things a better way" strikes me as a very odd argument.
> use-package lets me write modular code to solve every configuration problem I
> run into; am I really supposed to not do this, because things should ideally
> be better than they are? That's a bit like saying we shouldn't have locks on
> our doors, because it downplays a deeper issue: that we should convince people
> not to steal.

A more emacsish analogy:

Q: Should one indent C programs like this <eg in gnu style>?
  Or this <eg in K&R style>?

Answer1 : Sensible people only use gnu-style
Answer2 : Choose what you like. Set it in c-default-style

Which answer is more in the spirit of emacs?

Re: using use-package

[Ian Zimmerman]

On 2015-08-12 10:52 -0700, Rusi wrote:

> A more emacsish analogy:
> 
> Q: Should one indent C programs like this <eg in gnu style>?
>   Or this <eg in K&R style>?
> 
> Answer1 : Sensible people only use gnu-style
> Answer2 : Choose what you like. Set it in c-default-style
> 
> Which answer is more in the spirit of emacs?

I don't really have a horse in this race (I'm keeping my Emacs 23, and
I'm sure *-package won't be ported to it), but I don't see the analogy.

Stefan is saying that many packages do things _wrong_.  There are good
objective criteria for right and wrong in Elisp coding, unlike with
indentation styles.

I'll offer a different analogy, from OS packaging.  OS packages (debs
for example) also often have soft dependencies and have to perform some
tasks on installation to integrate well with the system.  Some are
broken and don't follow the system policy.  What happens in that
situation, is there a user level "clean up" package to work around it?
No, the broken package is tagged and fixed.

At least I _think_ this is what Stefan means ... correct me if
necessary.

-- 
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

Re: using use-package

[Stefan Monnier]

> Stefan is saying that many packages do things _wrong_.

Actually, no.  What I was saying is that several use-package features
are only useful if a package is poorly packaged.

In the mean time, it became apparent that the reason for that is that
I assume people (will) use ELPA to install their packages, whereas
use-package was designed for the case where packages are installed some
other way.

Hence use-package partly overlaps with ELPA, and in those parts that
overlaps, the work is done differently: in ELPA the work is done by the
packager, whereas in use-package the work is done by the end-user (since
there's no packager doing that work for him).


        Stefan

Re: using use-package

[tomas]

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

On Wed, Aug 12, 2015 at 09:13:42PM -0400, Stefan Monnier wrote:
> > Stefan is saying that many packages do things _wrong_.
> 
> Actually, no.  What I was saying is that several use-package features
> are only useful if a package is poorly packaged.
> 
> In the mean time, it became apparent that the reason for that is that
> I assume people (will) use ELPA to install their packages, whereas
> use-package was designed for the case where packages are installed some
> other way.

FWIW, and based on a recent experience of mine, yes, I think both ways
are needed/useful and complement each other. Recently, I installed some
package from ELPA (magit) and it failed to byte-compile. I've yet to
investigate what went wrong (perhaps my Emacs version is too new/old,
what have you), but I now find myself wrangling with the complexities
of the package itself *and* those of the packaging system.

So some "wholly integrated solution" makes life easier only when things
work out (duh ;-) Otherwise it makes life harder, and what's more important
in my view -- it tends to make a stronger separation of "outer circle"
and "inner circle", making it more difficult to get involved.

> Hence use-package partly overlaps with ELPA, and in those parts that
> overlaps, the work is done differently: in ELPA the work is done by the
> packager, whereas in use-package the work is done by the end-user (since
> there's no packager doing that work for him).

Perhaps the only problem is in this "differently": if ELPA and use-package
manage to converge towards some set of common conventions, the end-user
is only to win (whereas I'm convinced that there must be a first phase
of divergence: how else are we going to explore different options?)

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

iEYEARECAAYFAlXMRlIACgkQBcgs9XrR2kbkzgCggjAn2jW0iCGvTxwms7JJ5Ivn
VegAn1E+BLPj/ENQOCgit2G1vf1aIJYi
=j1G8
-----END PGP SIGNATURE-----

Re: using use-package

[Stefan Monnier]

> FWIW, and based on a recent experience of mine, yes, I think both ways
> are needed/useful and complement each other. Recently, I installed some
> package from ELPA (magit) and it failed to byte-compile. I've yet to
> investigate what went wrong (perhaps my Emacs version is too new/old,
> what have you), but I now find myself wrangling with the complexities
> of the package itself *and* those of the packaging system.

Please do keep us informed of those problems: it's indeed very important
to make package.el more robust.

In the mean time, you can do:

   mv ~/.emacs.d/elpa/magit/*.elc ~/somewhere-for-analysis/

which should "fix" the problem (Magit will be slower, tho).

We should probably also add a package-(re)compile command (after all,
the compilation step is conceptually independent from the actual
installation).

> So some "wholly integrated solution" makes life easier only when things
> work out (duh ;-) Otherwise it makes life harder, and what's more important
> in my view -- it tends to make a stronger separation of "outer circle"
> and "inner circle", making it more difficult to get involved.

I tend to agree.  My earlier package system attempt had less magic
power.  The main visible difference, is that instead of
(package-initialize), the user had to use a bunch of (load
"/foo/bar/pkg-autoloads.el") to activate each package.

But fundamentally, (package-initialize) still does just that (i.e. it
first looks for all installed packages, decides which to activate, in
which order, and then does the corresponding `load's).

Patches/suggestions to make this magic more transparent welcome.

> Perhaps the only problem is in this "differently": if ELPA and use-package
> manage to converge towards some set of common conventions, the end-user
> is only to win (whereas I'm convinced that there must be a first phase
> of divergence: how else are we going to explore different options?)

Agreed.  Hence my participation in this thread ;-)


        Stefan

Re: using use-package

[tomas]

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

On Thu, Aug 13, 2015 at 11:08:02AM -0400, Stefan Monnier wrote:
> > FWIW, and based on a recent experience of mine, yes, I think both ways
> > are needed/useful and complement each other. Recently, I installed some
> > package from ELPA (magit) and it failed to byte-compile [...]

> Please do keep us informed of those problems: it's indeed very important
> to make package.el more robust.

My hunch now is that the package brought with it an .elc file (probably
magit.elc) compiled with the wrong Emacs version. Removing all .elc and
recompiling the directory seems to succeed (I've ditched magit now for
anoter reason -- it doesn't like my git 1.7.x and wants 1.9.x, I'd have
to resort to an older magit, sigh). I'll try to verify (or falsify) my
hunch.

> In the mean time, you can do:
> 
>    mv ~/.emacs.d/elpa/magit/*.elc ~/somewhere-for-analysis/
> 
> which should "fix" the problem (Magit will be slower, tho).

Your proposal suggests that you have a similar hunch as mine :-)

> We should probably also add a package-(re)compile command (after all,
> the compilation step is conceptually independent from the actual
> installation).

Perhaps there should be a way for Emacs to find out that an .elc file
doesn't match the current binary interface (I've been stumped by
"wrong" .elc files (i.e such compiled by an Emacs with different
byte code conventions) more than once).

> > So some "wholly integrated solution" makes life easier only when things
> > work out (duh ;-) [...]

> I tend to agree.  My earlier package system attempt had less magic
> power.  The main visible difference, is that instead of
> (package-initialize), the user had to use a bunch of (load
> "/foo/bar/pkg-autoloads.el") to activate each package.
> 
> But fundamentally, (package-initialize) still does just that (i.e. it
> first looks for all installed packages, decides which to activate, in
> which order, and then does the corresponding `load's).
> 
> Patches/suggestions to make this magic more transparent welcome.

I'll ponder a bit on it. Perhaps I can offer more than just some
half-smart mumblings :-)

> Agreed.  Hence my participation in this thread ;-)

Thanks for your work -- and your insightful comments!

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

iEYEARECAAYFAlXM+ogACgkQBcgs9XrR2kbp1ACfSk+76Db++oXnBQVlyJ5+dhS6
MwgAniZGSBxOkZkE3kuwFwo1zczWQrxH
=x3fA
-----END PGP SIGNATURE-----

Re: using use-package

[Stefan Monnier]

>> Please do keep us informed of those problems: it's indeed very important
>> to make package.el more robust.
> My hunch now is that the package brought with it an .elc file (probably
> magit.elc) compiled with the wrong Emacs version.

Sounds unlikely both because of the way the ELPA package gets built and
because many other people would have bumped into this problem.

> Removing all .elc and recompiling the directory seems to succeed (I've
> ditched magit now for anoter reason -- it doesn't like my git 1.7.x
> and wants 1.9.x, I'd have to resort to an older magit, sigh).
> I'll try to verify (or falsify) my hunch.

My crystal ball tells me that you upgraded Magit from an Emacs where the
previous Magit was already loaded, and the old (loaded) version
interfered while byte-compiling the new version.
[ The typical interference, looks like this: Emacs tries to compile
  foo-1.el which does (require 'foo-2) to get some macros, but (the old)
  `foo-2' is already loaded so we end up using the old version of the
  macros (or the macros may simply not be defined at all).  ]

This is a problem in package.el that hit Helm pretty badly, apparently.
We have a tentative patch for that in Emacs-25.

This said, if you've erased the old problematic .elc files it'll be
difficult to verify/falsify my hunch.

Tho maybe if you can re-install the previous version of Magit, then run
Emacs, then use Magit, then in that same Emacs session upgrade Magit,
you might be able to reproduce the problem.

>> We should probably also add a package-(re)compile command (after all,
>> the compilation step is conceptually independent from the actual
>> installation).
> Perhaps there should be a way for Emacs to find out that an .elc file
> doesn't match the current binary interface (I've been stumped by
> "wrong" .elc files (i.e such compiled by an Emacs with different
> byte code conventions) more than once).

Normally byte-code is upward compatible, so the problem is only if you
compile with Emacs-NN and then use that file with Emacs-MM where MM<NN.
Admittedly, handling this more cleanly would be good.


        Stefan

Re: using use-package

[tomas]

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

On Thu, Aug 13, 2015 at 04:31:03PM -0400, Stefan Monnier wrote:
> >> Please do keep us informed of those problems: it's indeed very important
> >> to make package.el more robust.
> > My hunch now is that the package brought with it an .elc file (probably
> > magit.elc) compiled with the wrong Emacs version.
> 
> Sounds unlikely both because of the way the ELPA package gets built and
> because many other people would have bumped into this problem.

Sounds compelling, but...

> > Removing all .elc and recompiling the directory seems to succeed [...]

> My crystal ball tells me that you upgraded Magit from an Emacs where the
> previous Magit was already loaded, and the old (loaded) version
> interfered while byte-compiling the new version.
> [ The typical interference, looks like this: Emacs tries to compile
>   foo-1.el which does (require 'foo-2) to get some macros, but (the old)
>   `foo-2' is already loaded so we end up using the old version of the
>   macros (or the macros may simply not be defined at all).  ]

... the only version of magit to hit my computer was this one loaded
via ELPA (once). Unless I fat-fingered something (does happen sometimes).

> Normally byte-code is upward compatible, so the problem is only if you
> compile with Emacs-NN and then use that file with Emacs-MM where MM<NN.
> Admittedly, handling this more cleanly would be good.

I'll try to reproduce it -- after nuking .emacs.d/elpa (I can afford
this luxury since magit was my first dabbling in elpa anyway :-)

I'll report back.

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

iEYEARECAAYFAlXNB+YACgkQBcgs9XrR2kb8zACeIMcDlIaCbn/Fe+MkBHNOkQYc
E6cAn3B2WmNu2n2COtcKfkOHJiaXocy3
=2Ete
-----END PGP SIGNATURE-----

Re: using use-package

[Michael Heerdegen]

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

> My crystal ball tells me that you upgraded Magit from an Emacs where the
> previous Magit was already loaded, and the old (loaded) version
> interfered while byte-compiling the new version.
> [ The typical interference, looks like this: Emacs tries to compile
>   foo-1.el which does (require 'foo-2) to get some macros, but (the old)
>   `foo-2' is already loaded so we end up using the old version of the
>   macros (or the macros may simply not be defined at all).  ]

Sorry, I was not able to fetch the parent message, so I answer to this
one...

I recently had such an issue:
https://github.com/magit/magit/issues/2045.

If the issue is reproducible, it could be worth to report it to the
Magit maintainers.  In my special case, it was fixable from the Magit
side.

BTW, AFAICT since Helm uses async.el for package upgrading we have had
no more of such problems.


Regards,

Michael.

Re: using use-package

[Stefan Monnier]

> If the issue is reproducible, it could be worth to report it to the
> Magit maintainers.

And to Emacs maintainers, in case it the underlying problem is not
specific to Magit.


        Stefan

Re: using use-package

[John Mastro]

<tomas@tuxteam.de> wrote:
> ... the only version of magit to hit my computer was this one loaded
> via ELPA (once). Unless I fat-fingered something (does happen
> sometimes).

If you started with 1.4 and upgraded to 2.1 (all via ELPA), errors are
possible/likely. Magit's maintainer recommended first uninstalling 1.4
and then installing 2.1 [1].

Michael Heerdegen <michael_heerdegen@web.de> wrote:
> If the issue is reproducible, it could be worth to report it to the
> Magit maintainers.  In my special case, it was fixable from the Magit
> side.
>
> BTW, AFAICT since Helm uses async.el for package upgrading we have had
> no more of such problems.

Magit is now using async.el as well, and for the same reason [2].

[1] http://magit.vc/manual/magit/Updating-from-an-older-release.html#Updating-from-an-older-release
[2] https://github.com/magit/magit/commit/42e4632ed4925fc65f95ff03e55e80d04e62ffb2

-- 
john

Re: using use-package

[Rasmus]

John Mastro <john.b.mastro@gmail.com> writes:

> Michael Heerdegen <michael_heerdegen@web.de> wrote:
>> If the issue is reproducible, it could be worth to report it to the
>> Magit maintainers.  In my special case, it was fixable from the Magit
>> side.
>>
>> BTW, AFAICT since Helm uses async.el for package upgrading we have had
>> no more of such problems.
>
> Magit is now using async.el as well, and for the same reason [2].

My understanding is that Org faces the same issue¹ .  It would be great to
have a solution for this in Emacs-core, if it's not there already.

Rasmus

Footnotes: 
¹   E.g. http://permalink.gmane.org/gmane.emacs.orgmode/99746

-- 
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio

Re: using use-package

[Stefan Monnier]

> My understanding is that Org faces the same issue¹ .  It would be great to
> have a solution for this in Emacs-core, if it's not there already.

As mentioned, Emacs-25 should fix this problem.


        Stefan

Re: using use-package

[Rasmus]

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

>> My understanding is that Org faces the same issue¹ .  It would be great to
>> have a solution for this in Emacs-core, if it's not there already.
>
> As mentioned, Emacs-25 should fix this problem.

I installed org from GELPA from a "dirty" Emacs, and I got an error now
"byte-code: Invalid function".  Here's my version:

GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6) of
2015-08-11 on W530

How to I debug further to find out why the magic of Emacs-25 isn't working
for Org?

Rasmus

-- 
Sådan en god dansk lagereddike kan man slet ikke bruge mere

Re: using use-package

[Stefan Monnier]

>>> My understanding is that Org faces the same issue¹ .  It would be great to
>>> have a solution for this in Emacs-core, if it's not there already.
>> As mentioned, Emacs-25 should fix this problem.
> I installed org from GELPA from a "dirty" Emacs, and I got an error now
> "byte-code: Invalid function".  Here's my version:
>
> How to I debug further to find out why the magic of Emacs-25 isn't working
> for Org?

I suggest you report it as a bug, providing as much info as possible.
The most useful info would be a way to reproduce the problem.
Another useful info to include is a backtrace.


        Stefan

Re: using use-package

[Thierry Volpiatto]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> My crystal ball tells me that you upgraded Magit from an Emacs where the
>> previous Magit was already loaded, and the old (loaded) version
>> interfered while byte-compiling the new version.
>> [ The typical interference, looks like this: Emacs tries to compile
>>   foo-1.el which does (require 'foo-2) to get some macros, but (the old)
>>   `foo-2' is already loaded so we end up using the old version of the
>>   macros (or the macros may simply not be defined at all).  ]
>
> Sorry, I was not able to fetch the parent message, so I answer to this
> one...
>
> I recently had such an issue:
> https://github.com/magit/magit/issues/2045.
>
> If the issue is reproducible, it could be worth to report it to the
> Magit maintainers.  In my special case, it was fixable from the Magit
> side.
>
> BTW, AFAICT since Helm uses async.el for package upgrading we have had
> no more of such problems.

Magit is now using async also.

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

Re: using use-package

[John Wiegley]

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

> Hence use-package partly overlaps with ELPA, and in those parts that
> overlaps, the work is done differently: in ELPA the work is done by the
> packager, whereas in use-package the work is done by the end-user (since
> there's no packager doing that work for him).

I'd say this is a perfectly accurate characterization.  And if core Emacs does
not want to detract from the success of ELPA, I can understand that too.

John

Re: using use-package

[Phillip Lord]

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

>> Stefan is saying that many packages do things _wrong_.
>
> Actually, no.  What I was saying is that several use-package features
> are only useful if a package is poorly packaged.

Yes, or not packaged at all, or in development to be packaged in the
future or where the developer of a package which is well-packaged wants
to provide an option configuration for development time on his machine.

And this is some features, not but all of them.


> In the mean time, it became apparent that the reason for that is that
> I assume people (will) use ELPA to install their packages, whereas
> use-package was designed for the case where packages are installed some
> other way.

It became apparent that the original developer of use-package does not
use ELPA, but not the only developer, nor many of the users of use-package.


> Hence use-package partly overlaps with ELPA, and in those parts that
> overlaps, the work is done differently: in ELPA the work is done by the
> packager, whereas in use-package the work is done by the end-user (since
> there's no packager doing that work for him).

In the case of this form, can you tell me how the package is poorly
packaged, or how this is overlapping with ELPA?

(use-package pabbrev
  :ensure t
  :defer t
  :config (global-pabbrev-mode))


It does overlap with package.el -- as it obviates the need to use the
GUI to package.el, since this will install pabbrev if necessary.

But overlapping with ELPA? It seems to me that it is working entirely
with ELPA. The installation step uses package.el to achieve it's ends.

Even

(use-package org-mode)

is useful since it gives performance data on start up that

(require 'org-mode)

does not.

Phil

Re: using use-package

[Stefan Monnier]

>>> Stefan is saying that many packages do things _wrong_.
>> Actually, no.  What I was saying is that several use-package features
>> are only useful if a package is poorly packaged.
> Yes, or not packaged at all, or in development to be packaged in the
> future or where the developer of a package which is well-packaged wants
> to provide an option configuration for development time on his machine.
> And this is some features, not but all of them.

The core part of "Packaging" in the elpa.git world basically means:
- Start the package's main file with ";;; <name> --- <description>"
- Sprinkle a few ";;;###autoload"s.
- Add a "Package-Requires:" (when needed).

This is very straightforward and can be done from the very beginning
of development.

After that, something needs to create the *-pkg.el and *-autoloads.el
files, but we know how to do it mechanically ("make" in elpa.git takes
care of it, for example).

So what's missing here I think is just some extra support to
transparently do this "make" step (probably not with "make", of course)
for those packages not installed via package.el.

> In the case of this form, can you tell me how the package is poorly
> packaged, or how this is overlapping with ELPA?

I said "partly overlaps".  So it doesn't all overlap (and in those parts
that don't overlap, the correct/incorrect packaging is not relevant).

> (use-package org-mode)
> is useful since it gives performance data on start up that

If I didn't consider use-package useful/interesting I wouldn't
participate in this discussion.


        Stefan

Re: using use-package

[Phillip Lord]

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

>>>> Stefan is saying that many packages do things _wrong_.
>>> Actually, no.  What I was saying is that several use-package features
>>> are only useful if a package is poorly packaged.
>> Yes, or not packaged at all, or in development to be packaged in the
>> future or where the developer of a package which is well-packaged wants
>> to provide an option configuration for development time on his machine.
>> And this is some features, not but all of them.
>
> The core part of "Packaging" in the elpa.git world basically means:
> - Start the package's main file with ";;; <name> --- <description>"
> - Sprinkle a few ";;;###autoload"s.
> - Add a "Package-Requires:" (when needed).
>
> This is very straightforward and can be done from the very beginning
> of development.

I use use-package to load the modules in my personal configuration,
which I don't intend to ever release or install as ELPA packages. Still,
this is a minor use.


> After that, something needs to create the *-pkg.el and *-autoloads.el
> files, but we know how to do it mechanically ("make" in elpa.git takes
> care of it, for example).
>
> So what's missing here I think is just some extra support to
> transparently do this "make" step (probably not with "make", of course)
> for those packages not installed via package.el.

Yes. I use cask (normally via the python wrapper), but elpakit is also
an option here.


>> In the case of this form, can you tell me how the package is poorly
>> packaged, or how this is overlapping with ELPA?
>
> I said "partly overlaps".  So it doesn't all overlap (and in those parts
> that don't overlap, the correct/incorrect packaging is not relevant).
>
>> (use-package org-mode)
>> is useful since it gives performance data on start up that
>
> If I didn't consider use-package useful/interesting I wouldn't
> participate in this discussion.


True.

I'm still trying to scope what you are after, though. Are you interested
only in those features which can never overlap with ELPA? Or only in
those features will necessarily overlap with ELPA.

Phil

Re: using use-package

[Stefan Monnier]

>> The core part of "Packaging" in the elpa.git world basically means:
>> - Start the package's main file with ";;; <name> --- <description>"
>> - Sprinkle a few ";;;###autoload"s.
>> - Add a "Package-Requires:" (when needed).
>> This is very straightforward and can be done from the very beginning
>> of development.
> I use use-package to load the modules in my personal configuration,
> which I don't intend to ever release or install as ELPA packages. Still,
> this is a minor use.

For those, Package-Requires is probably unneeded (tho if you have such
things in your use-package you could move them there), so the only thing
needed is the ";;; name -- desc" convention and a few ;;;###autoloads
(which you put in the file instead of putting them in your use-package
call).  Doesn't look like much of a hassle.

> Yes. I use cask (normally via the python wrapper), but elpakit is also
> an option here.

Not sure about Cask, but IIUC elpakit will generate a package-archive,
whereas we just want to turn the source tree into a valid "installed ELPA
package" without going through "make a tarball, create an
archive-contents, package-install".

I.e. all we want (to make those packages look like they were installed
via package.el) is to create/update a *-pkg.el and a *-autoloads.el
(we can add byte-compilation, but it's not indispensable).


        Stefan

Re: using use-package

[Phillip Lord]

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

>>> The core part of "Packaging" in the elpa.git world basically means:
>>> - Start the package's main file with ";;; <name> --- <description>"
>>> - Sprinkle a few ";;;###autoload"s.
>>> - Add a "Package-Requires:" (when needed).
>>> This is very straightforward and can be done from the very beginning
>>> of development.
>> I use use-package to load the modules in my personal configuration,
>> which I don't intend to ever release or install as ELPA packages. Still,
>> this is a minor use.
>
> For those, Package-Requires is probably unneeded (tho if you have such
> things in your use-package you could move them there),

I generally do not do dependency stuff with use-package. In this case, I
would put a "require" statement into the secondary file. I think I will
not go the root of Package-Requires. As I said in the multi-line
discussion, I find Package-Requires: headers flawed, as they are
comments and yet still have to be a valid sexp.


>> Yes. I use cask (normally via the python wrapper), but elpakit is also
>> an option here.
>
> Not sure about Cask, but IIUC elpakit will generate a package-archive,
> whereas we just want to turn the source tree into a valid "installed ELPA
> package" without going through "make a tarball, create an
> archive-contents, package-install".
>
> I.e. all we want (to make those packages look like they were installed
> via package.el) is to create/update a *-pkg.el and a *-autoloads.el
> (we can add byte-compilation, but it's not indispensable).

Indeed. Cask doesn't have that option at the moment. It's not hard,
though

(let ((dir (make-temp-name "cask")))
  (cask-cli/package dir)
  (package-install-file
      (concat dir
         default-directory ".tar")))

that sort of thing (untested for demonstration purposes only). The
easiest way to have a package look like it was installed via package.el
is surely to install it via package.el!

Phil

Re: using use-package

[Stefan Monnier]

>> Not sure about Cask, but IIUC elpakit will generate a package-archive,
>> whereas we just want to turn the source tree into a valid "installed ELPA
>> package" without going through "make a tarball, create an
>> archive-contents, package-install".
>> 
>> I.e. all we want (to make those packages look like they were installed
>> via package.el) is to create/update a *-pkg.el and a *-autoloads.el
>> (we can add byte-compilation, but it's not indispensable).

> Indeed. Cask doesn't have that option at the moment. It's not hard,
> though

> (let ((dir (make-temp-name "cask")))
>   (cask-cli/package dir)
>   (package-install-file
>       (concat dir
>          default-directory ".tar")))

AFAICT this again is not what I want: it takes your source code, turns
it into a tarball, then installs a copy of it elsewhere.
Whereas you'd really want the package to be installed *in place*
(e.g. so that C-h f gives you hyperlinks that jump to the actual real
editable source under version control).

> that sort of thing (untested for demonstration purposes only).  The
> easiest way to have a package look like it was installed via package.el
> is surely to install it via package.el!

But it does not mimic what you do with your "packages not
installed via package.el".


        Stefan

Re: using use-package

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Indeed. Cask doesn't have that option at the moment. It's not hard,
>> though
>
>> (let ((dir (make-temp-name "cask")))
>>   (cask-cli/package dir)
>>   (package-install-file
>>       (concat dir
>>          default-directory ".tar")))
>
> AFAICT this again is not what I want: it takes your source code, turns
> it into a tarball, then installs a copy of it elsewhere.
> Whereas you'd really want the package to be installed *in place*
> (e.g. so that C-h f gives you hyperlinks that jump to the actual real
> editable source under version control).

Yes, that would be nice to have, although it has risks. First, it
assumes that what is installed actually is the source code, which is not
always the case. So, dash.el has autogenerated documentation. And
tangled code from an org file would be another counter.

Second, it also means that the developer of a package is not using them
same installation proceedure as their users. This is the way I develop
at the moment, but I am not convinced it is a good thing. If the code
that achieves your aim is out of sync with the package.el equivalent,
then the world has not been helped.

As an alternative, why not expand C-h f with a "redirect functionality".
So, you install your own packages using "cask install-to-local". In
normal running all the source code would load from ~/.emacs.d/elpa. But
C-h f would say

blah-blah is a compiled Lisp function in (~/.emacs.d/elpa/blah.el) but
developed in (~/my-emacs-dev/blah/blah.eh).

Pimping `load' so that as well as printing "loading blah.elc but blah.el
is newer", it would print "loading blah.el but the development file
blah.el is newer". On seeing this error message, the developer would
know to do "cask install-to-local" again.

This would facilitate live-editing and coding of ELPA packages, while
meaning that ELPA package developers would still be using the same
install proceedures as their users.



>> that sort of thing (untested for demonstration purposes only).  The
>> easiest way to have a package look like it was installed via package.el
>> is surely to install it via package.el!
>
> But it does not mimic what you do with your "packages not
> installed via package.el".

No!

Phil

Re: using use-package

[Stefan Monnier]

> Yes, that would be nice to have, although it has risks.  First, it
> assumes that what is installed actually is the source code, which is not
> always the case. So, dash.el has autogenerated documentation.  And
> tangled code from an org file would be another counter.

We're miscommunicating.  I'm talking here about how to make it easy for
your personal in-development never-to-be-distributed packages (which you
currently don't bother to package) to appear and be "default configured"
in the same way as normal ELPA packages.

If those packages really use mechanically generated files and hence need
some kind of "install" step, obviously, you could just use something
like cask or elpakit, indeed.  I was only here focusing on the
"quick-and-dirty" packages where you want the packaging effort to be
kept to an absolute strict minimum.


        Stefan

Re: using use-package

[Stefan Monnier]

> I'm still trying to scope what you are after, though. Are you interested
> only in those features which can never overlap with ELPA? Or only in
> those features will necessarily overlap with ELPA.

Not sure either.  Maybe I'm looking for something like use-package but
which takes better advantage of ELPA.  Maybe also one that better
integrates with Customize.

I guess I'm also interested to see what other users find important in
terms of "configuration problems that need solving".

Maybe one other aspect is the issue of bootstrap/ordering between
package.el and Customize: we want to be able to customize package.el via
Customize (and some of these settings may need to be set before
package-initialize), but the one-and-only call to custom-set-variables
often needs to be done after package-initialize.  So, splitting the
config "by package" is probably the right way to go about it.


        Stefan

Re: using use-package

[John Wiegley]

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

> Not sure either. Maybe I'm looking for something like use-package but which
> takes better advantage of ELPA. Maybe also one that better integrates with
> Customize.

If you come up with any work items for use-package to make it more interesting
to you, please let me know. The code is quite small, and fairly amenable to
design changes, since I always have the option of defining special keywords to
retain the behavior I prefer.

John

Re: using use-package

[John Yates]

On Thu, Aug 13, 2015 at 12:15 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> Maybe also one that better integrates with Customize.
>
> I guess I'm also interested to see what other users find important in
> terms of "configuration problems that need solving".
>

Not so much about use-package or ref-package, but because Customize has
come up a few time recently...

I like the customize interface.  It makes exploring unfamiliar packages
easier.  Typically a package remains "unfamiliar" long after I first start
tweaking its customization knobs.  I do persist my changes from within
Customize and I appreciate the speed with which my byte compiled
custom-file.elc loads.

What I do not appreciate is the flat, alphabetic, uncommented nature of
that file.  It gives me neither means to organize my customizations is a
logical structure nor means to add commentary.  Further it separates faces
from all other package tweaks.

I have resolved this problem by committing to maintaining two copies of my
customizations:

   - One automatically created by Customize's 'save for future sessions'
   functionality.
   - One that I maintain by hand in my .emacs file.

I have implemented a framework whereby reloading my custom-file
automatically compares my two sets of customizations and reports any
discrepancies or anomalies.  You can see it in my .emacs file on github
<https://github.com/jsyjr/MyConfiguration/blob/master/.emacs>.  The file
uses folding-mode.  You can see this at

;;=== Customization ====================================================
> ;;{{{  Customization auditing framework...
> ;;{{{  Load customizations...


/john

PS: I am a C++ programmer.  My elisp coding consists of mimicking things I
see in others' code.  I really have _very_ little grasp of (e)lisp
concepts.  So I expect no kudos on my code but welcome suggestions for
improvement.

Re: using use-package

[Phillip Lord]

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

>> I'm still trying to scope what you are after, though. Are you interested
>> only in those features which can never overlap with ELPA? Or only in
>> those features will necessarily overlap with ELPA.
>
> Not sure either.  Maybe I'm looking for something like use-package but
> which takes better advantage of ELPA.

Over and above the "ensure" keyword which does take advantage of ELPA.

> Maybe also one that better integrates with Customize.

This is something that I think would be nice, but is actually
independent of use-package.

I'd love to be able to do something like

(custom-setq my-variable 10)

which sets the variable, but does not result in the "the value of this
variable has been changed outside of customize" message in Custom. And
also (configurable) which errors if my-variable is typed as a string in
custom.


> I guess I'm also interested to see what other users find important in
> terms of "configuration problems that need solving".
>
> Maybe one other aspect is the issue of bootstrap/ordering between
> package.el and Customize: we want to be able to customize package.el via
> Customize (and some of these settings may need to be set before
> package-initialize), but the one-and-only call to custom-set-variables
> often needs to be done after package-initialize.  So, splitting the
> config "by package" is probably the right way to go about it.

I can see this is a problem, but haven't got anything to suggest I am
afraid.

Phil

Re: using use-package

[Stefan Monnier]

> What I do not appreciate is the flat, alphabetic, uncommented nature of
> that file.  It gives me neither means to organize my customizations is a
> logical structure nor means to add commentary.  Further it separates faces
> from all other package tweaks.

FWIW, I agree (tho the uncommented nature is largely bound to the UI:
it's pretty hard to provide a GUI that lets you add/maintain good
comments to the resulting customizations).

> I have resolved this problem by committing to maintaining two copies of my
> customizations:

>    - One automatically created by Customize's 'save for future sessions'
>    functionality.
>    - One that I maintain by hand in my .emacs file.

Even better (to me [and to Erik Naggum ;-)]) would be if Customize could
let you generate and maintain "normal" Elisp code.

E.g. when you change a setting, it looks for "(setq <thevar> <oldval>)"
in your .emacs file, rewrites it to "(setq <thevar> <newval>) ;Was
<oldval>" and shows you the result.

IOW turn Customize into a UI that lets you browse settings and that can
show you what code to use to change them.


        Stefan

Re: using use-package

[John Yates]

On Fri, Aug 14, 2015 at 9:51 AM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> Even better (to me [and to Erik Naggum ;-)]) would be if Customize could
> let you generate and maintain "normal" Elisp code.
>
> E.g. when you change a setting, it looks for "(setq <thevar> <oldval>)"
> in your .emacs file, rewrites it to "(setq <thevar> <newval>) ;Was
> <oldval>" and shows you the result.
>
> IOW turn Customize into a UI that lets you browse settings and that can
> show you what code to use to change them.
>

+100

/john

Re: using use-package

[Stefan Monnier]

> I'd love to be able to do something like
> (custom-setq my-variable 10)
> which sets the variable, but does not result in the "the value of this
> variable has been changed outside of customize" message in Custom.  And
> also (configurable) which errors if my-variable is typed as a string in
> custom.

You can try customize-set-variable.


        Stefan

RE: using use-package

[Drew Adams]

> > I'd love to be able to do something like
> > (custom-setq my-variable 10)
> > which sets the variable, but does not result in the "the value of
> > this variable has been changed outside of customize" message in Custom.
> 
> You can try customize-set-variable.

Yes.  (Or `customize-set-value', depending on what you want.)

Or use this, which is the part of `customize-set-(variable|value)'
that does what you are asking for:

(defun tell-customize-option-has-changed (option &optional msgp)
  "Tell Customize that OPTION, changed outside Customize, is now set."
  (interactive "vOption: \np")
  (put option 'customized-value (list (custom-quote (symbol-value option))))
  (when msgp (message "Option `%s' is now set (but NOT saved)" option)))

And for a face:

(defun tell-customize-face-has-changed (face &optional msgp)
  "Tell Customize that FACE, changed outside Customize, is now set.
The definition of symbol FACE for the current frame is used."
  (interactive (list (read-face-name "Face") t))
  (put face 'customized-face (list (list 't (face-attr-construct face))))
  (put face 'customized-face-comment (get face 'face-comment))
  (put face 'face-modified nil)
  (when msgp (message "Face `%s' is now set (but NOT saved)" face))))

In short:

 - option: (put OPTION 'customized-value
                (list (custom-quote (symbol-value OPTION))))

 - face:   (put FACE 'customized-face SPEC)
           (face-spec-set FACE SPEC)  ; See `face-spec-set' doc.

See also: http://www.emacswiki.org/emacs/CustomizingAndSaving#GetCustomizeToRecognizeChangedPreference

Re: using use-package

[Phillip Lord]

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

>> > I'd love to be able to do something like
>> > (custom-setq my-variable 10)
>> > which sets the variable, but does not result in the "the value of
>> > this variable has been changed outside of customize" message in Custom.
>> 
>> You can try customize-set-variable.
>
> Yes.  (Or `customize-set-value', depending on what you want.)

So this works....

(customize-set-variable 'tab-width 10)

but so does this....

(customize-set-variable 'tab-width "bob")

when surely it should error? Like this errorers?

(customize-set-variable org-tags-column "bob")

Phil

RE: using use-package

[Drew Adams]

> >> You can try customize-set-variable.
> > Yes.  (Or `customize-set-value', depending on what you want.)
> 
> So this works....
> (customize-set-variable 'tab-width 10)
> but so does this....
> (customize-set-variable 'tab-width "bob")
> when surely it should error? 

If you don't use it interactively (`M-x customize-variable')
then you are on your own wrt such type checks.  IOW, if you
are using Lisp instead of setting it interactively, then check
first, before setting.  Use (get 'tab-width 'custom-type).

> Like this errorers?
> (customize-set-variable org-tags-column "bob")

That raises an error only because you didn't quote `org-tags-column'.
If org.el is loaded then the error is a wrong-type-arg error.
If it is not loaded then the error is an undefined-variable error.

Re: using use-package

[Rusi]

On Thursday, August 13, 2015 at 6:44:02 AM UTC+5:30, Stefan Monnier wrote:
> > Stefan is saying that many packages do things _wrong_.
> 
> Actually, no.  What I was saying is that several use-package features
> are only useful if a package is poorly packaged.
> 
> In the mean time, it became apparent that the reason for that is that
> I assume people (will) use ELPA to install their packages, whereas
> use-package was designed for the case where packages are installed some
> other way.
> 
> Hence use-package partly overlaps with ELPA, and in those parts that
> overlaps, the work is done differently: in ELPA the work is done by the
> packager, whereas in use-package the work is done by the end-user (since
> there's no packager doing that work for him).

Yes!
There are packages and there are packages.
To expand on Ian's deb analogy:

On debian-ish systems [I am assuming mine are fairly typical]

- there is software running from download tarball; make; install
- there are proprietary/commercial debs installed eg Canon printer drivers
- there are 'improper' debs -- Only in debian; needed on ubuntu.
 So downloaded and dpkg-installed and (cross-fingers) runs so far
- there are more proper but still unsafe debs -- from ppas
- there are the fully proper debs -- apt-get installed or came with the base system

Of course from the pov of debian packagers only the last are qualified as
packages.

There is a case to be made for treating ALL as packages and not only the last

Also notice that debian has a finely honed combo of human/social/soft and
hard/technical: to get a package past debian's packaging policy is much
harder than taking software that make-s and wrapping it into a deb that will
be acceptable to dpkg -i even though it may violate all sorts of best practices

Re: using use-package

[Rusi]

On Sunday, August 9, 2015 at 4:54:39 AM UTC+5:30, Stefan Monnier wrote:
> > Putting in the core is rather some distance from promoting as the "one
> > true way"
> 
> FWIW, lots of use-package is designed to work around flaws in packages.
> 
> E.g. the :load-path thingy should never be necessary since the package's
> own autoloads should already take care of that.
> 
> Or to take another example from https://github.com/jwiegley/use-package:
> 
>    (use-package foo
>      :init
>      (setq foo-variable t)
>      :config
>      (foo-mode 1))
> 
> For any properly written foo-mode, the above can be replaced with
> 
>      (setq foo-variable t)
>      (foo-mode 1)
> 
> and it should work just as well.

Are you serious Stefan?

Here's a 3-line init:

---------------------
(add-to-list 'package-archives
             '("melpa" . "http://melpa.org/packages/"))
(package-initialize)
---------------------

Start emacs -Q with that and I get:
Symbol's value as variable is void: package-archives

Precede by a (require 'package) and error vanishes

Re: using use-package

[Stefan Monnier]

> Are you serious Stefan?

Not always.  Why?

> Here's a 3-line init:
> ---------------------
> (add-to-list 'package-archives
>              '("melpa" . "http://melpa.org/packages/"))
> (package-initialize)
> ---------------------
> Start emacs -Q with that and I get:
> Symbol's value as variable is void: package-archives
> Precede by a (require 'package) and error vanishes

You can get rid of the error by swapping the two statements as well.
Not sure what is your point.


        Stefan

Re: using use-package

[Rusi]

On Sunday, August 9, 2015 at 6:47:30 PM UTC+5:30, Stefan Monnier wrote:
> > Are you serious Stefan?
> 
> Not always.  Why?
> 
> > Here's a 3-line init:
> > ---------------------
> > (add-to-list 'package-archives
> >              '("melpa" . "http://melpa.org/packages/"))
> > (package-initialize)
> > ---------------------
> > Start emacs -Q with that and I get:
> > Symbol's value as variable is void: package-archives
> > Precede by a (require 'package) and error vanishes
> 
> You can get rid of the error by swapping the two statements as well.
> Not sure what is your point.

Generic Point:
Functional programming is neat; imperative programming is a mess
One basic property of FP is that things should not be more order sensitive
than the minimum (data-dependency) required
When you say
 (setq foo-variable t)
 (foo-mode 1)

should work *for a properly written* foo mode you are saying basically the same
thing. However...

Specific point:
By not having package-archive as an autoload, those two statements become
more order dependent than they (seemingly) need be.
[There may be all sorts of other reasons I dont understand of course.
Not saying its a bug; just that it is fragile].

And if core emacs functionality can be thus fragile is it realistic to expect
random packages to satisfy all the new/changing/confusing best practices?

IOW you folks should give a serious consideration to putting (something like)
use-package (better req-package) in the core

Re: using use-package

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> Generic Point: Functional programming is neat;
> imperative programming is a mess

How about: good programming tells the truth about
technology, and poor programming tells the truth about
the programmer?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: using use-package

[Stefan Monnier]

> One basic property of FP is that things should not be more order sensitive
> than the minimum (data-dependency) required

Agreed.

> By not having package-archive as an autoload, those two statements become
> more order dependent than they (seemingly) need be.

I don't see it that way: add-to-list is inherently different from setq
(from a data-dependency point of view), so you can't expect
(add-to-list 'foo bar) to work properly without first loading the
package that defines foo.
Relying on variables being autoloaded would just open another can of worms.

> And if core emacs functionality can be thus fragile is it realistic to expect
> random packages to satisfy all the new/changing/confusing best practices?

AFAIK those "best practices" aren't very new and changing.  They've been
used for bundled Emacs packages for many years and all GNU ELPA packages
have strived to do the same from the very beginning.

> IOW you folks should give a serious consideration to putting
> (something like) use-package (better req-package) in the core

The problem is to define "something like".


        Stefan

Re: using use-package

[Rusi]

On Sunday, August 9, 2015 at 10:15:33 PM UTC+5:30, Stefan Monnier wrote:
> > One basic property of FP is that things should not be more order sensitive
> > than the minimum (data-dependency) required
> 
> Agreed.
> 
> > By not having package-archive as an autoload, those two statements become
> > more order dependent than they (seemingly) need be.
> 
> I don't see it that way: add-to-list is inherently different from setq
> (from a data-dependency point of view), so you can't expect
> (add-to-list 'foo bar) to work properly without first loading the
> package that defines foo.

Ok -- add-to-list uses foo as lvalue and rvalue so yes.

> Relying on variables being autoloaded would just open another can of worms.

This makes no sense
Either you (devs) deal with the worms.
Or we users.
If first the autoloads etc magic should be so cleverly arranged that (for example) 
 (setq foo-variable t)
 (foo-mode 1) 
and much more just works non-functional sequence of requires etc fudging

If second somebody or other will come up with use-package, req-package 
etc. We suffer the babel; you suffer its backlash

> 
> > And if core emacs functionality can be thus fragile is it realistic to expect
> > random packages to satisfy all the new/changing/confusing best practices?
> 
> AFAIK those "best practices" aren't very new and changing.  They've been
> used for bundled Emacs packages for many years and all GNU ELPA packages
> have strived to do the same from the very beginning.

Unlikely
Emacs predates the cloud era
Today with package archives the in thing, dependency management is inevitable
Do emacs packages have the sophisticated .deb style packaging?
My impression is that wheel will slowly and painfully and inevitably get reinvented.
Why not leapfrog?
> 
> > IOW you folks should give a serious consideration to putting
> > (something like) use-package (better req-package) in the core
> 
> The problem is to define "something like".

Simply solved -- Just pick up req-package :-)

Re: using use-package

[Stefan Monnier]

>> Relying on variables being autoloaded would just open another can of worms.
> This makes no sense
> Either you (devs) deal with the worms.

No, it's a can of fundamental worms.

> If first the autoloads etc magic should be so cleverly arranged that (for example) 
>  (setq foo-variable t)
>  (foo-mode 1) 
> and much more just works non-functional sequence of requires etc fudging

foo-mode is not a variable but a function.  Autoloading functions does
not suffer from the "can of worms" effect.

> Today with package archives the in thing, dependency management is inevitable
> Do emacs packages have the sophisticated .deb style packaging?
> My impression is that wheel will slowly and painfully and inevitably get reinvented.
> Why not leapfrog?

I lost you here.  What does this have to do with use-package?
[ Side note: ELPA does have dependency management, tho it's not as
  sophisticated as the one in APT.  ]

>> The problem is to define "something like".
> Simply solved -- Just pick up req-package :-)

I haven't looked at it.  Does it drop the "work around mis-configured
packages" baggage?


        Stefan

Re: using use-package

[Rusi]

On Sunday, August 9, 2015 at 10:47:29 PM UTC+5:30, Stefan Monnier wrote:
> >> The problem is to define "something like".
> > Simply solved -- Just pick up req-package :-)
> 
> I haven't looked at it.  Does it drop the "work around mis-configured
> packages" baggage?

req-package is basically use-package + dependency management + el-get.
Do you see apt-get just off the horizon?

Does it work??
Long story
req-package 'requires' use-package, dash, log4e
So  kind of 'recursion' problem -- req-package needs (a bit of) the
problem that it is solving pre-solved.

So I tried the author's sister package-using-examplar system
https://github.com/edvorg/emacs-configs

which means I now have to get rid of my own .emacs.d
Use this new one
And retrofit all my stuff onto that framework

Re: using use-package

[Stefan Monnier]

>> I haven't looked at it.  Does it drop the "work around mis-configured
>> packages" baggage?
> req-package is basically use-package + dependency management + el-get.
> Do you see apt-get just off the horizon?

I'm not sure what el-get offers that ELPA doesn't, and ELPA does do
dependency management, so what I see on this horizon is more wheels
reinvented to work around poorly configured packages.


        Stefan

Re: using use-package

[Robert Thorpe]

Rusi <rustompmody@gmail.com> writes:

> On Sunday, August 9, 2015 at 10:47:29 PM UTC+5:30, Stefan Monnier wrote:
>> >> The problem is to define "something like".
>> > Simply solved -- Just pick up req-package :-)
>> 
>> I haven't looked at it.  Does it drop the "work around mis-configured
>> packages" baggage?
>
> req-package is basically use-package + dependency management + el-get.
> Do you see apt-get just off the horizon?

When you say "dependency management" what do you mean?  I think you're
talking at cross-purposes with the other, and you mean something else.

BR,
Robert Thorpe

Re: using use-package

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

>> req-package is basically use-package + dependency
>> management + el-get. Do you see apt-get just off
>> the horizon?
>
> When you say "dependency management" what do
> you mean?

Good question :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: using use-package

[Phillip Lord]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Rusi <rustompmody@gmail.com> writes:
>
>> On Sunday, August 9, 2015 at 10:47:29 PM UTC+5:30, Stefan Monnier wrote:
>>> >> The problem is to define "something like".
>>> > Simply solved -- Just pick up req-package :-)
>>> 
>>> I haven't looked at it.  Does it drop the "work around mis-configured
>>> packages" baggage?
>>
>> req-package is basically use-package + dependency management + el-get.
>> Do you see apt-get just off the horizon?
>
> When you say "dependency management" what do you mean?  I think you're
> talking at cross-purposes with the other, and you mean something else.


AFAICT, req-package solves problems of dependencies between your
configuration of packages, rather than between packages. For example,
you want to use company mode to provide completions for cider-mode.
Conclusion: you want to configure company-mode before you configure
cider mode. req-package allows you to declare this relationship and let
it figure out the order.

I never tried it, as it seems to solve an occasional problem. So, you
are right: "dependency management" is different from the other kind of
package dependency.

Phil

Re: using use-package

[Stefan Monnier]

> Conclusion: you want to configure company-mode before you configure
> cider mode.

Why?  Can't you do the `add-hook's and the `setq's in pretty much
any order you want?


        Stefan

Re: using use-package

[Nikolay Kudryavtsev]

Cider does not really require company, nor company requires cider. But 
when we have both we need to configure them to work together. I've 
noticed that those "intersection" configuration relationships are more 
common than real requirement relationships. Putting intersection like 
this into use-package declarations for either package does not seem like 
a correct way of doing it. Instead I wish there was a separate macro for 
cases like this.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: using use-package

[Edward Knyshov]

Nicolay, here is example from my config.

(req-package company
  :require yasnippet
  :config (progn (global-company-mode 1)
                 (setq company-idle-delay 0.1)
                 (setq company-show-numbers t)
                 (setq company-minimum-prefix-length 2)
                 (setq company-dabbrev-downcase nil)
                 (setq company-dabbrev-other-buffers t)
(setq company-auto-complete nil)
                 (setq company-dabbrev-code-other-buffers 'all)
                 (setq company-dabbrev-code-everywhere t)
                 (setq company-dabbrev-code-ignore-case t)
                 (global-set-key (kbd "C-<tab>") 'company-dabbrev)
                 (global-set-key (kbd "M-<tab>") 'company-complete)
                 (global-set-key (kbd "C-c C-y") 'company-yasnippet)))

(req-package company-quickhelp
  :require company
  :config (company-quickhelp-mode 1))

(req-package company-restclient
  :require company
  :config (add-to-list 'company-backends 'company-restclient))

So cider initialization would look like this

(req-package cider
  :require company
  :config ({init-cier-for-company-mode}))

It might solve your problem.

On Fri, Aug 14, 2015 at 8:12 AM Nikolay Kudryavtsev <
nikolay.kudryavtsev@gmail.com> wrote:

> Cider does not really require company, nor company requires cider. But
> when we have both we need to configure them to work together. I've
> noticed that those "intersection" configuration relationships are more
> common than real requirement relationships. Putting intersection like
> this into use-package declarations for either package does not seem like
> a correct way of doing it. Instead I wish there was a separate macro for
> cases like this.
>
> --
> Best Regards,
> Nikolay Kudryavtsev
>
>
>

Re: using use-package

[Nikolay Kudryavtsev]

Hello Edward.

It's not about the practical problem of setting up cider and company. 
Its about the generic problem of which cider and company is just one 
example.

Req-package makes our configuration for cider depend on our 
configuration for company-mode. This is a working solution in practice, 
but to me it seems wrong from a theoretical standpoint, since it mingles 
too much together. The original reasoning for use-package is separating 
package configurations into separate forms for every single package. But 
cases like this create multi-package forms, since our configuration for 
cider also sets up some stuff for company mode. A better (theoretical) 
solution is to have another macro specifically for situations like this.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: using use-package

[Edward Knyshov]

From my point of view cider couldn't be configured without company mode,
because some features lays on it, but company could.
That's why company is dependency of cider in this example. That's why
company is single req-package form and cider is dependent form.

On Fri, Aug 14, 2015 at 9:28 AM Nikolay Kudryavtsev <
nikolay.kudryavtsev@gmail.com> wrote:

> Hello Edward.
>
> It's not about the practical problem of setting up cider and company.
> Its about the generic problem of which cider and company is just one
> example.
>
> Req-package makes our configuration for cider depend on our
> configuration for company-mode. This is a working solution in practice,
> but to me it seems wrong from a theoretical standpoint, since it mingles
> too much together. The original reasoning for use-package is separating
> package configurations into separate forms for every single package. But
> cases like this create multi-package forms, since our configuration for
> cider also sets up some stuff for company mode. A better (theoretical)
> solution is to have another macro specifically for situations like this.
>
> --
> Best Regards,
> Nikolay Kudryavtsev
>
>

Re: using use-package

[Edward Knyshov]

So if we do not use cider, we still can use company in some other modes,
because they also could :require company

On Fri, Aug 14, 2015 at 9:44 AM Edward Knyshov <edvorg@gmail.com> wrote:

> From my point of view cider couldn't be configured without company mode,
> because some features lays on it, but company could.
> That's why company is dependency of cider in this example. That's why
> company is single req-package form and cider is dependent form.
>
> On Fri, Aug 14, 2015 at 9:28 AM Nikolay Kudryavtsev <
> nikolay.kudryavtsev@gmail.com> wrote:
>
>> Hello Edward.
>>
>> It's not about the practical problem of setting up cider and company.
>> Its about the generic problem of which cider and company is just one
>> example.
>>
>> Req-package makes our configuration for cider depend on our
>> configuration for company-mode. This is a working solution in practice,
>> but to me it seems wrong from a theoretical standpoint, since it mingles
>> too much together. The original reasoning for use-package is separating
>> package configurations into separate forms for every single package. But
>> cases like this create multi-package forms, since our configuration for
>> cider also sets up some stuff for company mode. A better (theoretical)
>> solution is to have another macro specifically for situations like this.
>>
>> --
>> Best Regards,
>> Nikolay Kudryavtsev
>>
>>

Re: using use-package

[Edward Knyshov]

If you have many packages depending on company, your multi-package form may
become very big and complex.

On Fri, Aug 14, 2015 at 9:46 AM Edward Knyshov <edvorg@gmail.com> wrote:

> So if we do not use cider, we still can use company in some other modes,
> because they also could :require company
>
> On Fri, Aug 14, 2015 at 9:44 AM Edward Knyshov <edvorg@gmail.com> wrote:
>
>> From my point of view cider couldn't be configured without company mode,
>> because some features lays on it, but company could.
>> That's why company is dependency of cider in this example. That's why
>> company is single req-package form and cider is dependent form.
>>
>> On Fri, Aug 14, 2015 at 9:28 AM Nikolay Kudryavtsev <
>> nikolay.kudryavtsev@gmail.com> wrote:
>>
>>> Hello Edward.
>>>
>>> It's not about the practical problem of setting up cider and company.
>>> Its about the generic problem of which cider and company is just one
>>> example.
>>>
>>> Req-package makes our configuration for cider depend on our
>>> configuration for company-mode. This is a working solution in practice,
>>> but to me it seems wrong from a theoretical standpoint, since it mingles
>>> too much together. The original reasoning for use-package is separating
>>> package configurations into separate forms for every single package. But
>>> cases like this create multi-package forms, since our configuration for
>>> cider also sets up some stuff for company mode. A better (theoretical)
>>> solution is to have another macro specifically for situations like this.
>>>
>>> --
>>> Best Regards,
>>> Nikolay Kudryavtsev
>>>
>>>

Re: using use-package

[Phillip Lord]

Hmmm. Yet `company-yasnippet' is autoloaded. So, you shouldn't need the
require. In this case, you do actually, because company-yasnippet does
not `(require 'yasnippet)', even though it uses several yasnippet
functions that are not autoloaded.

So, why does company-yasnippet not require yasnippet? Not sure. I guess
because they do not want to make company "Package-Require: yasnippet",
so they have used instead:

(declare-function yas-expand-snippet "yasnippet")

Perhaps, company needs to do

(unless (require 'yasnippet nil t)
  (declare-function yas-expand-snippet "yasnippet"))

which should obviate the need for your dependency and yet still shut the
byte compiler up if yasnippet were not installed.

Phil

Edward Knyshov <edvorg@gmail.com> writes:

> Nicolay, here is example from my config.
>
> (req-package company
>   :require yasnippet
>   :config (progn (global-company-mode 1)
>                  (setq company-idle-delay 0.1)
>                  (setq company-show-numbers t)
>                  (setq company-minimum-prefix-length 2)
>                  (setq company-dabbrev-downcase nil)
>                  (setq company-dabbrev-other-buffers t)
> (setq company-auto-complete nil)
>                  (setq company-dabbrev-code-other-buffers 'all)
>                  (setq company-dabbrev-code-everywhere t)
>                  (setq company-dabbrev-code-ignore-case t)
>                  (global-set-key (kbd "C-<tab>") 'company-dabbrev)
>                  (global-set-key (kbd "M-<tab>") 'company-complete)
>                  (global-set-key (kbd "C-c C-y") 'company-yasnippet)))
>
> (req-package company-quickhelp
>   :require company
>   :config (company-quickhelp-mode 1))
>
> (req-package company-restclient
>   :require company
>   :config (add-to-list 'company-backends 'company-restclient))
>
> So cider initialization would look like this
>
> (req-package cider
>   :require company
>   :config ({init-cier-for-company-mode}))
>
> It might solve your problem.
>
> On Fri, Aug 14, 2015 at 8:12 AM Nikolay Kudryavtsev <
> nikolay.kudryavtsev@gmail.com> wrote:
>
>> Cider does not really require company, nor company requires cider. But
>> when we have both we need to configure them to work together. I've
>> noticed that those "intersection" configuration relationships are more
>> common than real requirement relationships. Putting intersection like
>> this into use-package declarations for either package does not seem like
>> a correct way of doing it. Instead I wish there was a separate macro for
>> cases like this.
>>
>> --
>> Best Regards,
>> Nikolay Kudryavtsev
>>
>>
>>
>
>

-- 
Phillip Lord,                           Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

Re: using use-package

[Rusi]

On Tuesday, August 11, 2015 at 6:53:26 AM UTC+5:30, Robert Thorpe wrote:
> Rusi writes:
> 
> > On Sunday, August 9, 2015 at 10:47:29 PM UTC+5:30, Stefan Monnier wrote:
> >> >> The problem is to define "something like".
> >> > Simply solved -- Just pick up req-package :-)
> >> 
> >> I haven't looked at it.  Does it drop the "work around mis-configured
> >> packages" baggage?
> >
> > req-package is basically use-package + dependency management + el-get.
> > Do you see apt-get just off the horizon?
> 
> When you say "dependency management" what do you mean?  I think you're
> talking at cross-purposes with the other, and you mean something else.

The author of req-package posted a separate thread explaining its theme.

Re: using use-package

[Grant Rettke]

On Fri, Aug 7, 2015 at 9:36 PM, Rusi <rustompmody@gmail.com> wrote:
> Can you share (the relevant pieces of) your init??

https://github.com/grettke/help/blob/master/help.org#watch-what-you-eat
https://github.com/grettke/help/blob/master/.emacs.el#L116

Re: using use-package

[Rusi]

On Monday, August 10, 2015 at 7:49:58 AM UTC+5:30, Grant Rettke wrote:
> On Fri, Aug 7, 2015 at 9:36 PM, Rusi wrote:
> > Can you share (the relevant pieces of) your init??
> 
> https://github.com/grettke/help/blob/master/help.org#watch-what-you-eat
> https://github.com/grettke/help/blob/master/.emacs.el#L116

Thanks Grant!
Will need time to study your approach

using use-package

[Sharon Kimble]

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

I am having great difficulty in getting "use-package" to work
successfully.

I have this in my "init.org" -
--8<---------------cut here---------------start------------->8---
#+begin_src emacs-lisp
(use-package fold-this
  :commands (fold-this-all fold-this fold-this-unfold-all)
  :defer 2
  :init
  :bind (("C-c C-c C-f" . fold-this-all)
        ("C-c C-c C-d" . fold this)
        ("C-c C-c C-c" . fold-this-unfold-all)))
#+end_src
--8<---------------cut here---------------end--------------->8---

which when it is tangled shows -

╭────
│Invalid read syntax: . in wrong context
╰────

and using "bug-hunter-file" on my "init.el" shows

--8<---------------cut here---------------start------------->8---
"/home/boudiccas/.emacs.d/org/init.el", line 8029 pos 0:
  There's a . in wrong context on this position, and that is not valid elisp syntax.
--8<---------------cut here---------------end--------------->8---

But I've looked at https://github.com/jwiegley/use-package and laid it
out according to that page, but its still failing, and I don't
understand why. I'm obviously missing something in my understanding, but
why is it still failing, and how do I get it to run properly please?

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.0, fluxbox 1.3.7, emacs 24.5.50.3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: using use-package

[Chunyang Xu]

On Tue, Aug 4, 2015 at 11:01 PM, Sharon Kimble
<boudiccas@skimble.plus.com> wrote:
> I am having great difficulty in getting "use-package" to work
> successfully.
>
> I have this in my "init.org" -
> --8<---------------cut here---------------start------------->8---
> #+begin_src emacs-lisp
> (use-package fold-this
>   :commands (fold-this-all fold-this fold-this-unfold-all)
>   :defer 2
>   :init
>   :bind (("C-c C-c C-f" . fold-this-all)
>         ("C-c C-c C-d" . fold this)
>         ("C-c C-c C-c" . fold-this-unfold-all)))
> #+end_src
> --8<---------------cut here---------------end--------------->8---
>

A dash ("-") is missing between "fold" and "this" in your second bind.


> which when it is tangled shows -
>
> ╭────
> │Invalid read syntax: . in wrong context
> ╰────
>
> and using "bug-hunter-file" on my "init.el" shows
>
> --8<---------------cut here---------------start------------->8---
> "/home/boudiccas/.emacs.d/org/init.el", line 8029 pos 0:
>   There's a . in wrong context on this position, and that is not valid elisp syntax.
> --8<---------------cut here---------------end--------------->8---
>
> But I've looked at https://github.com/jwiegley/use-package and laid it
> out according to that page, but its still failing, and I don't
> understand why. I'm obviously missing something in my understanding, but
> why is it still failing, and how do I get it to run properly please?
>
> Thanks
> Sharon.
> --
> A taste of linux = http://www.sharons.org.uk
> TGmeds = http://www.tgmeds.org.uk
> Debian 8.0, fluxbox 1.3.7, emacs 24.5.50.3

Re: using use-package

[Phillip Lord]

Sharon Kimble <boudiccas@skimble.plus.com> writes:

> I am having great difficulty in getting "use-package" to work
> successfully.
>
> I have this in my "init.org" -
>
> #+begin_src emacs-lisp
> (use-package fold-this
>   :commands (fold-this-all fold-this fold-this-unfold-all)
>   :defer 2
>   :init
>   :bind (("C-c C-c C-f" . fold-this-all)
>         ("C-c C-c C-d" . fold this)
>         ("C-c C-c C-c" . fold-this-unfold-all)))
> #+end_src
>
>
> which when it is tangled shows -
>
> ╭────
> │Invalid read syntax: . in wrong context
> ╰────
>
> and using "bug-hunter-file" on my "init.el" shows
>



It's the line before!

:init


needs an argument. The problem is that ":bind" is being interpreted as
the argument for ":init", but not crashing (because it's a macro) and
then the alist is breaking.

Probably you don't need the :init at all.

Re: using use-package

[Sharon Kimble]

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

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

> Sharon Kimble <boudiccas@skimble.plus.com> writes:
>
>> I am having great difficulty in getting "use-package" to work
>> successfully.
>>
>> I have this in my "init.org" -
>>
>> #+begin_src emacs-lisp
>> (use-package fold-this
>>   :commands (fold-this-all fold-this fold-this-unfold-all)
>>   :defer 2
>>   :init
>>   :bind (("C-c C-c C-f" . fold-this-all)
>>         ("C-c C-c C-d" . fold this)
>>         ("C-c C-c C-c" . fold-this-unfold-all)))
>> #+end_src
>>
>>
>> which when it is tangled shows -
>>
>> ╭────
>> │Invalid read syntax: . in wrong context
>> ╰────
>>
>> and using "bug-hunter-file" on my "init.el" shows
>>
>
>
>
> It's the line before!
>
> :init
>
>
> needs an argument. The problem is that ":bind" is being interpreted as
> the argument for ":init", but not crashing (because it's a macro) and
> then the alist is breaking.
>
> Probably you don't need the :init at all.

Thanks, your right, it is tangling well now with no problems, along
with Chunyang's spot of a missing "-".

Thanks all folks, I'm hoping to rewrite my total init file this week to
use "use-package" with every package that I use, but we shall see.

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.0, fluxbox 1.3.7, emacs 24.5.50.3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: using use-package

[Grant Rettke]

On Tue, Aug 4, 2015 at 1:24 PM, Sharon Kimble
<boudiccas@skimble.plus.com> wrote:
> Thanks all folks, I'm hoping to rewrite my total init file this week to
> use "use-package" with every package that I use, but we shall see.

Cool let us know how it goes.

Re: using use-package

[Phillip Lord]

Sharon Kimble <boudiccas@skimble.plus.com> writes:

> phillip.lord@newcastle.ac.uk (Phillip Lord) writes:
>
>> Sharon Kimble <boudiccas@skimble.plus.com> writes:
>>
>>
>>
>> It's the line before!
>>
>> :init
>>
>>
>> needs an argument. The problem is that ":bind" is being interpreted as
>> the argument for ":init", but not crashing (because it's a macro) and
>> then the alist is breaking.
>>
>> Probably you don't need the :init at all.
>
> Thanks, your right, it is tangling well now with no problems, along
> with Chunyang's spot of a missing "-".

Ah, yes, you have to run it to actually see that error.

> Thanks all folks, I'm hoping to rewrite my total init file this week to
> use "use-package" with every package that I use, but we shall see.

Oh, use-package is great. It is not that it actually does that much
(although it does some stuff!), but that it allows (and in all honesty,
forces) you to group together all configuration. I used to do this with
multiple files that I loaded, but this works as better and is simpler.
Add in :ensure and the unison file sync tool, and you can move from
machine to machine, with identical set ups -- that's the way I use it.
Pretty much the only package that I do not use use-package for is
use-package, as it doesn't bootstrap!

If I can be allowed to add a plug, also worth taking a look at my own
lentic package. I know that some people are using this for their init
file. It allows you to use org without all that tangling business.

Phil

Re: using use-package

[Grant Rettke]

On Tue, Aug 4, 2015 at 4:24 PM, Phillip Lord
<phillip.lord@newcastle.ac.uk> wrote:
> Oh, use-package is great. It is not that it actually does that much
> (although it does some stuff!), but that it allows (and in all honesty,
> forces) you to group together all configuration. I used to do this with
> multiple files that I loaded, but this works as better and is simpler.
> Add in :ensure and the unison file sync tool, and you can move from
> machine to machine, with identical set ups -- that's the way I use it.
> Pretty much the only package that I do not use use-package for is
> use-package, as it doesn't bootstrap!

My system uses it for package provisioning and loading but not
compartmentalization of configuration. The system wouldn't be useful
with major features missing so I let it crash and burn as soon as
possible.

> If I can be allowed to add a plug, also worth taking a look at my own
> lentic package. I know that some people are using this for their init
> file. It allows you to use org without all that tangling business.

Lentic is a very nice system. All of the literate systems out there
are an important part of the collective mindshare.