On May 18, 2012, at 7:10 PM, "Mehrdad" <wfunction@hotmail.com> wrote:
> 
> 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?

sed using a regex that accounts for more of the line than just "length", like " length(".  It only gets tricky if you are renaming a method call with a non-unique name, which is when you need to use compiler output to flag the offending lines since pure text analysis won't cut it.

> 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?

Three operations, one for each method actually being renamed. Ultimately, it's hard to replace a real refactoring tool since it has a compiler built-in though. That said, I don't personally do this kind of thing... pretty much ever. So using a special tool when needed seems like an option.

On Saturday, 19 May 2012 at 13:49:28 UTC, Sean Kelly wrote:
> On May 18, 2012, at 7:10 PM, "Mehrdad" <wfunction@hotmail.com> wrote:
>> 
>> 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?
>
> sed using a regex that accounts for more of the line than just "length", like " length(".  It only gets tricky if you are renaming a method call with a non-unique name, which is when you need to use compiler output to flag the offending lines since pure text analysis won't cut it.
>

Somehow I fail to see how this is more productive than doing a "rename method"
option.

Am 19.05.2012 15:35, schrieb Sean Kelly:
> On May 18, 2012, at 5:39 PM, "Mehrdad"<wfunction@hotmail.com>  wrote:
>>
>> Yeah, imagine trying to name a method named "getValue()" to something else (probably because you realized that's not a great name :P).
>>
>> A HUGE time waster without refactoring tools, and last time I checked, no text-based tool did it.
>
> Possibly because this can be accomplished from the command line with find/grep/sed and the like.

While wiping everything else that is also called getValue() along the way, even if they belong to instances of other classes.

I like UNIX and the command line is invaluable for certain tasks regardless of the operating system, but sometimes I wonder if people realized that it is no longer 1970 and better ways to develop software do exist.

--
Paulo

On Saturday, 19 May 2012 at 19:28:44 UTC, Paulo Pinto wrote:
> I like UNIX and the command line is invaluable for certain tasks regardless of the operating system, but sometimes I wonder if people realized that it is no longer 1970 and better ways to develop software do exist.

…especially because it would be perfectly possible to provide a command-line interface to »intelligent« (i.e. frontend-backed) refactoring tools as well.

David

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>
> 
> :P

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.

True.


> >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:

	http://www.vim.org/scripts/script.php?script_id=301

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.


T

-- 
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

On Saturday, 19 May 2012 at 20:00:03 UTC, H. S. Teoh wrote:
> Now that _is_ pretty cool.

:D yes!

> 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

Indeed, that's one of the major reasons people use text editors over IDEs for a lot of tasks.


> Don't be shocked if you find a vim plugin that does just that. ;-)

I dunno, I might be xD


> It would be really cool if there were syntax tree manipulators

Omg yeah. And I think D is probably the closest to getting something like that.

I remember asking about whether something like this this in StackOverflow, but (perhaps because I didn't phrase myself properly) people didn't really understand what I was saying and I kinda got blank responses lol.


> Ah, but isn't that what we programmers specialize in? Turning theory into reality. ;-)

Touche


> Actually, vim does have some rudimentary support for moving across scopes. I don't know about statements, though.

Yeah, editors often have brace-matching and stuff ("go to matching/enclosing brace") but yeah, not statements.


> 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

Yup, I've been debating if I want a real-sized keyboard or not... might order one these days. :)


> 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.

Totally understand what you mean -- I could say the same thing for *nix tools, just the other way around. (Why can't I *browse* my choices? why do I have to look at /documentation/, for God's sake, to figure out how to just locate a file on my computer? etc.)


> Yikes!!

Indeed, that says it all. xD

> You do realize that building GCC involves two stages, right?

Someone told me like a year later. XD


> 	http://www.vim.org/scripts/script.php?script_id=301
> Ah, the wonders of opensource. :-)

:) I have a love-hate relationship with OS. It's among the greatest things in CS but it also has its own problems. I was going to post a link to a blog post I read about it, but while I agree with it, it's a little harsher than my view, so maybe not. xD


> Yikes! I highly recommend using plain vanilla vim, no GUI

Oh geez, that'll take a while lol. At least with GVim, I can discover the command names through the menus haha.

H. S. Teoh wrote:
> 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.
> 
	You mean like Emacs' Semantic mode?
https://www.gnu.org/software/emacs/manual/html_node/emacs/Semantic.html

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On Saturday, 19 May 2012 at 20:58:40 UTC, Jérôme M. Berger wrote:
> 	You mean like Emacs' Semantic mode?
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Semantic.html





O_O

On May 19, 2012, at 1:35 PM, "Mehrdad" <wfunction@hotmail.com> wrote:

> On Saturday, 19 May 2012 at 20:00:03 UTC, H. S. Teoh wrote:
> 
>> Yikes! I highly recommend using plain vanilla vim, no GUI
> 
> Oh geez, that'll take a while lol. At least with GVim, I can discover the command names through the menus haha.

The only way to really learn vim is to suffer through it until it clicks. The experience is so fundamentally different than other editors, that menus would just prevent that from happening. That said, some editors, like Sublime Text 2 (my current favorite) have a vi mode that functions pretty closely to how vi does. It's another way to ease your way into the vi mindset, as it were. Personally, I know enough vi to get around but not enough to prefer it. It's simy a matter of necessity though, as vi is the only editor I've found installed on every system I need to edit on. Too bad it couldn't at least be vim though.

On Sat, May 19, 2012 at 04:53:32PM -0700, Sean Kelly wrote:
> On May 19, 2012, at 1:35 PM, "Mehrdad" <wfunction@hotmail.com> wrote:
> 
> > On Saturday, 19 May 2012 at 20:00:03 UTC, H. S. Teoh wrote:
> > 
> >> Yikes! I highly recommend using plain vanilla vim, no GUI
> > 
> > Oh geez, that'll take a while lol. At least with GVim, I can discover the command names through the menus haha.
> 
> The only way to really learn vim is to suffer through it until it clicks. The experience is so fundamentally different than other editors, that menus would just prevent that from happening.

Exactly. Until you've grappled with GUI-less vim, you haven't _really_ used vim. I did say that it was a very frustrating experience for me. But when it clicked, it _really_ clicked. Now I couldn't bear to use pico or joe or any of that stuff. They've become so foreign to me.

It's one of those things that have a totally steep learning curve, but totally worth it once you get it. Just like console Linux/bash. (Even I myself find it hard to believe, but there was a time when I used to _hate_ Linux.  Yeah.) Or ratpoison (aka how to use a GUI without a mouse). :-P


> That said, some editors, like Sublime Text 2 (my current favorite) have a vi mode that functions pretty closely to how vi does. It's another way to ease your way into the vi mindset, as it were. Personally, I know enough vi to get around but not enough to prefer it. It's simy a matter of necessity though, as vi is the only editor I've found installed on every system I need to edit on. Too bad it couldn't at least be vim though.

Ugh. Plain vi (non-vim) is a bear to use. Many non-vim vi's have an undo buffer with a depth of 1. And it just goes downhill from there. :-P

But at least, once you've eased into the vim mindset, you can navigate around inferior vi's without stumbling into electric fences and stubbing your toes.


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel