bug#38273: emacs doesn't open files

bug#38273: emacs doesn't open files

[Jesse Gibbons]

guix describe :
Generation 139	Nov 19 2019 08:11:32	(current)
  guix 7b40d59
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 7b40d59114e1462d6d8140f325a66b12e91db667

emacs --version :
GNU Emacs 26.3
Copyright (C) 2019 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

When I launch emacs from the command line, I get the following message:
split-string: Wrong type argument: stringp, nil

As a result, when I try `EDITOR=emacs guix edit hello` it doesn't work.
I can confirm this is not a problem with guix edit, because when EDITOR=vim
it opens the package in vim.

(Joke about guix turning to the dark side goes here.)

Since I do not know if it is a problem with guix or emacs, I'm starting with
guix. It could be related to bug#38261

bug#38273: emacs doesn't open files

[zimoun]

Hi,

I do experiment the same issue.

--8<---------------cut here---------------end--------------->8---
$  guix describe
Generation 56    Nov 19 2019 12:52:57    (current)
  guix 7b40d59
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 7b40d59114e1462d6d8140f325a66b12e91db667
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------end--------------->8---
$ ls -l `which emacs`
lrwxrwxrwx 2 root root 64 Jan  1  1970
/home/simon/.guix-profile/bin/emacs ->
/gnu/store/vb0ia0qnkc92yp771hxhcp8k6ywqymkk-emacs-26.3/bin/emacs
--8<---------------cut here---------------end--------------->8---

Then "emacs -Q" works fine.
However "emacs -q" does not.


All the best,
simon

bug#38274: emacs doesn't open files

[Jesse Gibbons]

On Tue, 2019-11-19 at 08:35 -0700, Jesse Gibbons wrote:
> guix describe :
> Generation 139	Nov 19 2019 08:11:32	(current)
>   guix 7b40d59
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 7b40d59114e1462d6d8140f325a66b12e91db667
> 
> emacs --version :
> GNU Emacs 26.3
> Copyright (C) 2019 Free Software Foundation, Inc.
> GNU Emacs comes with ABSOLUTELY NO WARRANTY.
> You may redistribute copies of GNU Emacs
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING.
> 
> When I launch emacs from the command line, I get the following message:
> split-string: Wrong type argument: stringp, nil
> 
> As a result, when I try `EDITOR=emacs guix edit hello` it doesn't work.
> I can confirm this is not a problem with guix edit, because when
> EDITOR=vim
> it opens the package in vim.
> 
> (Joke about guix turning to the dark side goes here.)
> 
> Since I do not know if it is a problem with guix or emacs, I'm starting
> with
> guix. It could be related to bug#38261
> 
> 
> 
> 
I guess this was fixed for me by restarting my computer.

(joke about "turning it off and back on" working goes here)

bug#38273: bug#38274: emacs doesn't open files

[Maxim Cournoyer]

Hello Jesse,

Jesse Gibbons <jgibbons2357@gmail.com> writes:

> On Tue, 2019-11-19 at 08:35 -0700, Jesse Gibbons wrote:
>> guix describe :
>> Generation 139	Nov 19 2019 08:11:32	(current)
>>   guix 7b40d59
>>     repository URL: https://git.savannah.gnu.org/git/guix.git
>>     branch: master
>>     commit: 7b40d59114e1462d6d8140f325a66b12e91db667
>> 
>> emacs --version :
>> GNU Emacs 26.3
>> Copyright (C) 2019 Free Software Foundation, Inc.
>> GNU Emacs comes with ABSOLUTELY NO WARRANTY.
>> You may redistribute copies of GNU Emacs
>> under the terms of the GNU General Public License.
>> For more information about these matters, see the file named COPYING.
>> 
>> When I launch emacs from the command line, I get the following message:
>> split-string: Wrong type argument: stringp, nil
>> 
>> As a result, when I try `EDITOR=emacs guix edit hello` it doesn't work.
>> I can confirm this is not a problem with guix edit, because when
>> EDITOR=vim
>> it opens the package in vim.
>> 
>> (Joke about guix turning to the dark side goes here.)
>> 
>> Since I do not know if it is a problem with guix or emacs, I'm starting
>> with
>> guix. It could be related to bug#38261
>> 
>> 
>> 
>> 
> I guess this was fixed for me by restarting my computer.
>
> (joke about "turning it off and back on" working goes here)

