1.  

    Something I forgot: the Xref buffer can be replaced by a Helm buffer, which I find very convenient to “go to definition” and for all the sly-who-* commands.

    Still about SLY, I’ve updated Evil Collection bindings for SLY.

    1. 3

      What’s the engine?

      1. 5

        I was curious as well from the README.org in git: “Next supports GNU/Linux, macOS, and Guix with engine support for WebKit and WebEngine/Blink.”

        1. 8

          I would be tempted to try this, but I really don’t want to contribute to making the WebKit monoculture even worse.

          1. 10

            Look I am very vocal about browser monoculture and am a volunteer for Mozilla but I think you should reconsider here. Next browser has a lot going for it and the engine is not where its interesting parts are. The fact that it supports more than one engine makes it easier in the future to port to a non webkit-derived engine. A web with more user agents is always good, specially new browsers like this which are trying something different UX wise.

            Also, remember that Mozilla doesn’t make it easy for people to build on top of their engine. It is very hard to start a browser today and not go in the webkit/blink path. For example, I wanted a Web View for Racket because I couldn’t find one, I ended up with a mvp of a webkit wrapper. I’d prefer to go with Gecko but couldn’t find how. It is not as if the developer of Next browser is actively supporting a browser monoculture, they are doing what they can and shipping a nice product with the engines that are available today. I think that is great.

            1. 2

              Qutebrowser supports more than one engine, and is arguably much more mature than this project.

              1. 6

                It is not a competition. You can support Qutebrowser, or this one, or both. The more the merrier. If instead of supporting small independent vendors, we keep pointing fingers shouting $ALTERNATIVE is better then we just end with less browsers.

                I like Qutebrowser too, and Dillo. We need to support a diverse ecosystem, even if in terms of engines things are looking rather grim.

                1. 5

                  then we just end with less browsers

                  Except we don’t actually get “more browsers” in a meaningful way; we just have the same browser over and over again with different trimmings.

                  1. 2

                    Yes you do. Most of the differences are happening outside the engine with different browsers packing different UX, ad-blocking and other features.

                    I too want more engines but we don’t have more engines to embed. At the moment all the embedable engines are webkit/blink derived. MacOS WKWebView, Windows 10 is getting blink, Linux is mostly around WebKitGTK and QtWebEngine.

                    Yes, I agree we need more web engines but the web got so complicated that no one can build them from scratch anymore. Unless devs start contributing massively to Mozilla to make Gecko embedable (checkout GeckoView which is an embedable Gecko but as far as the repo goes, there are only samples for Android), we won’t have alternatives.

                  2. 3

                    This is far from a ‘diverse’ ecosystem. All of these browsers use webengine or webkit.

                    1. 1

                      Diversity is not an absolute, it is a spectrum. It is more diverse to have more user agents even if they use similar engines but are exploring different approaches to the rest of the app than it is to have just three browsers, two of which are webkit/blink. Opera, Brave, are all blink based and some of their innovations are being adopted by other browsers. I’m sure everyone would like more engines but we don’t have them.

                      Mozilla should throw more weight into making GeckoView work well on the Desktop so that people could build browsers with it, but even without that, more user agents is better.

                  3. 2

                    Indeed, and as a former Qutebrowser user myself I can say that it inspired me for many features of Next. Note that Next takes a radically different approach though: it exposes 100% of its (Lisp) code base to the user, open for configuration. The goal is to have something extremely extensible / hackable.

                    The minibuffer UX of Next is mostly inspired by Emacs Helm / Ivy and that differs quite a lot from Qutebrowser approach.

                  4. 2

                    Isn’t servo easier to embed? Why not go with that?

                    1. 3

                      Servo is very incomplete.

                  5. 2

                    What do you mean? We support 2 engines (and possibly more in the future), there is no monoculture here :p

                    1. 8

                      Like the old joke goes: “We play both kinds of music here: country and western.”

                      1. 3

                        I don’t get the joke, there are two browser engines, and the chrome here is agnostic of the engine.

                        1. 8

                          They’re both just different variants of one Google-backed codebase; it’s still a Google monoculture.

                          1. 4

                            Are Google contributions being backported into WebKit? Otherwise, Google hasn’t exerted influence over WebKit since they forked off six years ago, right?

                            1. 2

                              I’d say it’s the other way around: Google forked WebKit. WebKitGTK is developed independently. If I understand it right, WebKit has a long history (KHTML) that predates the work of Google.

                            2. 2

                              The “chrome”? Did you mean the “core”?

                              1. 9

                                Browser chrome usually means browser ui

                      2. 2

                        Indeed. For now the PyQtWebengine port needs a bit of finishing but we are working on it. Soon both renderers will be equally usable!

                    1. 3

                      Very nice project, I admire it is done in common lisp too although that will probably prevent some devs jumping in.

                      History tree is something new for me in the browser world (only had that in vim so far) and is awesome feature. Other things are not really new as Vimium plugin does many cool things. Other interesting thing, jumping to headers fuzzy way is also new for me, but I wonder its practicallity.

                      I suggest adding another great vim/Vimium feature - marking position on page (m) and jumping to it latter (`). Its fantastic way to navigate over big tehcnical documents.

                      1. 3

                        This is a good suggestion, I’ll note it down! :)

                        1. 2

                          With capital letter marks for bookmarks! I imagine the power….

                          1. 1

                            See what I wrote down: https://github.com/atlas-engineer/next/issues/392:

                            we could even name the marks, persist them, fuzzy-search them, etc.

                        2. 1

                          I think that netsurf also has a history tree.

                        1. 3

                          Do you have any plans for WebExtensions support? Would be the best browser.

                          1. 1

                            This is a very good question. To be honest, I personally don’t know enough about WebExtensions. My gut feeling is that they are way too limited compared to what Next offers. But that would not stop us from supporting them, for the sake of compatibility.

                            What would be interesting to collect is the most popular non-trivial WebExtensions out there.

                            1. 2

                              There are lots of situational/not popular webexensions people use, its impossible to move them all to next as lisp extensions (or whatever exension it supports) unless it will become a mainstream browser.

                          1. 7

                            Self-promotion for fundraising, flagged. Cool project though!

                            1. 4

                              Why is this any different then people self promoting their blog articles (which they do all the time here). In 99% of cases It ultimateivelly is about end effect, which is money.

                              1. 4

                                I highly dispute the 99% numbers. How do you even get this idea? There are so many blogs that don’t have ads, are not trying to promote their authors, etc.pp.

                                1. 0

                                  Self promotion, not ads - its about better prospects on future jobs by building and influencing community around the stuff you do.

                                  So 99% is from head, but I am sure its even higher. Or you tell me you know bunch of people, who write great technical blogs just for the sake of researching particular topic, are stuffed for life (rich family) or despise materialism and live in a barrel like 1 dude ever, and do it anonymously because they dont need any attention …

                                  1. 12

                                    Or you tell me you know bunch of people, who write great technical blogs just for the sake of researching particular topic, are stuffed for life (rich family) or despise materialism and live in a barrel like 1 dude ever, and do it anonymously because they dont need any attention …

                                    This seems to be an overly cynical perspective. I write blog posts because I want to share my knowledge or some other information with the world, and I’m sure I’m not alone.

                              2. 3

                                Thanks!

                                1. 4

                                  Something on the tagging: note that tags on lobsters are block-if-any.

                                  So, if you have a diehard emacs user that is filtering vim, they won’t see this, nor will a vim user filtering emacs, or anybody filtering web (which is usually kind of a broad tag). So, a smaller supporting set of tags is usually going to help you.

                                  1. 5

                                    That actually defeats the purpose of tags and looks more like categories.

                                    The said problem is internal software thing.

                                    In any case, about that dude filtering out emacs - I could totally live with that :)

                                    1. 2

                                      Thanks, didn’t know that!

                                1. 3

                                  If you’re wondering what browser engine this is running (as I did), it appears to be using WebKit: https://next.atlas.engineer/article/technical-design.org

                                  More importantly, they have gone to some effort to isolate the browser engine from the UI so that it is possible to swap out browser engines without rewriting the whole browser. Interesting project!

                                  1. 5

                                    Next also supports Webengine (a Blink fork, the Chrome engine) through the PyQt port.

                                    Edit: Note that the “technical-design” article is somewhat outdated. For instance, XML-RPC has been replaced by D-Bus.

                                    1. 2

                                      Could somebody write a gui wrapper for next browser fairly easy? Like if I wanted to add a gnome header with a menu listing buffers is there an api for hooking into that functionality from an external program?

                                      1. 2

                                        To clarify:

                                        • Do you want to extend the GUI of next by adding menus, etc.?
                                        • Or do you want to write a separate GUI that interacts with Next?

                                        For the former, this is just about extending Next. We have plans to add a status bar, possbly buttons, a configuration page, etc.

                                        For the latter, for now you can use the Swank protocol to send arbitrary Common Lisp to Next (and thus query anything). I’m soon planning to add a commnad line --eval option so that anyone can do it, even if they don’t speak Swank.

                                        1. 1

                                          I may have misread the design document. I was under the idea that Next was embeddable. So one could embed the browser in a gui (like neovim) and interact with it through rpc or dbus calls. This way somebody could write a ui that conforms to gnome or kde HIG.

                                          With regards to the clarification, will there be a gui extension api or will the extensions have to go upstream and get merged?

                                          1. 1

                                            The thing is that the browser and the GUI are the same thing here. What communicates over D-Bus is just the web renderer (e.g. WebKit). Common Lisp does everything else, including manipulating the minibuffer, creating buttons, etc. The UI elements are actually web elements (HTML / Javascript).

                                    1. 1

                                      It turns out that the static typing example works with ECL, CCL and SBCL, as far as I’ve tested. Does this mean that “Common Lisp is not statically typed” is a common misconception, and that it would be more accurate to say “Common Lisp has optional static typing”?

                                      1. 1

                                        Common Lisp is strongly, dynamically typed.

                                        1. 1

                                          Indeed, but the linked article explains how to do static typing as well.

                                      1. 3

                                        In particular, I really like the examples of static typing and algebraic data type definitions.