How-to disable persistent *EBDB-Message* buffer?

How-to disable persistent *EBDB-Message* buffer?

[Pankaj Jangid]

Whenever I type partial names in address fields and press tab,
completion buffer appears. That is fine. But after completion and new
buffer *EBDB-Message* appears in a separate window and it remains
open. How can I prevent this buffer from opening a new window?

I have tried setting ‘ebdb-mua-pop-up’ to nil, but I guess that is for
something else.

--
Regards
Pankaj

Re: How-to disable persistent *EBDB-Message* buffer?

[Eric Abrahamsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Whenever I type partial names in address fields and press tab,
> completion buffer appears. That is fine. But after completion and new
> buffer *EBDB-Message* appears in a separate window and it remains
> open. How can I prevent this buffer from opening a new window?
>
> I have tried setting ‘ebdb-mua-pop-up’ to nil, but I guess that is for
> something else.

Hi, thanks for the report! The `ebdb-mua-pop-up' option definitely
should govern this, but I see that you'd actually need to set another
option to nil to really make it work: `ebdb-completion-display-record'.
That should solve the immediate problem for you.

All of the completion stuff in EBDB is due for an overhaul, one of my
New Year's resolutions!

Thanks,
Eric

Re: How-to disable persistent *EBDB-Message* buffer?

[Pankaj Jangid]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Hi, thanks for the report! The `ebdb-mua-pop-up' option definitely
> should govern this, but I see that you'd actually need to set another
> option to nil to really make it work: `ebdb-completion-display-record'.
> That should solve the immediate problem for you.
>
> All of the completion stuff in EBDB is due for an overhaul, one of my
> New Year's resolutions!

Thanks for the workaround. It worked for me.

Thanks for all your work. I would like to see ebdb as part of built-in
packages. But since it is in ELPA, that is also okay.

ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Pankaj Jangid wrote:

> Thanks for all your work. I would like to see ebdb as part
> of built-in packages. But since it is in ELPA, that is
> also okay.

What is that, like ~/.mailrc ?

As for ELPA ... this has happened to me for as long as
I can remember.

  Packages that can be upgraded: 11; type ‘U’ to mark
  for upgrading.
  
  (hit U)
  
  package-menu--mark-upgrades-1: Wrong type argument:
  package-desc, nil

Also... can you do it without having to do this

  byte-compile=$(emacs) \
     -batch \
     -eval "(setq load-path (append load-path '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\" \"~/.emacs.d/elpa/vterm-20201004.2057\" \"~/.emacs.d/elpa/markdown-mode-20201015.1327\" \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
     -f batch-byte-compile

In the Makefile? (Set the load-path again for every pack, I mean.)

https://dataswamp.org/~incal/emacs-init/Makefile

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Eric Abrahamsen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Pankaj Jangid wrote:
>
>> Thanks for all your work. I would like to see ebdb as part
>> of built-in packages. But since it is in ELPA, that is
>> also okay.
>
> What is that, like ~/.mailrc ?

It's a port/rewrite of BBDB, so it's full-blown contact management, not
just mail completion.

> As for ELPA... this has happened to me for as long as
> I can remember.
>
>   Packages that can be upgraded: 11; type ‘U’ to mark
>   for upgrading.
>   
>   (hit U)
>   
>   package-menu--mark-upgrades-1: Wrong type argument:
>   package-desc, nil
>
> Also... can you do it without having to do this

I don't think either of these things should be happening. Do you have
something like this in your init file?

(require 'package)
(setq package-archives
      '(("gnu" . "https://elpa.gnu.org/packages/")
	("melpa" . "https://melpa.org/packages/")
	("org" . "http://orgmode.org/elpa/")))

(tbh even the `require' might not be necessary)

With that, all the load paths should be set correctly. And I wouldn't be
surprised if the earlier error would be resolved as well.

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eric Abrahamsen wrote:

> I don't think either of these things should be happening.
> Do you have something like this in your init file?
>
> (require 'package)
> (setq package-archives
>       '(("gnu" . "https://elpa.gnu.org/packages/")
> 	("melpa" . "https://melpa.org/packages/")
> 	("org" . "http://orgmode.org/elpa/")))

Yes, otherwise it wouldn't work at all :)

(setq package-archives
  '(( "gnu elpa" . "https://elpa.gnu.org/packages/")
    (    "melpa" . "https://melpa.org/packages/") )) ; [1]

> (tbh even the `require' might not be necessary)

Maybe not necessary but byte-compiler will complain
without it.

[1] https://dataswamp.org/~incal/emacs-init/elpa.el

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Eric Abrahamsen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Eric Abrahamsen wrote:
>
>> I don't think either of these things should be happening.
>> Do you have something like this in your init file?
>>
>> (require 'package)
>> (setq package-archives
>>       '(("gnu" . "https://elpa.gnu.org/packages/")
>> 	("melpa" . "https://melpa.org/packages/")
>> 	("org" . "http://orgmode.org/elpa/")))
>
> Yes, otherwise it wouldn't work at all :)

Actually it looks like package-archives defaults to containing gnu and
nongnu, so unless you're installing from melpa you wouldn't even need
that. But that might be a recent change -- what version of Emacs are you
running?

I wonder if you have a package in `package-selected-packages' that no
longer exists, and that's why the update is failing?

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eric Abrahamsen wrote:

>>> (require 'package)
>>> (setq package-archives
>>>       '(("gnu" . "https://elpa.gnu.org/packages/")
>>> 	("melpa" . "https://melpa.org/packages/")
>>> 	("org" . "http://orgmode.org/elpa/")))
>>
>> Yes, otherwise it wouldn't work at all :)
>
> Actually it looks like package-archives defaults to
> containing gnu and nongnu, so unless you're installing from
> melpa you wouldn't even need that.

  Original value was (("gnu" . "https://elpa.gnu.org/packages/"))

So yep, could just push melpa then...

> But that might be a recent change -- what version of Emacs
> are you running?

GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.5, cairo version 1.16.0) of 2020-10-23

> I wonder if you have a package in
> `package-selected-packages' that no longer exists, and
> that's why the update is failing?

  with-editor w3m vterm timp slime seq quiz markdown-mode
  lua-mode google-translate gnuplot-mode crontab-mode
  ascii-art-to-unicode

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Eric Abrahamsen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Eric Abrahamsen wrote:
>
>>>> (require 'package)
>>>> (setq package-archives
>>>>       '(("gnu" . "https://elpa.gnu.org/packages/")
>>>> 	("melpa" . "https://melpa.org/packages/")
>>>> 	("org" . "http://orgmode.org/elpa/")))
>>>
>>> Yes, otherwise it wouldn't work at all :)
>>
>> Actually it looks like package-archives defaults to
>> containing gnu and nongnu, so unless you're installing from
>> melpa you wouldn't even need that.
>
>   Original value was (("gnu" . "https://elpa.gnu.org/packages/"))
>
> So yep, could just push melpa then...
>
>> But that might be a recent change -- what version of Emacs
>> are you running?
>
> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.5, cairo version 1.16.0) of 2020-10-23
>
>> I wonder if you have a package in
>> `package-selected-packages' that no longer exists, and
>> that's why the update is failing?
>
>   with-editor w3m vterm timp slime seq quiz markdown-mode
>   lua-mode google-translate gnuplot-mode crontab-mode
>   ascii-art-to-unicode

Well that was a red herring. I don't actually know that much about
package.el, sorry! It almost looks more like a problem with
tabulated-list-mode. Would you do M-x toggle-debug-on-error and trigger
the error again, and post the full backtrace? Maybe someone will be able
to make sense of it, or we can do a proper bug report.

Re: ELPA

[Stefan Monnier]

> As for ELPA ... this has happened to me for as long as
> I can remember.
>
>   Packages that can be upgraded: 11; type ‘U’ to mark
>   for upgrading.
>   
>   (hit U)
>   
>   package-menu--mark-upgrades-1: Wrong type argument:
>   package-desc, nil

Sounds like a bug.  Please report it.  And if you can, try to get
a backtrace (e.g. via `M-x toggle-debug-on-error RET`).

> Also... can you do it without having to do this

Not sure what "it" refers to.

>   byte-compile=$(emacs) \
>      -batch \
>      -eval "(setq load-path (append load-path '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\" \"~/.emacs.d/elpa/vterm-20201004.2057\" \"~/.emacs.d/elpa/markdown-mode-20201015.1327\" \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
>      -f batch-byte-compile
>
> In the Makefile? (Set the load-path again for every pack, I mean.)

Which Makefile?

I think the answer is something like:

    byte-compile=$(emacs)                      \
       --batch --eval "(package-activate-all)" \
       -f batch-byte-compile


        Stefan

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>> Packages that can be upgraded: 11; type ‘U’ to mark
>> for upgrading.
>>   
>> (hit U)
>>   
>> package-menu--mark-upgrades-1: Wrong type argument:
>> package-desc, nil
>
> Sounds like a bug. Please report it. And if you can, try to
> get a backtrace (e.g. via `M-x toggle-debug-on-error RET`).

OK.

>> byte-compile=$(emacs) \
>>   -batch \
>>   -eval "(setq load-path (append load-path '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\" \"~/.emacs.d/elpa/vterm-20201004.2057\" \"~/.emacs.d/elpa/markdown-mode-20201015.1327\" \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
>>   -f batch-byte-compile
>>
>> In the Makefile? (Set the load-path again for every pack, I mean.)
>
> Which Makefile?

https://dataswamp.org/~incal/emacs-init/Makefile

> I think the answer is something like:
>
>     byte-compile=$(emacs)                      \
>        --batch --eval "(package-activate-all)" \
>        -f batch-byte-compile

80 errors of this, the same kind:

count.el: 
edit.el: 
buc.el: 
In toplevel form:
align-new.el:7:1: Error: Cannot open load file: No such file or directory, my-string
r-regexp

In toplevel form:
align-new.el:7:1: Error: Cannot open load file: No such file or directory, my-string
r-regexp

align-new.el: 
In toplevel form:
align-new.el:7:1: Error: Cannot open load file: No such file or directory, my-string
r-regexp

...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>> Packages that can be upgraded: 11; type ‘U’ to mark
>> for upgrading.
>>   
>> (hit U)
>>   
>> package-menu--mark-upgrades-1: Wrong type argument:
>> package-desc, nil
>
> Sounds like a bug. Please report it. And if you can, try to
> get a backtrace (e.g. via `M-x toggle-debug-on-error RET`).

*Messages*

  Packages that can be upgraded: 10; type ‘U’ to mark for upgrading.
  package-menu--mark-upgrades-1: Wrong type argument: package-desc, nil

*Backtrace*

  Debugger entered--Lisp error: (wrong-type-argument package-desc nil)
  signal(wrong-type-argument (package-desc nil))
  package-menu--mark-upgrades-1()
  package-menu-mark-upgrades()
  funcall-interactively(package-menu-mark-upgrades)
  call-interactively(package-menu-mark-upgrades nil nil)
  command-execute(package-menu-mark-upgrades)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?)

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Also... can you do it without having to do this
>
>   byte-compile=$(emacs) \
>      -batch \
>      -eval "(setq load-path (append load-path '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\" \"~/.emacs.d/elpa/vterm-20201004.2057\" \"~/.emacs.d/elpa/markdown-mode-20201015.1327\" \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
>      -f batch-byte-compile
>
> In the Makefile? (Set the load-path again for every pack, I mean.)
>
> https://dataswamp.org/~incal/emacs-init/Makefile

You can make it little more photogenic, a little less
error-prone, and give you a little more control by doing THIS,
but it's still the same, manual approach. Looks a lot better
tho so yeah, do it :)

emacs=/usr/local/bin/emacs

ema-path=~/.emacs.d/emacs-init
ema-gnus=\"${ema-path}/gnus\"
ema-ide=\"${ema-path}/ide\"
ema-init=\"${ema-path}\"
ema-w3m=\"${ema-path}/w3m\"
ema=${ema-gnus} ${ema-ide} ${ema-init} ${ema-w3m}

elpa-path=~/.emacs.d/elpa
markdown-mode=\"${elpa-path}/markdown-mode-20201220.253\"
w3m=\"${elpa-path}/w3m-20210104.424\"
elpa=${markdown-mode} ${w3m}

packs=${ema} ${elpa}

byte-compile=$(emacs)                                       \
	--batch                                                  \
	--eval "(setq load-path (append load-path '(${packs})))" \
	-f batch-byte-compile

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Stefan Monnier]

>>> byte-compile=$(emacs) \
>>>   -batch \
>>>   -eval "(setq load-path (append load-path
>>> '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\"
>>> \"~/.emacs.d/elpa/vterm-20201004.2057\"
>>> \"~/.emacs.d/elpa/markdown-mode-20201015.1327\"
>>> \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\"
>>> \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\"
>>> \"~/.emacs.d/emacs-init/gnus\"
>>> \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
>>>   -f batch-byte-compile
>>>
>>> In the Makefile? (Set the load-path again for every pack, I mean.)
>>
>> Which Makefile?
>
> https://dataswamp.org/~incal/emacs-init/Makefile
>
>> I think the answer is something like:
>>
>>     byte-compile=$(emacs)                      \
>>        --batch --eval "(package-activate-all)" \
>>        -f batch-byte-compile
>
> 80 errors of this, the same kind:

I didn't mean for you to use this literally.  Obviously, you'll need to
adapt it to your specific circumstance.  The `package-activate-all`
should take care of all the ~/.emacs.d/elpa/*


        Stefan

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>>> I think the answer is something like:
>>>
>>>     byte-compile=$(emacs)                      \
>>>        --batch --eval "(package-activate-all)" \
>>>        -f batch-byte-compile
>>
>> 80 errors of this, the same kind:
>
> I didn't mean for you to use this literally. Obviously,
> you'll need to adapt it to your specific circumstance.
> The `package-activate-all` should take care of all the
> ~/.emacs.d/elpa/*

Yes, that works!

... but I don't know what stuff there is in ~/.emacs.d/elpa/*
- the explicit method seems to offer more control.

emacs=/usr/local/bin/emacs

ema-path=~/.emacs.d/emacs-init
ema-gnus=\"${ema-path}/gnus\"
ema-ide=\"${ema-path}/ide\"
ema-init=\"${ema-path}\"
ema-w3m=\"${ema-path}/w3m\"
ema=${ema-gnus} ${ema-ide} ${ema-init} ${ema-w3m}

byte-compile=$(emacs)                                       \
	--batch                                                  \
   --eval "(package-activate-all)"                          \
	--eval "(setq load-path (append load-path '(${ema})))"   \
	-f batch-byte-compile

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Stefan Monnier]

>> I didn't mean for you to use this literally. Obviously,
>> you'll need to adapt it to your specific circumstance.
>> The `package-activate-all` should take care of all the
>> ~/.emacs.d/elpa/*
>
> Yes, that works!
>
> ... but I don't know what stuff there is in ~/.emacs.d/elpa/*
> - the explicit method seems to offer more control.

I suggested it based on your request:

    Also... can you do it without having to do this
    [...]
    In the Makefile? (Set the load-path again for every pack, I mean.)

So, either you want to enumerate every pack in order "to offer more
control", or you want to "do it without having to [...] set the
load-path again for every pack".

I don't think you can have your cake and eat it too, tho maybe it's just
me being too pessimistic.


        Stefan

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>>> I didn't mean for you to use this literally. Obviously,
>>> you'll need to adapt it to your specific circumstance.
>>> The `package-activate-all` should take care of all the
>>> ~/.emacs.d/elpa/*
>>
>> Yes, that works!
>>
>> ... but I don't know what stuff there is in
>> ~/.emacs.d/elpa/* - the explicit method seems to offer
>> more control.
>
> I suggested it based on your request:
>
>     Also... can you do it without having to do this
>     [...]
>     In the Makefile? (Set the load-path again for every pack, I mean.)
>
> So, either you want to enumerate every pack in order "to
> offer more control", or you want to "do it without having to
> [...] set the load-path again for every pack".
>
> I don't think you can have your cake and eat it too, tho
> maybe it's just me being too pessimistic.

I think there should be a way to recursively add a directory
to the load path, so all the subdirs would be added as well,
but without doing anything else, after that one could compile,
require, load, etc, without restrictions.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

> I think there should be a way to recursively add a directory
> to the load path, so all the subdirs would be added as well,
> but without doing anything else, after that one could
> compile, require, load, etc, without restrictions.

Like this maybe?

(require 'cl-lib)

(defun push-all (base)
  (let ((dirs (cl-remove-if-not
               (lambda (f) (file-accessible-directory-p f))
               (directory-files-recursively base "" t))))
    (setf load-path (nconc dirs load-path) )))

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Stefan Monnier]

> *Backtrace*
>
>   Debugger entered--Lisp error: (wrong-type-argument package-desc nil)
>   signal(wrong-type-argument (package-desc nil))
>   package-menu--mark-upgrades-1()
>   package-menu-mark-upgrades()
>   funcall-interactively(package-menu-mark-upgrades)
>   call-interactively(package-menu-mark-upgrades nil nil)
>   command-execute(package-menu-mark-upgrades)

Hmm.. from which buffer did you run `package-menu-mark-upgrades`?

If you put point in the like that says

    signal(wrong-type-argument (package-desc nil))

in the backtrace buffer and then do:

   e (point) RET

that should give you the position in the *Packages* buffer where it
found line that for some reason doesn't have the expected
`tabulated-list-id` text-property, so you might want to move to that
position in the buffer and look at that line, maybe select it to get
more info about that package.


        Stefan

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

> Hmm.. from which buffer did you run
> `package-menu-mark-upgrades`?
>
> If you put point in the like that says
>
>     signal(wrong-type-argument (package-desc nil))
>
> in the backtrace buffer and then do:
>
>    e (point) RET
>
> that should give you the position in the *Packages* buffer

I've now tried several places in *Packages* - the same.

> where it found line that for some reason doesn't have the
> expected `tabulated-list-id` text-property, so you might
> want to move to that position in the buffer and look at that
> line, maybe select it to get more info about that package.

Buffer *Packages*, line 4, column 2, looking-at "2048-game".

U

package-menu--mark-upgrades-1: Wrong type argument:
package-desc, nil

`describe-text-properties', then tabulated-list-id [Show]

#s(package-desc 2048-game
                (20200417 259)
                "play 2048 in Emacs" nil single "melpa" nil
                ((:commit . "aad4a590ea91f9a3256233b9b345e9159c6993f2")
                 (:authors
                  ("Zachary Kanfer" . "zkanfer@gmail.com"))
                 (:maintainer "Zachary Kanfer" . "zkanfer@gmail.com")
                 (:url . "https://hg.sr.ht/~zck/game-2048"))
                nil)
                
-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Stefan Monnier]

>> Hmm.. from which buffer did you run
>> `package-menu-mark-upgrades`?
>>
>> If you put point in the like that says
>>
>>     signal(wrong-type-argument (package-desc nil))
>>
>> in the backtrace buffer and then do:
>>
>>    e (point) RET
>>
>> that should give you the position in the *Packages* buffer
>
> I've now tried several places in *Packages* - the same.

Not sure what you mean "the same", but the value returned by `(point)`
above should not depend on where you are in *Packages* when you do the
`e` or what you do the `U`.  The `U` command will go through the
*Packages* buffer collecting info on each line, and the above `e`
command should tell you at which buffer position it bumped into
a problem.

In any case, I think we need more info about your situation.
E.g. can you reproduce it from `emacs -Q`?
If not, try to reduce your Emacs's init file as much as possible until
you find a recipe to reproduce the problem starting from `emacs -Q`.


        Stefan