It seems the EMACSLOADPATH was not defined in your environment.  Do you
use Emacs in your main user profile?  How did this happen?  Did you
simply 'guix pull' and 'guix upgrade -u .' said profile?

In all cases, simply login out and back in should probably have fixed
the issue (instead of a reboot).

Thanks for the report!

Maxim

bug#38273: emacs doesn't open files

[Maxim Cournoyer]

Hello Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> Hi,
>
> I do experiment the same issue.
>
> $  guix describe
> Generation 56    Nov 19 2019 12:52:57    (current)
>   guix 7b40d59
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 7b40d59114e1462d6d8140f325a66b12e91db667
>
> $ ls -l `which emacs`
> lrwxrwxrwx 2 root root 64 Jan  1  1970
> /home/simon/.guix-profile/bin/emacs ->
> /gnu/store/vb0ia0qnkc92yp771hxhcp8k6ywqymkk-emacs-26.3/bin/emacs
>
> Then "emacs -Q" works fine.
> However "emacs -q" does not.
>
>
> All the best,
> simon

Did you sort out your issue?  Perhaps logging out then back in could
define the missing EMACSLOADPATH environment variable? Or manually
sourcing your current profile's etc/profile and starting Emacs from that
shell?

I'll try to isolate how to reproduce the problem; if you have a way to
reproduce it I'm interested!

Maxim

bug#38273: emacs doesn't open files

[Jesse Gibbons]

I thought I closed this issue. Rebooting fixed it.

bug#38273: bug#38274: emacs doesn't open files

[Jesse Gibbons]

On Wed, 2019-11-20 at 06:20 +0900, Maxim Cournoyer wrote:
> Hello Jesse,
> 
> Jesse Gibbons <jgibbons2357@gmail.com> writes:
> 
> > On Tue, 2019-11-19 at 08:35 -0700, Jesse Gibbons wrote:
> > > guix describe :
> > > Generation 139	Nov 19 2019 08:11:32	(current)
> > >   guix 7b40d59
> > >     repository URL: https://git.savannah.gnu.org/git/guix.git
> > >     branch: master
> > >     commit: 7b40d59114e1462d6d8140f325a66b12e91db667
> > > 
> > > emacs --version :
> > > GNU Emacs 26.3
> > > Copyright (C) 2019 Free Software Foundation, Inc.
> > > GNU Emacs comes with ABSOLUTELY NO WARRANTY.
> > > You may redistribute copies of GNU Emacs
> > > under the terms of the GNU General Public License.
> > > For more information about these matters, see the file named COPYING.
> > > 
> > > When I launch emacs from the command line, I get the following
> > > message:
> > > split-string: Wrong type argument: stringp, nil
> > > 
> > > As a result, when I try `EDITOR=emacs guix edit hello` it doesn't
> > > work.
> > > I can confirm this is not a problem with guix edit, because when
> > > EDITOR=vim
> > > it opens the package in vim.
> > > 
> > > (Joke about guix turning to the dark side goes here.)
> > > 
> > > Since I do not know if it is a problem with guix or emacs, I'm
> > > starting
> > > with
> > > guix. It could be related to bug#38261
> > > 
> > > 
> > > 
> > > 
> > I guess this was fixed for me by restarting my computer.
> > 
> > (joke about "turning it off and back on" working goes here)
> 
> It seems the EMACSLOADPATH was not defined in your environment.  
Ok.
> Do you use Emacs in your main user profile?
Yes.
> How did this happen? Did you simply 'guix pull' and 'guix upgrade -u .'
> said profile?
"guix pull && guix upgrade" 
> 
> In all cases, simply login out and back in should probably have fixed
> the issue (instead of a reboot).
As I recall, I turned it off, commuted to a class, and turned it back on.
> 
> Thanks for the report!
> 
> Maxim

bug#38273: emacs doesn't open files

[zimoun]

Hi Maxim,

Thank you to looking.

On Tue, 19 Nov 2019 at 22:51, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> Did you sort out your issue?  Perhaps logging out then back in could
> define the missing EMACSLOADPATH environment variable? Or manually
> sourcing your current profile's etc/profile and starting Emacs from that
> shell?

Yes, sourcing the current etc/profile fixes the issue.

Therefore, EMACSLOADPATH should be the culprit and I had done a
mistake, not enough investigating before reporting. My bad! Sorry!


> I'll try to isolate how to reproduce the problem; if you have a way to
> reproduce it I'm interested!

I think it comes from the new EMACSLOADPATH variable. The new Emacs
binary is looking at it so if the etc/profile is not yet sourced then
troubles arises.
That's why it does not happen with "-Q" because no-site-file and
no-site-lisp, i.e., EMACSLOADPATH is not "required".
However, "-q" just turns off the ~/.emacs and needs EMACSLOADPATH.

So I think to reproduce: install an old Emacs, upgrade, do not source
again the current profile, launch Emacs from this profile.

Well, it is not an issue but a bad practise. :-)
Sorry.


All the best,
simon

bug#38273: emacs doesn't open files

[zimoun]

On Wed, 20 Nov 2019 at 05:09, Jesse Gibbons <jgibbons2357@gmail.com> wrote:
>
> I thought I closed this issue. Rebooting fixed it.

Reinstalling from scratch should also fix the issue. ;-)

bug#38273: emacs doesn't open files

[Maxim Cournoyer]

Hello Zimoun,

zimoun <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> Thank you to looking.
>
> On Tue, 19 Nov 2019 at 22:51, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> Did you sort out your issue?  Perhaps logging out then back in could
>> define the missing EMACSLOADPATH environment variable? Or manually
>> sourcing your current profile's etc/profile and starting Emacs from that
>> shell?
>
> Yes, sourcing the current etc/profile fixes the issue.
>
> Therefore, EMACSLOADPATH should be the culprit and I had done a
> mistake, not enough investigating before reporting. My bad! Sorry!

There's no need to be sorry; that's a pitfall many are likely to
encounter sooner or later.  I'm thinking one common place it'd bite
users would be when they use their desktop manager's application
launcher to start Emacs:  in this case, the EMACSLOADPATH would be taken
from what it was at the time they logged in their session, and would
never be refreshed until the next login.

Example of use case:

1. The user logs in.
2. The user starts Emacs using their DM's application launcher.
3. The user runs 'guix install emacs-paredit in a terminal.
4. The user try "M-x paredit" in their Emacs, only to find out it doesn't
exist.
5. User restart Emacs (again launching it from their application
launcher), but it still doesn't find the `paredit function.

The reason the above use case doesn't work is because the EMACSLOADPATH
environment variable inherited by the desktop manager is fixed and not
refreshed by 'guix install'.  It only gets refreshed when the user logs
out then back in.

This use case could work if all of our packages would be installed to a
single, such as some packages already do (emacs-magit and
emacs-guix) both live under share/emacs/site-lisp.  If all the packages
were installed there, Emacs would find newly installed packages and the
EMACSLOADPATH not being refreshed wouldn't be as much of a problem.

Examples of packages that depend on the EMACSLOADPATH being refreshed
are the packages installed to their own namespaced directory the
share/emacs/site-lisp/guix.d prefix.  One such example is
'emacs-grep-a-lot':

--8<---------------cut here---------------start------------->8---
tree /gnu/store/vhk1ljc45jn465xk3lqx0030qlkp53ws-emacs-grep-a-lot-1.0.7
/gnu/store/vhk1ljc45jn465xk3lqx0030qlkp53ws-emacs-grep-a-lot-1.0.7
└── share
    ├── doc
    │   └── emacs-grep-a-lot-1.0.7
    │       └── COPYING
    └── emacs
        └── site-lisp
            └── guix.d
                └── grep-a-lot-1.0.7
                    ├── grep-a-lot-autoloads.el
                    ├── grep-a-lot.el
                    └── grep-a-lot.elc
