A lot of the comments here suggest that some of the functionality can be replaced by extensions like vimium-ff [1]. If you only compare the list of features then maybe. If you try using the extensions, you immediately notice that the keybindings don't work outside of fully loaded page, have horrible lags and delays and misses a keyboard event from time to time.
For the curious folk, the GitHub page [2] seems to do a better job at telling the how of things.
My question is why Lisp for scripting? What's the technical reason behind choosing it? Or is it just personal preference? I use emacs myself and my only complaint is elisp. In this time and age it looks very alien-ish to most people and judging by my colleagues, It can be a major deterrent from using emacs.
Thank you for the kind words. You've nailed it: we can only do so much with typical extensions, they are limited. As per your quesiton: I'll do my best to answer.
1. Lisp is what enables any part of Nyxt to be reprogrammed at any time (even whilst running).
2. Lisp enables us to easily program DSL's for different bits of functionality. For example, we could easily write/interpret a DSL for describing uBlock matrix rules.
3. We try to insulate users who don't know Lisp a little bit by providing graphical configuration interfaces (like emacs), we are working on improving these to make them almost as effective as writing your config by hand.
We're working on it. Big projects like this take time. Hopefully with time our vision will crystallize into something more obvious :-)
You are being disingenuous here. Lisp is cool but it does not enable "any part of Nyxt to be reprogrammed at any time".
Your project is essentially a thin UI veneer on top of C browser engines. That latter part, which is by far the most interesting, can not be reprogrammed in Lisp except through the very limited exposed C library API. Which leads me to the issues I see with Nyxt:
Security will always be a serious problem (and getting worse as time flows). You don't have the resources of Google or even Mozilla, that ship self-contained browsers and can implement security solutions in a holistic, systemic manner. Doing browsing with the isolated engine libraries was (and still is) a recipe for disaster.
Then, for the same reasons, the big corporations can essentially kill your project at any point by treating it as unsafe/insecure and having their sites stop working (which is actually happening at Google).
But most important to me, other than security, is the lack of flexibility and power. The UI veneer and subsets of the rendering engine library APIs that you expose as programmable in Lisp, are the least interesting ones. Why would anyone want to reimplement uBlock or other popular extensions in some convoluted mix of Lisp and Javascript, rather than use the superior originals? This is the final tombstone for me.
It's clear that you're trying to build an ecosystem and deliver "apps" on top of, like an Emacs-like for the web maybe, but for the reasons I mentioned I see it as fundamentally flawed and want no part of it.
A welcome critique, though unfortunately mostly incorrect :-D! I'll address some of your comments:
1. Nyxt is entirely written in Common Lisp, so yes, any part of it can be reprogrammed at any time. All of our FFI bindings are also written in Common Lisp (https://github.com/atlas-engineer/cl-webkit). In fact, you can even GENERATE bindings at run time. So it is irrelevant what part is invoking C, it is still fully funcall'able at runtime. This is what makes Nyxt not a 'thin veneer', but rather a deep integration which exposes all resources to the end-user (something unique to Nyxt).
2. Our project is a chrome that is agnostic of the renderer engine. We can use both WebKit and Web Engine (Chromium). This makes us resilient to renderer specific problems. If websites decide to ban browsers that utilize WebKitGKT+, we'll have another renderer available to us. We talk about this in our article where we justify some of our technical design decisions: https://nyxt.atlas.engineer/article/technical-design.org
3. Security is very important to us. We rely on upstream providers of web engines (WebKitGTK+, Qt WebEngine) to test and audit secure web engines for us. We can't do everything, you're right about that. For this reason, we give users the choice, and hope for the best!
4. "Lack of flexibility and power"- I think this point is probably the most inaccurate. If you look through our articles you'll see a couple of things that make Nyxt powerful and flexible.
4.A. Composability, all extensions (plugins, as you may call them) can call and utilize each other. That means, as our ecosystem grows, so does the power grow exponentially!
4.B. Flexibility: We give the user access to the complete Common Lisp compiler, all packages on Quicklisp, and the ability to override and change literally any aspect of Nyxt. I often speculate that Nyxt is potentially the most flexible browser to have ever existed.
5. Lastly, no, we are not trying to deliver "apps" on top of Nyxt. Nyxt is a browser, and a programmable platform, not an app delivery mechanism.
I hope that the above was informative, and if not changed your mind, at least exposed you to our view point!
Once again, thanks for the critique, and happy hacking!
1. You're arguing semantics in a disingenuous fashion which reinforces my point and make me like Nyxt even less. Nyxt, the end-user product, "is not entirely written in Common Lisp". Your rendering and browsing engine, the core of your application, Webkit, is not a Lisp library.
2. This doesn't solve the problem. Being able to use both webkit and web engine in no way makes you resilient to the issue I brought up. Google has plenty of reasons to disallow and prevent their engine to be used by Nyxt and they have said that they will do so. Your answer strengthens my point.
3. Again, the issue is systemic and there's nothing upstream providers of web engines can do. Using these libraries in isolation will always expose you to significantly more security issues than using them as part of the browsers they were meant to be used in.
4. Flexibility and power (as I explained) is me using uBlock origin and coutless other extensions without reimplementing them from zero. Do you have uBlock origin for Nyxt? I rest my point.
I just one to write a positive comment to add some balance to the existing ones. I appreciate your effort to make an alternative web browser for power users! I hope this will be a successful long term project.
Turn on "caret browsing" in Firefox if this type of text selection and copying is your thing. Been around forever. I think you just hit F7 to activate
I prefer to set Firefox to start searching when I type, and to restrict searching in that way to links only. This means that I can just start typing some text from a link and hit enter to navigate there. No weird letter combos like vimium or vimperator, so easier in that regard, but also does not work for every click target, so crappier in that regard.
I do a heck of a lot more navigating than text selection, though.
And without search-on-type, you have these two in Firefox:
• / enters “quick find” mode, which is roughly the same as Ctrl+F/⌘F, just it’ll close the search bar automatically a short time after you stop interacting with it.
• ' enters “quick find (links only)” mode, meaning it searches only within link text.
I recently installed Tridactyl¹ as a Firefox extension². It has a ton of features but I my original intent was to only replace the functionality of two non-WebExtension add-ons:
* VimFx³ provided handy keyboard short-cuts for working within the browser
* ItsAllText⁴ which allowed me to use GVim to edit and save the contents of a text box
While going through its builtin tutorial, I found that it also supports keyboard-based selection of text (similar to that shown in this article). While this feature is documented as not yet being stable, I’ve found that it works well in my exeriment.
I’ve yet to incorporate the rest of Tridactyl’s extra functionality into my workflow but what they’ve achieved with the WebExtensions API is very impressive. Also, and importantly, the built-in tutorial and documentation are excellent.
While working from home, I’m currently using Windows 10 so I’ve ran into one issue⁵, “Encoding of non-Latin-1 characters entered in external editor gets messed up with Unicode-based external editors on Windows” (and it looks like that should be fixed soon).
As a newbie to using Tridactyl, I installed the stable version (1.20.4). Anyhow, I tried running the linked installer for the native messenger and noticed that GVim now opens with “fileencoding” set to “latin1”. This resulted in conversion errors (I have “encoding” set to “utf8” in my “vimrc”) but I was able to get around that by running “:x ++enc=utf-8”.
I’m now able to quickly and easily open, close and re-edit text-boxes containing UTF-8 character. Thanks.
Actually, GVim had been opening with “fileencoding” set to “utf-8” and the contents of the text-box were fine. It was only when saving that the text box would have the wrong characters. Late last Saturday night, I had edited the `editorcmd` to be
At that stage, I hadn’t discovered the use of `x ++enc=utf-8` to resolve the issue and gave up at that stage (I thought I had reset the `editorcmd` but must have forgot). Anyhow, with the new native messenger, I don’t need to mess with specifying character sets and I’ve now set the Tridactyl `editorcmd` to the simpler:
gvim -c "set filetype=markdown"
Now GVIm opens with UTF-8 as both the “encoding” and “fileencoding” so I can exit it as usual with a simple `:x` and the text-box updates correctly.
Thanks again (your help with this prompted me to become a sponsor).
Cool project. In the past I have had some frustration building Nyxt from source code, but that is probably on me doing something wrong. Playing with the prebuilt packages is easy. Their patreon link: https://www.patreon.com/nyxt
oh commonlisp. you came and you gave without taking.
what a beautifully-written lambda. i'm not finished reading source but i can't think of a reason i wouldn't prefer to use nyxt over every other browser when i'm in x11.
No, you can use hinting links and clickable links, but not with text selection.
qutebrowser has offered caret mode for a while, but without the hinting. You have to select some text with a search to initiate.
This is a new development in pointer-less and keyboard-driven browsing.
Also, the experience of a Chrome extension is pathetic compared to that of a browser where keyboard is first-class. With Chrome, even things like closing a tab or opening a new tab are inaccessible until the browser has parsed a page, the DOM has loaded, and the extension has injected and then run the JS into the page. (Which also means that you can't use it without also allowing JS in all pages you browse.)
That is not true. I use Tridactyl on FF and on pressing v it switches to selection mode very identical to the one shown. Then you can use hjkl to edit the selection.
Why doesn't Nyxt have online documentation? I can only see an unstructured list of Articles, but no proper manual. Nyxt has some docs embedded in it, but it'd be nice to have it online, so users can read it from the comfort of the browser they've been using for years, playing with Nyxt in a window side-by-side.
And only after reading this paragraph at the _bottom_ of README.org on Github [1] I could find help in Nyxt:
> For full documentation about Nyxt, how it works, and how to extend it please see the embedded help. To get started, run the help command (C-space help).
Could you make it more obviuos? It would be great to have the tutorial [2] and the manual [3] in a readable form on your site.
That's a really good question, thank you for asking. The reason we why we've so far opted to not include documentation online (we used to have it online) was because it would drift from different versions people were using. Lots of times people would see a feature or something in the manual, and wonder why it didn't work on their own installation!
If you have any suggestions as to how to remedy this, or if you think the trade-off is not worth it, we are all ears!
I'm just telling you about my experience. Obviously Nyxt is very different from more conventional browsers. I'm an Emacs and StumpWM user, and I'd love to have the same kind of power in browser environment. But without easily accessible docs it's just a little bit too high barrier for me.
> it would drift from different versions people were using
Good point. Maybe as a first step just copy that paragraph from readme file to a more prominent place on site? It's very unusual for a project site to have no manual.
Then make the latest version of docs available online. It should be clear 1) what version it talks about, 2) how to check version of user's installation, and 3) how to open the embedded help.
Sorry for the delay in replying. I was going to reply the next morning, but then I forgot as I was quite sleepy!
We do have a page https://nyxt.atlas.engineer/documentation that basically lists the information. We used to retain that link, but found it unnecessary since now documentation is all built-in.
As Nyxt is quite young, it is still rapidly changing between releases (this does include the UX (as you've mentioned)).
For this reason we would need to provide versioned documentation. Perhaps we can generate versioned documentation from our CI. I will look into it. Thank you for brainstorming with me :-)
Or, in any(?) browser of choice you can use ctrl-f, <search term>, enter, enter, ... (etc forward until target, reverse = shift+enter), esc, shift+arrow_right to highlight and ctrl-c to copy the selection.
BTW, the title is incorrectly editorialized: this is not about pasting at all.
now, I am on macOS and now nothing about Qt nor GTK.
I've read some in the internet and they say Qt is *generally* lighter than GTK. Is that the case? Should I try and build the Qt version for Nyxt if I want performance?
Also, does either version has more feature than the other? Thanks :)
I don't think there is a huge difference between the "weight" of the two. And when you have a small amount of chrome over a web engine the difference is almost certainly imperceptible compared to where the "real work" is happening.
I have wanted this actually. Might not be more productive, I don't know, but being able to just keep your hands on the keyboard is good for ergonomics.
Agreed, we have changed our slogan to 'the internet on your terms', because we recognize that Nyxt is firstly about control. You get to be in control of how you use the browser.
I'm curious as to what is the user case here. If you are connecting to a server from a command line or similar you don't have a mouse, but you also don't (probably) have a ui.
Other cases where your mouse is broken or damaged, ok, but otherwise...what are the benefits? (Apart from being able to say 'I don't use the mouse for anything').
The use case is all the situations where a mouse is not available. You already discovered several, and you're only scratching the surface.
The truth is that you cannot predict all the scenarios and possibilities out there, no matter how hard you try, and it is naive and arrogant to pretend that you can.
For me personally, mouse use comes with a huge ergonomic hit, and results in discomfort and pain.
Keyboard browsing (I use qutebrowser) is also much faster and more efficient once I've conquered the week-long learning curve.
Keyboard support also has a long history in browsers, with Opera 4.x being one of the pioneers of one-key shortcuts, though not vi-style.
Using a mouse heavily for the first 2 years of my career gave me the beginnings of carpal-tunnel syndrome. Switching to a 60% keyboard and carefully choosing keyboard shortcuts for everything has meant I've not had a problem since then.
On the contrary - a project, which ignores how the majority of their potential user base installs software is entitled and arrogant. I don't like Homebrew, but it is de facto the standard way of installing software on macOS.
Yeah, unfortunately when I try to package the MacPorts bundle for distribution as a .pkg file, the webview has a bunch of certificate errors. Haven't been able to figure this out yet!
A lot of the comments here suggest that some of the functionality can be replaced by extensions like vimium-ff [1]. If you only compare the list of features then maybe. If you try using the extensions, you immediately notice that the keybindings don't work outside of fully loaded page, have horrible lags and delays and misses a keyboard event from time to time.
For the curious folk, the GitHub page [2] seems to do a better job at telling the how of things.
My question is why Lisp for scripting? What's the technical reason behind choosing it? Or is it just personal preference? I use emacs myself and my only complaint is elisp. In this time and age it looks very alien-ish to most people and judging by my colleagues, It can be a major deterrent from using emacs.
[1]: https://github.com/philc/vimium
[2]: https://github.com/atlas-engineer/nyxt