Can you provide some info into how you typically use trackpoint. Which fingers do you use and how do you control the acceleration when going few pixels away or whole screen corner to corner. What about the clicks.
I have a thinkpad and am always curious on how to effectively use it. Even a video of someone using it might help.
Treat it as a tiny proportional joystick, which it is. I use index finger of dominant hand. Press hard and it'll fly the cursor across the screen. Press gently and it'll give excellent precision. If you keep overshooting, you haven't adjusted to gently enough. It is less movement and more thought for pixel perfect precision as you can barely feel any feedback but still get movement.
I always have to turn up acceleration, but rarely sensitivity, in Trackpoint settings a notch or two for my own preference. For me, if I turn sensitivity down, it ruins it. YMMV.
I will left, right and middle click with thumbs as they're just below space and land there naturally.
Thumb on middle and drag to scroll at pressure sensitive speed for as long as you press. No need to "reset" when you reach the end of trackpad or finger on scrollwheel. Two thumbs and index finger means select and paste are almost as fast as vi-only approaches, as it's placed so you're essentially still typing. :)
I realize the original poster responded, but I am currently in the process of going through this transition and my experience may be of use to you.
The thinkpad was the latest machine I got, after a string of macbooks and one XPS-15. I made a concerted effort to switch simply because I'm spoiled on OSX trackpads, and the thinkpad trackpad widget just isn't up to par (especially on ThinkPad + Linux). I asked a few colleagues how they got around the trackpad issue and a couple mentioned they just use the nipple cursor.
It's been a few months now. Changing over was really annoying at first. As the other poster mentioned - the key is learning muscle memory for _sensitivity_ to control the speed of the cursor. A light firm touch with a small pressure in the correct direction is all that's necessary for moderate speed.
I use my left index finger to control the cursor, and my left (spacebar) thumb to at the same time to click/drag/etc (as the mouse buttons are right below the spacebar).
Middle-click + drag-down for scrolling is really convenient.
I find myself having just crossed that midway point where the new system is becoming dominant. The trackpads are starting to feel somewhat unwieldy and cumbersome to me now - even the macbook ones when I use my wife's or friends'. It feels like they require too much hand movement, and are far more "gesticulatory" than gentle pushes and pulls on the nipple cursor.
I think I'm faster with the cursor now than with even high-quality trackpads.
If you do end up trying it out, be prepared to tweak settings a bit to get the right ones for you (and as the other replier mentioned - don't skimp on sensitivity), and be prepared to spend a couple weeks feeling like your hands are tied when you want to move the cursor around.
Interesting to read as I first used one so long ago most of the learning curve is lost to the mist of time.
> It feels like they require too much hand movement, and are far more "gesticulatory" than gentle pushes
Well put. This encapsulates it well.
> I think I'm faster with the cursor now
When I'd got the hang of never overshooting and changing pressure to vary acceleration as I move around, trackpads, even Apple's, just start to feel cumbersome. Quite apart from the need to move hand away from the keyboard so you can't press keys at the same time. It's the thing I miss most on my Mac.
Oh, and just to address the parent's comment that a video might help. Probably not, as there's not much movement to see. Press an index finger on a desk or table and roll your finger around the pad - that's the extremes of movement you should expect with a trackpoint, assuming your finger didn't move on the table at all. :)
I'm left handed, I use my left index finger to manipulate the trackpoint, and my left thumb for any of the three mouse buttons. Clicking the middle button is a middle click, and holding the middle button makes the trackpoint movements act as scrolling.
My laptop is a T450s, running Debian and KDE Plasma. Acceleration is set to medium, and "Adaptive". The key is tuning your sensitivity/accelaration so you can make very fine/slow movements, but also move the cursor all the way across the screen with stronger/faster ones.
A somewhat similar situation happened with India when in 1999, India-Pak Kargil war, the US denied India access to its GPS satellites. It forced India to have its own Regional Navigation System(https://en.wikipedia.org/wiki/Indian_Regional_Navigation_Sat...).
Countries realise that US acts as bully when they can. China just is acting in its own interest. Though as an Indian, I have my own problems with China policies, the US companies crying about IP theft is just them not owning upto their previous actions(of shifting major IP to china due to cheap labour).
It sounds like you many think GPS is property of the global community, and access to it - which the U.S. freely grants worldwide for the public good - is some kind of right. It is not. GPS was financed, developed, and deployed by the United States government, originally for military purposes. It is operated and maintained by the United States Air Force. American taxpayers foot the bill for this maintenance.
If we return to your example, we find India prosecuting a war with the use of American military technology. How exactly is it "bullying" for the U.S. to deny India access to this advanced capability? India is free to fund, launch, and maintain their own GPS alternative for Indian military purposes.
I don't think they use anything in common. Try to set your locale to "C" as otherwise string comparisons will do extra work handling your locale's notions of equivalent characters.
While it sure is possible to do text manipulation in C, I don't think it should ever be the first choice, even if 'fastest' is a goal. A 0 byte is perfectly acceptable in a utf8 string (or any unicode string, really). But C has those annoying zero-terminated strings, so if you want to manipulate arbitrary unicode strings the first thing you can do is kiss the string functions in the C standard library goodbye. Which you probably want to do anyway because pascal-strings are simply better.
> A 0 byte is perfectly acceptable in a utf8 string (or any unicode string, really)
What? My understanding was that utf8 was crafted specifically so that the only null byte in it was literally NUL. That all normal human language described by a utf8 string will never contain a NUL. They're comparable to C strings in that way, where it can be used safely as an end of string marker. If you have embedded NULs, it's not really utf8, is it?
> They're comparable to C strings in that way, where it can be used safely as an end of string marker. If you have embedded NULs, it's not really utf8, is it?
It is. NUL is a C-string convention, as far as unicode is concerned NULL (U+0000) is a perfectly normal codepoint (very much unlike e.g. the U+D800–U+DFFF range).
> My understanding was that utf8 was crafted specifically so that the only null byte in it was literally NUL.
Correct.
> That all normal human language described by a utf8 string will never contain a NUL.
Correct.
> If you have embedded NULs, it's not really utf8, is it?
Incorrect.
NUL is a valid character. If you accept arbitrary utf-8, or arbitrary ascii, or arbitrary 8859-1, then there might be embedded NUL. You can filter them out if you want, but they're not invalid.
It's invalid for unix filenames to have a null character. Therefore, if your application is printing filenames in their unicode representation, it doesn't ever need to consider there to be a null byte. This of course isn't an arbitrary case, but it shows one can make assumptions regardless of the "validity" of a character.
I believe for most cases of arbitrary input, the correct and safe thing to do is to assume a byte stream of unknown encoding.
Since we arrived on this null-character discussion by considering text manipulation in C, I suspect most comments in this thread are made in the assumption that the text must be manipulated in some way (mine are!), so treating it as a byte stream of unknown encoding doesn't really solve the problem.
While null in filenames may be forbidden on Unix (and also on Windows), there are more exotic systems where it is allowed [1]. When writing portable software it's probably best not to make assumptions about what characters will never be in a filename.
Naturally if you have a problem where you can get away with just moving bytes around and never making assumptions about its contents then that is a great solution.
> Which you probably want to do anyway because pascal-strings are simply better.
They're not though. While having an explicit length is great, p-strings means the length is the first item of the data buffer, which is just awful, and why Pascal was originally limited to 255 byte strings.
Rust or C++ use record-strings, where the string type is a "rich" stack-allocated structure of (*buffer, length[, capacity], …) rather than just a buffer/pointer.
That is a fair point, I misunderstood the term to refer to any type of string where the length is stored explicitly. I'll try and refer to them by their correct name ('record strings') from now on :-)
> You can represent it as a struct of (length, char[]) which isn't awful.
It kinda is still: if you're storing it on the stack you're dealing with an unsized on-stack structure which is painful, and if you're not you're paying a deref for accessing the length which you don't need to. If by `char[]` you mean `char*` then it's a record string, not a p-string.
I mean a variable-length array, all stored together.
Presumably you'd allocate it on the heap in general. But a record string also requires a heap allocation.
Most of the time you're touching the length you're probably touching the string data too, so that dereference isn't going to cost very much. And it comes with a tradeoff of more compact local data. So I stand by it being not awful! It may not be perfect, but it's a solid option.
When you have record strings you get slicing for free though. Without the indirection of a pointer you have to copy data when you slice (or you must have a separate 'sliced string' type).
Note that this and that are not necessarily related: you're talking about performing unicode-aware text matching and manipulation, TFA is solely about validating a buffer's content as UTF-8.
They are still mostly not multi-byte string (i.e. unicode) aware after decades of work. I.e. you cannot really search for strings, with case-folding or normalized variants.
This tool only does the minor task of validation of the UTF-8 encoding, nothing else. There are still the major tasks of decoding, folding and normalization to do.
How slow? On my 2013 MBP, `gsed` (sed from coreutils) can do a replacement like that at about 350 MiB/s (of which most seems to be spent writing to disk, since writing to /dev/null hikes it up to 800 MiB/s).
It was sed substitute command on a ~800Mb file on Thinkpad T470 with SSD. It was taking around 40-50 sec for each substitution. Though as others have pointed, it may not be directly related to article in discussion.
>It was taking around 40-50 sec for each substitution.
Substitution should not be really a relevant metric as it wouldn't influence the result much. Sed/Awk will still have to go through the whole file to find all occurrences they should substitute (and when they do find an occurrence, the substitution would take nanoseconds).
The size of the file is a better metric (e.g. how many seconds for that 800mb in total).
Also, whether you used regex in your awk/sed, and what kind. A badly written regex can slow down search very much.
So I went ahead and tried it. To not have `export PIPENV_VENV_IN_PROJECT=1` while creating an environment is giving me an environment with the hash value. This is not good. Looks like I am gonna have to keep creating pipenv environments manually and then import projects into pycharm.
test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 Average
cloudflare 35 ms 58 ms 89 ms 14 ms 14 ms 42 ms 44 ms 35 ms 13 ms 29 ms 37.30
cloudflare2nd 17 ms 16 ms 39 ms 57 ms 26 ms 42 ms 42 ms 64 ms 41 ms 64 ms 40.80
google 93 ms 98 ms 184 ms 246 ms 277 ms 122 ms 97 ms 91 ms 241 ms 82 ms 153.10
google2nd 60 ms 44 ms 43 ms 363 ms 90 ms 103 ms 110 ms 210 ms 10 ms 28 ms 106.10
quad9 284 ms 255 ms 204 ms 479 ms 292 ms 270 ms 282 ms 298 ms 279 ms 283 ms 292.60
opendns 35 ms 50 ms 34 ms 207 ms 42 ms 221 ms 34 ms 94 ms 36 ms 35 ms 78.80
norton 70 ms 80 ms 80 ms 90 ms 73 ms 38 ms 38 ms 43 ms 42 ms 44 ms 59.80
cleanbrowsing 271 ms 275 ms 283 ms 455 ms 333 ms 389 ms 406 ms 273 ms 235 ms 238 ms 315.80
yandex 263 ms 285 ms 304 ms 262 ms 403 ms 172 ms 298 ms 562 ms 222 ms 340 ms 311.10
adguard 346 ms 388 ms 317 ms 457 ms 243 ms 325 ms 396 ms 386 ms 394 ms 328 ms 358.00
neustar 130 ms 213 ms 196 ms 140 ms 281 ms 205 ms 73 ms 114 ms 104 ms 169 ms 162.50
comodo 277 ms 332 ms 252 ms 275 ms 298 ms 267 ms 302 ms 293 ms 277 ms 193 ms 276.60
test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 Average
cloudflare 3 ms 3 ms 2 ms 3 ms 3 ms 123 ms 3 ms 2 ms 3 ms 6 ms 15.10
cloudflare2nd 3 ms 3 ms 2 ms 3 ms 3 ms 2 ms 3 ms 2 ms 2 ms 3 ms 2.60
google 61 ms 61 ms 61 ms 61 ms 64 ms 273 ms 61 ms 64 ms 61 ms 62 ms 82.90
google2nd 1 ms 1 ms 1 ms 1 ms 66 ms 62 ms 2 ms 64 ms 1 ms 1 ms 20.00
quad9 124 ms 126 ms 124 ms 124 ms 124 ms 118 ms 127 ms 121 ms 125 ms 179 ms 129.20
opendns 2 ms 2 ms 2 ms 57 ms 5 ms 261 ms 2 ms 245 ms 2 ms 2 ms 58.00
norton 4 ms 4 ms 4 ms 5 ms 4 ms 4 ms 4 ms 4 ms 3 ms 4 ms 4.00
cleanbrowsing 225 ms 232 ms 235 ms 214 ms 232 ms 225 ms 219 ms 245 ms 233 ms 218 ms 227.80
yandex 136 ms 139 ms 142 ms 138 ms 140 ms 141 ms 136 ms 142 ms 142 ms 142 ms 139.80
adguard 205 ms 205 ms 196 ms 196 ms 217 ms 211 ms 212 ms 197 ms 205 ms 211 ms 205.50
neustar 233 ms 232 ms 236 ms 235 ms 233 ms 243 ms 246 ms 242 ms 232 ms 227 ms 235.90
comodo 132 ms 134 ms 133 ms 133 ms 133 ms 130 ms 130 ms 130 ms 131 ms 145 ms 133.10
For India, they have just two areas: Mumbai and Anywhere else. I am living in Gurgaon(near New Delhi) and it is as expensive as Mumbai in terms of renting an apartment. So Mumbai(0.227) and elsewhere(0.103) is not fair. I guess they don't have much data for elsewhere.
I appreciate them being transparent about this. But the calculator suggested salary was too low for me to consider applying :(
I have a thinkpad and am always curious on how to effectively use it. Even a video of someone using it might help.