Proposal: remove embark-collect-live and embark-collect-completions #466
Comments
|
I am in full support of removing this feature, since it narrows the focus of the package as a package centered around actions. Also having shorter command names is better and there has been confusion before about the difference of As you argued there are good alternative completion systems around. In particular I want to mention @protesilaos' Mct which can be used as substitute if people like a buffer display. Furthermore Embark completions were always a bit difficult to setup in contrast to just activating If there is interest in preserving an Embark-based completion display we can move this part of the code to a separate repository and consolidate it with @karthink's Elmo (See #1). It is arguably the cleaner solution to move the completions code out of Embark instead of moving more completion code into Embark. This will help maintenance in the long term. Therefore I don't see a reason to not take this step. If there is interest we can still bring the functionality back, but at a better place, where it fits better. |
|
Let me just tag @yoctocell who is the only other person besides @karthink and @protesilaos whom I remember ever using a live updating variant of embark-collect. |
Well, part of me never really recommending |
See discussion in oantolin/embark#466. In the light of capable and flexible alternative completion systems like Vertico and Mct, Embark will likely consolidate its feature set around actions and snapshot collections.
|
I removed the mentioning of Embark as completion system from the Consult README, which I feel has led to more confusion than it helped. Embark is of course still featured prominently there for all its other features!
Yes, I know. But one has to know your stuff very well to find this. I think if we want to preserve the functionality it is better to do that externally and if we are really going to do that we should also provide a mode as @karthink did in Elmo. |
|
First of all, let me emphasize that embark-collect-snapshot is here to
stay! (Although I guess that if the live and completions variants are
removed, then we might as well rename embark-collect-snapshot to
simply embark-collect.)
Yes, this makes sense. I agree with your decision and with what @minad
wrote.
I myself never used embark-collect-live and I bet I was probably one
of the last holdouts using embark-collect-completions.
I don't remember relying on the former. I did use the latter full-time
and only switched to the generic Completions after the 'one-column'
option for 'completions-format' was introduced.
In practical terms I was still using embark-collect-completions for
its features. Of course its main deficiency is how slow (#101) it is,
and for a long time I longed to switch to Vertico (which is what I use
now), but did not switch because other than being slow,
embark-collect-completions had a lot to offer: [...]
These are all nice features, which I also like. As has already been
noted, Elmo or Vertico are natural choices. It just is a matter of
keeping the code maintainable and putting features in the right place.
Whatever you do, I am happy to help test things.
…--
Protesilaos Stavrou
https://protesilaos.com
|
|
I too am in favor of removing Elmo is just a thin layer of glue code over |
|
I'm glad the reception to this proposed removal has been positive. I started working on a no-live-collection branch: b7e4b93 That should be usable, in case anyone wants to test, but I still want to simplify things a bit further: the annotations are curently computed only on demand, but without live-updating that laziness is not really necessary. Thanks @karthink, for your willingness to put together an embark-live package. But I think that, if we do want to do something like that, it should just be me adding some of the code I just removed from Embark to your existing Elmo package via a PR. How does that sound? (Well, not just adding some code to Elmo, it would also mean a tiny bit of refactoring to Embark, which I'd be happy to do.) |
Very good! This commit clearly shows that the completion functionality is separate from the main functionality provided by Embark. This is a great simplification!
That would be good! There was also issue #203 which may be relevant to this? |
|
Oh, just one thing. I went over the issues again and saw #405, #407 and #408, which are relevant to this discussion. If we remove live collect we remove the live updating toc functionality too. Do we want this? I think the simplification above justifies the removal. But I wonder if there is some way to retain the live collect feature, maybe without the fancy optimizations? Is it possible to implement a simpler variant of live collect based on the static |
I don't think I knew about |
I tried tree views for a while but I don't really like them. The point of |
|
Thanks @minad for collecting those particular issue numbers which was actually an item on my todo list! I am planning on storing the candidate collector and, as I said above, storing the annotations too. Also: thanks for chiming in @hmelman! I think it is perfectly feasible to add back an "external" (defun embark-live ()
(interactive)
(let ((live-buffer (format "*Live-updating Embark Collect for %s*"
(buffer-name)))
(run-collect (make-symbol "run-collect"))
timer)
(setf (symbol-function run-collect)
(lambda (_1 _2 _3)
(unless timer
(setq timer
(run-with-idle-timer
0.05 nil
(lambda ()
(embark-collect)
(when-let ((existing (get-buffer live-buffer)))
(kill-buffer existing))
(with-current-buffer "*Embark Collect*"
(rename-buffer live-buffer))
(setq timer nil)))))))
(add-hook 'after-change-functions run-collect nil t))) |
|
@oantolin Thanks, this looks good! Then I think we can go forward with the removal but maybe still retain the independent and simple live collector |
Do you mean the library or the general concept? Long ago I tried
|
|
@oantolin Anything missing or is this ready to merge?
For me the general concept is not useful in normal day use. However I see some value for demonstration purposes for clicking around etc. In that case, the tree visualization seems useful. Regarding the libraries, there are a multiple packages around and I lost track: speedbar, neotree, treemacs, ... I think treemacs is the most powerful and most advanced. Unfortunately it is also quite opinionated with multiple dependencies, e.g., uses a posframe instead of the minibuffer to read user input. Design decision like these go against my preferences of composable packages, which conform to the commonly accepted ways of Emacs.
You should really migrate to Org which already comes with all these features ootb. You can even make it look "modern", see https://github.com/minad/org-modern. ;) |
So I've heard ;) I'm in the Apple ecosystem so I need good iOS support. I've tracked a couple of org apps and they're not quite there yet for me. Markdown is sufficient for my needs and I kinda hate some of org's syntax. |
|
@hmelman Why do you need apps? Just use Emacs ;) Personally the Org syntax doesn't bother me much. It takes some time to get accustomed but the only syntax which I find noisy are the |
|
@minad I think I would love to use emacs on my phone, but then I think about trying to type One of the things I loved about osx when I first switched to it was that the basic text widget used in all apps supported the basic emacs editing keys, so I have them everywhere, in every text entry box. And there was an extension system to add more commands. One of the things I hate about new versions of macOS is that they no longer support this everywhere, (e.g., I think in catalyst apps) and it's really frustrating when it doesn't work. Turns out I use |
|
Regarding Emacs on phones - I think one thing I would really like to have and which I will probably set up at some point is a way to make captures/notes to Org from the phone, which are then sent via a trivial web app directly to Emacs. Furthermore Emacs generates a html from the Org agenda, which is also made accessible on a private web server. I guess that's all I would need. Org already provides many facilities to make that work, so I am sure there are a few people who have something like this running. |
|
The new hotness on IOS is Plain Org which seems to have some org-capture-like functionality via share sheets. The older beorg does have this. In both the org files are sync'ed via cloud services so your emacs should just see them. I'm not sure if that's what you mean or if you have something else in mind. |
|
I am not using iOS and I am also not interested in yet another proprietary app which will stop working at some point. I mean I have to bake something myself, but I am happy with something much more limited as long as I can hack it to my liking. |
|
I would think there are more options on android, but I appreciate the not wanting to use a proprietary app. My iPad editor of choice is Editorial which stopped getting updates several years ago. It still works and I still think it's the best markdown editor (and has a python interpreter in it for extensions) but it only works with dropbox and it's keeping me from moving to iCloud Drive exclusively. |
|
I think I don't even want an app. I am kind of an anti-app person to avoid spyware, advertisement and unnecessary disturbance. A simple web form and a plain html agenda would suffice for me. |
|
@hmelman I think Org's syntax is much more sensible than Markdown. First in Markdown there are two different syntaxes for headings, the There are also two syntaxes for italics, Other parts of Markdown syntax seem OK to me, but the Org syntax corresponding to those things is different but also fine. And finally, Org is extensible and Markdown is pretty limited. So for the very basics I find Markdown to be unnecessarily complex (supporting multiple syntaxes), and needlessly going against established tradition; and for more advanced things Markdown has nothing while Org has something reasonable in most cases and is extensible. In my opinion the only thing in which Markdown is better than Org is that it is supported in more applications. |
|
@minad You may want to check out the organice web app for Org on the go. It has a pretty sophisticated Org parser written in JavaScript and, while you could even host your own instance, you may not even want to: it is a purely frontend application and if you use their instance no data of your is stored on their servers. You do need to have your org files on Dropbox, GitLab, WebDAV or Google Drive to use organice, though. I guess GitLab would be fine, no? Or running your own WebDAV server, maybe. org-modern looks very elegant! I really need to figure out how to get notified by GitHub whenever you create a new repo. I keep finding out about these cool packages you write only when the appear on GNU ELPA, MELPA or someone mentions them here or on reddit. |
Organice sounds interesting. WebDAV seems like the only acceptable solution to me. But I think I don't need any kind of sophistication, only a quick way to drop notes directly into the Org files would be sufficient, without any further editing support.
Haha, thanks! I just stole the style ideas from Nicolas Rougier's beautiful svg works and also org-bullets/org-superstar. The goal is to have something lightweight which uses only the basic Emacs text styling facilities. Needs more work though, maybe even pixel perfect alignment for tables with LaTeX image preview. |
|
I currently have a low-tech solution for capturing things on my phone: I just use the note app that came with the phone. That application has cloud storage, so later at my computer I open my phone notes in the browser and just copy and paste into Emacs. I don't even really need the cloud storage: before realizing the note app had cloud storage, I would just retype things into Emacs. It was fine, I didn't find it too onerous; but it's definitely not as comfortable as copy/paste. I guess if I captured more things into my phone I would want to automate the process of getting them into my Org files, but so far this has been sufficient. I might try moving my Org files to GitLab and then using organice. On the Emacs end I don't really care what git forge I use. For my Emacs packages I do want GitHub but just because I believe more people have GitHub accounts already, but for my private repos I could use GitLab equally well, I guess. |
Me too. The next step up in the low-tech solution hierarchy would be a way to capture directly into Org. 😄 |
|
@oantolin Yeah there are some oddities, but I stick to the simple ones, ## for headers and |
|
@hmelman Well, for the subset of Markdown you mentioned Org's syntax is not clunkier. It is actually shorter than Markdown by one character for bold and the same length as Markdown for everything else you mentioned! Often the same syntax even, like for lists and checklists. The clunkier parts of Org syntax are for elements you didn't mention needing. That's why I prefer Org, for me it's not a case of "well, Markdown is nicer for simple things but you need Org for the fancy stuff", it's more a case of Org being the same or slightly better at everything, even the simple things. |
|
I remember org-bullets as slowing Emacs down a lot (I remember deciding that while I liked how it looked, the performance hit wasn't worth it and I uninstalled). I lost track of it and don't know if it fixed the performance problems, but I also seem to remember it was discontinued afterwards. Is that right? Anyway, I trust your version of it to be fast. 😉 Nicholas Rougier's packages are definitely very pretty, I love seen screenshots in reddit. I haven't tried them yet, but using SVG I'd also worry a bit about speed. I think you're version without rounded corners is nice enough and is likely to be faster. Is it? The tables look great, that would be alignment enough for me. I think there is a package already that does pixel perfect alignment of tables. Let me see if I can find it. |
|
I must say that I consider the syntax differences as quite superficial. For me the main selling point is that Org just integrates so well in Emacs and feature rich, org-babel support, agenda, ... The implementation is far more powerful than markdown-mode. I would just lose to much by not using it, in particular if you like to use Emacs for many things. I also considered Asciidoc at some point a longer time ago. Asciidoc also has a nice syntax, it is also somewhat extensible, but in terms of implementation no match to Org. |
|
That's right, the real difference is all the tooling behind Org mode. I'd still use Org because of this even if I preferred Markdown's syntax. But while the advantages in tooling are obvious I think people often think of Org as "clunkier" than Markdown and I disagree with that (for the small subset of Org that actually has equivalents in Markdown). |
|
Oh, I think maybe the "package" for tables I was remembering is actually this reddit post. |
The successor is org-superstar. I am not aware of performance issues. So far org-modern works well for me and only relies on simple font locking and text properties. I doubt that there is a way to make it faster than it is, but one could disable style elements one by one if they lead to a performance degradation.
Yes, it should be much faster, since I don't generate images. But I've also been told that the svg tags are not that bad actually. I have a hard time to believe that. I suspect you will at least notice it. The images will definitely put more load on the Emacs display engine and Emacs overall. I also like to push a bit what I can achieve with simple means.
There is the valign package, but it uses one overlay per separator character for its adjustments, which is a guarantee for performance issues. Therefore this package is out of question for me. Pixel-perfect alignment matters if your table cells don't have fixed width content, see minad/org-modern#5. So I may add some code to org-modern to handle pixel-perfect alignment if I find time for that. |
|
I find org's link syntax clunkier than markdown's, and as I said, I'm limited a bit by iOS support but watching developments. I agree that Nicholas Rougier's packages are definitely very pretty. For now I'm on the macport of emacs which is 27.2, so I look forward to trying some of the features of 28 when it releases. Lars recently added |
|
Oh, yes, links are maybe an exception to what I was saying earlier, @hmelman. I think the inline syntax in Markdown, |
|
By the way, I wish info rendered links in the Markdown reference style. The Embark manual looks pretty ugly in the info reader due to links. |
See my complaints about Info in minad/marginalia#131 (comment) :-P |
|
And you're voting with your feet: I have no consult info manual! |
|
My approach would be to change the rendered info format to be the markdown link format, basically just surrounding the text with brackets (or some other delimiter) and then having the emacs Info reader render the links cleanly. I don't care what the stand-alone reader does but don't see why it couldn't do something similarly pretty. But reading archived mailing lists threads about improving info is sooooo depressing. |
I didn't sabotage this intentionally 😆 |
Unless the only reason to have an Embark live buffer is for use as a completion framework, I think it makes sense to have the Between a very actively maintained MCT and vertico-multiform, I don't think there's a niche for Elmo any more. What do you think? |
|
@karthink The idea is to keep a cheap variant of |
|
Yeah, I think Elmo can be modified to use the above version of embark-live.
How does embark-live connect to the marking facilities?
|
|
I've merged this now. @karthink, please check out the new The new |
|
Thanks! That's great. I will test the new implementation soon and then maybe I can get back to #467. |
|
Argh, I forgot to put in obsoletion warnings. I'll add those. |
|
The "L" keybinding is also missing. Besides that it seems to work well. |
|
I added the "L" binding back. |
First of all, let me emphasize that
embark-collect-snapshotis here to stay! (Although I guess that if the live and completions variants are removed, then we might as well renameembark-collect-snapshotto simplyembark-collect.)I think that probably very few people use
embark-collect-completionsorembark-collect-live, and removing them would let me significantly simplify the code forembark-collect-snapshot. I myself never usedembark-collect-liveand I bet I was probably one of the last holdouts usingembark-collect-completions.It seems like a reasonable philosophical stance to say that
embark-collect-snapshotandembark-exportare of a very different nature thanembark-collect-liveandembark-collect-completionsand that the latter two are really out of scope for Embark.In practical terms I was still using
embark-collect-completionsfor its features. Of course its main deficiency is how slow (#101) it is, and for a long time I longed to switch to Vertico (which is what I use now), but did not switch because other than being slow,embark-collect-completionshad a lot to offer:But with (relatively) recent improvements to Vertico and Marginalia you can get almost of that in Vertico now, and Vertico has always been much, much faster. Only multiline display of multiline candidates (and zebra stripes) is missing from Vertico, but I've found I don't really need that at all! Also, let me say that if you want completions displayed only on demand like I do,
vertico-unobtrusive-modeis much better than truly displaying zero completions.I've never really recommended
embark-collect-completionsand would now actually recommend against using it, I mean, why wouldn't you use Vertico instead?I'm creating this issue to give people a chance to protest or in general give their opinion before I do anything about this.
The text was updated successfully, but these errors were encountered: