On Sat, 14 Sep 2013 01:11:52 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> (instead of whatever dreary soundtrack or cartoon popping sounds the app author feels I must endure through),

I hate those sounds. Disc ripping/authoring software seems to be the worst, with their patronizing new age-y jingles every time anything finishes/fails.

> and as long as skype can
> pick up my voice and transmit the other person's voice, that's good
> enough.
> 

Is the Skype software any less dreadful on Linux than it is on Windows? It used to be that even the close button doesn't work properly, *by design*. But last I looked, the damn thing no longer even *allowed* you to end the glitchy resource-draining process *at all*. And that's just one small aspect of the program.

I love the Skype service, but (at least on windows) the software seems committed to forging new ground in "crapware". The android version didn't seem nearly as bad though, but even that had a *lot* of user comments posted about its overall quality and reliability taking a steep nosedive. That was about a year ago though.

On Fri, 2013-09-13 at 14:29 -0700, H. S. Teoh wrote:
[…]
> Why can't I move down by 12 paragraphs instead of hitting the down key 120 times?! (Which, incidentally, takes only 3 keystrokes in vim: '12}'.)

OK Vim beats Emacs on that one, for Emacs it Esc 1 2 Ctrl+Down, 4 keystrokes.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Fri, 13 Sep 2013 23:55:55 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
>
> But I dunno, IME, when Windows 3.1 came
> along, it had so many gratuitous limitations that I said to myself,
> this sucks! So now I can't have direct access to hardware in the name
> of "protection", and what do I get in return? Nothing but being
> straitjacketed into a system that can't even do what I want.

OMG, iOS and Android == Win 3.1! Why did I never notice that before!

On Saturday, 14 September 2013 at 07:28:33 UTC, Nick Sabalausky wrote:
> Yea, notepad has *not* held up well. It's pretty awful. I occasionally
> use it to remove formatting from text I'm copy-pasting, and that's
> about it.
>

Many programs support Ctrl-Shift-V for pasting plain text.

Am 14.09.2013 10:40, schrieb H. S. Teoh:
> You're right that the most annoying thing
> about having a "real" debugger is the fact that you can't step
> backwards.

I've always wanted to try this:
http://velvetpulse.com/2012/11/27/scribe-the-deterministic-transparent-record-replay-engine/

It looks extremely powerful

On 14 September 2013 05:48, Namespace <rswhite4@googlemail.com> wrote:

> Just out of interest.
>
> I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD.
>

Visual Studio on Windows, and MonoDevelop on !Windows.
Eclipse occasionally, because Google technology doesn't integrate with VS
very well.

On Friday, 13 September 2013 at 21:00:14 UTC, H. S. Teoh wrote:
> On Fri, Sep 13, 2013 at 01:40:02PM -0700, Andrei Alexandrescu wrote:
> Syntax highlighting hurts my eyes. I've been using vim in black-on-white
> for more than a decade now. (Well, more accurately, black on an almost
> fully saturated off-white, but that's irrelevant.)
>
>
> T

Have you taken a look at solarized? I used to find my eyes straining after a few hours with syntax highlighting until I started using it, now I can stare for days at a time without issue.

http://ethanschoonover.com/solarized

Unfortunately it's a bit of a pain to set up for command line vim since you need to configure your terminal emulator too - well worth the time though! If you have gvim installed that's probably the easiest way to try it out and see how you feel about it before committing and setting it up properly.

Relevant lines for your .vimrc:

syntax on
" You can set it to dark too for a light-on-dark different theme
" I use dark - I figured light would be most similar to what you
" currently have with black-on-white. You can see samples of
" each on the page linked above
set background=light
colorscheme solarized

On 14 September 2013 08:23, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> On Fri, 13 Sep 2013 23:30:55 +0200
> "Namespace" <rswhite4@googlemail.com> wrote:
> >
> > I'm suprised that so few use an IDE. :D
>
> I think IDE users have been avoiding D due to (perceived?) issues with D's IDE support. So those of us that do use D tend to be the ones who don't rely on IDEs. "Chicken and egg"
>

I agree.. and there are still plenty of issues. major issues.
The day there is an IDE integration that's flawless (auto-complete,
debugging), and installs by default, is the day D reaches 1 million users ;)

On Sat, Sep 14, 2013 at 02:57:39AM -0400, Nick Sabalausky wrote:
> On Fri, 13 Sep 2013 22:15:06 -0700
> Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 
> > On Saturday, September 14, 2013 06:56:10 Paulo Pinto wrote:
> > > Am 14.09.2013 00:06, schrieb Jonathan M Davis:
> > > > .... The features that an IDE has that vim doesn't typically just aren't worth it. e.g. if I'm stuck doing Windows programming, about the most that I even do with VS is use the debugger. I even build from the command line rather than open the IDE.
> > > > 
> > > > Vim's learning curve is quite nasty, but I definitely think that it was worth it.
> > > > 
> > > > - Jonathan M Davis
> > > 
> > > You mean things like:
> > > 
> > > - Semantic refactoring

This would be nice, but I would say if something like this is necessary, then it means the code wasn't properly designed in the first place. Code can, and probably should, be written such that this is never necessary.


> > > - WYSIWYG design of user interfaces

Ugh. I don't trust that kind of design. It has a tendency to devolve into programs that need screen resolutions with exact pixel sizes and/or make unfounded assumptions about font dimensions. UIs should be *programmatically* specified in such a way that they are logically consistent in layout *regardless* of environmental factors such as screen resolution, font dimensions, etc..


> > > - code navigation, even across binary modules (call graph, derived class, overridden methods, call sites, ...)

Ctags. ;-)


> > > - graphical representation of code relationships

std.d.lexer + graphviz


> > > - UML design

Range-based design is better. ;-)


> > > - visual XML tooling

What would that be for?


> > > - background compilation showing where there are issues

Waste of resources. I hate it when programs (including IDEs) try to be "smart" and point out perceived problems that may or may not be real problems. The compiler already points out the *real* problems when I decide to compile the code anyway; having an IDE actively try to point out the fact that my code doesn't look like code yet (because I'm still thinking over various implementation possibilities) is very disruptive to my thought processes.  I prefer to doodle possible implementations until I mold it into possibly-compilable form first, *before* I even consider running the compiler on it.  An IDE to consume system resources while annoying me? No thanks. Let Clippy rest in his grave, don't bring him back from the dead.


> > > - background static analysis while coding

ditto


> > > - code completation with documentation popups

I can live without it. Vim has 'K' to open the manpage of the identifier under the cursor anyway -- one of these days, I'm going to write a program to autotranslate ddoc into manpages, then I don't even need to depend on dlang.org anymore. I find autocompletion redundant anyway, since I still prefer to read the module docs thoroughly to know exactly what something does before using it (*especially* if I don't know it well enough to recall the exact name off the top of my head).

So it's a nice-to-have, but meh.


> > > - integrate source code control with task management software to track code changes to project tasks

An IDE is not a substitute for my learning how to manage my projects independently of the coding itself. Besides, I've yet to find a task management software that I can tolerate using. I usually just use text files in a specific format that outlines tasks in a hierarchical format, organized into per-task per-project directory trees, in which I keep all associated data like backup files, crash logs, code diffs, etc.. All these have very specific naming conventions and structures that let me find stuff easily, and everything is plain text and greppable for when I need to find a specific detail from an unknown past bugfix, say. I still find grep -E more effective than any task management software's poor imitation of the google search box.


> > > - map failed unit tests to code lines

Er... isn't that what AssertError line numbers are for?


> I find most of that stuff to be "nice, but not that big a deal" (and a few I just plain don't care at all). I used to be a big IDE guy, but I've done enough development on various immature platforms and ecosystems that I can get by just fine as long as I have:
> 
> - Basic editing that's solid, fast, robust
> - Highlighting
> - CLI compiler

For me, I can dispense with the second item. :) Give me vim and a command-line compiler, and I'm good to go.


> I've had to debug things using as little as one LED. So printf debugging is perfectly comfortable to me, and I've gotten to the point where I even find it preferable to a full debugger in many cases.
> 
> The rest is just icing (or gravy if you prefer).

It's funny, the more years I spend coding, the less I found myself using the debugger. Nowadays my debugging approach is approximately:

1) Code inspection: based on the bug description / known steps to reproduce it, locate the general place in the code where the problem is likely to be, and thoroughly audit that piece of code for problems. Roughly 30% of the time, the bug would be found this way, and quite often, other not-yet-found bugs would be discovered too. So it's quite worth the effort before we even use any real debugging tools.

2) Printf/writeln debugging: mainly to determine execution path on the way to the problem, by strategically placing printfs/writelns at branch points and before/after loops, then refining it to loop bodies and functions down the call tree as the location of the problem reveals itself. Once the malfunctioning piece of code is identified, then start to dump variable values, etc., to ascertain the cause of the problem. This actually covers about 60% or so of the cases I've encountered.

3) Use a debugger. I find myself doing this only about 10% of the time. And out of that 10%, 9% is just to get stack traces from segfaults, and only 1% is really using the debugger for stepping through code.

All in all, writeln debugging is pretty effective, for all the stigma against it.


> > I honestly find almost all of that to be useless or nearly so. The only one that I'd actually be much interested in would be better code navigation (particularly the ability to hop to the definition of a function). And having poor code editing capabilities would hamper me quite a bit. So, for me, vim wins hands down.
> > 
> 
> Yea, the basics of code editing are the real #1 thing. If I can't "be one with the cursor and text-edit control", so to speak, then no amount of extra features can make up for it. (Of course, for me that means *not* vi, although I just haven't cared enough to get through the learning curve - but that's just me.)

I utterly hated vi(m) until I actually tried learning it. Then I found that the "be one with the cursor" approach is actually less effective than vim's "describe your edits in a *language* involving verbs, nouns, and adjectives, not just point and grunt" mindset. Nowadays, I actually find other editors rather crude for my tastes. They're too focused on the character-by-character motion of the cursor and the WYTIWAG (what you type is all you get), whereas vim lets you speak to it in a far more expressive language.


T

-- 
Do not reason with the unreasonable; you lose by definition.

On Sat, 14 Sep 2013 00:11:25 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Sat, Sep 14, 2013 at 02:14:49AM -0400, Nick Sabalausky wrote:
> > I just wish I could get a Linux file manager I liked.
> 
> A Linux file manager? You mean bash? ;-)
> 

Heh, well, that actually *is* my favorite out of all the Linux file managers!

> What about midnight commander? The only file
> manager I could tolerate back in the old DOS days was Norton
> Commander, which MC was modelled after. You might like it. Maybe.

I've tried Total Commander on Windows, which is another program modeled after Norton Commander. It's probably the only file manager in the world that's even less to my taste than OSX's Finder. However, I do keep it around because its multiple-file-renaming tool is freaking awesome.

What I'd really like to find is something I can at least configure to basically be "XP's Explorer, but less buggy and inefficient". And that's including something like TortoiseGit. So yea, probably a very tall order.

Anything based off Nautilus (which seems to count for most of them) are pretty far off the mark from what I'm looking for. They're *usable* and bear a similar resemblance to what I want, but the details of it are all goofy, and whenever that's all I have available I find myself just doing everything from the commandline instead. (Sometimes I figure that must be the same reason so many linux users swear by the CLI for file management - all linux's GUI ones suck!)

The best I've found so far is KDE4's Dolphin, but it's still no
Explorer rival, has nothing like Tortoise (to my knowledge), it still
has some irritating goofiness (ex: the horizontal scrolling in the
tree-view panel is every bit as broken-by-design as in Vista's
Explorer), and there's some other things, plus I don't like
KDE4 :(   (And I'd rather not have to pull in the bloat of KDE4 just for
a file manager.)

To me, a GUI file manager is like a keyboard and a text-editor: I rely on it so much that I need it to be *just right* or else it becomes a major bottleneck instead of a tool. Heck, I don't even like Win7's Explorer, really. Even after I configured/hacked the hell out of it, it still has some irritating Mac-like tendencies. Still beats Dolphin though :/


> DOS was a cartoon caricature of
> what a *real* shell can do, by comparison

I would tend to agree. ;)

Although, at the time, I had came to DOS from Apple 2's "Applesoft BASIC", so I didn't see DOS that way until many years later.

> so NC was quite the relief
> from the suffering when using DOS.

Yea, I can believe that.

> Or, failing that, you could write a killer file manager app in D, and we could take over the world. :-P
> 

Honestly, unless I find something that fits the bill, that's one of the top projects in my pile of "pet projects I want to do if I ever have time for stuff I can't rationalize as being vaguely work-related."