Now now, don't be talking about how things are fun and might appeal to newbies or children. Gatekeeping is Serious Business and is not a fit subject for play or enjoyment.
Give compilers some time and the optimizations will be "free" to developers.
Besides, if your application is one where performance is a serious issue, then you are going to spend some time optimizing rather than adding features. For some applications, performance is a feature.
People always seem to forget this in terms of CPU optimizations. It's both good and bad, though. If you're pegged to a given version of a compiler, the point releases likely won't see any optimization while the major releases will likely include additional optimizations for newer chipsets. And I'd wager AMD will be working to get optimizations into both open source compilers as well as things like Visual Studio. One thing to note is that switching to a newer compilker will likely be easier for most of Linux-land as opposed to Windows land. Upping the compiler version with your code compiled in GCC is often much easier than switching to a newer version of Visual Studio due to both cost and dropping older operating systems (the latest won't support Windows XP and Vista for instance, which may matter to some specific business lines and consumer areas).
> Would you do it if you had the choice between that or adding new money making features/fixing bugs?
Of course I would, because people are going to benchmark my software against my competitor's software and choose the one that runs faster on their hardware.
Especially if my software is a compiler and people are benchmarking the programs it produces against other compilers, which is where most of the optimizing actually happens these days.
It's been one of the biggest productivity improvements since moving from 640x480 to 1024x768.
The 1440p is now only used for minor stuff like email and not really necessary anymore.
I soon moved to a 32" 4K at home as well, because I just couldn't stand just 1440 anymore.
One of the interesting parts is that I don't use 4K fully: it's too much surface are and your head tilts too much to see everything at once. But what's great is that I can put a background process as full screen in the background and have a 3500x1800 window in front in which I do my real work. So I can observe the proceedings of the background talks without having to toggle windows all the time.
Agreed, I think 32" 4K is the sweet spot for Linux & Windows. The PPI is 140, which is "marginally retina" -- you can see pixels if you get close. Higher PPI is sharper even once you get past "retina", but it's definitely a case of diminishing returns. But the nice thing about 140 PPI is that you can run without scaling if you absolutely need to. You have to squint and you wouldn't want to do it too often, but it does work for those rare apps that don't scale well.
And the 32" size is about perfect too, IMO. The height is about the maximum you can view without head movement.
While, over time, a lot of today's annoyances with the new Macabook's will fade away, the lack of ESC key is a deal breaker for me.
I tried it at the Apple Store and it's pretty much unusable. (It had the seen issue as the writer, apparently relying on the physical click to know whether or not I had pressed it. In addition, I also mistyped it a lot. Maybe hack to replace the whole touch bar as one single ESC key will do it...)
I've been told to remap the ESC to CAPS LOCK to vim usage, but I seem to be one of a rare breed who uses the latter the way it was intended to be, so that's a no go for me.
> I've been told to remap the ESC to CAPS LOCK to vim usage, but I seem to be one of a rare breed who uses the latter the way it was intended to be, so that's a no go for me.
Not really relevant, but when Vi was originally developed, the escape key was in a more convenient location — right where the tab key is now. It was never intended for users to have to reach that far to hit such an essential key.
> Edit: also, Control-c and control-[ do the same thing.
They're not actually the same. C-[ is the same as Esc but C-c is not.
Using C-c to leave Insert mode won't trigger InsertLeave.
If you select a vertical visual block and insert a comma at the end of each line E.g. C-v}$A,
Using Esc or C-[ to leave insert mode will insert the comma at the end of every line in the paragraph but using C-c will only insert after the first line.
Also if you get used then to using C-c in Vim then you'll potentially run into issues if you try to use it in other Vi places e.g. anything that uses readline or your shell.
IMHO C-[ is a much better solution for these reasons.
You can get C-c to be pretty much identical with a little remap
:imap <C-c> <Esc>
Remapping caps lock would be good too, but I already have caps lock remapped to Ctrl and I'm just used to that. In anticipation of what seemed like the inevitable loss of my escape key, I've been trying really really hard to like Ctrl-[ the last three weeks, but I've just given up. I keep opening up Ctrl-P searches or hitting Ctrl-]. My pinky just can't do it. So I've given up and made Ctrl-C work and it's so much better.
> You can get C-c to be pretty much identical with a little remap
> :imap <C-c> <Esc>
True but you're still out of luck in other Vi like places.
As an alternative I used Karabina in the past to map Caps lock into Esc (when pressed and released) and Ctrl (when pressed with another key). I think you could also make it latch as Caps lock by using Caps-Shift but I'm not 100% on that.
Does anyone know if Karabina has been updated to work with Siera yet?
I've stayed El Capitan because I couldn't think of anything I found compelling in Sierra. I'll probably reconsider when Karabiner-Elements becomes a suitable replacement.
True but you're still out of luck in other Vi like places.
Agreed. I use set -o vi in bash and of course my little remapping is of no use there.
As an alternative I used Karabina in the past to map Caps lock into Esc (when pressed and released) and Ctrl (when pressed with another key).
This was something else I had suggested to me, but while probably about 50% of my computer use on a daily basis is on OSX, the other 50% is linux; for all of xkb's data-driven flexibility, I'm not sure whether it can do something like this. And I can't afford to build muscle memory for something I can only use on one platform.
It can. I've been using Caps Lock as Escape across Linux, FreeBSD, and OS X for 7 years now. The various gui interfaces to xmodmap even have an option to do the flip for you (at least in GNOME, Cinnamon, and KDE).
That's easy - what @Lio was talking about was having Caps Lock be a tap for <Esc> and then holding it with another key would be <C->. Is that what you're talking about? Karabiner can accomplish this on macOS, but I can't find a gconf/gsetting/xmodmap combination to do this on Linux. Caps Lock as Escape is easy. Caps Lock as Ctrl is easy. Caps Lock as both doesn't seem to be possible on Linux.
Am I wrong? Can you point me toward more info on this? I'd really appreciate it - I would so love to be able to use tap-for-escape in all readline contexts.
For vim, you can map tab to being your new esc. Chances are you are using expandtab option, so actual tab usage is not big (it exists though, left here as an exercise for a reader )
Anyway im moving to kabylake dell xps 13. After 9 years with apple. Windows from 2016 gives much better linux integration. And its good to challenge yourselfe with such a big change every 10 years. Its bicycle for your mind (c) Jobs.
In addition to considering a 2015 MBP refurb, I am also thinking about an XPS 15.
I find Windows 10 to be an enormous improvement over 7 and 8; they finally fixed some of the stupid little things that have been issues since NT 3.1. Like the awful terminal emulator or the dialog box for editing environment variables. It seems like Microsoft is finally being run by someone who cares about details.
Work: a metric ton of #defines that are generated by our hardware register addressmap generator, as well as a very particular file naming convention, which has a heavy mix of uppercase.
I actually think this is very relevant, just unknown! It's something I always wondered about Vi, the ESC key is just out of reach of the home row, making it a strange choice for a fundamental operation.
I use jk to exit from insert mode, but you still need an escape key to cancel actions when entering commands. For example if I type :wq and decide I actually don't want to quit, I still need to hit Esc to cancel. It would be nice if :wqjk (or :wqfd) would allow you to cancel but I don't think that's possible is it?
I've always found Ctrl-[ to be more intuitive instead of ESC for vim. Strangely enough I have no idea where I saw that Ctrl-[ works as an alternative and I don't see any reference to it in my vimrc so it should work out of the box. Having to move your left hand all the way over to esc is just slow and cumbersome, meanwhile [ is just right there.
Just clone it into your root directory and ensure it's named ".vimrc". It won't work otherwise. Then just restart your terminal. I'd google some things in there if you don't fully understand what they do.
The escape key is still there, it's on the Touch Bar, I have no issues with using it, and I haven't had to re-map it. Also you can hit the 'fn' key and the 'Function' bar and escape key will appear while using any other 'app' that changes the Touch Bar.
The prime issue is lack of tactile feedback. I wrote quite a bit about this in a previous comment, in that we "touch type" because we get feedback from our fingers. Implementing a "keyboard" interface that requires a change of visual focus is not a good UI practice.
In your comment 25 days ago, you stated that the problem is the layout of the Touch Bar changes regularly, therefore you need to look at it. But this doesn't make sense for the Esc key, because the Esc key is always in the same place on the Touch Bar (and is always available while you're typing).
To me there are a couple problems. One is the changing layout as I mentioned and the fact you have to shift focus constantly because you can't feel where things are (esp since they change from app to app). Then secondly the lack of feedback. I wouldn't mind the touch-bar so much if it hadn't replaced keys that some people use constantly. As an add on above the keyboard, sure... while I wouldn't be crazy about it it could be handy for some people. But half the comments talk about how you can re-map keys to work around it... and that to me spells UI downgrade. A fair percentage of people are perceiving this as enough of a loss in functionality they are finding work arounds.
Esc is always available while you're typing (and usually available when you're not). Holding Fn is for getting at the F-keys, not for getting at Esc (though it can be used for getting at Esc too if you're in a context that normally hides that key).
The touchpad is a good example here. I've got an HP with a large touchpad, and with the buttons implemented in software. It's horrendous to use in a situation where I'm mixing left and right clicks, while expecting the cursor to stay in one place (games, file management in the GUI).
I don't use Macs often, but that's definitely one place where Apple is so far ahead in their implementation that it's not even funny. Using the touchpad for anything more complex than surfing the web is much more comfortable.
Does the 'fn' key force-change the touchbar to display F1-F12?
If so, then I don't understand the folks bemoaning the lack of physical "function keys" from their apps, which I assume they mean that they use the F(n) keys, since the mechanics of this are the same.
I'm a fast touch typist, but have never have hit F(n) keys accurately without glancing at the keyboard when I do use them, so I assume I would have no problem with the TouchBar based F keys.
No. You can set the Touch Bar to show, by default, "App Controls with Control Strip", "Expanded Control Strip", or "App Controls". And you can change Fn so it shows "Expanded Control Strip" instead of the F-keys (e.g. if you never need F-keys). But you can't set the Touch Bar to default to F-keys and require Fn to do something else.
Was it not a problem getting used to it being in a different position? How do you find pressing a key with no physical presence - do you have to look down at it, or are you just used to it now?
