Posted in reply to Mehrdad
On Sat, May 19, 2012 at 09:45:20AM +0200, Mehrdad wrote:
> On Saturday, 19 May 2012 at 06:47:48 UTC, H. S. Teoh wrote:
> >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
OK, I concede. :)
> >>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.
Now that _is_ pretty cool.
Actually I've been thinking about this kind of problems. It's not just code, actually, the problem is much more general than that. It applies to _any_ structured text.
See, the thing is, one of the reasons I like vim in spite of its warts (yes it has warts, including what we're discussing here about syntax trees transformations) is that it gives me a _unified_ environment for working with all kinds of files: text files, XML files, configuration files with their own syntax, code in all kinds of languages, other files with formatted syntax, Python (hehe), and even my 4-dimensional esolang. The unification is very convenient: no need to switch between 15 different tools to work with different file formats. Better yet, you can do things like quote code in emails, write cross-language code, etc., without flinching.
But this unification is also its downfall: plain text, as the lowest common denominator, also suffers from not being able to deal with syntax trees in a meaningful way.
So what is needed is a way of plugging in arbitrary syntax tree parsers, such that you can have a generic editing environment which can handle any structured text, not just code, but _anything_ that can be parsed. You then have a basic core of text-editing operations, plus semantic operations that work with the syntax trees directly.
Now vim actually does have plugin capability, though I'm not sure if it's general enough to do what I just described.
> Try doing that in <your-text-editor-here>
Don't be shocked if you find a vim plugin that does just that. ;-)
> >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 would be really cool if there were syntax tree manipulators that could do stuff like that. Actually, thinking a bit more about what I wrote above, what if there were external parser programs that can do these kinds of transformations, then you can just invoke them to do their magic when you need syntax-tree based manipulations. A text editor really should just do one thing: edit text. With full command-line integration, you can even bind certain operations to external utilities that specialize in whatever language/format they're designed to deal with. Unix philosophy: every program does one thing, and does it really well; connect them together, and you can do stuff no individual program can hope to do, even stuff none of the authors of said programs even imagined possible.
> >It is possible in theory
> key word here :P ^
Ah, but isn't that what we programmers specialize in? Turning theory into reality. ;-)
> >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?).
Actually, vim does have some rudimentary support for moving across scopes. I don't know about statements, though.
> >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.
Ahh laptop keyboard. Honestly, I like the layout better (the standard PC keyboard is way too wide). However, the _size_ of a laptop keyboard is just too uncomfortable for me -- I have rather large hands, you see. After a while, my fingers just feel too cramped.
Laptop keyboards also have the advantage that they can have those nipple things to replace the mouse. This actually makes mouse usage marginally palatable, even for hardcore CLI freaks like me.
> >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.)
OK I admit I was being unfair. See, my problem is, the second I have to deal with rodent navigation and clicking through menus, I just get really really frustrated that I can't just tell the stupid machine to do what I already know I want to do. So any GUI interface just grates on my nerves -- what d'you mean I can't pipe the output of this program into that one? I just don't _think_ like that. It's like being reduced to pointing and grunting instead of using words when you're trying to talk about physics.
> >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!!
I can do that to a limited extent. Still nowhere close to that guy, though. What I can do is like baby-talk compared to his refined bash-speak. :-)
> >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
Same thing happens when a D newbie looks at a pro writing D code with seemingly magical templates and compile-time introspection that does wonders in mysterious ways. :-)
> >(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
Yikes!! GCC is one of the prime examples of makefiles gone horribly, horribly _wrong_. Well, that, and the entire autotools suite, which is exemplary for macros gone wrong.
You do realize that building GCC involves two stages, right? You first build the thing once with your current compiler (which in itself is no mean feat), to "bootstrap" it, and _then_ you use the resulting compiler to compile itself, to produce the final compiler. This is arcane black magic, in the realm of Ken Thompson's "Trusting Trust" (http://cm.bell-labs.com/who/ken/trust.html). Novices and mortals beware.
> >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
Y'know, with my idea of plugins that do specialized things, you might just be able to edit XML in a pain-free way in vim. Hmmm... actually:
Ah, the wonders of opensource. :-)
> >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...)
Yikes! I highly recommend using plain vanilla vim, no GUI, no fonts, no nothing, just pure, unadulterated text. Experience it like it was meant to be used. :-)
OK, maybe I'm just being too extreme here. I'll shut up now.
Perhaps the most widespread illusion is that if we were in power we would behave very differently from those who now hold it---when, in truth, in order to get power we would have to become very much like them. -- Unknown