Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating Helm settings and adding new bindings #71

Closed
wants to merge 61 commits into from

Conversation

punassuming
Copy link
Contributor

Added helm-mode to use-package idle timer to load when idle instead of just defer.

"SPC s" Bindings ("s" prefix signifies showing buffer data)

  • sy = yank / kill ring
  • sm = mark ring
  • sr = registers

"SPC f" Bindings ("f" prefix signifies file activies)

  • fh = helm-find-files

"SPC F1" is helm-apropos

syl20bnr and others added 30 commits October 29, 2014 00:43
Projectile takes time to load (around 0.2 seconds) and it is
lazy loading friendly if we want to enable it globally.

To be able to lazy load it, we encapsulate the binded calls
in spacemacs/xxx functions which take care of firing the
mode globally if required.
instead of at loading time which is useless :-)
Sometimes the spacemacs key bindings for ido-vertical did not work.
I had to explicitly enable projectile-enable-caching and explicitly
start projectile-mode to initialize projectile-projects-cache
Also add ?r projectile-replace to commander
It is now part of the package
This is the command for helm-projectile
guide-key does not play well with golden-ratio.
also set delay to 1 seconds, can be configured in .spacemacs
for shorter delay
Work-around a current bug in evil-nc with 24.4 byte-compilation
syl20bnr and others added 13 commits November 2, 2014 00:03
* Added helm-mode to `use-package` idle timer to speed up opening
* Bindings:
"s" prefix signifies showing buffer data:
 - l = links / tags\
 - y = yank / kill ring
 - m = mark ring
 - r = registers

"f" prefix signifies file activies
 - h = helm-find-files

"F1" default tied to help, so now is `helm-apropos`
:config
(progn
(helm-mode +1)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep it to have it enabled right when it is first used. Otherwise we have to wait withtout doing nothing to enable the mode. Watch for the "Helm completion enabled" in message buffer. It appears only if you let the idle timer activate the mode, using <SPC> b s does not activate it (even though the command works).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found in my testing that running hitting "SPC b s" still loaded the package the first time when using the :idle timer. I didn't have a dependency error by not specifying it in :config.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed <SPC> b s does work but there is no "Helm completion enabled" message in *Messages*. Wait for a few seconds and it will appears. By duplicating (helm-mode +1) in :prog the first <SPC> b s shows the message.

I don't know exactly what this message is for, but there is a difference between the 2 behaviors and I prefere the behaviors to be consistent.

@syl20bnr
Copy link
Owner

syl20bnr commented Nov 3, 2014

@Ralesi Very cool, see my comments above.

@syl20bnr
Copy link
Owner

syl20bnr commented Nov 3, 2014

I like <SPC> F1, for completeness you can add also the binding to the h prefix (for help): <SPC> h a in keybindings.el in the describe functions section (you can rename the section to help functions).

@punassuming
Copy link
Contributor Author

For SPC f h, I thought it would be nice to include helm even with the default being IDO. I for one agree with your preference for ido, but there are times when helm outperforms, especially when wanting to open multiple files or in an alternate window or frame.

I thought about using h as a prefix for help (F1) but it seemed like that was used for helm specific commands as well. I would vote that since helm is one of the pivotal packages in this repo, that we shouldn't prefix something with 'h' just because its a helm command. I think we should separate out mnemonics for what they do rather than the package associated. I think for the most part that they have been separated out; for example x is used for text manipulation, w for window management, and f for file management, but there are certain prefixes that have disparate commands in their domain (c, h, and s come to mind).

I would think all prompts (from helm or other packages) that would show you emacs or buffer related data without actually modifying anything should have the s prefix. This could probably be extended to the bookmark list as well (currently 'hb'). I know 's' is busy with the autohighlight microstate (is this for 'symbol'?)

guide-key has a 2.0 milestone of providing descriptions on each prefix, which would make it even more valuable to break all commands down by utility prefix.

@syl20bnr
Copy link
Owner

syl20bnr commented Nov 4, 2014

I just tried again helm-find-files and it is still not as fast as ido in its default settings. I looked into the configuration for helm-find-files and I didn't find anything to make it behave like fast ido. So it makes sense to have both, I agree with you. Keep it on <SPC> f h or on <SPC> f F.

Agree 100% with h should not refer to helm and the common rule that key bindings must be independent from the underlying system (my proposal about <SPC> f F referes to this).

I like the registers being under r or R though (depending on the frequency). s for show is too wide, a lot of things can potentialy show something like all helm buffers or Neo etc... Morevoer s is pressed with a weaker finger. I would rather reserve s for search or actions which relate to searching text, if symbol and search are on the same prefixe it is ok for me.

I'm not againt having a prefix with several meaning though. For instance ss for search symbol under point and sl for symbol list, so for search occurence etc... This is just quick proposal I did not think about it very hard.

@syl20bnr syl20bnr closed this Nov 4, 2014
@syl20bnr syl20bnr reopened this Nov 4, 2014
@punassuming punassuming mentioned this pull request Nov 4, 2014
@punassuming
Copy link
Contributor Author

I like using 's' for search (even symbols is a search), and r for all the register related data. Would you like me to rebase with current HEAD and update?

@syl20bnr
Copy link
Owner

syl20bnr commented Nov 4, 2014

Yes, but watch out, I messed with the branches and there is a new develop branch. I suggest you to branch again from the current develop head. Sorry for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants