Nyxt: The Hacker's Browser
nyxt.atlas.engineer
nyxt.atlas.engineer
I've never thought about it until I saw this! Now I'm really irked about there not being a solid, mature browser based on extensibility. Where the base is basically an address bar and history awareness (i.e. back/forward) and even bookmarks is a module, so that you don't even need an integrated solution but can instead rely on e.g. Raindrop.io as your bookmarks manager. Tab management another one, so for example you could have _only_ a powerful vertical tabs mode if that's all you need.
You know what, it feels like this should have happened 20 years ago and it would be as popular as Vim or Emacs now, but somehow never actually did. It would be the ultimate response to Chrome, Edge, even Firefox feature creep, forcing its developer to commit fully to web renderer excellence (speed, RAM, web standards) and maybe some optional official modules if you want them.
Curious about your roadmap with dosyago and BrowserBox, where our goals converge and diverge and how we can help each other. Feel free to reach out via email, it's in my bio.
Here's some other projects you might have inspo or crossover with and some discussions you might find possible collaborators in:
Bonsai https://news.ycombinator.com/item?id=28446147
Mullvad Browser (security oriented FireFox-based) https://mullvad.net/en/browser
Browsh (purely text-based browser) https://news.ycombinator.com/item?id=17487552
Ladybird (browser from scratch for SerenityOS)
Kosmonaut (browser from scratch in Rust) https://news.ycombinator.com/item?id=24170201
Refresh (concepts for a new kind of web browser) https://news.ycombinator.com/item?id=17638477
Really though? Why
While it may not be as technically elegant as using lisp, it greatly increases the count of folks who can contribute and simplifies the code with a single language for both front and back.
Secondly, while, in general terms, JavaScript is not as performant as Java or C++, for asynchronous real time operations, such as mostly used by this application, the event loop in node, a layer over io_uring, is a highly highly efficient method to perform these.
In other words, we get to trade simplicity for raw performance to ease maintainability, and less complex code means less security risk and bugs. In fact, the bottleneck in this application for performance is not JavaScript but network link latency, and the browser and the hardware that runs on.
Honestly it was incredibly cool but websites just get more and more complicated. From like 2004 to maybe 2014-2016 it was great. Somewhere after that, I'm not sure, something changed, maybe me, but it just became too much.
Some recent HN comments of mine:
https://news.ycombinator.com/item?id=34855750
https://news.ycombinator.com/item?id=33541173
I am 100% down for building this, open source, if I had a team to help me see it through as it's just too much for one person.
Do you have any dev experience / interest in helping create such a thing?
I love projects like nyxt and respect their priorities, but without big-player extension support it's usually a no-go for me. Still, I'll be interested to see the ideas they develop trickle out into the rest of the power-browser ecosystem. I especially like that lossless tree history – history management is a very under-explored UX area IMO
Mozilla believes that it creates a security risk and that you shouldn't do it.
[1]: https://www.ghacks.net/2017/10/27/how-to-enable-firefox-webe...
If you guys are really into the idea of an extendable virtualized browser API, an extendable browser that you can hack on, and customize programmatically fully (including all the browser UI, the so-called “chrome”), then my BrowserBox project might be for you.^0^1^2
That open extendable browser is actually my vision of BrowserBox and I think it’s a really powerful thing. For example: I imagine being able to create an "extension store" using the more powerful set of APIs enabled by this (compared to the more limited APIs available to regular browser extensions). Similar to the idea you related where bookmarks is a module--which is something we've wanted to do for a long time--but not sure about the API contours!
The other ideas you talk about are all great, too: a UI that can be fully customized (vertical tabs!) or even tree tabs / history. Or all kinds of crazy things. Browser UIs are pretty uninnovative mostly, but a fully customizable UI could really open that up.
Modules ideas (that in some sense we've been exploring at Dosyago over the last few years, through DiskerNet, client projects, GraderJS and so on):
- web scraping / automation script builder
- vim shell
- vertical tabs UI
- bookmarks
- public / shared bookmarks
- full text searchable bookmarks (DiskerNet)
- NodeJS shell (GraderJS)
And I think BrowserBox may have the right model for that extensibility (maybe not totally right but the idea of: instead of using a WebView tag you’re using the much more extensible and powerful set of APIs for browser instrumentation and automation in other words, the "remote debugging protocol" APIs) to create the surface of extensibility. And our company has already built the the application with the browser UI at the front, and the instrumented browser engine at back to enable that building out an API. Our system is already a fully functional browser: with multiple tabs, back/forward history, but no other modules!
The main modules we have built so far have been: web scraping / automation script building for clients. We've experimented with other modules, but the majority of the work we need to do is around carving out the contours of that API. What surface do we provide in order to make modules really great? That's the key question and one we are looking for help answering.
Having that API for the browser to allow like a modules type thing is something that’s been on our plans for a long amount of time we always thought it was a good idea, but we’ve never been sure if there was much demand for it. Like you say here this Nyxt project really highlights the fact that this is something that really is a good idea or at least it seems like it and definitely people seem like they want it. There's still a lot of problems with this approach, but I believe they all have achievable solutions!
While our project may not be as technically elegant as using lisp, but I think it has the prosaic advantage of: having a simple client/server architecture (browser UI at the front, instrumented engine at the back); using a highly extensible set of powerful API‘s that are on essentially standard track with the WebDriver specifications (making, at least in theory, the future ability to swap out the browser engine between Chrome, Firefox, Safari, or whatever else that supports WebDriver); and I think most importantly--it’s written in JavaScript, Node.JS, HTML, CSS--greatly widening the field of potential contributors
I’m encouraged today by this project and the thread you have started to push our BrowserBox project more in this direction and I would like to encourage people to come on and check it out and because of that we are opening up our projects today to contributions. I think there's a lot of work to do and we can't do it alone!
0: https://github.com/dosyago/BrowserBox
Today I'm more interestea in turning the web into a more textual format to integrate it in acme (http://acme.cat-v.org/) which is already built around modularity. Making the web a content provider and letting me interact withit the way I want
I mean even in Editor/IDE-Space the popular tools are not the ones who give you the most customizability, but those who give you enough customizing, while not bothering you with the rest, and instead focusing on stable powerful features. Maybe if Coding AI becomes stronger, we can reach this utopia of perfect customizability without all the problems.
Sorry folks, but it turns out that the creators of Vi(m) didn't actually invent the ultimate UI paradigm half a century ago. It's bad enough that a text editor that ignores the past few decades of UX research is still in widespread use, but please, for the love of God, stop incorporating that broken paradigm into new products.
What a pity, because Nyxt looks like a well-designed piece of software otherwise.
Besides, the whole point of Vim bindings is supposed to be that they are the same everywhere (muscle memory yadda yadda yadda). When you have to change core bindings to something random to make them work, that whole idea falls apart, and you're probably better off using the platform standard bindings for everything. Plus, you get the additional benefit that the software fits in with the rest of the system, rather than sticking out like a sore thumb.
I don't think that adage applies when the target user is the average VIM user
Vim is a nugget of battle-tested familiarity in an industry of constant change.
The few settings I find really important can just be quickly set with a couple commands. No big deal.
git clone https://github.com/MY_USERNAME/vim.git
You don’t hear the Arabic, Chinese or Greek crowds complain about this, they just switch layouts.
No, the point is customizability to tweak it to your personal needs. Vim has the most flexible keybinding system I've seen in a program so far. If you want "same everywhere" any editor will do. I have never in my life seen anyone make this argument that one of the most customizeable editors is meant to be used without configuration.
> you're probably better off using the platform standard bindings for everything
Or maybe I use Vim exactly because it fits my workflow better than the standard that was designed for the average user as a series of historical accidents?
> When a product is unusable without changing configuration, it absolutely is a bug
It's not a bug, it's a design based on how 99% of input devices in the region it was created in work. Just like US electrical appliances that you can't just plug into European power sockets. And honestly you're blowing this way out of proportion, very few Vim keybindings are incompatible with QWERTZ keyboards. I know because I used Vim for years with a QWERTZ keyboard and never felt limited by that.
No, the whole point of ViM bindings is that MY bindings are the same everywhere. That's why it's main config is a simple textfile that I can just `git clone` or `sftp` onto whatever machine I intend to spend more than a few seconds writing code on.
Which, incidentially, is something that is an absolute PITA, if it's possible at all with the more "modern" editors, or on the off chance it isn't a PITA, usually depends on some specific platforms offerings.
> Plus, you get the additional benefit that the software fits in with the rest of the system, rather than sticking out like a sore thumb.
Well, from my PoV, what with i3 desktop, vim in the terminal, and the browser being the only GUI application that I use regularly, vim seems to fit in pretty well with everything else.
So something completely unattainable by a small dev team on a startup budget. Great! These are the standards by which we prevent any good things from being created.
Here's the most important one of them: Don't surprise me. Blend in. Look and behave like other programs.
There are 50 applications on my system. Yours is one of them. If all other applications use 'Ctrl+C' for copying text, but your application uses 'y', then your application is the problem.
And something innovative and effective would be both self explanatory and actually useful, so it ultimately gets adopted by others instead of simply surprising and confusing people
I don’t know about 50 applications. The rest of the applications I use are more specialized, and have their own shortcut madness. Browsers ate most of the small stuff.
Trying to objectively describe vim as a problem by invoking UX research is very funny.
The end result of that logic is to rule out modal editors altogether.
In the context of the command line Ctrl+C sends SIGINT, which usually interrupts/terminates a program. When I press Ctrl+C, vim shows "Type :qa and press <Enter> to exit Vim". All my command line programs handle it as SIGINT. Imposing Ctrl+C as copy would be inconsistent and surprising.
If I'm using Visual Studio with vim keybindings Ctrl+C/Ctrl+V are still copy/paste (I suspect this is because VS provides this and the keybindings don't override it). I think every other editor with vim keybindings I've used preserves this behavior. Ctrl-C as copy is consistent with every other windowed program I'm running. Where have you encountered vim keybindings that don't permit this?
There is hardly anything in the world that blends in better with everythign else, then a terminal application between other terminal applications.
How's this a "research"? It's just about you, your attitude, your lack of experience with computers...
Why should anyone take seriously claims coming from someone who didn't even bother to learn to use the thing they claim to have bad user experience?
Imagine if those precious keystrokes wasted on setting a keyboard layout could instead be utilized usefully. Say, to post some cloying, whiny critique of someone else's work, wherein one might go so far as invoking their diety in the hopes it might stem the tide of what, I guess, must be a massive recent influx of vi(m)-keybinding-based projects.
Not necessarily, since it’d just be a matter of popularizing Vim + the community’s preferred shortcuts as a starter instead.
> in general hackers hate when their tools don't work out of the box
Indeed we do. However, we don’t give up on something if it doesn’t work. We simply hack at it until it works how we want ;)
There isn't that many software dev tools were a small variation in key bindings (or some similar small change) became ubiquious and propelled the popularity by adapting it to the local needs of American developers/IT (keyboard layout in this case), it's a chicken and egg problem because if Vim wasn't that popular there wouldn't be much interest in creation preferred shortcuts, so I conclude that what you suggested is not what would have happened.
Actually, you probably understand that on a deeper level. Since we are not talking about a product where "you can configure vim bindings in the settings". Its just that you personally appear to like this default and seem offended by others preferring sth else.
Using ViM as an example, using the keys that are prevalent on a US keyboard, was a sensible approach when it was developed, and since remapping the keys is probably one of the easiest things to do, it's also not an issue. In fact, writing a simple remap into a text file is easier than remapping keys in most "modern" editors, where the option to do so usually lives behind 2 sub-menus hidden behind a hamburger-button, and forcing me to scroll down an endless list that may or may not have a search function. And good luck if I want to export/import my config, or, god forbid, check it into a repo.
> But defaults matter, if you target anyone else.
Products have to target an audience and cater to them. That's how we ended up with alot of the modern webapps sharing the same usability problems, because "being like everyone else because that's what the audience is familiar with" encourages stagnancy, not evolution.
FOSS Tools on the other hand, have the freedom to explore ideas. If people don't like these ideas, they don't have to use the tools.
I use multi-language keyboard layouts and switch all the time... when coding (or using "hacker" software like this, which is completely based on emacs [and as far as I know is written in Common Lisp], not vim), just use a layout that makes it easier (in my case, en-AU).
But this doesn't work in shortcuts, e.g. when combined with Ctrl. That is, AltGr+8 generates the character '[', but Ctrl+AltGr+8 is not the same as pressing Ctrl+[ on keyboards that have a dedicated [ key.
This bug is decades old, and every Vim derivative suffers from it.
EDIT: the Dr Racket editor even lets you write Lisp using '[' and ']' because they don't require pressing shift like '(' and ')' so are easier to press.
If so, I'll try and remember that if ever tempted to use Ctrl and {[]} together I need to handle that as well.
I've been programmer for about 20 years now and I could never understand why Vi(m) or Emacs exists with those weird bindings which are completely different from pretty much everything else.
I'm not that old, maybe they had their cake in 80s, but perhaps time to move on to something modern which would have modern defaults (if many need to customize there's something wrong with the defaults) that appeal to all keyboards.
Inertia, traditionalism, elitism, insider culture, ignorance, "good enough" mentality, blind spots, cargo culting, ...
There's really no mystery here. The reasons are the same as in every other part of society where outdated conventions are maintained despite massive, obvious problems. The phenomenon itself is as predictable as the arguments used by its defenders, mostly variations of "it works for me".
First of all, vi predates all those others. That means it's always had an active userbase werken other tools were in fashion. Changing the bindings at any point in time would have hurt a lot of people's muscle memory. It would also be extremely annoying when one has older versions on some machines with the old bindings and some with the new. I deal with the Mac vs Windows/Linux copy paste problem every day.
Also, vim just has a ton of functions and there's always going to be some shortcuts that will be awkward on some or other keyboard layout.
Finally, you don't have to use it :) or you could distribute your custom config file with bindings to every machine you use.
I was basically forced into learning vi to begin with (editing things on a -very- heterogenous collection of servers) but then found after a few weeks that I found it surprisingly pleasant and stuck with it.
Then again I don't recall sending a vi instance anything involving the control key except for Ctrl-C, Ctrl-L and Ctrl-Z.
> massive, obvious problems
It’s not problems, it’s opportunities you’re missing, because you don’t understand and aggressively don’t want to understand the actual reasons why people are using it, whining about elitism and other bullshit instead.
Though it might not work - the original Mac user research found that keyboards make users think they're faster, but don't actually make them faster, because of time blindness.
I doubt there's any hope for you... but from other thing you said:
> are completely different from pretty much everything else.
I can conclude that you were programming something that's not a typical modern computer. I.e. you never used things like terminal (with readline), never red a manpage, never used pagers like more / less, which would mean that you also never used the most popular operating system in the world, where, for instance, if you need to get access to its service logs, they'd open in a pager...
I mean... was it like 20 years of Scratch programming on a game console or something? Or maybe COBOL on a MF? Like, what were you doing all these 20 years that kept you so far away from the most popular thing in the world?
Yup, I'm pretty much working with terminal everyday, though nowadays most popular thing seems to be Vscode.
Maybe you should modernize yourself instead of attacking people with a childish level of humiliation.
Also, was looking at JS/TS back in the days when I had to migrate away from AS.
> Yup, I'm pretty much working with terminal everyday,
Doing something every day doesn't mean you do it well. Apparently, in your case, you don't. Readline interface to the terminal uses the same keybindings as vanilla Emacs. You just somehow don't know it. Kind of weird, as there are hardly any keybindings to learn, and yet.
> most popular thing seems to be Vscode.
VSCode is, well, junk. And so is Linux! Popular doesn't mean it's good. In programming, it's actually rare when it's both. And people like you and me have contributed to this being the case.
You see, the difference between you and me was the stupid chance. When FlashDevelop was considering Linux support, they didn't have a good program about what to do with their text editing component (Scintilla) that was festered with p-invokes. So, in a very ambitious project I wanted to replace that component with Vim. That proved to be absurdly hard... and I quickly gave up any hope of that happening. But, I learned few things about Linux that, later, made me switch.
My first editor on Linux was Eclipse. I still used it on and off for a long time due to Flex Builder, and later Flash Builder. It sucked, especially because Adobe's support sucked, and eventually, they cut it off entirely. I was still patching the last version of Eclipse to get Flash Builder running, but, eventually, that became irrelevant.
Somewhat in parallel and increasingly more often, once I started working mostly on Linux, I switched to Vim. Ironically, because I wanted to work with Common Lisp, which is another hilarious misunderstanding story. After trying it several times and giving up, eventually, I switched to Emacs.
In my professional life, I was at that time hired by HP to work on some sort of a SAP knock-off that had its interface written in Flex. By the time the project was due, they declared to the customer they won't support Flex anymore, and switched to GWT (the Java framework that generated JavaScript). I didn't make it into the group of developers who were assigned to continue that project, however, somehow, I got reassigned to the ops team.
HP had a corporate IntelliJ license, and made use of IntelliJ products mandatory at work. My job in the ops team was to navigate the cubicles of desperate Java dummies hired into this mindless grind of Java/XML and "fix" their Maven builds. Usually, the fixing amounted to explaining to them for the zillions time the basics of using their editor -- the fabled IntelliJ IDEA. It was ridiculous how unproductive these people were with that monster of an editor. Ironically, quite a few of them would also use Notepad++ as a side hustle. But they sucked at that too.
Later on, I switched to supporting MSBuild projects in a different company, and had to battle the unimaginable stupidity of its MSVS users, who couldn't understand how their editor worked, and didn't care. It was a game shop that made games for "smart" TV, and they actually wrote them in TS.
I've seen editors like Atom or VSCode come and go. And I've seen quite a few users of those too. It's a choice for people who don't have or don't value the skill of using their editor. These people are in constant fear of the tools they use, constant anxiety about the next Git command they are going to type and how this will "ruin their day", people who don't know how to open a file without extension...
I don't work with such people anymore. Not in my day job at least. Though my wife, she has to deal with this kind of audience. And, sometimes, she has to call me to fix the problems these people create for themselves.
But, you know what served me faithfully through the years, no matter the language I used, no matter the platform, no matter how modern or archaic, no matter if in the cloud, in a crippled unter-computer, or in HPC setting, no matter if having X-server? -- And, always with great performance, and always keeping few tricks up its sleeve? -- That's right, Emacs. VSCode is so pathetically bad compared to it, it's ridiculous to even think that someone may suggest it as a hacker's tool. It's a toy "doctor set" from AliExpress in the real surgery room. Good for giggles, but that's about it.
So, back to how we contribute to the awful state of affairs in programming: we don't create a system of values based on research. We proclaim that thing X is better than Y. And sometimes also give rationalization that is complete nonsense. While we might have real experts, those aren't found in the places they should be: academia failed us -- their titles are worthless. Industry failed us -- it doesn't need quality, it ranks software success by commercial success. People like me and you may stay in the industry for decades and end up complete noobs. With the added aspect that after a long time of being a noob, even if nothing really changed the noobs start to believe themselves to be pros. And then they take to teaching others.
We belong to the wave of programmers which wiped the little accomplishment that there was there in the 70's and flooded the field with ridiculous unga-bunga nonsense that we sell as "programming". We are the lords of the flies.
I'm not using it anymore myself, but I know and respect people who do. For me the tradeoff was not worth it, however it still annoys me to hell and back that I have to reach for the mouse so often in vscode.
I develop mostly mobile apps and I need to be using mouse/trackpad anyway frequently so that's not an issue.
Though about the keyboard part: I'm used to Vscode's keyboard shortcuts too (and I can in no way say I know all of it) and I can easily navigate and code in Vscode too.
Perhaps many people who got used to those tools developed muscle memory so much that they can't give Vscode (or anything modern) the chance it deserves.
That's an oversight of Nyxt in particular.
Cue endless debates about how Vim is the best ever ...... I'm sick and tired of everyone telling me that their neovim setup with a tiling window manager with million customized rc files is somehow better than vscode with a mouse (which mind you still has plenty of keyboard shortcuts) with sane windows. /rant
The only thing that emulates vi well enough is Evil in Emacs.
Most of us think "we like it, some people don't, great if it's an option, probably shouldn't be the only option anywhere else."
The one-upmanship (over VSCode in your case but all editor wars get a dishonourable mention) is bullshit but, like, random strangers on the internet tell people with crippling depression "hey, you should do <thing>, it fixed -my- depression" so I think you have to just accept that "when something works really well for a human, sometimes they get overexcited and start trying to turn the something into a silver bullet that it isn't" is something that will always happen.
Note: The people doing the arseholish one-upmanship are not in any way forgiven by this, and the "everyone telling you" that you describe would aggravate me as well, but as with the Rust Evangelism Strike Force, you just have to nod and smile (and sometimes point and laugh) at the zealots and look at the technology for yourself.
Note 2: I use the original 1970 Bill Joy vi. Other people I know use VSCode. 'better' is relative, and what works best for any given person/project varies wildly - everything before this note is about the dynamics of people discussing such choices.
One might even argue that it's terrible for some other keyboard shortcuts, as they stop making sense: E.g., when Ctrl+Z is undo and Ctrl+X is redo, that makes perfect sense on QWERTY, but is hard to grasp on QWERTZ. Yet this is seemingly never customized/"translated", even in software that customizes other shortcuts (e.g., in word processing).
So, long story short, do yourselves a favor and don't use QWERTZ for serious computer use ;-)
Other ways to accomplish this would be coming up with macros or custom shortcuts (e.g., with one or more modifiers), to type the characters you don't have on an UK layout.
All of this is way easier to do than to fix all the 'bugs' in well established programs that have shortcuts that don't work or don't make sense on QWERTZ (or, to take it further, in the native language attached to that language - :wq should be :sb in German. ;-) )
My intention here was not to gatekeep, but to make the case/share my experience that when I first forced myself to use a different (UK [1]) keyboard layout and set my computer to English, many things that previously were cumbersome and hard to remember and did not really make sense, suddenly were easy to memorize and made perfect sense. It was almost life-changing!
Now: Should (1) it be this way, or should (2) internationalization/translation be way better? Certainly (2), but I just don't see it happen, neither in commercial (cost), nor in free (lack of contributors) software.
[1]: Don't do this, US international ISO is better: https://www.farah.cl/Keyboardery/A-Visual-Comparison-of-Diff...
While I live in Spain now I still use the US layout I'm used to from the Netherlands. It means I can't type the Spanish accents which are kinda important but anyway...
I have been thinking the same for years. Some guys at work used to add Vim bindings to their IDE and I just didn’t understand it.
I used VI back in the day when the choice was vi or ed. It worked well given the constraints of a Wyse60 or VT100. But I was happy to leave it behind for X windows, a mouse, and modeless editing.
So today, 25 years after I learned VI because I had no choice, the idea that having Vi bindings makes a tool for “hackers” is just not something that resonates with me. I’m happy to discover I’m not the only one.
In case it’s not clear from my tone, I’m totally sympathetic to relieving injury, and whatever works, works. I just don’t understand how Vim bindings help, and am genuinely curious.
Yes! I very much do. I do not use the arrow keys for cursor movement in edit mode.
inoremap <Left> <NOP>
inoremap <Right> <NOP>
inoremap <Up> <NOP>
inoremap <Down> <NOP>
The purpose of insert mode is to insert text, and that’s it. This occupies a very small proportion of total editing time.
Speak for yourself! I do it all the time. Navigating by word is my primary means of moving through a line.
Maybe that’s why I’m happy to be free of vi. It was my primary editor for at least 10 years. And I’m happy to see the back of it.
> Navigating by word is my primary means of moving through a line.
So how does your new editor do that more efficiently than pressing <Esc> once, followed by pressing <w> or <b> once for each word?
Just to be super clear, I don’t care what other people do. Go nuts with vi bindings. I was just agreeing with what someone else said, that vi bindings aren’t peak UI and that “hacker” != “vi”
Now we found out that leaving insert mode to navigate by words requires the "same number of keys", so @gsinclair was right and it is unnecessary to stay in insert mode for navigation.
> Same number of keys, but works pretty much everywhere. The box used to enter this comment, for example.
If efficient word navigation was the only thing vim key bindings had to offer I wouldn't be using them. But they do offer many things the current text box does not offer and since (as a programmer) I'm spending 95% of my time in an IDE and not some browser text box, I'll gladly accept some inconsistencies if that means editing and navigating in my IDE becomes more pleasant.
I’ve been using it for so long that apparently the muscle memory is the only memory I have.
I mean thinks like yy and p and ZZ sure, but for navigation I know where on the keyboard it is - but not the keys. (At least not while I’m using an iPhone keyboard)
Aren’t brains weird?
I was definitely on team vi in the Great Emacs Wars, but it’s not my preferred way of editing any more. Nevertheless it’s something that I know quite well, and this conversation has really opened my eyes to the idea that this sort of thing can help people.
I started with vi eons ago because it was easier to use it remotely to do my school work than it was to walk into the labs and use a graphical editor. The habit stuck -- vi has a steep learning curve, but it's also habit forming, so to a large degree I use vi because of the habits I developed.
However, when pain from ulnar deviations began to set in I had to experiment and research to find something that worked, and that was sticky keys, and I've not been in pain since. The fact that I didn't have to give up vi certainly says something, namely: that vi wasn't the cause of the injury. But also now that I understand what caused the pain (ulnar deviation), I shudder to think of using emacs.
> Do you know others in your situation who use vi bindings?
I do not, though I do very much recommend using sticky keys.
I have taught my son how to use vi and he loves it. Like I said, vi is habit forming, but good habit forming :)
I’ve used vi since at least the early 1990s. I still use it today, but I really do prefer a non modal approach to editing and always have.
That said, of course, I wouldn’t be caught dead using nano :P
> That said, of course, I wouldn’t be caught dead using nano :P
ISTR that Rachel by the Bay uses nano. No shame in that!
I‘m one of these guys.
I’m used to its text editing hotkeys from years of using it, but when jumping between a bunch of languages/environments it’s a lot easier to leverage the ‚integrated‘ nature of a lot IDEs (in my case Jetbrains).
Having to find, configure and remember how to use a bunch of different debuggers, linters, codegen tools and other tools manually is a pain
It’s time we pander to each and every culture’s random conception of symbol manipulation and end this era of universal, gate-keeping, commonality. The time of personalized input devices is upon us.
Vim and thus this browser is unusable on my custom 20% HIQPK layout numpad.
I accept that U.S. English is the computer lingua franca.
However, even if I wouldn't switch - wouldn't it just be to remap the keys in my config?
Has the US keys on the first/second levels and most/all special symbols for European languages easily accessible w/ modifier keys. Entirely removed the need to switch keyboard layouts for me.
Keyboard is a one-time investment of 20-200 Euro, but learning to use your editor efficiently is an investment of years of your life... amplified by the fact that there aren't that many good editors. So, any person who needs to work with the editor on a daily basis will have to make a choice between buying a keyboard that works well with that editor or a keyboard that allows them to type Euro / Pound sign more easily... And nobody in this situation is going to choose the keyboard that doesn't work well with the editor.
This obviously varies by country, but at the places I’ve worked at, most people used the local layout instead of the US one. They couldn’t bother relearning it and then switching every time they wanted to enter some text in the local (Slavic) language.
So the user just presses Ctrl-AltGr-[, what's the problem? And changing keyboard layouts or keybinds, isn't something that someone using vim should have a lot of trouble with anyway.
> It's bad enough that a text editor that ignores the past few decades of UX research is still in widespread use,
Maybe that's because a lot of people using it decided that the "decades of UX research" produced precious little of worth. That's because alot of the "research" done in areas that are, by their nature, heavily opinionated, produces, what a surprise, mostly opinions.
And when we take a giant pile of opinions, and pile them all on top of one another, well...
...that's how we ended up in a world where, somehow, people now actually have to wait for an application to open, like they did in the early 90s, on machines that are orders of magnitude more powerful. Where webpages load 20MiB of giant hero images, useless framework code and spyware, to display 4 lines of text. Where applications get more "modern" and "streamlined" by somehow lowering information density, losing functionality and getting less self-explanatory.
In other words: you are complaining about a problem that doesn't exist. Users who want Vim / Emacs experience don't want keyboards that don't work well with their editor of choice. They will not be in a situation where they have to adjust their editor to the keyboard layout. If there's a mismatch, then the keyboard will be adjusted, not the editor.
Now, I'm not sure how Vi(m) users handle other written languages, but since I every now and then have to write in two non-Latin languages, in Emacs, I keep buffers for those languages with input method set accordingly. However, say, I need to write in Cyrillic, I still use the en_US modified QUERTY layout that I use for everything else + phonetic transliteration into Cyrillic. This is both easier for touch-typing, as I don't have to memorize several different layouts, and this method makes more letters easily available than there would've been on a physical keyboard.
So... no. don't stop incorporating Emacs / Vi key usage into new products. It works great.
Also:
> ignores the past few decades of UX research
Except there was none. Unless you mean it in the same way how for some reason people who make HTML pages call themselves "UX developers". What happened is that big companies wanted to sell products that looked "impressive", but offered worse user experience overall. This is how MSVS, Eclipse, and similar happened. There's literally no UX research on how people deal with typing text into computers. Whereas in practice, what I see is that people who use "visual" tools just suck at writing text. And, myself, having worked with both "visual" editors and Emacs / Vi, I would literally refuse a job position if I had to work with VSCode / IntelliJ products.
> Nyxt is a browser with deeply integrated AI and semantic document tools that work as a second brain to help you process and understand more, more quickly.
It'd be nice if they elaborated on what this “integrated A.I.” thing actually is in that or another FAQ entry.
Does this support profiles by any chance? I currently use chrome profiles to separate work and personal
Looking forward to giving it a spin
The first thing I found awkward about it is that prompt fields are always initiated in normal mode. So if you want to execute a command with : or interact with an element using f, you have to manually activate insert mode first before being able to enter text into the prompt.
I'm sure there's a way to change this since the entire thing is in Lisp, but it sure is an odd default.
Now, that may not be true of -me- in practice, but it's definitely possible for whoever did implement that part to genuinely prefer it that way.
Of course, if the implementer wasn't a vi user, who fucking knows, vi is kinda baroque as fuck if you run face first into it without preparation so "the person who picked that default was trying to do vi users a solid but had to guess at some bits" is totally viable too.
There is also Chromium which you can build and patch if you really need low level changes to the browser not achievable from JS, but nothing immediately comes to mind to necessitate that.
|grep ...|awk ...
And the text of the document gets processed. But if you want to mess with the dom you could:
Html.Body | sed ... | jq ...
You could however, use a tool like External Application Button [0] in order to send the URL of the page to a script/program, which in turn can make the body of the page parsable by downloading the URL it gets, automating some action on it. I use it pretty often to automate downloads with yt-dlp or opening a picture directly in GIMP from the browser, but since you're invoking a bash/python/whatever script, the possibilities are basically endless.
[0]: https://github.com/andy-portmen/external-application-button
This works less well than it used to now that CMSs and blogs are now SPAs that render no text without javascript being enabled.
I’m curious about this comment. Surely this should be possible using accessibility hooks for a normal browser or in Nyxt via scripting, right?
The "configuration" is just more code that gets compiled in on loading. It's a complete first class citizen unlike extensions for most software which is sandboxed in a separate language and can only see certain APIs.
In Nyxt, StumpWM, Emacs, and other Lisp software you can literally put bugfixes in your config, redefine existing functions, and generally do whatever the hell you want.
(defun get-buffer-text (&optional buf)
(nyxt/mode/document:select-all buf)
(nyxt/mode/document:copy buf)
(trivial-clipboard:text))
(define-internal-page cmd-result (&key text) (:title "*Result*")
(spinneret:with-html-string
(dolist (line (str:split #\newline text))
(:p line))))
(define-command-global buf-text-to-pipe-cmd (&optional buf cmd)
(let* ((buf (or buf (nyxt:current-buffer)))
(safe-text (uiop:escape-sh-token (get-buffer-text buf)))
(cmd (or cmd (prompt1 :prompt "cmd: " :sources 'prompter:raw-source)))
(cmd-output (uiop:run-program
`("bash" "-c" ,(str:concat "echo '" safe-text "' | " cmd))
:output :string)))
(nyxt:buffer-load-internal-page-focus 'cmd-result :text cmd-output)))
DOM handling would be a tad more laborous, but you can pick DOM elements from output of nyxt:document-model with CSS selectors using clss:select.
[1] https://blog.mozilla.org/en/uncategorized/its-a-new-firefox-...
"Nyxt is web engine agnostic. We utilize a minimal API to interface to any web engine. This makes us flexible and resilient to changes in the web landscape. Currently, we support WebKit and WebEngine (experimental (Blink))."
tl;dr; no. It's just another browser UI, albeit a very different one.
You can also combine commands into so called command chains.
Back in the days, before Firefox switched to the Google Chrome model of extensions, there used to be a really nice advanced search addon. Nicely integrated into the UI.
So, '/' then '\r' and your regex then 'n' or 'shift+n' for next/previous.
Genius! I’ll be trying it out
My ideal browser would be
- chromium-based [optional] - willing to forgo this if (1) it has a lot of features built-in, or (2) it is extendable in a language like `lua`.
- tree view of tabs
- vim keybindings
- splits, moving windows to new tabs and back
- file-based configuration
- [optional] history sync (i'm fine with using my own cloud provider like icloud/dropbox)
- renaming tabs and windows
- remote control server (so i can interact with it from hammerspoon/alfred, eg: open the tab that is a local file with .pdf extension and refresh it (for asciidoctor/latex development))
- pdf preview
- adblocker
- redirecting urls, eg reddit.com -> old.reddit.com
- automatic dark mode
- modifying js and css of websites (eg removing toolbar on SO)
- command line
- smooth scrolling
- [optional] chromium print preview
- [optional] reader mode
- [optional] vim mode for text input
- [optional] easy integration with text-to-speech that is keyboard controlled
They added support for things such as keepassxc. It has nice defaults.
But they really went ALL IN with the lisp here. For some people that's a plus, but it seems a lot more unapproachable than emacs configuration to me.
I think that will ultimately hurt its adoption and unfortunately these things thrive on the size of the active community.
EDIT: part of that is also lack of practical documentation. They have documented a lot about nyxt, but there is very little practical documentation
How misinformed is my take? Are these kinds of browsers OK? I’d like something light, if possible.
It seems like an absolutely fantastic project and I shall see if I want to invest in the effort it takes to move.
I remember checking it out, being disappointed about its not-great availability for MacOS, and thinking that I should learn lisp.
There was a programming language taxonomy thread posted a few weeks ago and I seriously think if you want to ‘git gud’ you should dabble in all of the families.
https://news.ycombinator.com/item?id=35813496
When you see how to implement a REPL in Lisp, it will blow your mind.
Yes. Nyxt just had a major 3.0.0 release, and we had a thread about that: https://news.ycombinator.com/item?id=35869378
Is someone familiar with how hard it would be to use the hook system to allow it to sync with e.g. firefox android?
it would be interesting to have a customizable browser for undetectable automation
Why would you call tabs "buffers"? It's not a text editor. (And that barely makes sense for a text editor anyway.)
With my https://upload.wikimedia.org/wikipedia/commons/7/77/Adm3aima... keyboard
Please, do acknowledge this is nearly pointless.
Stop coding that please: first thing first, namely code a web engine in a plain and simple language (like C89+ with bits of c99/c11) and not using that any grotesque and absurd language syntax like c++... even though the core of the issue is the web itself.
windows is only for gaming and testing the software you ship
Don't gatekeep.
It's proprietary and user-hostile, with things like tracking and forced updates.
https://lispcookbook.github.io/cl-cookbook/debugging.html#re...
FTFY.
Nyxt [nýkst] is a keyboard-driven web browser designed for power users. Inspired by Emacs and Vim, it has familiar keybindings (Emacs, vi, CUA), and is infinitely extensible in Lisp.
It's not for the OSINT community, is how I'd read it.
That Nyxt is targeted at "hackers" therefore requires some disambiguation. It is not primarily for the former camp, and is largely for the latter, it appears.