1

I'm probably going down the wrong path here, so let me know if I am. I'm trying to build a similar user interface to that which Vim's ctrlp and other plugins use, whereby the user is given a prompt, and as they type, results are shown above the minibuffer prompt line.

I've gotten the minibuffer command handling part working fine with minibuffer-with-setup-hook and a local post-command-hook (easy) and can get the results I want to display (verified by just (message)ing them for now).

If I want to show, say, 10 lines of results above that minibuffer prompt line, should I be somehow prepending text to the minibuffer, or using a separate buffer that I'll close once the command finishes? Any pointers to parts of the manual I should be reading to be on the right track with this?

d11wtq
  • 34,788
  • 19
  • 120
  • 195
  • You're looking to implement helm? https://github.com/emacs-helm/helm – event_jr May 24 '13 at 15:04
  • @event_jr helm is a gigantic bag of everything, so no. – d11wtq May 24 '13 at 22:42
  • Helm is exactly what you describe. Look at how it's implemented if you want to redo it in a simpler way. – event_jr May 25 '13 at 03:45
  • @event_jr yeah reading its source now. What I meant was yes, that style of UI, but I'm not re-inventing Helm. Helm is massively bloated. If the completions part of it had been in a separate project, I'd have used it, but it's all bundled into a God package, which is hugely unappealing ;) – d11wtq May 25 '13 at 03:58
  • @d11wtq saying Helm is bloated is like saying Emacs is bloated. Emacs has lots of packages, but you don't have to use them. It's the same case with Helm. It only provides an interface and you can display anything in it what you want. So if you want to show only file name matches then you can do that, etc. – Tom May 25 '13 at 05:34
  • That's kind of like saying we should install Windows just so we can read text files in Notepad. If people want more focused tools, they'll either find them, or create them. I'm doing the latter. Obviously we have different opinions, but in my mind, small, lean, focused tools are better than bloated ones. It's is a UNIX philosophy. Yes, Emacs is bloated, but there's not much of a choice there. It doesn't mean we should just write packages that stuff every conceivable into one big project, though. Also, I just don't like the performance of Helm. It's sluggish. – d11wtq May 25 '13 at 05:41
  • I'm just going to leave this here for posterity's sake. @d11wtq, you are wrong about helm. I use it with great success. I use it to find files in projects (>5k files) without sluggishness. I have invested the time to customize some settings to get what I need out of it. I understand it's not for you, and that's fine. – event_jr May 25 '13 at 12:16
  • @event_jr By fast I mean this https://dl.dropboxusercontent.com/u/508607/fiplr-dev-demo.mov (> 5800 files here). Pardon the primitive UI at this stage ;) – d11wtq May 26 '13 at 04:53
  • @d11wtq My helm experience is experientially as fast as your video, although I haven't benchmarked it. – event_jr May 26 '13 at 11:45
  • @event_jr interesting. You must have spent a fair bit of time customizing its logic, as I could get nowhere even close. No benchmark, you can just feel the lag. I did the same with the linux kernel too (48K files). https://dl.dropboxusercontent.com/u/508607/linux_kernel_search.mov – d11wtq May 26 '13 at 22:49

2 Answers2

2

The "minibuffer" is a normal buffer, so you can modify it by inserting/deleting text into it in the normal way. This said, adding text "before" means basically modifying the prompt which might lead to problems down the line. You'll probably be much better off doing something like

(let ((ol (make-overlay (point-min) (point-min))))
  (overlay-put ol 'before-string (format "%s\n" myresults)))
Stefan
  • 27,908
  • 4
  • 53
  • 82
  • From a quick play around, it feels like an overlay will do the job nicely, thanks for the suggestion. – d11wtq May 25 '13 at 06:31
1

I started to write this as a comment, but it got a bit too long ...

TBH, I feel there is room for a lighter weight version of helm. But the reality is helm is good enough, and someone else has already written it.

Neither I nor anyone else (so far) is motivated enough to rewrite it. What you describe as "God" aspect of it is indeed unappealing. But it is possible to load it (huge as it is, with modern computers, it really isn't an issue), and change settings so it is minimalistic.

ido is a simpler alternative, but the style of UI is not exactly how you described.

event_jr
  • 17,467
  • 4
  • 47
  • 62
  • Yeah, ido is slimmer and at least it can be used in isolation (I'm integrating with it right now, but only as a stop-gap). I'm motivated, but as I say, I'm not looking to simply rewrite helm, I just want find-in-project and live, fast fuzzy searching of the manual/apropos. Helm is also quite slow. I have a fuzzy-search lookup table algorithm that is very fast. Helm uses two buffers, so I'll start with that. Thanks. – d11wtq May 25 '13 at 04:23
  • You can add your own quick fuzzy matching algorithm as a new source in Helm. You don't have to use Helm's algorithm at all, you can reuse the interface only. That's what Helm is about. – Tom May 25 '13 at 05:36
  • I don't want to use Helm, as already stated, thank you. If it had been structured in a more adoptable way, perhaps, but it's all in one. A bit like adding a dependency on Ruby on Rails just to get the numeric helpers. It's just not how you approach a new project. – d11wtq May 25 '13 at 05:58
  • @d11wtq Is your fuzzy-search thingy open sourced? – event_jr May 25 '13 at 12:24
  • @event_jr yes, but it's still a work in progress ;) https://github.com/d11wtq/fiplr/blob/no-ido/fiplr-search-index.el Based on the overlay idea, when fiplr-completing-read is invoked, I'm currently just live-updating a count of how many strings matched, but it is fast, because it uses a lookup table and excludes results with each keypress. – d11wtq May 25 '13 at 13:03
  • @event_jr that code will probably move into a separate project, providing just the indexing and the completing-read function, which fiplr will depend on. – d11wtq May 25 '13 at 13:04
  • @d11wtq: " If it had been structured in a more adoptable way, perhaps, but it's all in one." This comment suggest you didn't really spend time understanding Helm. helm.el is the core, it contains only the completiion framework, everything else is in other files (completion sources, etc.). So it's not "all in one", because the completion/dislpay framework is clearly separated from the actual completion implementations and one can use only the core for one's own purposes without using the rest of Helm. – Tom May 25 '13 at 15:29