--8<---------------cut here---------------end--------------->8---

The motivation for the above layout was to make sure the package files
wouldn't clash together.  I'm not sure if this motivation is truly
important, given that all the Emacs symbols are global and must already
be uniquely named to avoid clashes (the common thing to do is to use a
prefix named after the package for every procedure/variables defined);
I'd expect the same rigor to be employed when naming the package files.

So, there's a couple things we could do to make the life of users
better:

1) Deprecate the use of guix.d and adapt the emacs-build-system so that
it stops producing it.
2) Contribute a patch to Emacs so that the directories present in the
EMACSLOADPATH would be searched recursively for packages.
3) Do nothing and expect the users to use the
'guix-set-emacs-environment' (from emacs-guix) to source their user
profile so that EMACSLOADPATH is refreshed, then issue
'guix-emacs-autoload-packages' (from the site-start.el shipped with our
Emacs package).

The third option seems like too complicated and bothersome to be worth
explaining to newcomers, so I'd personally go for either 1 or 2.

What do you think?

Maxim

bug#38273: emacs doesn't open files

[zimoun]

Hi Maxim,

Thank you for all the details.


On Fri, 22 Nov 2019 at 04:46, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> There's no need to be sorry; that's a pitfall many are likely to
> encounter sooner or later.  I'm thinking one common place it'd bite
> users would be when they use their desktop manager's application
> launcher to start Emacs:  in this case, the EMACSLOADPATH would be taken
> from what it was at the time they logged in their session, and would
> never be refreshed until the next login.

I do not know if it is related, but the initial report of this bug
seems similar to this bug report [1].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38309


> --8<---------------cut here---------------start------------->8---
> tree /gnu/store/vhk1ljc45jn465xk3lqx0030qlkp53ws-emacs-grep-a-lot-1.0.7
> /gnu/store/vhk1ljc45jn465xk3lqx0030qlkp53ws-emacs-grep-a-lot-1.0.7
> └── share
>     ├── doc
>     │   └── emacs-grep-a-lot-1.0.7
>     │       └── COPYING
>     └── emacs
>         └── site-lisp
>             └── guix.d
>                 └── grep-a-lot-1.0.7
>                     ├── grep-a-lot-autoloads.el
>                     ├── grep-a-lot.el
>                     └── grep-a-lot.elc
> --8<---------------cut here---------------end--------------->8---
>
> The motivation for the above layout was to make sure the package files
> wouldn't clash together.  I'm not sure if this motivation is truly
> important, given that all the Emacs symbols are global and must already
> be uniquely named to avoid clashes (the common thing to do is to use a
> prefix named after the package for every procedure/variables defined);
> I'd expect the same rigor to be employed when naming the package files.
>
> So, there's a couple things we could do to make the life of users
> better:
>
> 1) Deprecate the use of guix.d and adapt the emacs-build-system so that
> it stops producing it.

It seems the easiest, isn't it? I have a poor understanding of the
details by it seems to simplify how it works.

Maybe, asking on guix-devel to have the inputs of Pierre and/or Alex
should be helpful.


> 2) Contribute a patch to Emacs so that the directories present in the
> EMACSLOADPATH would be searched recursively for packages.

Following time to time the list emacs-devel, I do not how hard it
would be to convince for this kind of change. :-)


> 3) Do nothing and expect the users to use the
> 'guix-set-emacs-environment' (from emacs-guix) to source their user
> profile so that EMACSLOADPATH is refreshed, then issue
> 'guix-emacs-autoload-packages' (from the site-start.el shipped with our
> Emacs package).
>
> The third option seems like too complicated and bothersome to be worth
> explaining to newcomers, so I'd personally go for either 1 or 2.

Even if I am a fan of emacs-guix, I am not sure that this presumption
would be true. I mean that I agree with your comment.


Thank you for all your insights in the Emacs land.

All the best,
simon