One under appreciated aspect about nobs is sweeping through a range of units for a set of functions quickly. Making the nobs pluggable is still hugely important for the same reason you mentioned here. I think a decent example of this idea done pretty well is modern MIDI controllers and Digital Audio Workstations. They let you wire physical knobs to control arbitrary functions in the software. There are a lot of software and hardware tasks that I think would benefit from this same approach. Especially when dealing with graphics and visualizations. But even congrolling parameters in your hardware might make sense. Right now I only see it commonly used to control audio volume.
Yet another best-in-class video! PS: some viewers (especially, I assume, skeptics), might appreciate a link to the code at 00:25; it is unreadable after zooming in on a full hd screenshot of the frame, unfortunately.
github.com/positron-solutions/dslide/blob/master/dslide.el#L2802-L2938 github.com/positron-solutions/dslide/blob/master/dslide.el#L2137-L2139 In the first case you check a bunch of stuff and the implementation has to be able to handle any arrangement of the options. In the second case, you could write your own version of the first but with zero customize variables and just have it your way entirely. It will be about 25% of the original code and if you want something crazy, 30%. The image action is also like this. It has so many little warts that piled up from supporting different use models. Being configurable can save time when those options are really common, but it can grind development to a halt. Spacemacs struggles from time to time with the abstract configuration layers.
Good day! Thank you for sharing this video. Interesting perspective. However, it seems to me that you have assumed that viewers already understand the problem that Emacs is trying to solve, and frankly, that may not be the case. The video suggests to me that the target viewer is expected to be someone who is already struggling with the issue of a rigid, intractable interface, or perhaps I am misunderstanding your message ... ? In my somewhat limited experience, most people don't even imagine any other computer experience or interaction is conceivable, far less programmable. They certainly don't expect that they themselves can program it. Rather, they are content to work within a rigid interface. (I personally find the Apple MacIntosh desktop stifling, for example, but others love it) So, Emacs, with its almost mystical learning curve, simply does not register for them. I confess that I have only taken an interest in Emacs this year, starting in December 2023. While I find it fascinating and am using it on a daily basis now, that learning curve is daunting. I know I will eventually get to a point of being comfortable with Emacs, and possibly even with elisp, but it is a slow and gradual process. I consider myself fairly competent with computers, having started back in the 1980s, with 8 bit computers, and I've used many operating systems, taught myself C programming, database management, networking and PBXs, learning from books and the internet, so the idea that Emacs is proving to be a challenge to me, even though I see its potential, suggests, to me, that for most people, this mountain is just too hard to climb. That is where Emacs's problem lies, in climbing that mountain. And seriously, there is no gentle ascent to the top. It _is_ a struggle.
It's a matter of audience. While obviously the Taliban could be watching this right now, the likely and intended audience is people deciding on a coding environment. The default assumption might be to use software based on what it does out of the box and then try to fix it up with knobs and checkboxes. The argument made here is that knobs and checkboxes always fall short and that IDEs made for one era of technology are always left behind. Only the programmable tools truly have staying power, and that will be more true, not less true, in the AI era.
@@Positron-gv7do Not sure what the Taliban have to do with computer interfaces. Though I'm sure they would bring an unique perspective to the discussion of computer interfaces, and I would be interested to hear it. Having been through several generations of computers/operating systems/languages/databases/networks, I am fully aware of the limitations of the various interfaces I've encountered over the decades. The OS/400 interface was particularly interesting as an alternative to the UNIX command line, for example, in giving the user access both to the elements of the environment AND to the ability to program that environment. Both operating systems are powerful in their own way, both trying to solve different problems. In my exploration of Emacs, I was struck by how Microsoft Excel seems to have "borrowed" several concepts from Emacs. Excel uses worksheets instead of buffers, but include both built-in functions and an embedded programming language. Excel even allows the interface to be modified by scripts. I'm not an Excel fan myself. I loathe spreadsheets but I recognise that, for many people, Excel is their primary working environment. Many people load Excel in the morning and stay in it all day. For many people, Excel is much more approachable than Emacs. Perhaps that is simply due to market propaganda, since as just as many people use Excel without any understanding of its full potential as well. I do recognise that Emacs is likely to be around forever. There will always be people looking for more flexible environments, but sometimes such "open-endness" can be a limitation in itself. The mind balks at too much complexity. Unless you have discovered a path to understanding Emacs that you wish to share (perhaps in a less breathless manner :) ... ? Thank you for taking the time to reply to my comment.
One under appreciated aspect about nobs is sweeping through a range of units for a set of functions quickly.
Making the nobs pluggable is still hugely important for the same reason you mentioned here.
I think a decent example of this idea done pretty well is modern MIDI controllers and Digital Audio Workstations. They let you wire physical knobs to control arbitrary functions in the software.
There are a lot of software and hardware tasks that I think would benefit from this same approach. Especially when dealing with graphics and visualizations.
But even congrolling parameters in your hardware might make sense.
Right now I only see it commonly used to control audio volume.
You hit the nail on the head OP, well done!
Offtopic: I thought I was done configuring my Emacs config for the year. Drop your dots OP!
Fully agree and you conveyed your point in a very sophisticated way!
Yet another best-in-class video!
PS: some viewers (especially, I assume, skeptics), might appreciate a link to the code at 00:25; it is unreadable after zooming in on a full hd screenshot of the frame, unfortunately.
github.com/positron-solutions/dslide/blob/master/dslide.el#L2802-L2938
github.com/positron-solutions/dslide/blob/master/dslide.el#L2137-L2139
In the first case you check a bunch of stuff and the implementation has to be able to handle any arrangement of the options. In the second case, you could write your own version of the first but with zero customize variables and just have it your way entirely. It will be about 25% of the original code and if you want something crazy, 30%.
The image action is also like this. It has so many little warts that piled up from supporting different use models. Being configurable can save time when those options are really common, but it can grind development to a halt. Spacemacs struggles from time to time with the abstract configuration layers.
Good day!
Thank you for sharing this video. Interesting perspective.
However, it seems to me that you have assumed that viewers already understand the problem that Emacs is trying to solve, and frankly, that may not be the case.
The video suggests to me that the target viewer is expected to be someone who is already struggling with the issue of a rigid, intractable interface, or perhaps I am misunderstanding your message ... ?
In my somewhat limited experience, most people don't even imagine any other computer experience or interaction is conceivable, far less programmable. They certainly don't expect that they themselves can program it.
Rather, they are content to work within a rigid interface. (I personally find the Apple MacIntosh desktop stifling, for example, but others love it)
So, Emacs, with its almost mystical learning curve, simply does not register for them.
I confess that I have only taken an interest in Emacs this year, starting in December 2023.
While I find it fascinating and am using it on a daily basis now, that learning curve is daunting.
I know I will eventually get to a point of being comfortable with Emacs, and possibly even with elisp, but it is a slow and gradual process.
I consider myself fairly competent with computers, having started back in the 1980s, with 8 bit computers, and I've used many operating systems, taught myself C programming, database management, networking and PBXs, learning from books and the internet, so the idea that Emacs is proving to be a challenge to me, even though I see its potential, suggests, to me, that for most people, this mountain is just too hard to climb.
That is where Emacs's problem lies, in climbing that mountain.
And seriously, there is no gentle ascent to the top. It _is_ a struggle.
It's a matter of audience. While obviously the Taliban could be watching this right now, the likely and intended audience is people deciding on a coding environment. The default assumption might be to use software based on what it does out of the box and then try to fix it up with knobs and checkboxes. The argument made here is that knobs and checkboxes always fall short and that IDEs made for one era of technology are always left behind. Only the programmable tools truly have staying power, and that will be more true, not less true, in the AI era.
@@Positron-gv7do Not sure what the Taliban have to do with computer interfaces.
Though I'm sure they would bring an unique perspective to the discussion of computer interfaces, and I would be interested to hear it.
Having been through several generations of computers/operating systems/languages/databases/networks, I am fully aware of the limitations of the various interfaces I've encountered over the decades.
The OS/400 interface was particularly interesting as an alternative to the UNIX command line, for example, in giving the user access both to the elements of the environment AND to the ability to program that environment. Both operating systems are powerful in their own way, both trying to solve different problems.
In my exploration of Emacs, I was struck by how Microsoft Excel seems to have "borrowed" several concepts from Emacs. Excel uses worksheets instead of buffers, but include both built-in functions and an embedded programming language. Excel even allows the interface to be modified by scripts.
I'm not an Excel fan myself. I loathe spreadsheets but I recognise that, for many people, Excel is their primary working environment. Many people load Excel in the morning and stay in it all day.
For many people, Excel is much more approachable than Emacs. Perhaps that is simply due to market propaganda, since as just as many people use Excel without any understanding of its full potential as well.
I do recognise that Emacs is likely to be around forever. There will always be people looking for more flexible environments, but sometimes such "open-endness" can be a limitation in itself. The mind balks at too much complexity.
Unless you have discovered a path to understanding Emacs that you wish to share (perhaps in a less breathless manner :) ... ?
Thank you for taking the time to reply to my comment.