Refresh the talk on spliting Hyperbole into many packages #6
Comments
|
On Feb 14, 2019, at 12:18 AM, Felipe Barros ***@***.***> wrote:
Hello and, first of all, thank you for your work! It's amazing!
Thank you.
I know this is an old topic and I hope that I'm not offending you by bringing this up again,
Not at all. We want Hyperbole to be adoptable and easy to use.
but since the package is now available here on Github, others may come looking for answers on the subject. My hope is to better understand the reasoning behind the bundle and, if possible, to constructively think of ways to lower the barrier of entry.
I will have to respond when I have time later this week but I have forwarded your message to the Hyperbole mailing list for discussion, [email protected].
— Bob
|
Ok. So most of Hyperbole should stay out of your way when you are using Koutlines and there is a mode-specific pop-up menu that you can use with just those commands. If something gets in your way, just make a note and then send a list of items and we'll discuss and see whether any changes should be made.
I use Hyperbole specifically because it doesn't get in my way and just makes me more productive but of course I have tuned it to what I think is a good way of working and other people use other combinations of packages, so I understand that there can be issues.
We would be very interested to hear all the things you think it changes or your sense it does so we can understand this thought. Yes, there are a few keys that it binds globally that sometimes override mode-specific key bindings but these can be turned off permanently from a menu or with a setting.
Of course, Emacs is similar. Just because it is there doesn't mean you have to master or use it all. Learn one feature set/subsystem at a time. Implicit buttons and Smart Keys, explicit buttons, global buttons, HyRolo, Koutlines and HyControl. Each can be learned individually and then combined for more power.
If you can be specific and you identify issues that are generally a problem, we are likely to resolve them as we want our users to be happy and productive. Give it a shot. We have some very experienced users with highly custom configurations using Hyperbole basically out-of-the-box, so if this were generally the case, we would hear about it and would have many more open issues.
This is a valid concern and is certainly something we have thought of, especially in the last few years. But so far, we have decided that the benefits of having the features integrated outweigh the simpler adoption that unbundling the subsystems might provide. Secondarily, documenting the subsystems separately would be a bigger burden and difficult because you want to talk about using core Hyperbole features with the subsystems, e.g. Hyperbole buttons embedded within HyRolo entries (explicit buttons embedded in HyRolo files actually work when displayed within the temporary buffer displayed after searching for matching entries. In hypertext systems, everything is supposed to be connected :-)
Maybe. HyRolo used to be separate and can be used by itself without much effort. Hyperbole's manual and demo can be viewed in bite-sized pieces, a section at a time.
I agree. These issues are worth exploring.
So why do they feel they don't need it? Is the demo inadequate? No doubt it takes some time to appreciate, like Emacs itself. If you can just show them how every filesystem path becomes a live link, even if it has environment variables embedded in it, maybe that would be a start. The next release even understands Windows paths in an intelligent way. Show them the power of implicit buttons and how any pattern they like can become an active link, even displaying files in external programs of your choice.
So you are talking about other Emacs packages above, right? I will just say that on the surface that is true but when you dig down and see how things work, there are many benefits of Hyperbole's versions of these tools over others. In the case of Org-mode, Hyperbole and Org are quite complementary and can be used together if desired.
Hyperbole was created before many of these other packages existed, so it does have some legacy elements and support that goes way back (again, like Emacs itself). But we have done a lot to modernize it and are interested in making it attractive against and together with other common packages.
And we are with you on wanting to simplify adoption, just not on unbundling. Maybe we just move back to autoloading subsystems and then it will appear more like on-demand, separate packages. At one point, we had to stop doing that because there were so many different ways to invoke Hyperbole features that autoloading could not be supported. Can anyone provide specific, individual issues that may impede adoption and proposed solutions? I certainly don't use all of Hyperbole on a regular basis but I also don't find that having those other features around gets in my way. Can you give examples of how your workflow is interrupted by things that you don't intend to use? Thanks for your initial feedback. -- Bob |
|
Just want to bring this topic back to life and encourage you to list specific conflicts/problems that you find, so they can possibly be resolved. Thanks for the feedback. -- Bob |
|
I'm a little late to the party but I agree with @barrosfelipe in almost everything. I have a very unpopular opinion regarding our beloved Emacs world: I don't like org-mode. I also want to share some thoughts on it, although I don't want to offend, but some things are sometimes harder to say without sounding a little off, but I hope it can be understood in a positive way. I'm very amazed by some of the Hyperbole super powers, I still finishing the Demo but I'm already surprised. But I can say to you that I almost didn't installed Hyperbole and I was about to lose a nice piece of software for a reason: there is not much information about it, and reading a lot of different topics on reddit about it (and paraphrasing another user from one year ago), a lot of feedback given was acknowledged but simultaneously dismissed. It sounded a lot like you or the team was not interested in anybody else using it, you know? I can also say another thing about it: both documentation and feedback problem might not exactly be the case, because you received @barrosfelipe feedback very well and sounded very welcoming in this issue, and the DEMO is way more understandable and nice documented than any other video, talk, post or information about the package out there. So maybe, a major problem about the package would be regarding communication issues between the team and the community?
I can see how this can be a problem, although might not to be the case as well. About the documenting issue I think this might not to be the case because if you search "org" on google or Github, you will find a huge amount of packages for it, and they're pretty much subsystems for org-mode as well, and nobody fells like it's hard to understand or to document a subsystem because... well, it's a org-mode package, what else would it interface with?
I don't think it's inadequate, but it's strange and confuse to have unrelated features being talked altogether. "So, Hyperbole is about a Information Management System... Cool, that's what I need!
I just sensed it getting in my way for some reason but I don't remember why anymore since I've started to write this. I will try to pay attention next time so I can report something if it happens again. What I can say is that I don't understand very much some of the keybindings decisions. I know that it's very hard to keybinding, specially in a package that can offer a lot. In Koutline
I have this impression that keybindings could take advantage of mnemonics. So Just because in the same paragraph we're already using three patterns for supposedly related commands, a pure For some reason kimport and kexport isn't working, like Something that bothered me a little is that pressing Another thing that bothered me a little is that looks like if I'm in the end of a button, it don't detect the I would like to say that I would be very happy to contribute as I can if in the future the project unbundle things. With all that have being said, I hope it doesn't sounded rude as a feedback. I wish a happy New Year for you all. |
|
Thank you for your extensive thoughts. We will discuss and consider them. We do want Hyperbole to be easily adoptable. What helps most is when you identify specific features that get in the way of adoption rather than just indicating that Hyperbole’s breadth itself slows adoption. For example, your questions about Koutliner key bindings are specific and helpful to discuss. New adopters may not realize that Hyperbole stays out of your way most of the time until you need it and therefore may assume with all its features that it may be hard to integrate or get used to. But if you use standard Emacs key bindings and just add Hyperbole in, things should be pretty easy. If they are not, then that is what we should discuss. |
|
Hey @rswgnu and @jacksonbenete , nice to see and think about this again.
Sorry Bob, I don't want to be rude, but it was this unshakable stance that demotivated me from continuing the discussion. It's exactly the breadth itself that slows adoption, in the way that I see. There is little point in discussing minutiae, especially since you have developed a really robust defensive argumentation system when it comes to the design decisions in Hyperbole, so it would require investing considerable time in understanding the details to a point where I'm able to discuss each individual section with someone as knowledgeable as you. I still admire Hyperbole, I still admire your work and patience (as I often see when you comment in the community), but there is this Zen saying (I don't recall where I've read it) that says something like the following: "You can't drink tea in a cup filled with coffee. To drink the tea you must first throw the coffee away." And this is how I feel here. There is little room for new ideas to grow, little soil. The Emacs ecosystem is thriving (I work with Clojure, so its everywhere in my work life) but I still haven't met a single person who is using Hyperbole. Not once. And all that I described above is still valid today. It's still something I don't have installed (even though I constantly think of installing it yet again), and when I talk about it (and others eventually try it), they just get scared away or don't understand the necessity for functionality overlap with other tools they are already familiarized with. |
|
I think your last paragraph is fair and is a similar reason many people shy away from Emacs. Maybe Hyperbole is too much for many people. Maybe they just don’t know how easy it is to adopt and to turn on and off now that it is a global minor mode. Maybe Org mode despite its complexity is enough for many users. We want Hyperbole to be a turnkey environment for people, easy to install and to turn on and off. We want people to understand they can learn one part of Hyperbole at a time and grow into things across years as they do in Emacs. We continue to add videos and simplify introductions and demos. Given how many point packages exist already for Emacs, it makes little sense to just offer competing point solutions and then somehow expect people to join them together in more advanced workflows. We feel the capabilities need to be at your finger tips. Yes, that makes the getting started barrier a bit higher as we can agree but we don’t see a much better path given the developer time available. And we do welcome feedback even if we don’t follow every prescription given. We have adopted a lot of user and pre-user feedback. We only object to people criticizing the package without having given it a good try. Thanks to both of you for your comments. |
|
Reading through this thread, I think I might have a different perspective to offer on this discussion than what's been said so far, in case it's helpful. In my case, hyperbole being a single package is a hindrance to my adoption not because I am overwhelmed by the number of features or capabilities (as you say I can simply ignore them if I don't know how to use them yet), but for the simple fact that, since it is all bundled in one gigantic package, it takes a very long time to load. Hyperbole alone takes 1.5 seconds to load when added to my Emacs config, whereas the entire rest of my Emacs config — which is over 63 packages, some of them very large and extensive — takes less than half of that amount of time, at 0.65 seconds. I am currently using a So although I know hyperbole gives a breathtaking amount of functionality in return for its load time, that load time is still an extremely heavy price to pay. Starting Hyperbole alone takes an amount of time comparable to something like Visual Studio Code! Perhaps if hyperbole was separated into a few general packages, it would make it a lot easier to adopt. However, I do understand why you are hesitant to do that, since multiple separate packages is more complexity to document and maintain. I think the compromise solution might be, as you briefly mentioned somewhere in the middle of this thread, bringing back autoloading? That way you don't have to pay for the full night of hyperbole up front when your editor starts or the first time you run a hyperbole command, and all of the features that my overwhelm people aren't necessarily there from the start. |
|
1. You can try use-package with the :defer keyword.2. We expect people to rarely restart Emacs, so that 1.5 seconds should typically be amortized over a long time.3. Treat Hyperbole as part if the Emacs env. You can make it part of the pre-dumped Emacs if you like.On May 18, 2024, at 12:06 PM, Alexis Purslane ***@***.***> wrote:
@rswgnu
Reading through this thread, I think I might have a different perspective to offer on this discussion than what's been said so far, in case it's helpful.
In my case, hyperbole being a single package is a hindrance to my adoption not because I am overwhelmed by the number of features or capabilities, since as you say I can simply ignore them if I don't know how to use them yet, but for the simple fact that, since it is all bundled in one gigantic package, it takes a very long time to load. Hyperbole alone takes 1.5 seconds to load one added to my Emax config, whereas the entire rest of my Emax config, which is some 63 packages, some of them very large and extensive, takes less than half of that amount of time, at 0.65 seconds. I know hyperbole gives a breathtaking amount of functionality in return, but that's still an extremely heavy price to pay. It makes Emacs slower to start for me then Visual Studio Code.
If hyperbole was maybe separated into two or three packages, it would make it a lot better. However, I do understand why you are hesitant to do that, since multiple separate packages is more complexity to document and maintain.
I think the compromise solution might be, as you briefly mentioned somewhere in the middle of this thread, bringing back autoloading? That way you don't have to pay for the full night of hyperbole up front when your editor starts or the first time you run a hyperbole command, and all of the features that my overwhelm people aren't necessarily there from the start.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Thanks for responding! Apologies for all my grammatical errors by the way, I'm using voice dictation and it's a bit hard to get it to cooperate sometimes.
That's true — that's my current plan, why this isn't a totally pressing issue for me. However, more granular control would also be very nice. I understand if that's too much work to be worth it though! You are doing all this for free, after all 😄
Fair enough! I personally treat Emacs more like an editor than an IDE, but if that's not the use case Hyperbole has in mind, I understand.
I'll look into this! |
|
Sounds good. Additionally, if you can find anywhere that hyperbole subsystems are being loaded when they are not being used such as HyRolo or the Koutliner. please identify these will work to eliminate them.-- rswOn May 18, 2024, at 12:28 PM, Alexis Purslane ***@***.***> wrote:
Thanks for responding! Apologies for all my grammatical errors by the way, I'm using voice dictation and it's a bit hard to get it to cooperate sometimes.
You can try use-package with the :defer keyword
That's true — that's my current plan, why this isn't a totally pressing issue for me. However, more granular control would also be very nice. I understand if that's too much work to be worth it though! You are doing all this for free, after all 😄
We expect people to rarely restart Emacs, so that 1.5 seconds should typically be amortized over a long time.
Fair enough! I personally treat Emacs more like an editor than an IDE, but if that's not the use case Hyperbole has in mind, I understand.
Treat Hyperbole as part if the Emacs env. You can make it part of the pre-dumped Emacs if you like.
I'll look into this!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Will do! |
Hello and, first of all, thank you for your work! It's amazing!
Maybe I'm just not the target for Hyperbole, or maybe it's just too much work and nobody getting paid to do it (completely understandable), but I would like to refresh the discussion around splitting Hyperbole into many packages.
I for once would love to use Koutlines and nothing else for some time. it's an amazing tool in its own right. Klinks are magical, and I would surely like to dedicate time to master its ways and incorporate its powers into my workflow. I know it would be great (the idea is brilliant), but I don't have the time right now so maybe this is something I would have to leave to a holiday or something. The other parts don't really interest me right now, but I'm sure they have the potential to.
I have tried Hyperbole many times already, and have a few
kotlfiles hanging around, but every single time, a short time after I get amazed positively, I just to end up removing it because it changes oh so many things (it's very opinionated, which I don't think is bad per se, but adds a lot of pressure). Its much more functionality than I can handle learning at once. And I can't focus on the whole thing at a time.Maybe, if someone is beginning a new Emacs configuration from scratch and picks it up straight away, this wouldn't be the case. But realistically, how many are still entering Emacs this way? I can only conjecture, but as far as I see, most people at least start through a pre-built configuration that, if you install Hyperbole on top, will break in unexpected ways.
The way I see it, it is clear that this is a bundle of many packages with related but disparate functionalities, and that releasing those packages separately would, I believe, increase adoption of some tools that are being hindered by other, less understood ones. Maybe this would attract new contributors to the project, give it a fresh air, and allow some of it to be easily integrated into many Emacs workflows. Allow it the glory it deserves :)
It's not only me. Every single time I try to introduce someone to the niceties of Hyperbole, they also get overwhelmed and just run away or never even try it. Especially because they don't think they need it! We have a powerful outline tool, ways of managing contacts, ways of dealing with the frame (tiling window managers for example) and the windows. We even have excellent packages that gives us on the fly overview of key-bindings available under
C-c,C-x,M-s,C-h, etc. The Emacs landscape has changed a lot. Why should one install a bundle on top of all they have (and that works) and be forced to deal with the way others idealized the whole Emacs experience? In this busy world, it's unfortunately harsh.I know this is an old topic and I hope that I'm not offending you by bringing this up again, but since the package is now available here on Github, others may come looking for answers on the subject. My hope is to better understand the reasoning behind the bundle and, if possible, to constructively think of ways to lower the barrier of entry.
Again, thank you!
The text was updated successfully, but these errors were encountered: