smex default bind to M-x

[cg505]

By default there is no (global-set-key (kbd "M-x") 'smex) except in my local config. Is there a reason for that?

[samontea]

False it's in my config too. See this line

[samontea]

Also while you're there appreciate my comments because they're the best.

[cg505]

Heh, you keybindings file is almost identical to mine. Maybe we should make it default and put @rye's stuff in his personal config (which doesn't exist yet cough cough).

EDITed by @rye, to change username from @krye to @rye

[samontea]

I feel like that may or may not be because he doesn't have time what with moving or what not. Though I do suggest we also remove the unbinding of C-h from the default config considering me and Chris both don't use that.

[rye]

Haha, I should probably get around to dumping a personal config here. What with time and all of that, I haven't done it yet, but I'm considering starting from scratch and re-evaluating exactly what it is that I want in Emacs. I might re-write my personal configuration (for what, like, the 4th time?) and figure out how to do stuff.

Since this was a copy of my previous iteration of my configuration, I've neglected to contribute to this repository since there's a lot of overhead that I've since removed. Lots of configuration stuff that has changed in my personal configuration, and I don't see the reason to keep using my old stuff.

[samontea]

@cg505 and @rye would you both approve of

• smex by default
• c-h enabled by default
• show-paren by default

Because I feel like those are changes we all can agree to.

[samontea]

@cg505 ???? Approve/Disapprove? Talk to me bruh.

[rye]

show-paren yes, smex yes, and C-h no. Besides C-h {f,v}, C-h is a terrible keybind. I have bound it to C-x h.

Addendum: C-h is also a very good homerow bind. Most decent quality Emacs installs have bound the same as C-h, so you can use either one. I always just unset C-h and use it either for my tmux control sequence or whatever.

[samontea]

@rye reasonable enough. I was really waiting on @cg505 to approve because you know we're the only two people who use this...

Hopefully he'll get to this soon...

[cg505]

I just don't have time to engage but probably. Also @rye are you using this?

[Sammidysam]

I thought @rye mentioned that he was not using it.

[rye]

I'm not using this yet, but that doesn't mean that feedback isn't a bad thing, especially if an issue has been stale for 2+ months.

Once I have free time, I may jump in and contribute some things to this config, perhaps bringing it to a point where I thoroughly enjoy using it. At that point, I might switch to using this. I just haven't seen much movement on this project, and it doesn't seem to have much momentum. My personal .emacs.d gets at least 8 private commits a day, usually getting squashed bimonthly before getting pushed to GitHub, and while I realize that this group effort is a group effort, I enjoy using a faster-moving config.

[samontea]

So the conclusion is that I made the smex change and the c-h change, but not the paren mode change because I'm the only person who uses that.

@rye I feel like if you were contributing it would be a faster moving project, but what do I know. I'm probably going to rage rewrite it in the summer because a lot of things don't make sense, but I don't have time for that now. Anyway I hope we can get this thing working and @Sammidysam can add his config in here because it's a cool project.

[Sammidysam]

Why does a faster moving config matter? More configuration means slower Emacs.

On Dec 9, 2014, at 12:43 AM, Samuel Mercier notifications@github.com wrote:

Closed #4.

— Reply to this email directly or view it on GitHub.

[rye]

I'm talking about a faster-moving project. I don't enjoy doing everything by myself, hence my continued frustration with nearly every group project I've ever done that has undergone an eventual petering-out of developer momentum.

And @Sammidysam, generally my ranges of changes from the 20-something branches that I'm concurrently juggling that actually make it into the public codebase are so tiny it doesn't matter. I'm talking about exploration and decision-making. Sometimes I squash 64 commits down to 1 and it's only a few lines' change, because I commit and revert, commit and revert, merge and revert, commit and revert, and the few lines that make it are what I really think are the best. The important thing is that I'm finding stuff I like and stuff I don't like.

[Sammidysam]

If it's in a good state, though, why does it matter if it is constantly getting committed to? That's what I don't understand very well. Like FReCon is fine to not have many commits because it is in a good state. WeBCa no, FReCon yes.

On Dec 9, 2014, at 8:39 AM, Kristofer Rye notifications@github.com wrote:

I'm talking about a faster-moving project. I don't enjoy doing everything by myself, hence my continued frustration with nearly every group project I've ever done that has undergone an eventual petering-out of developer momentum.

And @Sammidysam, generally my ranges of changes from the 20-something branches that I'm concurrently juggling that actually make it into the public codebase are so tiny it doesn't matter. I'm talking about exploration and decision-making. Sometimes I squash 64 commits down to 1 and it's only a few lines' change, because I commit and revert, commit and revert, merge and revert, commit and revert, and the few lines that make it are what I really think are the best. The important thing is

— Reply to this email directly or view it on GitHub.

[rye]

FReCon is still unfinished. There's a large amount of documentation to be done, and perhaps a test suite to write. However, I do understand your point. While it's functional, I'd still say that weekly (or biweekly) updates would be a good thing, if not only to update dependencies and any backend code that needs tweaking.

WeBCa is still just barely functional (I count design as part of functionality, shoot me), which means that there's a lot of work to be done on it, and all of it in the next 20 days. That project really needs to be moving right now.

kotct.emacs is unfinished. However, this is a different category of project. We're writing a configuration, which is not software per se. Creatively, there's needs to be motion. I don't think it's very effective to establish a configuration that "works" and is in a "good state," and then not touch it for five months, because new ideas leveraging new technology and new design concepts are not explored. Even if the motion of this project at the end of a week is minimal (due to the commit-revert pattern I described), it's still motion. I appreciate @samontea's latest commit(s) to this project. As I've said,

"Even a modicum of momentum is still infinitely more momentum than no momentum." — Me, yesterday on Twitter

Perhaps we can get things rolling again? I'm up for that. I'd love to rewrite this in my new configuration's style, but in a more modular and tweakable way.

[cg505]

Part of the problem is that it's impossible to jump onto the rolling ball that is your configuration. I tried to do that with this project, essentially pulling your latest config in and then adding on to that, but I believe your emacs configuration changes the most and was long departed by the time you noticed that this existed. So I think what needs to happen is you should copy your config into this repo and start using it, and we can develop on top of your changing config. Essentially, a complete, exact copy of your config would be a good starting point for this repository IMO.

[rye]

Does that mean that you are suggesting completely obliterating everything and dumping my current configuration into here? I'd suggest changing the repository title in that case, but if we did that I'd definitely be using this one (collaboration is enticing), and then I'd remove my own and work on this configuration as my primary. Then, this configuration can roll. I'm just worried that my preferences will not be congruent with those of others. We can work out a user config directory.

[cg505]

Yes. I can copy in the user config stuff once you've done that. And obviously don't obliterate this, but rename it with -old or something.

[rye]

Yeah, I'll rename it to -old and then make a .emacs.d repository, dumping my stuff in there.

[rye]

Okay, I am doing this now. This won't break existing urls, but you should change them.