[HN Gopher] Nyxt: The Hacker's Browser
___________________________________________________________________
Nyxt: The Hacker's Browser
Author : sathishmanohar
Score : 574 points
Date : 2023-05-19 20:22 UTC (1 days ago)
(HTM) web link (nyxt.atlas.engineer)
(TXT) w3m dump (nyxt.atlas.engineer)
| jvanderbot wrote:
| Never in my life have I been excited about a browser, until now!
| friend_and_foe wrote:
| I'm a qutebrowser user and I really have been rolling it around
| in my head to check this out and switch to it. My main issue with
| it is that I develop userscripts for qutebrowser (not
| greasemonkey scripts, qutebrowsers version of extensions) and the
| lisp only thing in nyxt bugs me. I like lisp, but I'm stronger in
| other scripting languages. The benefit is of course i would not
| be limited at all to functionality because any part of nyxt can
| be modified.
|
| It seems like an absolutely fantastic project and I shall see if
| I want to invest in the effort it takes to move.
| keyle wrote:
| I personally use Orion Browser (macOS) and Homerow (macOS) and it
| gets me in a similar situation, without the buffer stuff, and
| with a more traditional setup. I can recommend that if you're
| looking for an alternative.
| xkcd1963 wrote:
| Can it be run on a server?
| vindarel wrote:
| I expect you can run it in headless mode (new --headless
| switch), start a Swank server (the backend of Slime, the
| backend of the most used CL "language server"), and connect to
| the Lisp process from home, through a SSH tunnel. And control
| the browser from the Lisp REPL, or a Lisp script, like we would
| with any running Common Lisp program.
|
| https://lispcookbook.github.io/cl-cookbook/debugging.html#re...
| graderjs wrote:
| If you want a remote browser capable of running on a server
| (with the client, browser UI in a regular web page) check out
| BrowserBox: https://github.com/dosyago/BrowserBoxPro
| ktm5j wrote:
| Can you clarify what you mean? It can certainly be run on
| hardware that you call a server, just would depend on if you're
| running a graphical environment, it's not able to run in a
| terminal emulator afaik.
| sicariusnoctis wrote:
| The main thing I miss in these vi-like browsers is a tab tree
| sidebar like Sidebery.
| asimjalis wrote:
| Lisp programmability. I love this already.
| xwdv wrote:
| Can it spoof the user agent? Unfortunately browsing a site with a
| strange browser can often get you treated like a second or even
| third class citizen.
| vntok wrote:
| It's even more suspicious to security layers to spoof the UA
| while keeping a different SSL handshake profile (or a different
| JA3 hash).
| cutler wrote:
| Why is the only Mac option a non-default, local repo-based
| Macports installation? What's wrong with a binary or a port that
| is actually listed in Macports? Isn't that the whole point of
| Macports?
| msie wrote:
| I've always thought of developing a Hacker's browser. One where
| there are no restrictions of what it can do. For example, you
| can't write a chrome extension to spoof the Referrer header on
| requests. The Chrome browser is more locked down than you think.
| extheat wrote:
| What other restrictions are you referring to? This SO post
| seems to cover how to change headers (including Referrer) in
| Chrome API: https://stackoverflow.com/q/30999159/11173996
|
| 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.
| msie wrote:
| It doesn't look easy to change and even then, there is some
| doubt whether it works with newer Chrome versions. Anyways,
| the Chrome developers are purposely making hard if not
| impossible to change the Referrer and other headers. Part of
| the blame is to comply with standards but there should be
| some flag to turn off that behaviour.
| modeless wrote:
| Doesn't this one do that?
| https://chrome.google.com/webstore/detail/referer-control/hn...
| msie wrote:
| Hmm, if you look at the reviews, it doesn't seem to work for
| everybody. Also seems to make a "referrer" header instead of
| "Referrer".
| hattmall wrote:
| VB webbrowser control. I'm pretty sure you could do anything
| imaginable.
| vrglvrglvrgl wrote:
| [dead]
| do-me wrote:
| Awesome project! From the website I wasn't quite able to tell
| where exactly and how AI comes into play. I think apart from
| fuzzy searching headings a semantic search functionality for the
| whole text would be a really nice default feature. I implemented
| frontend-only semantic search with transformers.js here:
| geo.rocks/semanticfinder. The implementation is very
| straightforward and it would be easy to integrate in the browser,
| maybe as a plugin or similar.
| 8organicbits wrote:
| The code references stochastic modeling[1] for predicting the
| users next command. There may be other places too.
|
| https://github.com/atlas-engineer/nyxt/pull/2593
| raman162 wrote:
| This looks like my type of browser. I currently rely heavily on
| the vimium chrome extension.
|
| Does this support profiles by any chance? I currently use chrome
| profiles to separate work and personal
|
| Looking forward to giving it a spin
| lez wrote:
| You can use your OS to do that: Run: `env HOME=~/nyxt-profile-
| work nyxt` and `env HOME=~/nyxt-profile-personal nyxt` for
| separating profiles.
| dimator wrote:
| you should also checkout https://qutebrowser.org/ which is
| pretty mature.
| rochak wrote:
| A dealbreaker as it doesn't suppport ublock origin extension
| which is essential to browsing the web these days.
| yokem55 wrote:
| Qutebrowser can use the same adblock filters that ublock
| uses.
| lost_tourist wrote:
| Not really as customizable though, ublock has useful
| features like build your own filter and pick/create to
| block annoying webpage widgets. I do wonder if the python
| based aspects of qutebrowser might give a large surface
| to fork it and make this type of "hacker's browser" out
| of it though.
| kovac wrote:
| This looks really good, will be trying it out. Looks like they
| wrote their own rendering code as well? Or are they using some
| other rendering engine?
| leephillips wrote:
| WebKit and Webengine. And the versions of these renderers that
| this and similar projects like qutebrowser use are just too
| full of bugs to be a main browser. That's why I don't use them,
| although I would really love to.
| kovac wrote:
| Thanks for the information. Yes, this is why I stopped using
| qutebrowser too.
| uoaei wrote:
| This looks like it could become a powerful web crawler with
| relative ease.
| nittanymount wrote:
| not for mac sadly...
| 3np wrote:
| FAQ says Mac support is experimental so any hacker should be
| able to compile it?
| ynniv wrote:
| Last time I tried I was unable to sort out the dependencies.
| IIRC it was something to do with Qt and sbcl.
| AndrewKemendo wrote:
| This looks like a modern browser UI with an embedded cli that
| uses the page as a database!
|
| Genius! I'll be trying it out
| jerryzh wrote:
| One thing that stopped me from using it is unable to sync
| history.
|
| Is someone familiar with how hard it would be to use the hook
| system to allow it to sync with e.g. firefox android?
| p-e-w wrote:
| Looks like Nyxt, a browser "inspired by Vim", inherits Vim's
| showstopper bug: Being unusable on many non-US keyboards, at
| least with the default bindings. The 'switch-buffer-previous'
| command is bound to C-[, which cannot be pressed e.g. on QWERTZ
| layouts because the [ character requires AltGr. This is like
| sending around text files encoded in Windows-1252 and expecting
| things to just work.
|
| 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.
| SanderNL wrote:
| Yes and calculators have the same issue. I mean, what about
| Indian numerals, Ethiopian and how does one perform a _proper_
| Coptic calculation using these awful devices with showstopping
| UX flaws?
|
| 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.
| trinix912 wrote:
| Remember that most European keyboards don't have [ and ]
| accessible on the first/second level. That's already half of
| the western civilization, not some random's custom layout.
| olodus wrote:
| Yes, mine for example. Swedish keyboard layouts are
| horrible for coding. The [ and lots of other symbols
| require super weird hand movements to input. That is why
| when I code I usually use an American layout keyboard
| instead.
|
| However, even if I wouldn't switch - wouldn't it just be to
| remap the keys in my config?
| anthk wrote:
| European here. I don't care, I don't use the Spanish
| layout, it sucks for programming. No one uses that at
| professional level for programming, US-Intl it's much
| better with the menu/super_r key as the 'compose' one.
| tincholio wrote:
| I'm from South America, and have lived in Europe for over
| 20 years, and I use a US layout, with compose key. It gives
| trivial access to accents and more, without the annoyance
| of different layouts (I used AZERTY for years while living
| in France, and it's just atrocious). I know many people
| here in Finland who code with a nordic layout, and for the
| life of me, I don't understand how they remain sane.
| anthk wrote:
| Also, remember that Nyxt it's a Lisp based browser, so for
| sure has an Emacs layout.
| knerz wrote:
| https://eurkey.steffen.bruentjen.eu/
|
| 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.
| trinix912 wrote:
| That's nice but doesn't include the letters used in
| Slavic languages.
| crabbone wrote:
| I live in Europe and buy my Chinese-made keyboards from
| Amazon, US. In the company I work for, I have not seen a
| single keyboard with "European" layout. People who buy
| those keyboards aren't people who need to be good at using
| their editor, while on the other hand, people who want to
| be good at using their editor will buy a keyboard that
| works well with it.
|
| 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.
| trinix912 wrote:
| Yet nobody here has thought of just localizing the
| shortcuts like Microsoft Office and macOS have been doing
| for ages. Solves this problem very elegantly. Ironically,
| Word is the "professional" editor of most professions
| outside of coding, and people do learn the shortcuts to
| use it effectively.
|
| 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.
| Gud wrote:
| I switch between keyboard layouts all the time, depending
| on which input language I need to use. I simply cycle
| between the langugaes I write in(Swedish, German and
| English) by pressing alt and caps lock.
|
| I accept that U.S. English is the computer lingua franca.
| cobbaut wrote:
| Same (US-qwerty and BE-azerty). Which is easy on a blank
| keyboard.
| chjj wrote:
| The road to hell is paved with UX research.
| eimrine wrote:
| Sadly, but the goal of those UX research is not a user's
| satisfaction.
| cryptonector wrote:
| It's a pity that your negative, flame-baity comment is the top
| comment on this post.
| brabel wrote:
| If you have trouble hitting [ how do you ever program anything?
|
| 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).
| p-e-w wrote:
| Entering [ works just fine on QWERTZ: You simply press
| AltGr+8.
|
| 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.
| brabel wrote:
| I use Cmd+[ on MacOS to "go back" on multiple software like
| IntelliJ, emacs (I probably configured it) and Firefox, so
| I would say this is a pretty common combo. It's easy to
| remember, specially given that the mirror, "go forward", is
| Cmd+]. As I said, even though my first language is not
| English, I only write code in an English keyboard layout so
| I've never even considered that [ is "hard to press".
|
| 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.
| cschmatzler wrote:
| Using [ and ] is completely normal in so many
| applications. QWERTZ just is a bad design, and
| applications shouldn't have to work around that by making
| keybindings more difficult. My team has ~100 engineers in
| QWERTZ countries and I don't know a single one of them
| that actually uses it. QWERTY is the standard order for
| all new laptops. Nobody complains.
| mst wrote:
| Does that mean that one could trap Ctrl+AltGr+8 and map it
| to the same effect? (and the same for 7/9/0 if required)
|
| If so, I'll try and remember that if ever tempted to use
| Ctrl and {[]} together I need to handle that as well.
| zelphirkalt wrote:
| All the time while reading this thread I could not remember
| an issue like that from the time I used Vim/NeoVim. Perhaps
| it somehow did not affect me? At least in Emacs that works
| exactly like it should.
| kagevf wrote:
| Nyxt has a vim mode, but it's more inspired by emacs, and
| therefore fully customizable.
| can16358p wrote:
| This!
|
| 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.
| crabbone wrote:
| > I've been programmer for about 20 years now and I could
| never understand
|
| 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_?
| can16358p wrote:
| Started with Flash/ActionScript. Then C#. Now JS/TS.
|
| 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.
| cryptonector wrote:
| Modal editing exists because the mouse didn't exist then, and
| it continues to exist because modal editing is very powerful
| because you get to be in a mode where you type commands for
| cursor movements, textual transformations, etc., which allows
| power users to be very productive.
| astrange wrote:
| I don't think I've ever seen evidence that emacs users
| actually need to be very productive in their text editor
| even if it works.
|
| 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.
| cryptonector wrote:
| I wouldn't know. I'm a vi user. I don't know how much
| more productive I am with VI than non-modal editors, and
| even if I did know that would just be anecdotal, but I
| _feel_ more productive coding in (Neo)vi(m) than I do in
| any non-modal editor, and it 's much more comfortable
| anyways.
| mpenick wrote:
| Do you have a link for that claim?
| p-e-w wrote:
| > I could never understand why Vi(m) or Emacs exists with
| those weird bindings which are completely different from
| pretty much everything else.
|
| 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".
| mst wrote:
| I use heirloom vi (while making it clear when asked that I
| doubt the person asking me should do the same ;)
|
| 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.
| wkat4242 wrote:
| I think there's more reasons that are not so negative.
|
| 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.
| cschmatzler wrote:
| ... or also because it's significantly more productive than
| any other editor. But hey, it's much easier for you to
| assume everyone making a choice for themselves is part of
| some cult than giving them the ability to think and make
| good choices.
| bornfreddy wrote:
| Vi has a steep learning curve, but once mastered, it is on-
| par or exceeds the best of other editors. It is also present
| everywhere (on Linux at least) and works via ssh as well as
| locally.
|
| 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.
| can16358p wrote:
| I see.
|
| 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.
| bornfreddy wrote:
| I also use keyboard shortcuts (obviously), but in some
| cases it seems impossible to configure them - for example
| maximizing the terminal window vertically seems to not be
| supported by shortcuts.
| orbital-decay wrote:
| A _paradigm_ is something more high-level than a very specific
| keybind conflict. Mature vim mode addons for browsers are
| layout-insensitive. How do you think j /k work on non-Latin
| (e.g. any Cyrillic) layouts? And they do.
|
| That's an oversight of Nyxt in particular.
| crabbone wrote:
| As a long-time Emacs user who also occasionally uses Vi and
| very rarely Vim... but also knows a bunch of people who are in
| the later camp: nobody in that camp buys / uses "non-US"
| keyboards. Even on "US" keyboards, the amount of remapping a
| typical user does to their keys is significant.
|
| 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.
| anthk wrote:
| I am a Spaniard which I learnt to use the ES layout as the 100%
| of the Spaniards and then I realized it sucked a lot for
| programming symbols. If you use Linux/BSD for programmaing and
| don't run something like "setxkbmap us -option ctrl:swapcaps
| -option compose:rwin" (or menu instead or rwin in order to use
| menu+'+a to type a, you are losing your time. Stuff like
| "recogera" can be easily written with menu+' made solely with
| the right hand as a pinch and 'a' with the left key. The only
| issue is 'n' which is a bit cumbersome to type, but there
| aren't many words with 'n' usable in the same context.
| mst wrote:
| The other approach I've seen is having some sort of weird key
| combination (like "hitting both shift keys at once") to
| switch back and forth between two layouts. I saw somebody
| using it for QWERTY vs. DVORAK but it seems like it'd be
| viable for two language layouts too.
| bharrison wrote:
| True, Hackers hate changing settings.
|
| 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.
| mattigames wrote:
| if Vim had the very same problem for US keyboard layouts it
| would have never become the standard choice for "hackers"
| (e.g. in a parallel universe where Vim was created by a
| Japanese for Japanese keyboards), so yeah, in general hackers
| hate when their tools don't work out of the box, hackers
| expect the very basics of any tool to work out of the box,
| changing settings should be a step to accommodate it to your
| liking, not to fix basic functionality.
| tourmalinetaco wrote:
| > if Vim had the very same problem for US keyboard layouts
| it would have never become the standard choice for
| "hackers"
|
| 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 ;)
| mattigames wrote:
| > Not necessarily, since it'd just be a matter of
| popularizing Vim + the community's preferred shortcuts as
| a starter instead.
|
| 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.
| pineaux wrote:
| I love the true scotsman arguments in this subthread.
| Defining "hackers" as this or that.
| Faark wrote:
| Having settings is nice, but I'm not gonna spend a lot of
| time configuring something that I'm not yet sure will even be
| useful to me. Power users of / users already invested in your
| product will use settings to great effect, sure. But defaults
| matter, if you target anyone else.
|
| 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.
| usrbinbash wrote:
| The problem with defaults is, someone won't like them
| anyway, so trying to make them likeable to everyone, isn't
| going to happen, no matter how hard we try.
|
| 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.
| muti wrote:
| Hardly sounds like either a bug or a showstopper when you can
| rebind any command
| p-e-w wrote:
| When a product is unusable without changing configuration, it
| absolutely is a bug. Being customizable is great, but being
| broken by default is not.
|
| 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.
| [deleted]
| alpaca128 wrote:
| _> the whole point of Vim bindings is supposed to be that
| they are the same everywhere_
|
| 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.
| usrbinbash wrote:
| > Besides, the whole point of Vim bindings is supposed to
| be that they are the same everywhere (muscle memory yadda
| yadda yadda).
|
| 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.
| theK wrote:
| I've heard this argument in variations from QERTZ users.
| The thing is, programming was invented with the QWERTY UX
| in mind. The fact that the German keyboard resembles the
| American keyboard for 80% of its Lay-out doesn't change
| that.
|
| You don't hear the Arabic, Chinese or Greek crowds complain
| about this, they just switch layouts.
| RhodesianHunter wrote:
| >When a product is unusable without changing configuration,
| it absolutely is a bug
|
| I don't think that adage applies when the target user is
| the average VIM user
| dexterdog wrote:
| But the average vim user is jumping to new instances
| often, so if he has to reconfigure it everywhere he might
| as well install a different editor with a config.
| alpaca128 wrote:
| I have over 100 custom keybindings in my Vim config and
| can assure you I can still use the default configuration
| without any issues, it's just a bit slower.
|
| The few settings I find really important can just be
| quickly set with a couple commands. No big deal.
| irishloop wrote:
| I am not sure thats true. vim does give you extra utility
| in its availability on a wide variety of server-type
| platforms, but I suspect most vim users are using it
| actively for development on their local (or docker etc)
| boxes
| sodapopcan wrote:
| Yep, lots of us "Vim as a local IDE" users out here. I
| haven't "jumped around machines" in years.
|
| Vim is a nugget of battle-tested familiarity in an
| industry of constant change.
| usrbinbash wrote:
| Lets see, how many commands does it take me to port my
| entire vim config to a new machine? Ah, right...one.
| git clone https://github.com/MY_USERNAME/vim.git
|
| Not exactly what I'd call a difficult or time consuming
| method.
| zamnos wrote:
| you missed the _~ /.vim_ at the end
| evilspammer wrote:
| [dead]
| dirkg wrote:
| Vim style keybindings and navigation is massively overhyped as
| is vim itself.
|
| 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
| xigoi wrote:
| I personally don't like having to use a whole browser engine
| to edit text, and being reliant on a greedy user-hostile
| corporation for it.
| z_open wrote:
| Why do comments like this always ignore the obvious solution
| of using an IDE like code with a vim plugin. And yes that's
| more efficient.
| danieldk wrote:
| I tried vi emulation VS Code for a while, but the emulation
| is often incomplete and breaks at times.
|
| The only thing that emulates vi well enough is Evil in
| Emacs.
| brirec wrote:
| Try embedding a real neovim into vscode: https://marketpl
| ace.visualstudio.com/items?itemName=asvetlia...
| mst wrote:
| There's a class of fanboys who will be telling you about that
| because they're Really Excited that they got it Just How They
| Wanted It.
|
| 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.
| nurettin wrote:
| Have you tried C-u and C-+ ?
| Eldt wrote:
| You're not going to get a default that suits everyone. Stop
| being so sensationalist and just rebind them.
| p-e-w wrote:
| What nonsense. Every single modern operating system has
| bindings that are usable with all keyboard layouts. Having
| such a default is not only possible, it's the status quo
| everywhere, except in software designed during the era of the
| moon landings.
| BeetleB wrote:
| You're not wrong about the poor default keybindings. When
| the effort to fix it on your part is probably less than all
| the time you've spent complaining about it, chances are you
| _really_ are not part of the intended user base.
| colordrops wrote:
| So use a normal browser. Don't use one self-described as
| being for _hackers_.
| RhodesianHunter wrote:
| >Every single modern operating system
|
| 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.
| p-e-w wrote:
| You don't have to "develop" anything, you just have to
| follow the binding conventions for the platform(s). In
| practice, this simply means using
| Ctrl/Cmd+[LETTER/NUMBER] for everything, and the problem
| is solved.
| flagrant_taco wrote:
| Tell that to my pinkies. Reaching for
| Ctrl/Cmd+[LETTER/NUMBER] when navigating entirely by
| keyboard is a really bad idea.
| [deleted]
| wkat4242 wrote:
| Even that won't work everywhere. French keyboards have
| the numbers under shift (yeah really...)
| jan_g wrote:
| Ha, true! But also interesting, how differently we work. I
| switch to national keyboard layout only when I have to write an
| email/chat message with my compatriots or maybe a document that
| needs those national characters. Otherwise, I just use US
| layout for everything. Like 99% of time I'm on US layout. It
| makes much more sense when programming (not just brackets, but
| also quotes, colons/semicolons, slashes, backticks, etc.),
| which is my primary use of computers.
| xigoi wrote:
| I'm Czech and use the UCW layout which works exactly like US
| English, but allows me to enter Czech letters with AltGr.
| It's so much better than the traditional Czech layout.
| linmob wrote:
| Honestly, as a fellow QWERTZ-native, QWERTZ is generally a
| terrible layout for doing any programming in languages that go
| beyond round brackets. Instead have all these umlauts you
| rarely need, even in normal writing, right there - just a bad
| tradeoff.
|
| 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 ;-)
| nier wrote:
| If you're using QWERTY as a QWERTZ-native, chances are you
| have a curious mind that won't settle for the status quo.
| croes wrote:
| Do you know how often I need umlauts if I want a proper
| variable name?
| wuiheerfoj wrote:
| Not sure what language you speak, but in German umlauts can
| always be replaced with an ,e' suffix. Having written
| codebases in German, I've never seen anybody actually use
| special chars in a var names! (probably a carryover from
| the pre-UTF-8 dark ages)
| [deleted]
| thepostman0 wrote:
| Talking of rarely need, most 105-key boards have numeric pads
| that are dust covered. TKL layouts are the future and they
| have an additional fn modifier, maybe there's room here to
| add another purpose to it.
| europeanNyan wrote:
| This sounds like a lot of gatekeeping. QWERTZ types need not
| apply for serious computer use. Even worse are those ones who
| would prefer to write a proper e-mail using umlauts.
| linmob wrote:
| Now, you can complain about gatekeeping, or you can set up
| more than one keyboard layout (I have yet to run into a
| reasonable OS or DE that does not allow for this), and
| switch around when it's appropriate.
|
| 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...
| wkat4242 wrote:
| Spanish keyboards, while QWERTY, are terrible for this too.
| All the special characters are in a weird place and many
| require modifiers.
|
| 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...
| cfn wrote:
| Same here with Portuguese keyboards! I gave up on them 30
| years ago and adopted UK or US layouts. For a long time I
| wrote a kind of pidgin Portuguese due to this but
| eventually learned the Portuguese layout by heart using
| both US and UK layouts.
| okl wrote:
| Try the EN intl layout. Most of the accents are accessible
| using AltGr. Also the ! and ?
| wkat4242 wrote:
| The problem with this is that it works differently on
| each OS. Every day I use Windows, Mac, Linux and FreeBSD.
| I need an input method that is unified in every OS or
| I'll constantly mistype. Apple's different shortcuts for
| copy paste are difficult enough already.
| anthk wrote:
| Using super_r+'+a is not that bad. Super_r+' can be done
| with ease with the right key as a pinch.
| agumonkey wrote:
| Any pointers to research? As an emacser I consider most of vim
| very very :repeat efficient. I'm very much still open to new
| ergonomic ideas though, I just never see any.
| TheRoque wrote:
| I'm curious about what "decades of UX research" improvements
| you are talking about, to me everything about the UI for text
| editors or browsers hasn't improved much in decades. If you
| have a laptop with just a touchpad, chances are you'll never
| get better than vim keybindings. Moreover, the keyboard layouts
| themselves are centuries old.
| p-e-w wrote:
| > I'm curious about what "decades of UX research"
| improvements you are talking about
|
| 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.
| xigoi wrote:
| Vi is several years older than the Ctrl+C shortcut for
| copy. How could it possibly have know that Ctrl+C would
| become a more popular choice for copying?
| spoonfeeder006 wrote:
| Thats a basic principle. But when you say decades of UX
| research you imply actual new ways of doing things
|
| 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
| usrbinbash wrote:
| > Don't surprise me. Blend in. Look and behave like other
| programs.
|
| There is hardly anything in the world that blends in better
| with everythign else, then a terminal application between
| other terminal applications.
| gsinclair wrote:
| That would be a problem if vim was installed front and
| centre on everybody's computer and they were all expected
| to use it. That is not the case. You choose to use it, so
| you either accept, or better yet, embrace that y=copy, or
| you choose to use something else.
|
| 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.
| 8organicbits wrote:
| What are you talking about? I suspect you haven't used vim
| recently.
|
| 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?
| akho wrote:
| But Nyxt (which is modeled on Emacs, not Vim) would blend
| in for me. I spend most of my time in Emacs and Firefox; I
| would prefer a browser that blends in.
|
| 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.
| crabbone wrote:
| > Don't surprise me.
|
| 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?
| usrbinbash wrote:
| > C-[, which cannot be pressed e.g. on QWERTZ layouts because
| the [ character requires AltGr.
|
| 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.
| doctor_eval wrote:
| > Sorry folks, but it turns out that the creators of Vi(m)
| didn't actually invent the ultimate UI paradigm half a century
| ago
|
| 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.
| cryptonector wrote:
| What's key about vi is modal editing. Modal editing is very
| powerful. It also means not having to use the mouse for
| everything and also not having to type too many modifier key
| sequences. For some of us that's absolutely essential to
| avoid deviations that lead to injury.
| doctor_eval wrote:
| I don't really understand. Many of the common bindings in
| Vim use modifiers. How do you navigate back a word without
| a modifier? Do you just exit editing mode like in the old
| days? Do you just forgo this and arrow back?
|
| 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.
| cryptonector wrote:
| Ah, I forgot some context: I use sticky keys, so for me
| shift is not a problem, but I still have bad habits from
| before discovering sticky keys so control and other
| modifiers -and especially multi-modifier combinations-
| are still a problem for me, and vi doesn't use that many
| of those.
| cryptonector wrote:
| > Do you just exit editing mode like in the old days?
|
| Yes! I very much do. I do not use the arrow keys for
| cursor movement in edit mode.
| mst wrote:
| In fact, it got to the point where I realised I was only
| ever hitting the arrow keys by accident while in insert
| mode so my vimrc now contains: inoremap
| <Left> <NOP> inoremap <Right> <NOP>
| inoremap <Up> <NOP> inoremap <Down> <NOP>
|
| (the rest is at https://trout.me.uk/X11/vimrc)
| gsinclair wrote:
| Navigating back a word while in insert mode is just
| unnecessary.
|
| The purpose of insert mode is to insert text, and that's
| it. This occupies a very small proportion of total
| editing time.
| doctor_eval wrote:
| > Navigating back a word while in insert mode is just
| unnecessary.
|
| 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.
| wander_homer wrote:
| Can you provide a concrete example, like a piece of text
| with the current cursor position, the outcome you want to
| achieve and the sequence of shortcuts you're using to
| achieve that with your favorite text editor?
|
| > 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?
| doctor_eval wrote:
| Navigating by word is a matter of holding the Option key
| and pressing left or right arrow. Same number of keys,
| but works pretty much everywhere. The box used to enter
| this comment, for example.
|
| 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"
| wander_homer wrote:
| No, you suggested that leaving insert mode to navigate by
| words is somehow less efficient (since navigating by word
| is your primary way to navigate in lines) and that maybe
| that's why you're happy you stopped using 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.
| wuiheerfoj wrote:
| > Some guys at work used to add Vim bindings to their IDE and
| I just didn't understand it.
|
| 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
| dicytea wrote:
| Did a quick run with it and turned on vi mode from the settings
| menu.
|
| 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.
| mst wrote:
| if it's a fresh field, I think I might turn out to prefer them
| always initialised the same way for the sake of my muscle
| memory.
|
| 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.
| badrabbit wrote:
| You know what would be cool, if you could use unix cli tools in
| the browser. Press control+<space>, a small console box shows up
| and run:
|
| |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 ...
| [deleted]
| GlumWoodpecker wrote:
| This probably wouldn't be possible due to browser sandboxing.
|
| 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
| schemescape wrote:
| > This probably wouldn't be possible due to browser
| sandboxing.
|
| I'm curious about this comment. Surely this should be
| possible using accessibility hooks for a normal browser or in
| Nyxt via scripting, right?
| aidenn0 wrote:
| > 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.
|
| This works less well than it used to now that CMSs and blogs
| are now SPAs that render no text without javascript being
| enabled.
| GlumWoodpecker wrote:
| Yes, that is a shame, but that can be worked around by
| sending it to something like PhantomJS, headless Chromium,
| or any other scriptable browser that will actually run the
| JS on the page and render it in the background. Very heavy
| as you're basically running a full browser in the
| background, but totally doable.
| badrabbit wrote:
| I was thinking of running gnu binaries like that as a WASM
| compiled app/pwa
| newcup wrote:
| The page content piping could be done e.g. like this:
| (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)))
|
| And then call the function like C-space buf-text-to-pipe-cmd
| and specify the commands to pipe to. Output will appear in a
| new buffer that can be further used as the source for piping.
|
| 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.
| mtlmtlmtlmtl wrote:
| You could probably add this to Nyxt in a solid hour or two of
| configuration hacking.
|
| 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.
| sureglymop wrote:
| That is good! I have been creating some add ons for firefox
| and what i dislike the most is that i can't just easily
| modify the UI of the browser itself. I hate that i can't
| change stuff even if i am only creating add-ons for myself...
| bee_rider wrote:
| I've always assumed the major browsers had all sorts of security
| stuff going on behind the scenes, and using a small alternative
| like this (or suckless surf) was just asking for trouble. But, I
| don't have any real knowledge about security stuff.
|
| How misinformed is my take? Are these kinds of browsers OK? I'd
| like something light, if possible.
| smokeypanda wrote:
| Lightweight web browsers don't have as large of an attack
| surface, particularly if they eschew JS, cookies, etc or you
| disable them. Nyxt is alpha software, so YMMV until it's more
| feature complete, and independently audited to correctly
| implement WebKit and WebExtensions. Run Tor Browser without JS
| in a VM for security+privacy.
| jug wrote:
| Hmm, not sure it's for me (a bit too much hacker) but I'd
| definitely like a highly customizable, module based browser with
| a pure shell by default. Something like Visual Studio Code but
| with less cruft from the get go.
|
| 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.
| rakoo wrote:
| uzbl (https://www.uzbl.org/) used to do that but it seems it
| was too heavy in practice.
|
| 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
| tenebrisalietum wrote:
| There was uzbl.
| graderjs wrote:
| I'm building something similar: WebDriver protocol not WebView
| tag, more extensible, written in JavaScript, web tech. Get in
| touch (cris@dosyago.com) if you want to contribute! or check
| out the project: https://github.com/dosyago/BrowserBoxPro /
| https://github.com/dosyago/BrowserBOx
| soulofmischief wrote:
| I commented here [0] and am extremely interested in
| discussing BrowserBox with you. This is something I've
| brought up over and over, I'm an experienced web dev and
| generalist but simply couldn't tackle on my own.
|
| 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.
|
| [0] https://news.ycombinator.com/item?id=36008340
| graderjs wrote:
| Dude! I can't parse your email but like definitely reach
| out to me: cris@dosyago.com :D ;p
| kdrag0n wrote:
| Looks like it's reversed :)
| graderjs wrote:
| Haha I guess i was too dumb to see that! ;p :)
| culi wrote:
| This is a very cool interaction and I hope it turns into
| something. Would love a place to keep up if anything ever
| materializes.
|
| 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
| graderjs wrote:
| Thank you kindly, this is such a good list i want to see
| if i can add it to our projects README.
| RhodesianHunter wrote:
| >written in JavaScript
|
| Really though? Why
| graderjs wrote:
| Two main reasons:
|
| 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.
| graderjs wrote:
| > 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
|
| 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
|
| 1: https://github.com/dosyago/BrowserBoxPro
|
| 2: https://news.ycombinator.com/item?id=35996647
| comfypotato wrote:
| Contemplating my navel, I propose that it didn't happen because
| the purpose of an editor and browser are so different.
| (Realistically the driving factor is that an editor is much
| more useful for making money.)
| wahnfrieden wrote:
| I'm building it
| replwoacause wrote:
| As in... you've been building it, or you just started
| building it because of this comment?
| wahnfrieden wrote:
| I've been building it
| hattmall wrote:
| I use to build my own like this with the VB web browser
| control. I had tons of automation built in for a lot of tasks
| but it becomes too much to keep up with. I've looked into
| headless chrome but it's not as cool as working in the Visual
| Studio and being able to pause and just develop on the fly.
|
| 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.
| culi wrote:
| The web standard really has exploded since that time range
| you mentioned. Nowdays there's a native browser API for text-
| to-speech. It's easier to generate speech for an article you
| wrote than it is to style an option in a native <select>
| element
| soulofmischief wrote:
| So I've ranted about this in various places on the internet...
|
| 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?
| ghostpepper wrote:
| How much work would it be to convert either Firefox /
| Chromium / Nyxt into this instead of starting from scratch?
| micimize wrote:
| There are always going to be limitations to extension-based
| approaches but Firefox with tridactyl is most of the way
| there capability-wise IMO
| (https://github.com/tridactyl/tridactyl). I use that plus
| tree-style tabs and find it excellent. There's always some
| extensibility limitations that break the integration
| though, like extensions getting disabled on mozilla
| domains.
|
| 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
| bovine3dom wrote:
| You can let extensions run on Mozilla domains by tweaking
| some settings in about:config [1].
|
| 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...
| hughw wrote:
| I mean, you're looking at it, but you said it was too much
| hacker.
| jahsome wrote:
| Tridactyl checks my boxes.
| PurpleRamen wrote:
| We basically had this with old Firefox, didn't work out. We
| kinda have and had this with all the small custom browsers,
| like Qutebrowser or Nyxt here, doesn't work either.
| Customizability is a liability, it's work. It comes with many
| problems, responsibility, work for the users, and not many are
| willing to take this. Chrome, Firefox and the others are more
| or less the best we can get regarding balancing customizing,
| stability, security and user-friendliness.
|
| 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.
| revelio wrote:
| Maybe? IntelliJ plugin API is pretty much infinite in scope,
| you can customize nearly anything. Not everything is well
| documented, mind you.
| userbinator wrote:
| For those wondering whether this is a new browser engine, the FAQ
| says:
|
| "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.
| mtillman wrote:
| Really cool. Looks like it supports a good mix of emacs and vim
| bindings.
| beebmam wrote:
| No support for Windows, really? That's unfortunate.
| throwawayadvsec wrote:
| what kind of "hacker" use windows as a main OS though?
|
| windows is only for gaming and testing the software you ship
| deafpolygon wrote:
| What about Windows that makes it unsuitable? In fact, the
| majority of "hacking" and the proliferation of "hacking
| culture" over the history has been done on Windows - not any
| flavor of UNIX like many would have you believe.
|
| Don't gatekeep.
| anthk wrote:
| You wish. Proper hacking has been done under Unixen and
| before, MIT with ITS and Lisp. You don't know anything
| about hacker culture. The cracking one, maybe. Unix and
| Lisp users run circles on Windows' crappy warez culture any
| day.
| throwawayadvsec wrote:
| Windows is good for getting hacked, unix is good for
| hacking
| akho wrote:
| What's a "hacking culture"?
| deafpolygon wrote:
| I did quote it.
|
| https://en.wikipedia.org/wiki/Hacker_culture
| akho wrote:
| I thought you somehow differentiate "hacker" and
| "hacking", because you are not making sense otherwise.
| anthk wrote:
| This. Common Lisp and Emacs' hacker/AI/REPL programming
| world make Windows' cracking culture a running joke.
| xigoi wrote:
| > What about Windows that makes it unsuitable?
|
| It's proprietary and user-hostile, with things like
| tracking and forced updates.
| deafpolygon wrote:
| I agree that aspect is unpalatable for some, but it does
| not exclude the usefulness of the OS to hack on things
| with.
| tptacek wrote:
| Previously: https://news.ycombinator.com/item?id=28623720
| ainar-g wrote:
| https://nyxt.atlas.engineer/faq
|
| > 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.
| mikl wrote:
| Nyxt: The Emacs Superfan's Browser
|
| FTFY.
| tortoise_in wrote:
| Plans to bring on Android?
| mm007emko wrote:
| Keyboard-driven UI on Android? Well, for the brave and true
| hackers (if you don't connect a keyboard to your android device
| which you can ... but why having an android device then?)
| n8henrie wrote:
| Wasn't this just posted last week? And recently before that as
| well?
|
| I remember checking it out, being disappointed about its not-
| great availability for MacOS, and thinking that I should learn
| lisp.
| slondr wrote:
| > Wasn't this just posted last week? And recently before that
| as well?
|
| Yes. Nyxt just had a major 3.0.0 release, and we had a thread
| about that: https://news.ycombinator.com/item?id=35869378
| mikrl wrote:
| > 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.
| n8henrie wrote:
| Thanks, I'll check it out!
| Janymos wrote:
| Really like the idea of a tree-based browsing history. It is more
| in tune with the graph-traversal nature of browsing the internet,
| and could be extremely useful for people who conducts extensive
| reading or research on the internet. Honestly feel like this
| should be an option for more web browsers as an alternative to
| the 1D, flat structure of tabs.
| klntsky wrote:
| No need for a separate browser to do all that - all the features
| exist as firefox extensions.
| sylware wrote:
| Still using big tech c++ diareha of webkit(apple) or
| blink(google).
|
| 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.
| friend_and_foe wrote:
| You can use any engine you want.
| throwawayadvsec wrote:
| In terms of fingerprinting/bot detection, is it flagged as
| suspicious/automated browser?
|
| it would be interesting to have a customizable browser for
| undetectable automation
| [deleted]
| noisy_boy wrote:
| Since we are on the topic of hackers browsers, does anyone know
| if Firefox can be made to split pane (both for seeing the same
| page side by side and also doing it for two different pages)?
| Having done that with file browsers and IDEs, I wonder how come
| it wasn't a main feature? Nobody needed to compare pages side by
| side?
| elashri wrote:
| Actually the had official extension[1] that did that in the
| past but I don't remember and can't find why it is no longer
| available.
|
| [1] https://blog.mozilla.org/en/uncategorized/its-a-new-
| firefox-...
| easrng wrote:
| https://addons.mozilla.org/en-US/firefox/addon/side-view/
| noisy_boy wrote:
| Thanks - this is useful indeed but it is sort of a hobbled
| view - I don't have access to the extensions I have
| installed in the side view. E.g. the main view shows the
| page in dark mode via dark reader but the side view doesn't
| have access to the extension so it has white background
| which is very jarring (better than nothing though). I wish
| they allowed a full-on split - almost like having two
| browser windows (with a common menu/bookmarks bar that acts
| upon the "active" pane).
| dagurp wrote:
| Vivaldi does this out of the box
| hiatus wrote:
| So too does Arc.
| IshKebab wrote:
| > we select and close all buffers
|
| Why would you call tabs "buffers"? It's not a text editor. (And
| that barely makes sense for a text editor anyway.)
| shrimp_emoji wrote:
| Oops, I made a yank-pasta error.
|
| With my
| https://upload.wikimedia.org/wikipedia/commons/7/77/Adm3aima...
| keyboard
| qwertox wrote:
| Does it do regex search? I so often need to do a foo|bar in a
| page.
|
| 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.
| Zetice wrote:
| I think the whole point is you can add it!
| joshspankit wrote:
| Another one I constantly wish for: search for numbers between a
| range
| ivanjermakov wrote:
| You can do that with vimium: https://github.com/philc/vimium/
| issues/367#issuecomment-3535...
| skywal_l wrote:
| TLDR: "Regex support (turned on by the \r escape sequence)"
|
| So, '/' then '\r' and your regex then 'n' or 'shift+n' for
| next/previous.
| aaron695 wrote:
| It's not what I expected from their webpage, I think their Github
| explains it better -
|
| Nyxt [nykst] 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.
| bee_rider wrote:
| Open source intelligence? What's the link, are you speculating
| that it might be insecure or something?
| yosito wrote:
| I just want a WebKit-based browser where everything can be
| controlled by a prominent LLM prompt box. No more clicking
| through constantly changing menus or trying to remember rarely-
| used vim shortcuts, just tell it what you want to do. Bonus if it
| supports continuous voice input.
| dagurp wrote:
| Use Vivaldi then. Just press F2 and you can type any command in
| the browser. You can also use it to search your history and
| bookmarks and do basic arithmetic.
|
| You can also combine commands into so called command chains.
| akomtu wrote:
| Cool stuff. We all need to escape the oligopoly of Chrome and
| Safari. Consider making a build for Android and consider
| inserting a JS polyfill layer that could stub any weird API with
| an extension, without rebuilding the browser (side effect: it's
| an ultimate adblock solution).
___________________________________________________________________
(page generated 2023-05-20 23:01 UTC)