lispy core #74
Comments
Those packages need to be included because there are no core packages to fall back on. Lispy used to depend on
Same thing with |
|
I think the core should be about manipulating sexp/parens without external dependencies. Other fancy stuffs, if a user uses one, should print a message that it requires a dependency. It's better that way instead of installing several packages at once. |
I disagree, it's all about the fancy stuff for me:
|
|
So, how about making |
I'd gladly do it if package.el had that capability. But it doesn't, so I don't. |
|
Ok, but originally I suggested that if a user uses a fancy feature and the required dependency is not available, |
Jumping to tags and occur aren't fancy features, they are core features. CIDER, SLIME and Geiser are fancy. Lispy cooperates with them without installing them. What you're suggesting should be solved on the level of package.el and not lispy.el and any other package. Something like: Here, Maybe @Malabarba could comment if these style of dependencies are possible or useful. |
|
I think they're both possible and useful. The only problem right now is that (if this were to be implemented) a package which specifies dependencies like this would not be compatible with the current package.el version, so user of Emacs < 25 wouldn't be able to install the package. In order to avoid that, and to allow packages to work on all package.el versions, the syntax for specifying these special dependencies would have to be designed in a very clever way. |
|
And if I may add to the actual discussion: I think the disagreement comes from the fact that I'm not saying all these lispy features are just "fancy stuff" (in fact, I feel these features create a cohesive development environment and I like when things just-work). As for @tuhdo's requests, you could then refactor the manipulation of sexps/parens into a separate package, and use that as a dependency for |
Exactly. I prefer adding features to just shuffling code about. I start shuffling only if the code become overwhelming, which it isn't at the moment. |
Probably. I don't want look arrogant by using the term IDE: lispy doesn't compare to SLIME. Maybe "vi-like LISP Toolkit". |
|
What @Malabarba suggested is reasonable: you can make a new Lispy minimal package with no external dependencies. Then, when a user incrementally learns Lispy, he may encounter a feature that requires an external package. In this case, Lispy prints a message suggesting him to install the dependency to use this feature. I think making a package out of existing package should be easy for you. |
This never works. I joined Emacs before package.el, and I hated having to go through a lengthy README just to install a package.
It's not easy. Having everything in one place means I can use |
|
I agree the priority should be having features ready out of the box. I know some people like to keep things as slim as possible, but I think for most people their time is more important than their disk space. |
|
Ok, so here is the idea: how about separate Lispy commands that depends on nothing into a file, and commands that depend on things another files, then we can introduce a package on MELPA with such Lispy core package. I want such a package, so I can integrate it into Spacemacs, since it already has its replacement for Hydra and Ivy. |
It's possible to do, but I'm not a big fan of shuffling code just for the sake of it. Is it so objectionable to you that lispy pulls in two packages that you don't need to use if you don't want to? Two extra packages at ~3000 lines extra, The venerable |
|
The problem is if
I don't think CEDET is loaded if you don't enable it. And in Spacemacs, CEDET is lazy loaded as well. The In the case of Spacemacs, it already has Helm and Ido and Evil micro state (that gives the same feature as hydra), so adding |
It is fully loaded if you
By how much? My config starts in 1.3 currently, I have 130 packages, and
Reusing a package wasn't my complaint. Auto-enabling it even when
So there's place for two completion packages but not three? That's nonsense. Especially considering that Bundling code and loading it are two different things. I don't see spacemacs people complaining on emacs-devel that emacs bundles 1500 el files.
Worf is experimental and hasn't had a single release. I can tag a pre-hydra version in MELPA stable if you really want. I'm not extending that package lately. |
|
In any case, making I can work on removing the dependency on |
I remember reading a post where you autoloaded everything. Lazy-load with
If so, you should not install it in the first place.
Actually I'm not sure about this, so I may ask @syl20bnr whether it's ok to add such package. However, I am certain about one thing: currently Helm is only package that can compete with Vim packages and win. No other narrowing and completion package in Emacs can compete with the likes of Command-T or CtrlP or Unite, in term of speed and scalability. About
Thank for you consideration! Sure, I will help adding and maintaining it. And I agree, the
Currently |
Sounds like you could require it inside eval-when-compile. |
Thanks, I guess that could work. It could be possible to not depend on hydra, dispatch on |
Other than installing two packages that extend Ido.
flx-ido is slow, I avoid it on purpose. I could try to enable it for small collections, but then it would feel weird to have two different behaviors.
Ivy has started as an alternative to Ido, because Ido code was so convoluted that I couldn't extend it for my needs. In only 2000 lines, Ivy has alternatives to:
Ivy is just as fast as Helm, some people may prefer it since it's smaller and easier to understand. For users coming from Vim, Ivy is basically a theme for Helm. Here's a quote from a happy user:
|
|
|
As a general thing, if you only use macros from a package (regardless of whether the dependency is optional or mandatory), it's a good idea to only require it inside |
Please explain, maybe link to some Vim sources. I've had a great kick at emulating Vim easymotion.
It's a matter of approach.
It does.
I'll put this one on the list.
A plain g
while Ivy gives:
This one is pretty cool. I'll add it to the list.
Ivy is better here with
Again,
Very nice, I may add a similar command. But C-h m +
Seems much worse than even
Haven't heard of platinum before. How is it better than ag?
I'm just using CEDET. I tried GTAGS ages ago, it was too simplistic for C++.
This is just the built-in
This is developer-side. And as a developer that wrote a very sizable amount of Helm-enabled packages (I was very enthusiastic about it around a year ago), I can tell you that Helm is super-painful to debug, and very hard to completely understand. You can play games with it, copy-paste stuff, it still won't work exactly how you want if you want something more complex than |
Thanks. Question: how do I proceed from this code? (eval-when-compile
(if (featurep 'hydra)
(progn
(require 'hydra)
(defhydra lh-knight ()
"knight"
("j" lispy-knight-down)
("k" lispy-knight-up)
("z" nil)))
(defun lh-knight/body ()
(interactive)
(error "Please install `hydra' package"))))Suppose the user didn't have |
If you join Another popular plugin is Command-T. Another popular plugin which is closet to Helm (but still has much less features) is Unite. When a Vim user joins Spacemacs, they often ask about Ctrl-P equivalent in Emacs. Only Helm satisfies the requirement.
Ok good to know. But Helm has a lot of useful actions, for example open file as root, open file other window, insert file path... Only Helm Projectile can do something like this at the moment.
But here you query entire index of an info manual, not just a page. Man page users don't like Info since they cannot use Vim to search within a page. But with Helm, such problem does not exist.
You can toggle the basename with
How does it compare with
I do not use
With
It does not depend on
Maybe you should use the user APIs such as |
|
You can evaluate a macro at runtime like this: So you can wrap that in a It's not pretty, but it's the only way to use a macro that wasn't available at compile time. Optional dependencies really aren't Emacs forte. |
I'm not that interested in Vim. But thanks for the links, I'm looking at Command-T now.
Ah, I see. So it's topics+index, not just topics.
That's a pretty good solution.
It's invisible to the point that you don't notice it's there, and I think that's a great feature. Other than that, the candidates are there, but there's no stuff like mode narrowing.
I see. Ivy binds similar things to C-M-n and C-M-p by default. The problem this can't be used within the @Malabarba, do you think there's a chance to convince emacs-devel to extend the
Trust me, it's hard.
All of these without an option to debug, just editing the code and hoping it would work. |
The completion engine could always just check the value of |
It's not that simple: examining For example, I'm getting ~600 mentions of Here's what I'm talking about: (defun switch-to-buffer-new (buffer-or-name &optional norecord force-same-window)
(interactive)
(completing-read "Switch to buffer: "
;; ...
(lambda (buffer)
(switch-to-buffer buffer norecord force-same-window))))When there's clearly one exit point after the completion takes place, it's possible to just let completion engine know how to finish the call and exit the function. Advantage:
Disadvantage:
|
Yes, you're right.
That suggestion looks plausible, and adding an extra argument to The good thing is that you don't really need to pass the |
You're right. Maybe
I think it's necessary: C-M-n in Ivy or C-down in Helm don't return to their caller. They call their lambda action and ask for more input. With And stuff like |
Currently, The alternative I'm suggeting is this: Is that too ugly?
Unless the pause/resume functionality is implemented directly in The advantage of letting completing-read handle all this action-related functionality is that you get less code redundancy between all those completion packages. The disadvantage is that you get less versatility. |
It's a bit ugly, since I'd have to toggle between two functions when debugging.
That's limiting. Here's another idea that I haven't implemented yet:
True, but I'll take versatility over redundancy any time. That's what Emacs is about for me. |
|
Most important thing for dependencies is that they are actively maintained which is the case here. The fact that the author is the same for all dependencies has some values too. My concern is not on the size of lispy, @abo-abo mentioned the helm case with thousands of line of codes. My concern is consistency, in Spacemacs we made the choice to use helm everywhere and I even ditched ido from it as a default for some tasks I prefer to do in ido (smex and Ido-find-file for instance). We also have a custom macro for transient maps. When a package is not modularized with isolated dependencies in package extensions it makes its integration harder which is sad when the package has great values. I think that those improvements/extensions upon lispy should go in separated packages like it is often the case with helm or flycheck. It is beneficial on a architectural point of view but also on a practical point of view. The good solution of using lispy combined with hydra and other packages should be something done in your distributed .emacs.d. Now I understand that this better architecture does not give you anything new so it's hard to ask you something that's purely for us. I'm on a mobile excuse the typos ;-) |
FWIW, I admit I have a preference towards building this stuff into completing-read, but that's just because I'd really like to see these features in Emacs core. :) As for the initial question. I think you can get the approval (or at the least, the non-disaproval) of the dev list on this. Here are some things I try to do when proposing important changes (not that you need it)
|
|
Thanks for the help.
Maybe Ivy will displace/join icomplete.el at some point. I've actually adapted it from icomplete initially.
Nice strategy, I've never thought of that. I'll make sure to give it a try sometime:) |
ivy.el (ivy-partial-or-done): Update. Fixes abo-abo#74
Is it possible to make
lispyjustlispy, with the exception ofavyincluded for ace stuffs? I don't useivy, butlispyincludes it. Some people may not usehydraas well, so it should not be forced.The text was updated successfully, but these errors were encountered: