View mode: basic / threaded / horizontal-split · Log in · Help
May 19, 2012
Re: Posix vs. Windows
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.
May 19, 2012
Re: Posix vs. Windows
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.
May 19, 2012
Re: Posix vs. Windows
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
May 19, 2012
Re: Posix vs. Windows
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
May 19, 2012
Re: Posix vs. Windows
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
May 19, 2012
Re: Posix vs. Windows
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.
May 19, 2012
Re: Posix vs. Windows
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
May 19, 2012
Re: Posix vs. Windows
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
May 19, 2012
Re: Posix vs. Windows
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.
May 20, 2012
Re: Posix vs. Windows
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
1 2 3 4 5
Top | Discussion index | About this forum | D home