rswgnu
Refresh the talk on spliting Hyperbole into many packages
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 kotl files 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!
On Feb 14, 2019, at 12:18 AM, Felipe Barros [email protected] 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
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.
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.
The other parts don't really interest me right now, but I'm sure they have the potential to.
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.
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).
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.
Its much more functionality than I can handle learning at once. And I can't focus on the whole thing at a time.
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.
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.
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.
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.
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 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 :)
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.
It's not only me.
I agree. These issues are worth exploring.
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!
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.
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.
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.
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.
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.
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.
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 currently using a package called Deft to organize some notes and files and it's great but reading about Hyperbole I think that Hyperbole can either be enough for me, or be used to power up Deft just like it can power up Org.
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?
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.
I can see how this can be a problem, although might not to be the case as well. As a new user, something that it's really confusing honestly is the subsystems. I can see how it's hard for people to understand the package. Like I've said, the DEMO is way better, but even then it's... confuse.
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?
So why do they feel they don't need it? Is the demo inadequate?
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! (...) Wait, why we're stopped talking about Smart Keys (core function) and Koutlines (information management system related, then kinda of a core function) to talk about... Window management?"
Can anyone provide specific, individual issues that may impede adoption and proposed solutions? Can you give examples of how your workflow is interrupted by things that you don't intend to use?
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.
E.g. I think that M-RET is a very good decision, but why C-u M-RET for the Assist Key? Why not, say... C-RET?
In Koutline C-q TAB for a regular tab sounded kind of random, but maybe it's not.
C-j create a cell, cool. C-u C-j sounded strange, C-c a sounded way better...
I have this impression that keybindings could take advantage of mnemonics. So C-c sounds like a good "Control cell".
"Control cell add" sounds good as C-c a, make it easy to remember that it will add a child cell.
But where did C-j come from? It have relation to j in Vi/Evil meaning "down"? That's why C-j open a new cell below?
Why not C-c n (Control cell new) or at least C-c j instead of just C-j?
Just because in the same paragraph we're already using three patterns for supposedly related commands, a pure C like in C-j, then C-c and C-u C. It's kinda confuse because sounds very random and unrelated keybindings.
Sorry if my thoughts doesn't make much sense. I'm just sharing it so maybe it can contribute in some way if it's not just me...
For some reason kimport and kexport isn't working, like C-x i. But I think I can open another issue for this later.
Something that bothered me a little is that pressing TAB in the DEMO will always return me to line 2 (the Hyperbole logo).
Maybe this is something related to help-mode, but I thought it would be cool if TAB just jump for the next "button" like it behave with widgets in widget-forward. I think it bothered me because in my mind the "hyperbole buttons" sounds a "widgets made simple", so I was expecting it to behave like widgets. Of course it's not a Hyperbole problem, but just thought it might be something helpful to have at least in the DEMO... I'm reading the DEMO, instead of having to move the cursor to press the button to continue the learning I could just hit TAB and jump to it.
I can see how a user could benefit from it as well in a document, I have a lot of links/buttons? Cool, I will hit some Tabs and now I'm in the button I want. Way better than C-n, C-f, arrows/mouse around a lot for reach buttons.
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 M-RET, I need to be in the beginning of it or in the middle/inside the text. Maybe can be a bad idea for some reason to detect the button in the end of the word, but it's a little annoying that you're supposedly "right next" the button but have to move the cursor one position back to be able to activate the button.
I would like to say that I would be very happy to contribute as I can if in the future the project unbundle things. But well, a no is a no, if the team don't think that unbundle it's a good idea despite repeated feedback about the monolithic approach, well, it's ok. I would just advise for avoiding dismissing the same feedback over and over again as people might just give up the package as it already seems to be the case. Like I've said, every time it got promoted sounded like the team didn't wanted or care about more people using it by the way some answers were given and (recurrent) feedbacks dismissed.
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. I wish 2021 to be a beautiful year, and maybe it will be the year of Hyperbole as well. :)
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.
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.
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.