Test Alternative initialize scheme

Test Alternative initialize scheme

[Tim Johnson]

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

Re: Test Alternative initialize scheme

[Emanuel Berg]

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

Re: Test Alternative initialize scheme

[Tim Johnson]

* Emanuel Berg <moasen@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


> 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.

  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.
  thanks
-- 
Tim Johnson
http://www.akwebsoft.com, http://www.tj49.com

Re: Test Alternative initialize scheme

[Emanuel Berg]

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 :)

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

Re: Test Alternative initialize scheme

[Emanuel Berg]

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?

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

Re: Test Alternative initialize scheme

[Emanuel Berg]

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.

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

Re: Test Alternative initialize scheme

[Tim Johnson]

* Emanuel Berg <moasen@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

-- 
Tim Johnson
http://www.akwebsoft.com, http://www.tj49.com

Re: Test Alternative initialize scheme

[Nikolay Kudryavtsev]

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

Re: Test Alternative initialize scheme

[Tim Johnson]

* Emanuel Berg <moasen@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
http://www.akwebsoft.com, http://www.tj49.com

Re: Test Alternative initialize scheme

[Tim Johnson]

* Nikolay Kudryavtsev <nikolay.kudryavtsev@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 topi.
  cheers
-- 
Tim Johnson
http://www.akwebsoft.com, http://www.tj49.com

Re: Test Alternative initialize scheme

[Emanuel Berg]

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 :)

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

Re: Test Alternative initialize scheme

[Emanuel Berg]

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?!

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

Re: Test Alternative initialize scheme

[Nikolay Kudryavtsev]

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.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Test Alternative initialize scheme

[Emanuel Berg]

Nikolay Kudryavtsev wrote:

> 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.

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?

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

Re: Test Alternative initialize scheme

[Eli Zaretskii]

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@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.

Re: Test Alternative initialize scheme

[Nikolay Kudryavtsev]

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.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Test Alternative initialize scheme

[Nikolay Kudryavtsev]

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.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Test Alternative initialize scheme

[Eli Zaretskii]

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@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.

Re: Test Alternative initialize scheme

[Emanuel Berg]

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 :)

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

Re: Test Alternative initialize scheme

[Nikolay Kudryavtsev]

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.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Test Alternative initialize scheme

[Emanuel Berg]

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.

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

Re: Test Alternative initialize scheme

[Nikolay Kudryavtsev]

> 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.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Test Alternative initialize scheme

[Emanuel Berg]

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

Re: Test Alternative initialize scheme

[Nikolay Kudryavtsev]

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.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Test Alternative initialize scheme

[Emanuel Berg]

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");
    }

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

Re: Test Alternative initialize scheme

[Nikolay Kudryavtsev]

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

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Test Alternative initialize scheme

[Emanuel Berg]

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?"

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