joe is still better. nano caught up lately, but joe ditto
GNU nano is my editor of choice
231–236 of 236 posts
Re: GNU nano is my editor of choice
#232Earlier quoted context omitted.
> Simple. Programs should themselves be programmed(Generated). Anything that has a structure should be generated, never written. This is the idea behind compilers/assemblers. And if you extend that idea, that's true for some thing like Python too. If the code -- I assume that's what you mean by program -- is generated, the code is not the true source of the program. The true code should be the code that describe or i…
We write a lot of recipe'ish code all the time. That should really be templated. Nobody should write fileopen-read-close repeatedly over and over again. The editor should write this kind of code for you.
No, the compiler or preprocessor should process a higher level instruction that you write using the editor. The editor can run the preprocessor or compiler or a chain of them with single click and load or view any intermediate code with convenience of course, but none of the generated intermediate form should be written or saved in a repository.
Re: GNU nano is my editor of choice
#233It's worth pointing out that many distros ship with a positively prehistoric version of nano (i.e. v2.9), whereas the latest version is actually lightyears better. I agree with the author completely. As for the "yes but vim keystrokes" apologists, honestly I have yet to find something truly important I can do with significantly less keystrokes in vim. (especially if you factor in programmability and macros).
Do you not use motions? I use stuff like `dfXa` where X is the character I want to delete to, for example. I could do 23x, d6w, or d/foo , depending on the information I have, either way this is light-years faster than what I can do without motions. Macros and programmability are great, but they are more for boilerplate stuff than just one-off mangling text fast. You can also hit the arrow keys in sed mode to reuse o…
My claim is not that motions and the like are not useful constructs. My claim is that most functionality of this sort, whose use-case is not contrived or trivial, has equivalently low-keystroke solutions in nano; these often tend to be more intuitive as well, and sometimes require even less keystrokes/keyboardtime than vim (especially considering the whole enter/exit edit mode extra keystroke, which tends to be conveniently absent in keystroke wars).
E.g. dfXa -> Mark, Search, X + Enter, Delete d/foo -> Mark, Search, foo + Enter, Delete d6w -> Mark, EndOfWord x 6, Delete (or store 'EndOfWord Delete' as a temp macro, and use a predefined repetition command)
To me, '23x' (and to some extent even d6w) is an example of a contrived use-case; while you can come up with ways to minimize keystrokes for such a scenario in nano too, in reality if you have text or code where you need to find the 23rd instance of a character EXACTLY, there's something REALLY wrong with your code/text, in which case '23x' is the least of your problems. In all non-trivial/non-contrived cases, if you need to look up something 23 times, you're probably going to want to walk through those instances as well, and the act of 'counting first then executing the incantation' is likely to cost you far more time spent on the keyboard than what is saved by minimizing keystrokes. And if you really, really need something as arcane as that, and use it often, then you can write a relevant macro easily. No need to bother regular users with that bloat.
Somebody else here already mentioned the ^U^U^U^U^U^K vs y5p comparison: this is a prime example of the above philosophy, and I agree. Keystrokes are saved at the cost of actual time spent on the keyboard. At the end of the day, I'd much rather spend 5 seconds on 10 keystrokes, than 10 seconds on 5 keystrokes. And in practice, most people would use a selection instead anyway, resulting in more keystrokes in vim compared to nano to begin with.
Re: GNU nano is my editor of choice
#234Earlier quoted context omitted.
I get the sentiment that having features like "go to definition/implementation" can encourage poor code structure, but that is still ultimately a self-discipline issue more than a UI issue. There are tools for enforcing good code structure that work with many of these fancy IDEs (Visual Studio included). Just hitting F12 over an identifier to go to it's declaration will always be faster than manually navigating to it…
> Just hitting F12 over an identifier to go to it's declaration will always be faster Nope - even if you need only one hit, you are now mildly disoriented and need to re-establish mental context in order to correctly interpret what you are reading[0]. Often, you need multiple hits to reach what you needed, in which case you are completely lost outside the single method body you're starting at. This cost is hidden, an…
Multiple hits? Maybe in a dynamically typed language, but in a statically typed language a good IDE will know exactly what definition to go to 99% of the time. I mostly only have to pause and look at options when using the feature on an interface with more than one implementation.
Re: GNU nano is my editor of choice
#235Earlier quoted context omitted.
We write a lot of recipe'ish code all the time. That should really be templated. Nobody should write fileopen-read-close repeatedly over and over again. The editor should write this kind of code for you.
No, the compiler or preprocessor should process a higher level instruction that you write using the editor. The editor can run the preprocessor or compiler or a chain of them with single click and load or view any intermediate code with convenience of course, but none of the generated intermediate form should be written or saved in a repository.
>>No, the compiler or preprocessor should process a higher level instruction that you write using the editor.
Yes. Macros.
Only Lisp has it. No body really uses Lisp. And languages like Python don't have it. So we have to use these hacks for the mean while.
Re: GNU nano is my editor of choice
#236Earlier quoted context omitted.
Do you write code in BBEdit? VS Code feels way more capable, at least at first glance, but I know BBEdit fans have a lot of love for it. I ask because I'm growing a little tired of VS Code. It works nicely, but it never feels like a native editor. BBEdit, and Panic's Nova, feel like I'm actually using a Mac. I'm trying to decide if either of those are better than (or at least as good as) VS Code.
Yes, I write my own code in BBEdit. When there's no collaboration needed, it's more than adequate, and the Mac integration (AppleScript API) is great. VS Code is good for git blame integrations, finding references to functions in a deeply nested project, and using extensions. It's an IDE, not just a text editor. So I suppose it depends on your use case: if you're the only developer, a text editor is enough. If you're…
Thanks! That's the kind of perspective I was looking for.