>> If you're going to spend hours of your life staring at something,
>> wouldn't you like it to look nice?
> 
> I look at the text, not the window furniture. (I don't care much for the M$
> window furniture anyway, but I definitely appear to be in a minority there ;-))

OK. But it would be nice if the text itself was crisp and readable, no?

>> I mean, if you're forced to use a console window to do something, then
>> fair enough. But this is 2009. We have graphics systems capable of
>> better. Why not make use of that fact?
> 
> Because it's not relevant? Most people who would benefit from using something
> like emacs probably don't give a monkeys about how it looks.

Funny, each time I set up SciTE, the first thing I do is change *all* 
the fonts to monospace, and then fiddle with the sizing so it's 
appropriate for the resolution of monitor I'm using (and how far away 
I'm sat). And then I turn on the line numbering. And line wrapping. (The 
kind where it shows you where the wrapped lines are, not the kind where 
it actually inserts newline characters.)

Being stuck with one ugly terminal font would just annoy me.

> In any case, I think
> a black background and fixed-width text is much more suitable for programming
> than a wysiwyg word processor.

No sensible person programs with a word processor. It's the wrong tool. 
But there are studies that show that black-on-white is easier to read 
than white-on-black, and I'd prefer to be able to change it.

>>> C = ctrl
>> So "C-u" actually means "Ctrl+U"?
> 
> Aye. Again, I think it's just an old notation.

OK, fair enough.

By the way... what kind of keyboard actually has a Meta key?

>> Well, I don't know. SciTE is open-source. If you want to, it's perfectly
>> possible to download the source code and modify it. But let's face it,
>> who the hell is going to do that? Nobody.
> 
> What's that got to do with it? I may be a new user, but even I can see that
> customising emacs is nothing like editing its source code.

Emacs is a Lisp interpretter running a text editor application written 
in Lisp. If you just want to change some setting, you can probably get 
away with adjusting a variable. But if you want to alter something there 
isn't a setting for... you need to modify the source code.

>> Similarly, Emacs lets you
>> change absolutely anything [with the not inconsiderable detail that you
>> don't have to recompile anything]. But only once you've read and
>> memorised the entire source tree. How feasible is that, really?
> 
> Not at all, if it were true. Did you not glance over Warp's config file? Seems
> fairly self evident, I don't know any of these configuration keywords from
> memory but I'll certainly be swiping some of them for my config file in future.
> If you want the extra flexibility but don't like the ancient shortcut standards,
> just change them to what everyone uses now. That's what Warp did.

On some level, it's similar to how you configure SciTE - i.e., with a 
giant text file. The difference with Emacs is that you can write complex 
blobs of arbitrary executable code to define new functionallity. (It 
seems Warp has done this.) The similarity is that, like SciTE, it'll 
take you hours to figure out which secret hidden setting changes the 
thing that's annoying you. (Or even whether there *is* a setting to 
change a particular behaviour...)

> I'm not saying learning to use something like emacs isn't daunting - I probably
> wouldn't use it myself if we didn't have it here. But you should watch a power
> user navigating code libraries and running external commands. It's like a movie
> scene, where single keystrokes don't seem to match up with what's happening
> on-screen. (Like Scotty bringing up a 3D model of transparent aluminium in 4
> seconds work - name that movie!)

I don't know the title. Whichever Star Trek movie it was that featured 
time travel.

Post a reply to this message