On Sat, May 19, 2012 at 04:10:29AM +0200, Mehrdad wrote:
> On Saturday, 19 May 2012 at 01:28:32 UTC, H. S. Teoh wrote:
> >You must be using Emacs with a GUI.
> 
> No, I told you I hate Emacs. :P
> I've seen *other* people do it, and it's horribly slow.

Well, let's just say that Emacs and gui in a single sentence is just a recipe for pain. Especially when you're talking about doing it over the network.


[...]
> >Which is what I mean. GUI's are useless across an SSH connection.
> 
> Ah, ok. That makes more sense than "GUIs are slow over an internet
> connection".
> Yes, SSH wasn't designed for GUIs (or the converse), so of course
> it's slow.

Although, to be fair, the reason for much of this slowness on *nix systems is that X11 is one phat protocol. Trying to to run X11 over a remote SSH session is like trying to parse a 5MB XML file on a 386 with 512k RAM instead of just reading the data directly from a binary file. It's just _asking_ for pain, and lots of it.


> Trying to force GUIs onto *nix systems is like trying to force a command-line tool on Windows... doesn't exactly work the way it's supposed to, and it gives you the wrong impression.

Well... I think a lot of it is that people are used to the way Windows work, and they imagine that _all_ GUIs must work just like that. Which is not true.

On the flip side, X11 was designed in a bygone age, and its age is showing (and rather badly at that). It paid lots of attention to little trivial things that are no longer applicable in today's systems, and as a result performs poorly over the internet. There have been efforts to design a more modern windowing system, but none of them have caught on just yet. One day it's bound to happen, though.


[...]
> >Oh? It's called "rename the method and recompile, get 50 pages of compile errors, pipe it to a grep command that extracts the filenames and line numbers, use sed to transform that into a sed command that automatically substitutes every instance of the matching identifier on the given files/line numbers".
> >
> >See, I told you I was a command-line freak. :-)
> 
> 
> 
> Yes, that's clever. :P **EXCEPT**:
> 
> 1. Compilers (cough, DMD?) generally limit their output to a few dozen errors, so your '50 pages' is kinda off. :P But yea, you could just loop until it works.
> 
> 
> 2. Okay, so that's clever. :P Now tell me what you do when you have dozens of lines in your source file like
> 
> 	@property auto length() { return _range.length; }
> 
> and you want to rename the field 'length'? How do you prevent the second one from getting renamed?

Substitute "length(" with "size(" instead of just "length" with "size".
Problem solved. :-)


> Or say you have
> 
> 	@property auto back() { ... }
> 	@property moveBack() { assert(0, "Cannot move an element from the
> back!"); }
> 	auto popBack() { }    // Remove an element from the back
> 
> and you change the name of the property 'back' to 'last':
> 
> 	@property auto back() { ... }
> 	@property moveBack() { assert(0, "Cannot move an element from the
> last!"); }
> 	auto popBack() { }    // Remove an element from the last
> 
> Notice something funny?

Again, you rename "back(" to "last(" instead of "back" to "last". This is a trivial mistake that anyone who's used vim for at least a year would've known without thinking twice. :-)


> Worse yet, no way in hell that a command-line tool would tell you your documentation is messed up. :P

Oh yeah? And what about when documentation mentions the old name of the method? In which case you *want* to rename it. :-)


> >Well, I _did_ demonstrate how to do it above, given the proper tools and shell support. :-) It's a bit clunky, but hey, it works.  And if you get further compile errors, just look those up (using suitable combinations of grep/sed) and undo the wrong substitutions. Just two steps, and you're done.
> 
> 
> You're done? Or so you think.
> See above.

I did say it's clunky. But it's also a trivial case that one quickly learns and remembers how to deal with correctly. :-)


> >My IDE is called vim. :-P *runs and hides*
> 
> Better than Emacs loll :-P  *also runs and hides*

OK, no need to ignite the flames for that flamewar.


> >You're missing the point. My point was that you can do this with *arbitrarily complex sequences of operations*. Yes search and replace with regex is a specific command that's supported by your IDE, but what about "move one line down, one word over, increment the number by 1 repeated 50 times to repair a table of numbers that had some miscalculations"?
> 
> Visual Studio has a "Record Macro" feature, to record keystrokes and such, but I haven't used it, so I don't know if it does what you want -- but yeah, if it doesn't, I can see why you'd choose Vim/Emacs/whatever.

Plus, you've to keep in mind that integration with arbitrary shell commands add a whole new dimension to this that no Windows-centric IDE can ever hope to achieve. Like "filter selected lines through grep, sed, and this 1-line perl script that transforms the text in ways too complex to express with editor commands". You can even pipe the stuff through an XML parser and query engine, perform tree-based transformations, etc.. Without an adequately expressive shell on Windows, things like these are just unattainable wild fancies. For Linux lusers, they're a reality.

This is because the Windows model is to have the app do everything, handle everything, be everything to the user. If the developers left out the kitchen sink, you're on your own. The Unix model, by contrast, works based on the idea that programs should interoperate, the more the better, so what this program can't do, another can, and the shell provides the unifying interface for mutual invocation. Thus it lets you tie together two programs that the developers never dreamed of putting together, and in that way achieve things they never even conceived when they wrote their code.

Obligatory quote:

	A program should be written to model the concepts of the task it
	performs rather than the physical world or a process because
	this maximizes the potential for it to be applied to tasks that
	are conceptually similar and, more important, to tasks that have
	not yet been conceived. -- Michael B. Allen

This also makes for cleaner, more robust programs, because they don't have to worry about implementing every functionality under the sun: just do what they were intended to do, and let the user hook them up with other programs to add functionality on top of it.

It is possible in theory, for example, to have an external program that parses D code and does queries/transformations on them, and invoke that from vim on a particular section of code. So you can actually do IDE-like operations in vim, which in itself has no idea what D code is. Such is the power of function composition, which the Unix model strives for.


> >It was just for illustrative purposes. It doesn't have to be "repeat n times"; what about "apply operation X,Y,Z until the end of the enclosing block"?
> 
> Uhm, just highlight it and apply the operation to the highlighted block...

What I'm getting at is that logical range modifiers for operations are much more expressive than merely "highlight this, do that". Thing is, in vim the various movement keys can be applied as modifiers to a particular action. So instead of going "start highlighting, move 6 lines down, 13 columns across" you effectively say "lowercase all text from here till 2 paragraphs down, 5 words across". "Lowercase" is a basic operation, which is modified by a range specified in terms of logical units, like paragraphs and words. And because these are logical entities, not physical positions, the same command can be applied to vastly different parts of the text and still have the same logical meaning. That is, 2 paragraphs in this case may span 6 lines, but in another part of the file it may span 8 lines. By using logical positioning units, you can have the same command apply to both correctly without having to tediously construct the physical distance each time.


> >It sucks to have to open 15 different apps and waste time switching between them when I could do everything without my fingers leaving the keyboard for 1 second (and without focus-distracting cycling through windows).
> 
> My hands don't leave the keyboard too often either... even the basics Alt-Tab/Ctrl-Tab/F8/PageUp/PageDown/etc. get the job done fairly well, and the mnemonics (e.g. Alt-O to hit the button with "O" underlined) make it 10x better.

Eeek! On most modern keyboards, PgUp/PgDn, etc., are so far out of the way that you might as well reach for the mouse. Funnily enough, one of the things I hated the most about vim was its modality. But now in retrospect, it makes SO much sense. In command mode, all your alphabetic keys can be put to good use, so your fingers never even leave typewriter position. The only bad design in vi/vim is the overuse of Esc (which is slow because of a maldesign in early unix terminal emulation, and also causes my fingers to twitch for the upper left corner of the keyboard every now and then). Besides that, everything is lightning fast because there's no need to reach all the way up to the F1-F12 row of keys, nor the badly-placed PgUp/PgDn/whatever keys. One can essentially type at maximum typewriting rate and perform editing commands at that same rate. It's so efficient that it's addictive. Once you taste that kind of power you never want to go back to the bad ole world of reaching out for obscure parts of the keyboard every 4 seconds.


> >Your example went over my head, 'cos I haven't used windows in any serious way for at least 15 years. :-P
> 
> lol ok. If you get the chance sometime, might wanna give Windows 7 a try. :P

Yikes. I wouldn't touch Windows 7 with a 20-foot sterilized flagpole. XP was the last usable version of Windows in many senses of the word. There's a reason the adoption rate of Windows 7 is significantly slower than MS would like. But I freely admit I'm heavily biased, so take that with a 1kg grain of salt.  :-P


> Last time I used Linux was a few days ago (Ubuntu) so I guess I'd naturally have more to say about it haha.

Now don't get me wrong, Ubuntu is doing a very good thing in making Linux accessible to the masses, but frankly, you haven't _really_ used Linux until you've mastered the command-line and can regularly compose long chains of pipes that does magical transformations to data without thinking twice. In my previous job, there was a part-time contractor who regularly writes 5-line long bash commands complete with subshells, multiple redirections, obscure sed/grep tricks, AND HAVE IT ALL WORK THE FIRST TIME ROUND WITHOUT NEEDING TO HIT BACKSPACE EVEN ONCE. Seriously, the guy just breathes bash command lines like a fish in water, it's uncanny. Sometimes you just stare at him compose these incredibly complex commands and your jaw just drops to the floor in amazement. Your first thought is "that can't possibly work! Isn't that a typo right there?! He spelt that option wrong!" and then the next second, your eyes are popping out of their sockets, "what the... it WORKED?!?!?!".

Sufficiently advanced shell commands are indistinguishible from physics-defying magic. ;-)


> >Stop right there. Project settings, eh? lol...
> 
> Better than configure.in/configure/makefile.in/makefile/all that crap. :P

On that, I heartily agree. Autotools is the hellspawn of all evil, next in line to XML and Javascript. Well, ANYTHING that uses make is, frankly, the hellspawn of evil just by association. Use SCons. :-)


> >For me, an SConscript does my project management way better than
> >any IDE project settings could ever do.
> >[...]
> >Now try writing an IDE that can do all of _that_ in one go. :-P
> 
> I gotta use SCons, haven't used it before :)

Yeah, throw out your makefiles, they're from before the last ice age and reeks of poor holey design. Use SCons, or any of the much saner modern incarnations of build tools that aren't dainbramaged. (If you've ever had to deal with the monstrosities that are makefiles for very large (>2 million lines of code) projects, you'll understand why.)


> >XML is the spawn of evil, next in evilness only to Javascript, but I digress. :-P Seriously though, you could just use xmlstar (google for it) if you really have to. XML is not meant for human consumption. Only machines can process that horribly tedious stuff without its brain turning into a pretzel.
> 
> Haha okay well if you claim the entire STACK of tools is evil then I guess I can't help you there lol.

OK, I think I went a bit overboard with the hyperbole there. All I wanteed to say, really, is that XML is designed for machine processing, not for human processing. Trying to edit XML by hand is like trying to render a 3D animation with a magnet, a tweezer, and very very steady hands over the opened casing of your video card's GPU. Trying to read XML is like trying to give a speech while decrypting your GPG-encoded notes in your head in real-time. It's just not meant for manual manipulation. You _want_ to use specialized tools for working with it, unless you're into masochism.


> >You don't know what you're missing.  No, really. Trust me, I know, because I used to hate them too. I hated them so much, that I wrote (well, tried to write) my own editor just so that I didn't have to use them, when pico just didn't cut it anymore for doing serious work.  And then my supervisor at my first job made me learn vim. Which made me hate it all the more. Until one day, after investing lots of time (and venting lots of frustration) into learning how to use it properly, it suddenly all *clicked*.  Try it sometime. You might find yourself liking what you thought was impossible not to hate, ever. :-)
> 
> 
> Haha I definitely will. I actually never thought they were /bad/ (they're just hard to learn and unintuitive, and so I hate them) but I definitely agree, I could certainly give them another chance and perhaps like them. Will give them another try when I get the chance. :)

Well I applaud your willingness to try. :-)


T

-- 
Lottery: tax on the stupid. -- Slashdotter

On Saturday, 19 May 2012 at 06:47:48 UTC, H. S. Teoh wrote:
> One day it's bound to happen, though.

Yeah I'd heard about some similar stuff too, waiting to hear about it.


> Substitute "length(" with "size(" instead of just "length" with "size". Problem solved. :-)


Er, you missed the entire point of my example. :\

Those were PROPERTIES. They are used *without* parentheses. Your solution doesn't actually work on them. :P



>> Worse yet, no way in hell that a command-line tool would tell you your documentation is messed up. :P
>
> Oh yeah? And what about when documentation mentions the old name of the method? In which case you *want* to rename it. :-)


My answer might suprise you then... you should _REALLY_ try using a real IDE to get a feel for what I'm talking about.

Eclipse actually _automatically renames_ identifiers inside your documentation comments.
All it takes is Alt+Shift+R to say you want to rename an identifier, and it corrects all references _as you type_.
With 100% accuracy, I might add. Unlike the CLI-based solution, it's NOT a half-baked text-based solution. AFAIK it uses the syntax tree.

Try doing that in <your-text-editor-here>

:P


> I did say it's clunky. But it's also a trivial case that one quickly learns and remembers how to deal with correctly. :-)

Again, see above.
Your solution fails miserably when you're working with properties like In my example, since those don't have any parentheses.


> Plus, you've to keep in mind that integration with arbitrary shell commands add a whole new dimension to this that no Windows-centric IDE can ever hope to achieve.


+1 yes, it's powerful indeed. But they're all text-based.

Editing source code with text-based tools is error-prone. Editing them with an IDE that uses the syntax tree is not.

Simple as that.



> It is possible in theory

key word here   :P    ^


> Thing is, in vim the various movement keys can be applied as modifiers to a particular action. And because these are logical entities, not physical positions, the same command can be applied to vastly different parts of the text and still have the same logical meaning. That is, 2 paragraphs in this case may span 6 lines, but in another part of the file it may span 8 lines.

Yes, that's very powerful. But again, it's for *TEXT*, not CODE.  Unless your editor can go "two scopes down and six statements to the right", what you're saying doesn't really work for code (or maybe I'm not understanding it right?).



> Eeek! On most modern keyboards, PgUp/PgDn, etc., are so far out of the way that you might as well reach for the mouse.


Lol, 100% correct -- except in my situation. :P

I code on my laptop, and it's Fn+Up and Fn-Down. Home/End are Fn-Left and Fn-Right.
Takes a little getting used to at the beginning, but it's VERY handy. :)

Especially compared to ESC, as you mentioned.


> Yikes. I wouldn't touch Windows 7 with a 20-foot sterilized flagpole. XP was the last usable version of Windows in many senses of the word.


If you haven't used it then you can't really say that now, can you? (If you're thinking of Vista when you think of 7, FYI it's on the opposite end of the spectrum from Windows 7. And if you don't like the looks, you can always switch to an XP-like theme, like me.)



> There's a reason the adoption rate of Windows 7 is significantly slower than MS would like.

I thought it was doing well?

But yeah I just swallowed your chunk of salt, thanks. :P



> Now don't get me wrong, Ubuntu is doing a very good thing in making Linux accessible to the masses, but frankly, you haven't  _really_ used Linux until you've mastered the command-line and can regularly compose long chains of pipes that does magical transformations to data without thinking twice. In my previous job, there was a part-time contractor who regularly writes 5-line long bash commands complete with subshells, multiple redirections, obscure sed/grep tricks, AND HAVE IT ALL WORK THE FIRST TIME ROUND WITHOUT NEEDING TO HIT BACKSPACE EVEN ONCE. Seriously, the guy just breathes bash command lines like a fish in water,


My God, how I wish I could do that! :O As much as I'm not a Linux fan, I still want that ability -- it can be very *very* useful in quite a few situations!!


> it's uncanny. Sometimes you just stare at him compose these incredibly complex commands and your jaw just drops to the floor in  amazement. Your first thought is "that can't possibly work! Isn't that a typo right there?! He spelt that option wrong!" and then the next second, your eyes are popping out of their sockets, "what the... it WORKED?!?!?!".

I've seen 1 person who did stuff *close* to what you're describing... and yes, my jaw dropped indeed, so I know what you mean perfectly. it's... out of this world... x___x


> Sufficiently advanced shell commands are indistinguishible from physics-defying magic. ;-)

+1


> (If you've ever had to deal with the monstrosities that are makefiles for very large (>2 million lines of code) projects, you'll understand why.)


Spending days on end trying to compile GCC and GDC (and ultimately failing) was more than enough time wasted for the rest of my life, so I know perfectly what you mean. xD


> You _want_ to use specialized tools for working with it, unless you're into masochism.

Haha right, that's why I don't really edit XML text directly. xD


> Well I applaud your willingness to try. :-)

Thanks, I downloaded GVim a few hours ago. Now to find some time to learn it haha... it turns me off pretty badly every time I open it (hell, it doesn't even save my font settings...)