Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Test Alternative initialize scheme

1 view
Skip to first unread message

Tim Johnson

unread,
Apr 4, 2018, 7:12:24 PM4/4/18
to Emacs
On emacs GNU Emacs 25.3.2, ubuntu 16.04
---------------------------------------

I use an .emacs.d directory with init.el. I'm contemplating making a
permanent move for this directory so that I can try out alternative
configurations such as spacemacs. It might also reduce clutter at
the top-level of /home/$USER/ I can't tell from reading the
instructions for setting spacemacs that it would be as easy to put
the spacemacs configuration in a different location.

I have the following ~/.em_init.el as a bootstrapper
;; code follows
(setq user-emacs-directory "~/.emacs.d")
(load (concat user-emacs-directory "/" "init.el"))
;; code ends
and I then start emacs with the following bash script named my_emacs

#!/bin/bash
emacs -Q --load ~/.em_init.el

If this is deemed to be a workable solution, then I would then move
.emacs.d to ~/prj/emacs.d (as an example) and change the the path
for user-emacs-directory accordingly. Of course since I have added
to the clutter with .em_init.el at the top /home/$USER, that
bootstrapper could then also be moved.

(A review of my elisp code indicates that it would be a minimal
effort to edit some hard-coded load paths, so portability is not a
big issue.)

Comments? Caveats?
thanks
--
Tim Johnson
http://www.akwebsoft.com, http://www.tj49.com

Emanuel Berg

unread,
Apr 4, 2018, 8:34:17 PM4/4/18
to
Tim Johnson wrote:

> I use an .emacs.d directory with init.el.
> I'm contemplating making a permanent move for
> this directory so that I can try out
> alternative configurations such as spacemacs.
> It might also reduce clutter at the top-level
> of /home/$USER/ I can't tell from reading the
> instructions for setting spacemacs that it
> would be as easy to put the spacemacs
> configuration in a different location.
>
> [...]
>
> Comments? Caveats? thanks

Yes, it is almost always a bad idea to move
something that already is in its right place.
This applies to the computer as well as the
physical world. If you've always had a handsaw
on a hook on a wall, don't put it anywhere else
just because you now have a chainsaw! Instead,
find yet another "right place", only this time
for - you guessed it - the chainsaw.

To have "top-level clutter" in your home dir is
nothing to be ashamed or bothered about. It the
right place for init files of all kinds.
You can configure ls in different ways to
show/not show them, tho. And here we stumble
upon rule number two - the interface. So even
tho one is forbidden to change sound technology
just because it doesn't "look" right, one is
unrestricted to change the interface, or view,
so that you don't want to see, isn't shown.
Interestingly, if one does that long enough,
when one temporarily disables the interface, to
see everything you once didn't want to see, it
doesn't look wrong anymore! It looks right.
But you might still want to switch back to the
interface as that looks even better :)

But OK, you have two versions of Emacs. So have
all config files in your home dir, separated,
for each version. If they read the same init
file, I'd recommend a branch (`if' clause) to
find out what version in particular, version A,
OK `load-file' these files, version B,
`load-file' the other files. I.e., the common
init file will just be a gateway and then
you'll have everything separated.

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

Tim Johnson

unread,
Apr 4, 2018, 8:55:37 PM4/4/18
to help-gn...@gnu.org
* Emanuel Berg <moa...@zoho.com> [180404 16:41]:
> Tim Johnson wrote:
>
> > I use an .emacs.d directory with init.el.
> > I'm contemplating making a permanent move for
> > this directory so that I can try out
> > alternative configurations such as spacemacs.
> > It might also reduce clutter at the top-level
> > of /home/$USER/ I can't tell from reading the
> > instructions for setting spacemacs that it
> > would be as easy to put the spacemacs
> > configuration in a different location.
> >
> > [...]
> >
> > Comments? Caveats? thanks
>
> Yes, it is almost always a bad idea to move
> something that already is in its right place.
> This applies to the computer as well as the
> physical world. If you've always had a handsaw
> on a hook on a wall, don't put it anywhere else
> just because you now have a chainsaw! Instead,
> find yet another "right place", only this time
> for - you guessed it - the chainsaw.

I think you're right ... there's a lot of hard coded paths showing
up in .elc and .pyc files under my .emacs.d
Emanuel, do you mind providing a simple example of such a logical
branch?

I'm not sure how one might combine spacemacs and emacs resources
under one directory. The spacemacs install directions call for
installing spacemacs directly into .emacs.d and I'm presuming that
will totally clobber my existing config.

I guess in the meantime I will find out.

Emanuel Berg

unread,
Apr 4, 2018, 9:09:30 PM4/4/18
to
Some more ranting on this... Now: It is very
useful to have your eyes and brain have the
same intuition when it comes to what works,
what makes sense, and what doesn't.

Sometimes this isn't so! That can be a problem.
And at the other end, it is great to just be
able to look at for example a wood shed, 1s,
and then think/know that will not be
disintegrated next storm. The same
with computers!

If one has a "mismatch", for example with the
dot files in one's home dir, when one sees them
and think, incorrectly, "yuk!", I suppose one
must just stop the instinct to remove them or
put them somewhere else and instead think,
verbalize internally "are they in their right
place?" and each time the answer "well, er,
yes!" will come a little faster, until finally
eyes-brain-intuition are all sync'd to the
point when one sees an .emacs in /var/cache or
one's pal's shabby wood shed and immediately
one understands here someone has screwed up and
is in for trouble :)

Emanuel Berg

unread,
Apr 4, 2018, 9:15:19 PM4/4/18
to
Tim Johnson wrote:

> I'm not sure how one might combine spacemacs
> and emacs resources under one directory.
> The spacemacs install directions call for
> installing spacemacs directly into .emacs.d
> and I'm presuming that will totally clobber
> my existing config.

That shouldn't happen. How did you install
Emacs/spacemacs? Do you use a package manager?
I'm on Raspbian which is Debian for the R-Pi,
one can say, and I don't get any hits for
"spacemacs". However that isn't an excuse for
the developers to mess up a typical Emacs
init/config dir because they now where it is,
for sure. Does that really happen?

Emanuel Berg

unread,
Apr 4, 2018, 9:28:54 PM4/4/18
to
Tim Johnson wrote:

> I'm not sure how one might combine spacemacs
> and emacs resources under one directory.
> The spacemacs install directions call for
> installing spacemacs directly into .emacs.d
> and I'm presuming that will totally clobber
> my existing config.

OK, sorry, now I understand the problem!
If this is what you mean by "clutter" it is
very poor engineering indeed! Unbelievable -
you should mail the developers and tell them!

*Yes* you should definitely change it!

I'd do it like this: Do a grep for any
reference to .emacs.d in the spacemacs source
and instalation scripts, Makefiles etc. If it
is a variable somewhere, change it, to
.spacemacs.d - and if it isn't, change
every occurence.

Then you might need to tell spacemacs to look
there, as well.

Tim Johnson

unread,
Apr 5, 2018, 11:16:10 AM4/5/18
to help-gn...@gnu.org
* Emanuel Berg <moa...@zoho.com> [180404 17:30]:
> Tim Johnson wrote:
>
> > I'm not sure how one might combine spacemacs
> > and emacs resources under one directory.
> > The spacemacs install directions call for
> > installing spacemacs directly into .emacs.d
> > and I'm presuming that will totally clobber
> > my existing config.
>
> OK, sorry, now I understand the problem!
> If this is what you mean by "clutter" it is
> very poor engineering indeed! Unbelievable -
> you should mail the developers and tell them!
>
> *Yes* you should definitely change it!

You and I are likely on similar latitudes but different
longitudes - i.e. while you were thinking I was sleeping :).

Given that I have backed up my emacs.d - I will have my coffee,
then follow the spacemacs installs instructions to the letter and
see what happens. I will then report back.

> I'd do it like this: Do a grep for any
> reference to .emacs.d in the spacemacs source
> and instalation scripts, Makefiles etc. If it
> is a variable somewhere, change it, to
> .spacemacs.d - and if it isn't, change
> every occurence.
>
> Then you might need to tell spacemacs to look
> there, as well.
Understood. Good tactic. Great minds run in the same gutter.
More l8tr

Nikolay Kudryavtsev

unread,
Apr 5, 2018, 5:43:47 PM4/5/18
to Emacs
There's a script called emacs-distribution on EmacsWiki:

https://www.emacswiki.org/emacs/emacs-distribution

It achieves the same thing you're trying to do, but using a different
method - it presets HOME env variable.

Advantage over your setup - configs get ran normally, so even Customize,
which gets disabled by -q would work.

Disadvantage - you can't refer to subfolders in your ~ from inside of
Emacs, I usually symlink the ones I need.

--
Best Regards,
Nikolay Kudryavtsev


Tim Johnson

unread,
Apr 5, 2018, 5:47:03 PM4/5/18
to help-gn...@gnu.org
* Emanuel Berg <moa...@zoho.com> [180404 17:30]:
> Tim Johnson wrote:
>
> > I'm not sure how one might combine spacemacs
> > and emacs resources under one directory.
> > The spacemacs install directions call for
> > installing spacemacs directly into .emacs.d
> > and I'm presuming that will totally clobber
> > my existing config.
>
> OK, sorry, now I understand the problem!
> If this is what you mean by "clutter" it is
> very poor engineering indeed! Unbelievable -
> you should mail the developers and tell them!
>
> *Yes* you should definitely change it!
>
> I'd do it like this: Do a grep for any
> reference to .emacs.d in the spacemacs source
> and instalation scripts, Makefiles etc. If it
> is a variable somewhere, change it, to
> .spacemacs.d - and if it isn't, change
> every occurence.

I could do that and see what happens, probably will.
However, the preferred installation sidesteps that process.

I installed spacemacs with the following preferred command:

git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d

git will not overwrite .emacs.d, so I had to rename it (was
already backed up elsewhere).

Spacemacs seems to be put together quite professionally.

I believe that I could merge the the new .emacs.d and my current
one without anything getting clobbered except for init.el. So the
option of a custom init file is doable.

It is probably best to just investigate further and submit
questions to the spacemacs IRC before I do any merging. I couple
of simple scripts should handle that.

I'm an eternal noob on emacs and even more rusty since I retired
my coding business *but*, I think that spacemacs could have put
this together with transitions from older, established emacsen in
mind.

Their installation instructions seem to procede from only one
scenario:

Newbie doesn't have emacs, noobie installs emacs and spacemacs on
top of that fresh install and it's good to go. Not so easy for
someone like me who has a collection of legacy resources.

Thanks for the help, Emanuel. If you like, in a few days, I can
post an update, this time with spacemacs in the subject.

cheers

> Then you might need to tell spacemacs to look
> there, as well.
>
> --
> underground experts united
> http://user.it.uu.se/~embe8573

Tim Johnson

unread,
Apr 5, 2018, 5:57:16 PM4/5/18
to help-gn...@gnu.org
* Nikolay Kudryavtsev <nikolay.k...@gmail.com> [180405 13:50]:
Thank you. That is one of the sites that I reviewed before
opening this topi.
cheers

Emanuel Berg

unread,
Apr 6, 2018, 2:57:14 PM4/6/18
to
Tim Johnson wrote:

> Thanks for the help, Emanuel. If you like, in
> a few days, I can post an update, this time
> with spacemacs in the subject.

Well, I don't think I did anything substantial
in this affair, but in general followups are
while not compulsory always appreciated: they
are good when people Google the same problem,
and they are good for everyone's karma :)

Emanuel Berg

unread,
Apr 6, 2018, 3:06:21 PM4/6/18
to
Nikolay Kudryavtsev wrote:

> There's a script called emacs-distribution on EmacsWiki
>
> https://www.emacswiki.org/emacs/emacs-distribution
>
> It achieves the same thing you're trying to do,
> but using a different method - it presets HOME
> env variable.

Clever!

BTW what is the reason for the different
Emacs distributions?

And why are they so few in numbers compared to
the distributions of Linux for example?
Which are so many, and the vast majority isn't
even "Linux distributions" - because what is
being forked isn't Linux, the kernel, but
rather the distribution itself! So they are
distributions of a distribution!

Is it because the "Joe-Hacker creativity" with
Emacs goes into Elisp, which can float on top
of everyone's Emacs, instead of combining the
window manager with another desktop manager (and
new background color) in yet
another permutation?

But couldn't people do that, the Elisp way, on
Linux as well, only even more so, because there
any conceivable programming language and
environment can float wherever it wants?
And isn't that what's is happening by the way?

So what is really going on?!

Nikolay Kudryavtsev

unread,
Apr 6, 2018, 5:15:41 PM4/6/18
to help-gn...@gnu.org
Emacs distributions aka as kits are quite numerous. There's Spacemacs,
which is the elephant in the room, then there's prelude and quite a few
others. It's not much different from Linux distributions.

The reason for their existence is that building a working config with
bells and whistles may take quite a lot of time and effort, depending on
required applications. And at some point there would be workflow
disagreements. The two major areas are keyboard bindings(vanilla, vim,
ergoemacs) and minibuffer completion(ivy, icicles, helm). Then there's
package management, I think there's almost as many package managers for
Emacs now, as there are for Unix. Init.el organization is another hotly
contested area, with different ideas like storing it in org-mode and
tangling.

Emanuel Berg

unread,
Apr 6, 2018, 5:55:26 PM4/6/18
to
OK, thanks for the info, but put it this way,
what is the one key problem that all of this is
trying to solve?

Are there groups of people who like similar
keyboard styles and instead of everyone setting
it up his/her way, which is similar to the next
guy/girl, one does this once and for all in
a "distribution" and then they all use that
particular distro?

Well, great, but how come this isn't just an .el
file like any other and you just load it from
your init file?

Because if so, aren't the 100+ Elisp files
I have a distribution as well? A distribution
of one?

Because if so (again), then yes, there should
be almost as many "distributions" as there are
Elisp hackers!

So in a way, yes, but this definition is
clearly not usable, really. So what is the
definition of an Emacs distro?

Eli Zaretskii

unread,
Apr 7, 2018, 2:41:10 AM4/7/18
to help-gn...@gnu.org
> From: Nikolay Kudryavtsev <nikolay.k...@gmail.com>
> Date: Sat, 7 Apr 2018 00:15:31 +0300
>
> The reason for their existence is that building a working config with
> bells and whistles may take quite a lot of time and effort, depending on
> required applications. And at some point there would be workflow
> disagreements. The two major areas are keyboard bindings(vanilla, vim,
> ergoemacs) and minibuffer completion(ivy, icicles, helm). Then there's
> package management, I think there's almost as many package managers for
> Emacs now, as there are for Unix. Init.el organization is another hotly
> contested area, with different ideas like storing it in org-mode and
> tangling.

>From my POV, the only issue with these "distributions" is that
whatever problems they try to solve, they don't seem to communicate
them back to the upstream project development, and don't try to
contribute their solutions to upstream. They are completely separate
"cultures", which IMO is a pity, since I think quite a few of the
problems they bump into are unbeknownst to the project, and thus might
not be solved correctly, or maybe just worked around instead of
solving. And if they do solve some problems, the rest of Emacs users
cannot benefit from those solutions.

The relationship between these distributions and upstream Emacs
development should IMO be a two-side street. I don't feel that is
currently the situation.

Nikolay Kudryavtsev

unread,
Apr 7, 2018, 8:20:53 AM4/7/18
to Emanuel Berg, help-gn...@gnu.org
The key problem is providing a preconfigured environment.

Often you need one configuration for package X to work well with package
Y and another for X to work well with package Z. Distributions provide a
sets of package configurations designed to work well together.

Your init becomes a distribution(aka kit) when you make it generic for
general use and publish it.

Nikolay Kudryavtsev

unread,
Apr 7, 2018, 8:39:00 AM4/7/18
to Eli Zaretskii, help-gn...@gnu.org
While I agree about the lack of upstream communication, I don't see the
situation changing any time soon, nor them dying. One reason is
(understandably) slow pace of upstream development, and for kit devs
it's often much easier to provide a patch downstream, since upstream fix
may not be coming until one or more major versions.

Spacemacs seems to have "should report upstream" tag on their bug tracker:

https://github.com/syl20bnr/spacemacs/labels/Should%20report%20upstream

But they do not seem to separate package upstreams, from the main Emacs
upstream.

Eli Zaretskii

unread,
Apr 7, 2018, 8:54:03 AM4/7/18
to help-gn...@gnu.org
> From: Nikolay Kudryavtsev <nikolay.k...@gmail.com>
> Date: Sat, 7 Apr 2018 15:38:51 +0300
>
> While I agree about the lack of upstream communication, I don't see the
> situation changing any time soon, nor them dying. One reason is
> (understandably) slow pace of upstream development

Upstream development is not slow: just look at the number of commits
per months or even per week. Many bugs get fixed within days if not
hours of them being reported.

What is slow is the rate of releasing official versions. Whether that
matters to many users, I don't know, what with quite a few following
the development branch.

> for kit devs it's often much easier to provide a patch downstream,
> since upstream fix may not be coming until one or more major
> versions.

I see no contradiction here: one could do both.

The advantage of talking to the development team, apart of fixing the
problems in future releases, is that the workarounds will be of higher
quality and will run smaller risk of introducing new bugs because the
person who proposed a workaround missed some aspects of the problem or
didn't understand well enough the true nature of the issue.

It's a win-win situation, and the effort of reporting an issue
upstream is not that significant.

Tim Johnson

unread,
Apr 7, 2018, 8:56:03 PM4/7/18
to help-gn...@gnu.org
* Tim Johnson <t...@akwebsoft.com> [180405 14:02]:
> * Nikolay Kudryavtsev <nikolay.k...@gmail.com> [180405 13:50]:
> > There's a script called emacs-distribution on EmacsWiki:
> >
> > https://www.emacswiki.org/emacs/emacs-distribution
> >
> > It achieves the same thing you're trying to do, but using a different method
> > - it presets HOME env variable.
> >
> > Advantage over your setup - configs get ran normally, so even Customize,
> > which gets disabled by -q would work.
> >
> > Disadvantage - you can't refer to subfolders in your ~ from inside of Emacs,
> > I usually symlink the ones I need.
> >
> Thank you. That is one of the sites that I reviewed before
> opening this topic.

So my usage of emacs is pretty limited, since I am "resting on my
laurels", "enjoying a golden sunset", etc.

Thus I discarded the goal of running more than one "kit" at a time
and just set up two launch scripts, one which symlinks my
"standard" .emacs.d (now located elsewhere) to ~/.emacs.d, and the
other symlinks .spacemacs.d to ~/.emacs.d.

It seems to be a workable solution and switching them is very fast on
my machine. For decades I've used both terminal vim (system work via MC)
and Gui-Emacs for coding.

Spacemacs should turn out be a reasonable marriage of two
paradigms - and as my wife would tell me, a reasonable marriage
beats one made in heaven (if indeed any marriages really are).

Seriously, spacemacs seems to be a nice piece of work. Kudos to
the developers.

Emanuel Berg

unread,
Apr 7, 2018, 9:43:45 PM4/7/18
to help-gn...@gnu.org
Nikolay Kudryavtsev wrote:

> The key problem is providing
> a preconfigured environment.

But how is this any less complicated than
configuring the software yourself? Which is
a basic skill anyone would like to have,
including Spacemacs and other "kit" users?

Why is it better to install a new binary when
this accomplish the equivalence of using the
old binary to load a couple of .el files?

> Often you need one configuration for package
> X to work well with package Y and another for
> X to work well with package Z.
> Distributions provide a sets of package
> configurations designed to work
> well together.

The way you put it I agree but in practice
there are an insane amount of Linux
distribution, many of which are just endless
Debian forks, and forks of forks, and I don't
think they all are intented to solve dependency
issues. Perhaps that was the reason of the few
distribution progenitors but not anymore or in
the majority of cases at least.

Besides instead of putting all this effort into
distros as a way of solving dependencies issues,
if that really is the reason, why not put the
same effort into making the software lay onto
each other in a straightforward way bottom-up?
Instead of providing a new distro so there can
be a new desktop on top of X, why not provide an
option: what desktop, if any, would you like?

It is just distributions for the sake of it
which I don't consider very productive, tho in
principle this diversity is a strength and in
the long run the best model to do anything and
everything, no doubt.

The only distributions I consider very helpful
at the moment are the adaptations of old and
trusted Debian to exotic software. Raspbian for
the R-Pi (perhaps not that exotic anymore),
ev3dev for the Mindstorms - which is real
Debian by the way, tho some people, perhaps
rightfully so, consider Raspbian real Debian
as well.

PS. I'm not making any comments on Spacemacs in
particular because I didn't use it, except
my instinct tells me, if it is a separate
program, it should have a separate
config dir.

> Your init becomes a distribution(aka kit)
> when you make it generic for general use and
> publish it.

It's a kit alright because I have it on my
home page with a Makefile and all :) I'll even
consider putting it on my resume -
Emanuel Berg, Emacs kit developer :)

Nikolay Kudryavtsev

unread,
Apr 8, 2018, 8:31:15 AM4/8/18
to help-gn...@gnu.org
Most of those kits are .el file based, usually they provide a preset
~/.emacs.d. Actually since having multiple configurations like this is
somewhat common, maybe someone should open a feature request to
implement it as a flag out of box, something like
--with-user-emacs-directory...

It's less complicated for the end user, especially the new user, because
successfully configuring Emacs for different advanced applications
involves making dozens of decisions. Most of those decisions require
some knowledge and testing. And you may still wound up with something
controversial. This is even harder for a new user when there's already a
learning curve.

> why not put the
> same effort into making the software lay onto
> each other in a straightforward way bottom-up?
Because this requires each package developer to be aware of pretty much
every package that may be used simultaneously with yours. I'm explicitly
talking about Emacs here, since it's less of a problem in Unix world.
The way to help with it upstream is providing protocols for package devs
to use, the new xref is one such thing.

Emanuel Berg

unread,
Apr 8, 2018, 10:48:45 AM4/8/18
to
Nikolay Kudryavtsev wrote:

> Most of those kits are .el file based,
> usually they provide a preset ~/.emacs.d.
> Actually since having multiple configurations
> like this is somewhat common, maybe someone
> should open a feature request to implement it
> as a flag out of box, something like
> --with-user-emacs-directory...

Good idea, if now things are like this
anyway...

> It's less complicated for the end user,
> especially the new user, because successfully
> configuring Emacs for different advanced
> applications involves making dozens of
> decisions. Most of those decisions require
> some knowledge and testing. And you may still
> wound up with something controversial.
> This is even harder for a new user when
> there's already a learning curve.

It is much better if the developers put their
energy and creativity in truly advancing the
scope of the technology, rather than to putting
it together in new ways, just because the user
is supposedly too incompetent to install their
stuff on the base platform!

1) it is a waste of creative energy

2) the user isn't that stupid

3) and if the user IS, s/he is much more
benefited from leaving that state ASAP,
rather than a tailor-made product, and
it isn't a huge cognitive leap if anyone
thought that

4) and besides using that distro/kit will
imply other issues - and how to solve
those? yet another distro/kit - return
to base and start over? etc. etc.

>> why not put the same effort into making the
>> software lay onto each other in
>> a straightforward way bottom-up?
>
> Because this requires each package developer
> to be aware of pretty much every package that
> may be used simultaneously with yours.
> I'm explicitly talking about Emacs here

First, does it really require a huge stack of
packages just to change *the keyboard layup*?

Second, if it does, why is this a problem?
We can go right now to M/ELPA and see that the
pack "academic-phrases", whatever that is
("Bypass that mental block when writing
your papers." :D ???), we learn that it
requires

dash-2.12.0, s-1.12.0, ht-2.0, emacs-24

and then we can learn that "dash" (not the
shell by the way but "[a] modern list library
for Emacs"), that dash doesn't require anything
and certainly not academic-phrases, so there is
no circular or interdependency situation.
Just do it!

So this is obviously not the problem, so can
you describe it again or provide an example?

> The way to help with it upstream is providing
> protocols for package devs to use, the new
> xref is one such thing.

OK, I don't know xref (do tell!) but in
principle that's infinitely much better than
burning down the house to kill the rats -
each time.

Nikolay Kudryavtsev

unread,
Apr 9, 2018, 1:42:25 PM4/9/18
to Emanuel Berg, help-gn...@gnu.org
> So this is obviously not the problem, so can
> you describe it again or provide an example?
I was not talking about the relationship dependence, but of coexistence.
For example there's Evil, which is a package that provides Vi keyboard
layout. It works fine by itself. Then there's Ivy which is a minibuffer
completion interface. Ivy by default uses vanilla Emacs key bindings.
Spacemacs provides some improvement in its layer that allows using Ivy
with Evil. Now the question is - who's area of responsibility it is to
provide that? Emacs upstream developers? Of course not. Nor should we
expect developers of Evil to care about providing configuration for Ivy,
or Ivy developers providing configuration for Evil. So there's a space
for a third party(the first being Emacs developers and the second -
package developers). The problem is how to enable those third party
contributions, while taking some measures to inhibit unnecessary
fragmentation. And I think it is to be expected that good solutions to
this end may not be feasible.

One solution would be providing a repository for such configurations
snippets and infrastructure for pulling them. And then the main dev team
can ideally mark some of them obsolete or let's say broken. This of
course is a mammoth task. Actually not so long ago somebody released a
basic implementation of such system:

https://github.com/dustinlacewell/emacs-nougat

I haven't tried it myself yet, and personally I'm not a fan of org-based
configs, but I have to admit that it's trying to solve the problem we're
currently discussing.

Emanuel Berg

unread,
Apr 9, 2018, 2:56:49 PM4/9/18
to
Nikolay Kudryavtsev wrote:

>> So this is obviously not the problem, so can
>> you describe it again or provide an example?
>>
> I was not talking about the relationship
> dependence, but of coexistence. For example
> there's Evil, which is a package that
> provides Vi keyboard layout. It works fine by
> itself. Then there's Ivy which is
> a minibuffer completion interface. Ivy by
> default uses vanilla Emacs key bindings.
> [...] Now the question is - who's area of
> responsibility it is to provide that?

I wouldn't use the word "responsibility" as
that sounds negative, like a burden, but let's
put it this way, it is in the Ivy people's
interest to have their software work with any
keyboard layout simply because then more people
can use it!

If it (Ivy) is really that hard coded so people
can't use their own keys this in itself is
a problem so Ivy will benefit to have the
functionality in neat functions and then people
can use whatever keys they want - I mean, they
(Ivy) will benefit from this regardless of
anyone actually using Vim keys or anything but
the vanilla layout.

So if the question isn't "who should do it?"
but "where should it be done?", and the
alternatives are


1. Evil
X. Ivy
2. Spacemacs (or another fork)


The answer is (I put it in my signature, and
you'll have to flip your monitor upside down to
read it)

--
X

Nikolay Kudryavtsev

unread,
Apr 9, 2018, 6:24:50 PM4/9/18
to Emanuel Berg, help-gn...@gnu.org
You're missing the point. Ivy is not hard-coded in any way. It's just
that its default settings are set up for vanilla Emacs keybindings. E.
g. previous-candidate in Ivy is "C-p". But if we're using Evil we want
"k" to be that key(while respecting the mode). With ergoemacs-mode we
would expect "M-i". I don't think that we should expect any package
developer to provide defaults for all available keyboard layout packages.

To continue the whole "things that would help, but are unlikely to be
implemented" thing, I think Emacs would have benefited from ability to
remap keybindings in a similar fashion to commands. So in the previous
example I could do something like (remap "C-p" "M-i") and then in Ivy
(define-key keymap "C-p" 'previous) would automatically do (define-key
keymap "M-i" 'previous) instead. This would have made layout
customization much more pleasant.

Emanuel Berg

unread,
Apr 9, 2018, 6:44:43 PM4/9/18
to
Nikolay Kudryavtsev wrote:

> Ivy is not hard-coded in any way. It's just
> that its default settings are set up for
> vanilla Emacs keybindings. E. g.
> previous-candidate in Ivy is "C-p". But if
> we're using Evil we want "k" to be that
> key(while respecting the mode).
> With ergoemacs-mode we would expect "M-i".
> I don't think that we should expect any
> package developer to provide defaults for all
> available keyboard layout packages.

The people we expect this from is the people
who want it. If there isn't anything fishy to
setting up the keyboard for Ivy, all that is
needed is a single .el file that go thru the
whole thing, which is loaded on Emacs init.
Certainly not a fork of the whole project!

Observe:

if (init(Ivy) && init(my_Ivy_keys) {
return 0;
}
else {
fprintf(stderr, "Oh, no! We have to fork Emacs to do it!\n");

Nikolay Kudryavtsev

unread,
Apr 9, 2018, 7:15:34 PM4/9/18
to Emanuel Berg, help-gn...@gnu.org
Who's claiming that any of those kits we're discussing are forks of the
whole project?

Emanuel Berg

unread,
Apr 9, 2018, 7:41:11 PM4/9/18
to
Nikolay Kudryavtsev wrote:

> Who's claiming that any of those kits we're
> discussing are forks of the whole project?

"Add a bunch of configs/extentions to an
existing piece of software, pretend that this
is anything different from what people do every
day all around the world, give it a fancy name,
all the while inventing lots of problems
associated with it to make it appear cooler?"
0 new messages