For those who are wondering what the config setting is:
Finder -> Preferences -> Advanced -> When performing search: Search the current folder
HN user
For those who are wondering what the config setting is:
Finder -> Preferences -> Advanced -> When performing search: Search the current folder
Premature abstraction is the root of all evil.
Interesting proposal for a forward compatible instruction set architecture by Agner Fog:
I don't want a general purpose tree editor. I want a general purpose text editor that understands the semantics of the text I'm editing. One that understands all the various not-necessarily-sexp-based code I'm editing is a tree and supports (ParEdit style) operations on that tree. Especially with languages in the Algol/C family. I think this can be accomplished (eventually) via language servers and editors that speak the Language Server Protocol (LSP) [0].
But I don't need a UI oriented around visually displaying tree-like things. Expanding / collapsing nodes is very meh. Moving / splitting / joining nodes is much more interesting and useful.
As a simple concrete example: changing the order of the parameters (and their type) in a function definition. Wouldn't it be great to 'swap-with-prev-node' or 'swap-with-next-node' rather than copy/paste and dealing with commas? The same operations could swap the order of two fields in a struct or two functions or two classes or any pair of adjacent nodes in a tree.
Or how about moving an 'if' block inside the 'for' block that follows it? Just execute the 'move-node-inside-next-node' (or whatever) command.
This only requires editors that (indirectly) understand the semantics of the text you're editing. Thus far the biggest barrier is all wheel re-invention needed for the cartesian product of all editors and all languages. But that's the wrong approach. We need each language to provide a tool that each editor can use via a common protocol.
This is precisely the point of the LSP. The functionality only needs to be written once per language and per editor. This is totally tractable. I don't know if LSP currently supports the specific tree-manipulation functionality I mentioned, but I'm confident it could.
Does anyone knowledgeable about LSP know if this is already possible, feasible, and/or generally desirable? Are there deal breakers that make this hard / not worthwhile?
I think that's why Stroustrup says "zero overhead" instead of "zero cost". There are costs to many of these abstractions; some at compile time and some at run time. For me, "zero overhead" conveys this a little better.
Another one by ryg: https://fgiesen.wordpress.com/2012/07/21/the-magic-ring-buff...
A funding campaign for Wasteland 3 recently completed successfully! https://www.fig.co/campaigns/wasteland-3
See also Foster's Rule
Interesting page! It links to what is now my new favorite wiki page name:
https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...
Jonathan Blow is currently doing an AMA on reddit right now https://www.reddit.com/r/IAmA/comments/45fu74/i_am_jonathan_...
Rob Pike talks about it here: https://youtu.be/cF1zJYkBW4A?t=29m6s
Apparently, a Vulkan "Hello, world!" program takes about 600 lines of code!
"Elegance" is a slippery slope. I'd much prefer "Clarity".