Mouse or keyboard? BOTH obviously! each are good at different things.
>But you can use programs/extensions with hints like vimfx, surfingkeys, qutebrowser, vim easymotion etc and be just as fast as mouse without moving your hand away!
Yes but the implementation of the mouse is much simpler.
With hints there is no clear standard how it is done: what letters to use for hints? What about different keyboard layouts? How are they combined and prioritized? For selecting text do you use hints for every letter? word? what kind of word? Does the program even have the ability to distinguish words? What about keybindings consistency? What about the extra features that will be needed like switching scroll areas, using text selection hints or link following hints, which come naturally with the mouse?
And if you do drop the complexity for something simpler like vim without easymotion or navigating using navigation keys links/w3m style you end up either being slower or being very roundabout.
>But I still save time not moving my hand!
You save very little time if any at all; you save more time doing automations or making task specialized tools/interfaces.
The mouse is standard, simple and easy to learn and good tool for handling medium to large amounts of unstructured data, don't be afraid to use it.
Mouse is objectively superior at image and video editing. Keyboard for everything else.
>hurr muh time spent on development
Doesn't count. We're all autistic around here. If you spend 5 years creating a car that can go 1000 km/h, you're still gonna call it the fastest car, right?
>>208 The advantage of the keyboard is this: commands for everyday interaction turn into commands for scripting. A command that edits a single line in vim can be turned into a macro which seamlessly edits thousands of lines.
>>209 >Mouse is objectively superior at image and video editing.
Really depends what your doing. For drawing of course the mouse wins, but the tablet beats the mouse. For placing things in specific locations, the keyboard wins again. This is because the keyboard can instruct things like "2/5 of the way from the bottom", whereas the mouse requires you to say "about here". Improved speed is sacrificed to improved accuracy.
>>1018 >Really depends what your doing.
Mouse is better for getting things done quickly, then you use the keyboard to improve the precision. E.g. you want to position a layer "about here", and then use high precision on your keyboard to get it in exactly the right place.
tl;dr you need both for image and video editing.
>>998288 Mouse for image/video editing (other than ffmpeg/IM/vapoursynth, of course) AND the web. Even as a qutebrowser user, I understand that the modern web is basically image clicking, so I use hints sparingly.
>>1036 But links has a retarded codebase (I know, since I patched the file association to work with HTTPS) and is horrible. Say netsurf at least, larper.
>NetSurf — Featherweight browser written in C, notable for its slowly developing (((JavaScript))) support and fast rendering through its own layout engine.
I mean I was going to complain about css but it is much worse...
owo what is this?
>The following REQUIRED_USE flag constraints are unsatisfied:
> any-of ( fbcon gtk gtk2 gtk3 )
So if I am not a framebuffer larper I have to use gtk?
Lets take a quick estimate at the LOC (find . -name "*.c" -o -name "*.h" | xargs wc -l)
>377K netsurf
>196K links
Only being roughly twice as big is pretty good for a browser with both css, some javascript and gtk. Still a big negative though. When installing netsurf there where 16 dependencies, with links there where none.
Yes links codebase seems pretty bad, heard the comments were in czech as well, and having skimmed it trying to change the keybindings I noticed many files with things that seemed unnecessary.
But netsurf despite having a better written codebase does not seem an alternative with all these negatives.
>>1056 >framebuffer larper
If you can get it to work in the fb that is a good thing. I have never gotten the mouse or keyboard to work with framebuffer netsurf.
Do you happen to know if there exists a browser with good HTML5 and CSS3 support, but no pajeetscript? Such a browser would be a perfect fit for this site.
>>1056 M8, you should be happy there's a gtk2 frontend. Sure, an xlib/xcb one would be better, but beggars can't be choosers. Look at the USE flags too, it's very modular.
>Lets take a quick estimate at the LOC (find . -name "*.c" -o -name "*.h" | xargs wc -l)
>not find . -name "*.c" -o -name "*.h" -exec cat {} + | wc -l
Git gud before waving your dick here, boi. Your solution shits itself if a whitespace appears in a filename.
Here's a better solution that doesn't count comments, blank lines nor lines with only a curly bracket.
> find . -name "*.c" -o -name "*.h" -exec cpp -fpreprocessed -dD -o- {} \; 2>/dev/null | grep -vE '^([[:blank:]]*[{}][[:blank:]]*|)$'
| wc -l
With this, I get 43588 for netsurf-all (with all its libraries) 3.8 and 5783 for links. But if we neuter netsurf to be as near to links as possible, we get:
> find buildsystem libdom libhubbub libnsgif libnslog libnspsl libnsutils libparserutils libpencil librufl libutf8proc libwapcaplet Makefile netsurf/{content,desktop,include,utils,frontends/gtk} -name "*.c" -o -name "*.h" -exec cpp -fpreprocessed -dD -o- {} \; 2>/dev/null | grep -vE '^([[:blank:]]*[{}][[:blank:]]*|)$' | wc -l
23413
For something that still supports HTML5 and a LOT more stuff than links (especially on the platform side), this looks okay to me. Especially since it's well documented.
>>1057 You can disable javascript completely at build time for netsurf. And no, only netsurf can give you HTML5/CSS3.
>links is only 3% actual code
I think your script is going a bit crazy; seems to work well on individual files though, and I have already counted more than 6000loc in links with it by using it on individual files.
Mouse or keyboard? BOTH obviously! each are good at different things.
>But you can use programs/extensions with hints like vimfx, surfingkeys, qutebrowser, vim easymotion etc and be just as fast as mouse without moving your hand away!
Yes but the implementation of the mouse is much simpler.
With hints there is no clear standard how it is done: what letters to use for hints? What about different keyboard layouts? How are they combined and prioritized? For selecting text do you use hints for every letter? word? what kind of word? Does the program even have the ability to distinguish words? What about keybindings consistency? What about the extra features that will be needed like switching scroll areas, using text selection hints or link following hints, which come naturally with the mouse?
And if you do drop the complexity for something simpler like vim without easymotion or navigating using navigation keys links/w3m style you end up either being slower or being very roundabout.
>But I still save time not moving my hand!
You save very little time if any at all; you save more time doing automations or making task specialized tools/interfaces.
The mouse is standard, simple and easy to learn and good tool for handling medium to large amounts of unstructured data, don't be afraid to use it.