Everybody "knows" that Emacs is "the best" text editor.

(Actually, in truth anybody who *knows* about such things would know 
that Emacs isn't a text editor at all. It's an elisp interpreter that 
comes with a text editor application preloaded. :-P )

The more vocal proponents will tell you how Emacs is the most advanced, 
sophisticated, powerful and generally /perfect/ piece of software that 
Mankind has ever produced, and that no other editor could ever come 
close to equalling its supreme perfection. And yet, none of them can 
explain /why/ it's so perfect. (Except that, hey, you can *customise* it!)

Actually, you know what? That sounds rather like Lisp. Everybody "knows" 
that Lisp is the most powerful, most perfect language, but nobody can 
explain why. Except that "everything is data", so you can write PROGRAMS 
that write PROGRAMS!

Obviously, in spite of all the fanboys, practically nobody actually uses 
Lisp, and as best as I can tell, nobody uses Emacs either. (For 
sufficiently large values of "nobody".) So clearly these are sound 
arguments. :-P

Once upon a time, I did sit down and try to learn Lisp. What I found was 
a language with a simple and reasonably elegant idea, then swiftly 
buried under several miles of clutter and junk. No thanks.

Suffice it to say, I /still/ don't get why anyone would want to use 
Lisp. But hey, whatever.



I'm curious to know in which sense Emacs is "the best".

Is it "the best" in the same way the Lisp is "the best"? In other words, 
"everybody knows" it's the best, but nobody can actually explain why, 
and nobody actually uses it.

Or perhaps it's "the best" in the same way as Eiffel. Basically Eiffel 
is the ultimate, most perfect OO language. That's what it was designed 
to be, from the ground up. It's the most perfect embodiment of the OO 
paradigm. (Although they also tacked on Design By Contract, which isn't 
strictly anything to do with OO.) A perfect language... shame the 
implementation sucks arse, eh?

Maybe it's "the best" in the same way as TeX. The output of TeX is quite 
simply the most beautiful thing I've ever seen. Nothing else even comes 
remotely close to looking this damned good. Which is just as well, 
because otherwise TeX would have been nuked from space long ago. The 
/output/ is delightful. The /input/ is the stuff of nightmares. For TeX 
is basically a PDP-era text macro expansion system which also houses a 
sophisticated constraint-solver for typesetting text. It really doesn't 
handle colour, it really doesn't handle images, and it most certainly 
does /not/ handle styling or customisation of any kind! Oh, and don't 
try debugging it.

Maybe it's "the best" in the same way that C is "the best". Everybody 
knows it's dangerous, unreliable and difficult to use. But everybody 
uses it because everybody /else/ uses it.

Or perhaps it's "the best" in the same way that Unix is: It's ancient 
and basically obsolete, but nothing can match it for reliability, 
flexibility and compatibility with a large library of existing stuff.



Having sparked my interest, I decided to go find out about Emacs, to see 
if I could discover what's so damned special about it. I began at the 
GNU Emacs web page. Within about 4 mouse clicks, I came across the 
phrase "VT100".

No, I am not kidding. Just skimming the introductory text, already I'm 
finding references to 40-year old technology. Then again, ASCII is 
pretty ancient, yet still relevant. The VT100 itself may be long 
obsolete, but the protocol it speaks has become something of a de facto 
standard for terminal emulators.

Then again, only Unix nerds use terminal emulators. The rest of us, here 
in the second decade of the twenty first century, have moved on a tad 
from that. :-P

Suffice it to say, Emacs is /ancient/. From what I can gather, it's even 
older than Unix - if that's actually physically possible. As tools go, 
comparing Emacs to my current text editor is like comparing a electric 
microwave oven to a paleolithic flint axe. We're really talking about 
the most distant aeons of computing prehistory, almost from before 
computers were computers. (Unit record equipment, anyone?)

Directly because of this, the introductory material uses strange phrases 
like "if your keyboard has a backspace key"... What do you mean *if*? 
It's only been there for, like, over two decades. :-P Similarly, suffice 
it to say that Emacs does /not/ follow any remotely modern standard for 
normal keyboard commands. They simply didn't exist when Emacs was written.

Even the terminology is all wrong. Cut & past are called kill & yank. 
(Even though those sound like synonyms, they are in fact inverses of 
each other.) Except that... no, not really, no. Kill and yank are 
/similar/ to cut and paste... but not quite. Oh, and there's no copy.

Everything is like this. "Load" is called "find". Except that, again, no 
it isn't quite the same. Because "find" is also for switching between 
buffers. There is no "new"; instead you must "find" a non-existent file, 
type some stuff, and then save it. As best as I can tell, it is 
impossible to save an existing file under a new name. (I.e., there is no 
"save as".)

Similarly, the cursor isn't called a cursor, it's called "point". The 
status bar isn't called a status bar, it's called a "mode line". Loading 
a file is called "visiting" it. The list goes on.

Given that the major "feature" of Emacs is that it's completely 
configurable, I'm interested to see how easy it is to actually configure 
it. My editor of choice is SciTE, which has quite a lot of configuration 
options. Unfortunately, that means that after you download it, you have 
to spend about three weeks configuring all the stupid defaults to more 
sensible settings. It takes so damned long that I actually find it worth 
while transporting the configuration settings from machine to machine.

Also, given that it apparently has billions of commands, I'm curious to 
know how you map all these things to the keyboard. Without getting into 
a long keyboard vs mouse debate, both have their advantages.

I think it was Warp who mentioned a while back how every film and TV 
program you'll ever see always shows the ultra-hacker frantically typing 
away on his computer as stuff appears on the screen. And yet, very 
little software can actually be controlled from the keyboard like that. 
It occurs to me that one program which /can/ is FractInt.

Once you get to know FractInt (i.e., once you've wasted several years of 
your life experimenting with the several hundred fractal types, options, 
bells, whistles and doodads it offers), you can use the keyboard to 
control it astonishingly fast. Each sub-menu and command is basically 
one keystroke, and you end up casually typing three or four keystrokes 
at once without really having to think about it, such that screens zip 
past faster than the eye can see, and the program is reconfigured.

Then again, FractInt is about drawing pictures. You hardly ever need to 
type in text. Emacs is a /text editor/. Typing in text is kind of THE 
ENTIRE REASON IT EXISTS. So I wonder how well you can control it from a 
keyboard?



And then, on Wednesday morning, I did possibly the nerdiest thing I've 
ever done in my entire life: I installed (GNU) Emacs. On Windows XP. Yah.

So how do you install it? Well, you go to the website, download a zip 
file, and unzip it. You then execute runemacs.exe, and a window opens. 
I'm rather fond of programs which are this easy to set up.

OK, so what does it look like? Well, it's fairly ugly. Not the worst 
I've ever seen (e.g., gnuplot is just awful), but it's obviously FOSS. 
You can tell by the big logo utterly lacking antialiasing, the ugly 
fonts in inconsistent styles and sizes, the thoughtless gaudy colour 
scheme, and the grab poorly drawn icons with far too much empty space 
around them.

Aside from that... it looks pretty normal. It's got a menu bar and a 
toolbar at the top, a status bar at the bottom, and a scrollbar on the 
side. Now on a normal status bar, the various status elements are 
separated by actual *graphics*, whereas Emacs is using some lame ASCII 
art to do the same job. That looks kinda tacky. But so far, that's about 
the only difference.

So I click on "Emacs tutorial" and start reading. Heh, apparently Emacs 
predates thinks like cursor control keys. Rather than Page Up and Page 
Down, it directs me to use Ctrl+V and Alt+V. And rather than arrow keys, 
we have Ctrl+N ("next"), Ctrl+P ("prev"), Ctrl+F ("forward") and Ctrl+B 
("backward") for cursor movement. In place of Home and End, we have 
Ctrl+E ("end") and Ctrl+A ("aahhh... wuh??").

Interestingly, while Ctrl+F moves the cursor one character forward, 
Alt+F moves it one /word/ forward. (And similarly for Ctrl+B vs Alt+B.) 
I've never seen a text editor that can do that. (But then again, it's 
not exactly a feature you'd bother looking for.) I'm kinda curious as to 
what Emacs considers to be a "word", but as best as I can tell be 
experiment, it just moves the cursor to the next non-alphabetic character.

In a similar way, Alt+A and Alt+E move by "sentence". Again, not sure 
how Emacs decides what constitutes a sentence. It seems to be going by 
punctuation or by line ends or something.

Fortunately, it turns out that the arrow keys and the scroll bar both 
work just fine, so I don't actually need to remember any of this 
nonsense. Oh, except... the scroll bar has a quirk. Scrolling the view 
actually moves the cursor. It can never be scrolled off the screen. 
(Presumably because on a VT100 there's no way to turn off the cursor. :-P )

This annoying quirk means I can't use one of my favourite editing 
behaviours: If I'm editing line 700, and I want to check something on 
line 300, I can leave the cursor on line 700, scroll up to line 300, 
look at what I want, and then when I start typing, the view instantly 
snaps back to line 700 (so I don't have to hunt around for it). On the 
other hand, the documentation suggests that you can have more than one 
view of the same buffer open at once, and if that's actually true it 
would be even /better/...

What's that? I can move to the top of the file with "M+<"? Oh, perhaps 
you mean "Shift+Alt+,"? :-P Interestingly, by this point, I'm rapidly 
discovering that using the Alt key is surprisingly uncomfortable. :-/ I 
wonder how come I never noticed this fact before?

Apparently by typing Ctrl+U 8 Ctrl+F, I can move the cursor exactly 8 
characters left. I'm left wondering why in the name of God I would 
*ever* want to do this. Still, I guess there might be other commands 
where the numeric prefix is actually useful for something. I 
particularly like the way that typing Ctrl+U gives absolutely no visual 
indication at all that something just happened, as per good HCI design 
guidelines.

LOL @ inaccurate description of how a scrollbar works.

There's a section on "when Emacs is hung". What, you're actually 
expecting that to happen? Maybe I need another editor. o_O In fact, it 
turns out what it /really/ tells you is that Ctrl+G cancels a command. OK.

Finally we come to the part about how to actually /edit text/. (Hey, I 
guess a text /editor/ is also a text /viewer/, right?) After four 
paragraphs explaining what "backspace" is and what to do if you don't 
have one (??!), it tells you how Emacs handles lines too long to fit on 
the display. Oh, that's nice. It wraps it for you and puts little 
markers there to tell you it's wrapped. That's how I usually configure 
my editor. On the other hand, it wraps characters, not words. *sigh*

I quickly discover that, say, Ctrl+K deletes (sorry, cuts) all the text 
from here to the end of the line. But the usual approach of positioning 
the cursor, holding Shift, and then repositioning the cursor doesn't 
select text. It works if you drag with the mouse, but doesn't work at 
all with the keyboard.

As best as I can tell from the documentation I've seen, as well as 
"point" there is also "mark", and you use this to delineate regions (for 
deletion or whatever). You also use it to return to the place where you 
last were. (So, no possibility for confusion there then.) Oh, and 
there's one "point" per window, but only one "mark" per buffer. Nice 
symmetry there! >_<

Also, you can't see the mark. Only the point. Again, I'm guessing this 
is a limitation of the obsolete VT100 technology on which Emacs appears 
to be fundamentally based. Never mind that 40 years later, we have 
raster graphics terminals capable of displaying arbitrary graphics. No 
sir, ANSI escapes for me!

Trying to wrap my head around the exact semantics of killing, yanking, 
the kill ring, the mark and point, and so on is pretty damned hard. I 
suppose if I persevere I'll get it eventually. The undo concept is 
similarly baffling.

What particularly strikes me is that a rare operation such as moving 
forward one word is given a fairly short key sequence (Alt+F), but a 
common operation like undo gets a comparatively long one (Ctrl+X U). The 
documentation helpfully mentions that you can use "Ctrl+_" instead. 
Except that "_" is "Shift+-", so what you're actually saying here is 
"Shift+Ctrl+-". Yeah, that's much easier. :-P

Ooo, now it starts talking about how to load and save files. Because, 
you know, that's kind of crucial too. (In fairness, without cursor 
movement, you can't actually read the tutorial!)

Now, get this: Apparently a very rare operation such as "search" is 
Ctrl+S, but an extremely common operation like "save" (arguably the 
single most important command that any file editor can ever have) is 
Ctrl+X Ctrl+S. Quite apart from the fact that this clashes with modern 
usage (which arguably is no fault of Emacs), why is a highly specialised 
and uncommon operation like searching given a fast direct-access 
command, and the infinitely more common operation of saving your work 
requires two key presses in the correct order?

Also, as I say, you can't just say "new file". You have to actually 
specify the full name and path first. Apparently the only way to get a 
file dialogue to open is to use the mouse. Sure, the minibuffer prompt 
has tab-completion, which is arguably faster. Some visual feedback would 
still be nice though. (You can get that if you press Tab twice. But then 
you have even more buffers open...)

I notice that Ctrl+X Ctrl+S saves the current file, while Ctrl+X S 
/asks/ you whether to save the current file. I've noticed similar 
behaviour with a couple of other commands. (Not that this seems to be 
mentioned anywhere...)

Emacs allows you to have multiple files open at once. The standard way 
to switch the current view to another file is to "find" the file - i.e., 
do what you'd do in order to open it in the first place. Fortunately, 
the GUI provides a menu that shows you what buffers exist and lets you 
switch to them, without the extreme clunkiness of the various switching 
commands. (E.g., list available buffers, change window, select the 
buffer you want, close that other buffer...)

I notice that the window titlebar provides no indication of what file 
you're editing. (It just says "Emacs" and then the DNS name of the PC. 
Yeah, that's very useful information. :-P ) Only by actually looking at 
the Emacs window can you see this. Oh, and if you have several buffers 
visible, the buffer name is at the /bottom/ of the display, not the top 
where you would logically expect to find it. Great!

I also notice that the buffer name "is the same as the file name, 
without the directory part". Great. Let's hope I never have to edit half 
a dozen files all named Desktop.ini or something... Oh, wait.

Earlier I was wondering how Emacs maps all its millions of commands to 
the keyboard. Apparently the answer is that the most common commands get 
a Ctrl or Alt sequence, less common ones are Ctrl+X and then something, 
and the leave common ones of all are Alt+X followed by typing in a 
command name.

...which seems reasonable, although some of their decisions about what 
constitutes "common commands" are /highly/ dubious! It's kinda neat how 
the command name prompt does tab completion without needing tab though.

LOL @ the bit about using Ctrl+Z to temporarily take the terminal back 
to the shell. No deary, see, in this modern age, we don't use 
/terminals/ any more. We have *real* computer displays. :-P

LOLRUS: Pressing Ctrl+Z actually minimises the Emacs window! :-D So I 
guess it does still have a use.

Having tried the incremental search I discovered something quite nice: 
it actually /highlights/ everything on the page that matches your 
search. A trivial feature, but one which I haven't seen in any other 
software. It's also kind neat how jabbing the search keys takes you to 
the next or previous match. OTOH, once you exit search, the search term 
is gone forever, in contrast to modern editors.

Ever since I started this tutorial, I've been looking at the 
70-character text down one side of my enormous widescreen monitor, 
trying to figure out how to add more windows. To my frustration, every 
command that creates a new window splits the display /vertically/, not 
horizontally. (Still, at least you can drag it with the mouse, eh?)

Eventually I discover that the command in question is Ctrl+X 3. 
(Obviously...) I also discover that you can only drag the divider if you 
point at exactly one part of it, in contrast to the horizontal dividers 
which can be grabbed anywhere.

The documentation also claims that if you middle-click on either the 
status bar or the scrollbar while holding Ctrl (um, why?) it splits the 
window. Clicking the status bar /does/ work, but clicking the scrollbar 
does /not/ work. (The minibuffer even pops up a message to tell you that 
this action is not defined.) Score another one for accurate 
documentation. (Remember, I just got this out of the box.)

It's a nice touch that Ctrl+Alt+V scrolls the /other/ window. I guess. I 
mean, if it weren't so trivial to do it by hand anyway.



OK, so pretty much one of the "killer features" of Emacs is supposed to 
be syntax highlighting. So how does it work? I proceed to open a random 
selection of files, and sure enough, their syntax is highlighted in 
various ways.

The whole idea of major modes and minor modes is interesting and all. 
But what happens if, say, I have JavaScript embedded in HTML? If I open 
a JavaScript file, it correctly colours the listing. If I open an HTML 
file, same deal. But if I open an HTML file that contains JavaScript... 
nothing happens. The HTML is recognised, the JavaScript isn't. So here 
is where Emacs fails, and SciTE succeeds.

The HTML highlighting is actually nicer than most. Usually you just get 
the actual markup elements highlighted; Emacs goes that step further, 
simulating certain aspects of the formatting. For example, section 
headings appear bold and underlined, making quickly scanning through the 
markup for that section heading much easier. That's a nice touch. Bits 
marked with <i> or <em> actually come out italic. (Which is admittedly 
kind of ugly with a typewriter font.) Just a few details like that.

It's not very obvious unless you know to look for it, but all the menus 
change when you open various kinds of files. That's nice. (The command 
for "open a browser and display this page" is a bit buried, but it's there.)

There's a whole bunch of annoyances so far. Emacs gives you a vertical 
scrollbar, but no horizontal one. The horizontal commands listed in the 
command reference don't appear to work at all. The vertical scrollbar 
behaves incorrectly (it sometimes scrolls past the end of the file). 
There's a minor mode that wraps text as you type - by word - but only 
after you *finish* typing, which is no good at all. (Thunderbird manages 
to do this completely interactively. It even draws a line to show you 
how much width you have to play with.)



In short, after spending a few days playing with Emacs, I'm still not 
finding anything that makes me to "wow!" Yes, it has a tetris 
implementation. And yes, it's the ugliest, least entertaining tetris 
you've ever seen in your life. Big deal.

Perhaps if I spent a few years reconfiguring Emacs, I could make it more 
to my liking. But I doubt it. In some ways, it's like Unix. Oh, sure, a 
modern Linux distro has lots of shiny eye-candy. But underneath all 
that, it's still the same kludge hodge-podge of ancient software that it 
always has been, and always will be.

Don't believe me? mgetty. "Modem-aware get TTY". That's TTY as in 
teletypewriter. Still think Unix is part of the modern era?

Emacs is obviously /trying/ to be a modern application. Trouble is, 
every step you take to make it more modern is also a step that makes it 
less compatible with all the old cruft written for it - which is half 
the benefit of using it in the first place.

Emacs is trying to pretend that it's a modern GUI application. But take 
more than a casual glance and the truth shows through. Don't get me 
wrong; I'm sure there was a time when being able to see multiple windows 
on the same green screen connected to a modem communicating with a 
lumbering mainframe somewhere has a major technical achievement. Today I 
just find myself irked that I can't freely move windows around like I 
can with the rest of my desktop.

Sure, you can drag the window edges. But there's no way to create new 
windows or close existing ones with the mouse. Nor is there a quick and 
easy way to switch the view of one window. (You have to click on that 
window and then go to the menu to select which buffer you want it to 
display.) You can't swap two windows around just by dragging them. 
Instead you have to find out what buffer each one displays, and then 
switch buffer on each window, one at a time.

You can make the final display look like anything you want. It's just so 
much /hassle/ to get there. In a real GUI program, this stuff is all 
trivial.

Emacs can view info pages. Again, once upon a time, a program that 
allows you to view its own documentation might have been considered 
radical and revolutionary. Today I just find myself shrieking "why can't 
I open this link in a new tab?!" (And answer, apparently, is that you 
have to create a new info buffer, navigate to the same place on that, 
and then click the link in question in /that/ buffer.) Oh, I'm sure if 
you know Lisp you could code up something that does exactly what you 
want... or you could just use an editor which already includes this 
trivial functionality out of the box.

One of the interesting things stated in the documentation is that Emacs 
supposedly lets you use its full text editing capabilities on things 
over than file contents. For example, Emacs can display a directory 
listing, and if you do a find and replace on it, that effectively 
implements a batch rename operation.

Nice idea, but... Well, treating something structured like that as flat 
text seems wrong to me. For example, what if you wanted to rename all 
the files name frame25 (or whatever) to F25, but the frame files happen 
to be owned by a user called frameserver. Would the owner name also get 
changed to fserver? Because that would be /bad/...

In truth, while I didn't try this particular experiment, I found the 
dired mode to be utterly excruciating to use. It's just too clumsy. I'm 
using to being able to effortlessly explore the system. With this thing, 
I'm not even sure where I *am*. (Tree views exist /for a reason/, as do 
full file paths.) Here again, the terminal heritage shows through; 
rather than nice graphics to indicate structure, we get ASCII art.

I suspect you could probably make something /like/ Emacs, but with a 
modern design, and it would work well. But Emacs itself just looks old, 
klunky and irrelevant to me.

Post a reply to this message

On 4-8-2011 17:02, Invisible wrote:

I'll leave correcting you on several EMACS mistakes to the others. I 
just want to point out that you apparently have been looking at an 
*implementation* (under windows?). You should not confuse that with the 
/idea/ EMACS.

But with regards to TeX or LaTeX

> Maybe it's "the best" in the same way as TeX. The output of TeX is quite
> simply the most beautiful thing I've ever seen. Nothing else even comes
> remotely close to looking this damned good. Which is just as well,
> because otherwise TeX would have been nuked from space long ago. The
> /output/ is delightful. The /input/ is the stuff of nightmares.

It isn't. It is more straightforward than e.g. Word. Everything you need 
to know is in plain sight.

> For TeX
> is basically a PDP-era text macro expansion system which also houses a
> sophisticated constraint-solver for typesetting text. It really doesn't
> handle colour,

It does. No idea how you got that impression.

> it really doesn't handle images,

It does. No idea how you got that impression.

> and it most certainly
> does /not/ handle styling or customisation of any kind!

It most certainly does. Style files are are at the heart of the system. 
As a small comparison: a friend of mine had written her thesis in Word, 
after her text was accepted by the committee she needed 3 weeks of hard 
work to convert it from an A4 draft version into a paperback format text 
that she could submit to the printer. I did it, with the help of a 
student, in one evening. And I had different layouts for chapters 
depending on whether it was published before or not.

> Oh, and don't try debugging it.

If you want to debug TeX, that is relatively easy, all sources are 
available, documented and even published as a book 
(http://www.amazon.com/Computers-Typesetting-B-TeX-Program/dp/0201134373/). 
Moreover Don Knuth has a reward for anybody finding a bug.

If you mean debugging your text or layout, that is more simple than in a 
wysiwyg editor.

If you mean debugging style files or bibstyle files you are correct, 
that is a nightmare if you don't know what you are doing. Simple advise: 
don't touch them.


-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> The more vocal proponents will tell you how Emacs is the most advanced, 
> sophisticated, powerful and generally /perfect/ piece of software that 
> Mankind has ever produced, and that no other editor could ever come 
> close to equalling its supreme perfection. And yet, none of them can 
> explain /why/ it's so perfect. (Except that, hey, you can *customise* it!)

  It's things like this: http://www.youtube.com/watch?v=EQAd41VAXWo

  (As for the rest of your post, tl;dr, sorry.)

-- 
                                                          - Warp

Post a reply to this message

On 8/4/2011 8:02, Invisible wrote:
> Once upon a time, I did sit down and try to learn Lisp. What I found was a
> language with a simple and reasonably elegant idea, then swiftly buried
> under several miles of clutter and junk. No thanks.

Well, that's what happens when you take something that has evolved in 
several different directions for a few years, then mushed it back together.

> Suffice it to say, I /still/ don't get why anyone would want to use Lisp.
> But hey, whatever.

You want to learn Forth?  Here's what you can do with Forth:

http://www.reddit.com/r/programming/comments/iyb2d/freeform_a_meta_language_that_allows_defining_and/c27ojnx

> (Although they also tacked on Design By Contract, which isn't strictly
> anything to do with OO.)

If you didn't understand why DbC is fundamental to "perfect" OOP, you've 
missed a major point of the development of it. DbC *is* the OO. The actual 
bodies of the methods are an implementation detail. :-)

> A perfect language... shame the implementation sucks arse, eh?

True. The first time I tried it, and this is like version 5.2 or so, you 
started a new project and it gave you a Hello World skeleton to start from. 
If you started a new project, then clicked "compile" without touching 
anything else, the compiler bombed out.

> Maybe it's "the best" in the same way as TeX. The output of TeX is quite
> simply the most beautiful thing I've ever seen.

Hopefully they've improved it. TeX is probably OK as long as you don't use 
it with metafont files, but the output with metafont is pretty sucky.

> Or perhaps it's "the best" in the same way that Unix is: It's ancient and
> basically obsolete, but nothing can match it for reliability, flexibility
> and compatibility with a large library of existing stuff.

I'd argue that Windows may have better flexibility (modulo not actually 
having the source to it, and not counting "portability" as "flexibility") 
and a larger library. It's certainly not a slam dunk for Unix. Plus, Unix 
isn't really all that reliable, either.

> Suffice it to say, Emacs is /ancient/. From what I can gather, it's even
> older than Unix

The first versions were. I don't think it was called emacs at the time. It 
was also originally developed on an OS other than Unix, so the "meta" key 
was actually a separate key from "alt".

> Similarly, the cursor isn't called a cursor, it's called "point".

The two are different things. The point is where text is inserted. The 
cursor is an indication on the screen.  The two aren't necessarily the same 
thing.

> Ctrl+A ("aahhh... wuh??").

Because Ctrl-H is help, you see.

That's the thing that always killed *me* about Emacs. The key mappings were 
half mnemonic and half abbreviation and half based on keyboard position. On 
the other hand, Wordstar I still remember every keystroke, in spite of not 
having used it since 1982 or so.

> Interestingly, while Ctrl+F moves the cursor one character forward, Alt+F
> moves it one /word/ forward. (And similarly for Ctrl+B vs Alt+B.) I've never
> seen a text editor that can do that.

Really? Even notepad does that: ctrl-rightarrow. Every editor does this.

 > (But then again, it's not exactly a feature you'd bother looking for.)

Of course it is, especially if you're editing text.

> I'm kinda curious as to what Emacs
> considers to be a "word", but as best as I can tell be experiment, it just
> moves the cursor to the next non-alphabetic character.

It depends on the mode. A "word" is one token.

> In a similar way, Alt+A and Alt+E move by "sentence". Again, not sure how
> Emacs decides what constitutes a sentence. It seems to be going by
> punctuation or by line ends or something.

Again, it depends on the mode. If you're editing a program, it's one 
statement, one s-expr, etc.

> (Presumably because on a
> VT100 there's no way to turn off the cursor. :-P )

No, it's because VT100s don't have scrollbars. Emacs didn't have scrollbars 
until after windowed operating systems with scroll bars were common. Heck, I 
suspect emacs predates the invention of the scroll bar.

> Apparently by typing Ctrl+U 8 Ctrl+F, I can move the cursor exactly 8
> characters left. I'm left wondering why in the name of God I would *ever*
> want to do this.

Because you want to draw a line of 30 hyphens across the screen. Or you want 
to skip to line 287 in your file.

> There's a section on "when Emacs is hung". What, you're actually expecting
> that to happen?

If you're writing your own code, or you hand it a few megabytes and say "go 
indent this".

> Now, get this: Apparently a very rare operation such as "search" is Ctrl+S,
> but an extremely common operation like "save" (arguably the single most
> important command that any file editor can ever have) is Ctrl+X Ctrl+S.

I'm not sure why you think you'd save a file more often than you search. It 
boggles my mind to think you think searching for text in a file is highly 
specialized and uncommon.  Oh, wait, this from the guy who doesn't use 
google. ;-)


> I notice that the window titlebar provides no indication of what file you're
> editing. (It just says "Emacs" and then the DNS name of the PC. Yeah, that's
> very useful information. :-P ) Only by actually looking at the Emacs window
> can you see this. Oh, and if you have several buffers visible, the buffer
> name is at the /bottom/ of the display, not the top where you would
> logically expect to find it. Great!

Again, you're cutting on emacs for being a program written and popular 
before windowing OSes were common? Before the Mac and MSWindows established 
the standards of title bars and scroll bars and where status lines go and 
what they're called?

> ...which seems reasonable, although some of their decisions about what
> constitutes "common commands" are /highly/ dubious!

That's why you can remap the keys as you like. ;-)

> Having tried the incremental search I discovered something quite nice: it
> actually /highlights/ everything on the page that matches your search. A
> trivial feature, but one which I haven't seen in any other software.

Damn, man, you gotta get out more. I haven't seen any decent editor since 
Win95 that doesn't do that. Sure, not notepad, but everything else.

> same deal. But if I open an HTML file that contains JavaScript... nothing
> happens. The HTML is recognised, the JavaScript isn't. So here is where
> Emacs fails, and SciTE succeeds.

Nobody uber enough to use emacs would stoop to editing web pages with 
embedded javascript. ;-)

Really, the code that recognises that stuff just needs to be updated.

> The HTML highlighting is actually nicer than most.

You should check out VIM if you want a somewhat more rational editor that 
does all this stuff emacs does.

> In short, after spending a few days playing with Emacs, I'm still not
> finding anything that makes me to "wow!" Yes, it has a tetris
> implementation. And yes, it's the ugliest, least entertaining tetris you've
> ever seen in your life. Big deal.

Many of the nice features of emacs become redundant in an environment with 
windows, and especially in an environment with IDEs customised for the 
specific languages you're using.

> Don't believe me? mgetty. "Modem-aware get TTY". That's TTY as in
> teletypewriter. Still think Unix is part of the modern era?

Sadly, Unix *is* part of the modern era, because we are still doing things 
like we did in 1970.

> You can make the final display look like anything you want. It's just so
> much /hassle/ to get there. In a real GUI program, this stuff is all trivial.

Me, I usually use VIM, and open each VIM in a separate window. If you 
actually want to do emacs-y like stuff, like run the compiler over the 
buffer that you just typed, and then write code to jump from error number to 
error number in your source code, I expect that would be much more difficult 
with emacs.

> I suspect you could probably make something /like/ Emacs, but with a modern
> design, and it would work well.

Yes. They call it an IDE. ;-)  Or "a windowed desktop."

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 8:45, andrel wrote:
> It does. No idea how you got that impression.
> It does. No idea how you got that impression.

The original versions didn't. It has probably been added to. It certainly 
didn't when I used it for my thesis.

> small comparison: a friend of mine had written her thesis in Word,

Did she use styles in Word? I suspect not.

> And I had different layouts for chapters depending on whether it
> was published before or not.

You can do that in Word also, ya know. You just have to use styles from the 
start, instead of trying to plug them in after the fact. Just like TeX.

> If you mean debugging style files or bibstyle files you are correct, that is
> a nightmare if you don't know what you are doing. Simple advise: don't touch
> them.

"Why does it insist on putting the images at the top of the next page 
instead of the bottom of the page where I include it?"

"Because Leslie likes it that way."

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 8:48, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> The more vocal proponents will tell you how Emacs is the most advanced,
>> sophisticated, powerful and generally /perfect/ piece of software that
>> Mankind has ever produced, and that no other editor could ever come
>> close to equalling its supreme perfection. And yet, none of them can
>> explain /why/ it's so perfect. (Except that, hey, you can *customise* it!)
>
>    It's things like this: http://www.youtube.com/watch?v=EQAd41VAXWo

Yes, my editor can do that. Indeed, it can even take that bunch of text and 
export the table to an actual SQL server.  It's exactly that sort of stuff 
that keeps corporations buying Word instead of OpenOffice.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >    It's things like this: http://www.youtube.com/watch?v=EQAd41VAXWo

> Yes, my editor can do that. Indeed, it can even take that bunch of text and 
> export the table to an actual SQL server.  It's exactly that sort of stuff 
> that keeps corporations buying Word instead of OpenOffice.

  Can you do it in a text terminal through ssh? Can you customize the
functionality, change it, add new features or modify existing ones? Can
you run it on Windows, Linux, MacOS X, BSD, Solaris, and basically any
Unix-style OS in existence? Can you get that software for free?

  I didn't think so.

-- 
                                                          - Warp

Post a reply to this message

On 4-8-2011 18:08, Darren New wrote:
> On 8/4/2011 8:45, andrel wrote:
>> It does. No idea how you got that impression.
>> It does. No idea how you got that impression.
>
> The original versions didn't. It has probably been added to. It
> certainly didn't when I used it for my thesis.

If this is about color, it might indeed have been added later. What I am 
using now does support it. Note that the source of TeX has been stable 
for a long time, so it probably was possible earlier, but only supported 
when there was a sort of generalized output format (or input format for 
the printing device, depending on your POV).

>> small comparison: a friend of mine had written her thesis in Word,
>
> Did she use styles in Word? I suspect not.

I guess she didn't and it was more than a decade ago (as was mine)

>
>> And I had different layouts for chapters depending on whether it
>> was published before or not.
>
> You can do that in Word also, ya know. You just have to use styles from
> the start, instead of trying to plug them in after the fact. Just like TeX.

I know.

> "Why does it insist on putting the images at the top of the next page
> instead of the bottom of the page where I include it?"

You can put them elsewhere, but it indeed is sometimes a fight.

OTOH so is it in Word. When I write a short 4 paper abstract in Word 
(for some reason the norm for biomedical engineering conferences) 
getting the layout right takes more time than writing. Not the initial 
layout, but every time someone edits a piece of text, and again after it 
was transported between various versions of Word and/or open office etc. 
Often it is more simple to do the complete layout yourself by adding 
linefeeds <shudders> than by using the template provided by the 
organization. For some reason they often also want to have the original 
*.doc file for inclusion in the abstract book. So I can not escape to 
something better.



-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 8/4/2011 9:28, andrel wrote:
> If this is about color, it might indeed have been added later. What I am
> using now does support it.

Neither color nor images were supported by TeX in 1991 when I used it for my 
thesis.

> there was a sort of generalized output format (or input format for the
> printing device, depending on your POV).

Well, more like only supported when there was a post-processor to put the 
images into the empty spots TeX left for them, and only supported when color 
printers were common. :-)

> OTOH so is it in Word.

Yep. I was just commenting that TeX and LaTeX aren't really simple enough 
that you can make them do what you want with ease.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 9:22, Warp wrote:
>    Can you do it in a text terminal through ssh?

Why the hell would I do that? I can run it remotely in a variety of ways, 
but no, not in a text terminal.

Can emacs run on a hardcopy terminal?

> Can you customize the
> functionality, change it, add new features or modify existing ones?

Yep. Heck, at this point, I can program it in C# instead of elisp. I can 
also trivially connect it to and incorporate anything else that has a COM or 
.NET scripting interface under Windows, including remoting it to other 
processors on the network, in order to extend its functionality. It's messes 
like that that make it popular - the fact that the average business user can 
get something custom done without going thru the IT department.

> Can
> you run it on Windows, Linux, MacOS X, BSD, Solaris, and basically any
> Unix-style OS in existence? Can you get that software for free?

That wasn't the question, tho. The question the video asked is "can your 
text editor do this" and then showed embedding a spreadsheet into a text 
document and regenerating HTML from that. And the answer is "yes, my text 
editor can do that." I mean, come on, they're showing off that they can put 
columns in a text file that adjust to the width of the text in the column? 
Yes, indeed, my text editor can do that.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 9:44, Darren New wrote:
> That wasn't the question, tho. The question the video asked is "can your
> text editor do this" and then showed embedding a spreadsheet into a text
> document and regenerating HTML from that.


BTW, let's see how usable it is when that embedded spreadsheet has 1800 rows 
in it, like the last time I embedded a spreadsheet into a text document 
(namely, my tax paperwork last year). Let's see how responsive it is at 
keeping everything nicely aligned.  IME, emacs is powerful but the macros 
are rarely optimized for processing large blobs of text.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 8/4/2011 9:22, Warp wrote:
> >    Can you do it in a text terminal through ssh?

> Why the hell would I do that?

  Ah, the magic words. The always trusty answer when you can't do something.

  A simple "no" would have sufficed, you know.

> > Can
> > you run it on Windows, Linux, MacOS X, BSD, Solaris, and basically any
> > Unix-style OS in existence? Can you get that software for free?

> That wasn't the question, tho. The question the video asked is "can your 
> text editor do this"

  The video might have asked that question, not me. I was just giving an
example of why emacs has been traditionally deemed as a very powerful text
editor in the unix world.

> and then showed embedding a spreadsheet into a text 
> document and regenerating HTML from that. And the answer is "yes, my text 
> editor can do that." I mean, come on, they're showing off that they can put 
> columns in a text file that adjust to the width of the text in the column? 
> Yes, indeed, my text editor can do that.

  Are you sure you don't mean "my spreadsheet software, embedded in my
word processor, can do that" instead of "my text editor can do that"?
Not exactly the same thing.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> BTW, let's see how usable it is when that embedded spreadsheet has 1800 rows 
> in it, like the last time I embedded a spreadsheet into a text document 
> (namely, my tax paperwork last year). Let's see how responsive it is at 
> keeping everything nicely aligned.  IME, emacs is powerful but the macros 
> are rarely optimized for processing large blobs of text.

  That reminds me of all the people who complain how the Gimp can't do this
and the Gimp can't do that, always comparing it to PhotoShop.

  The thing is, the rare occasion I need to do some image editing, I'd
rather use the *free* software rather than pay big bucks for the pro
software which might be really superb, but costs a kidney and runs only
on Windows. The free alternative might not have even a fraction of the
features, but at least it's free and available for my system of choice.

-- 
                                                          - Warp

Post a reply to this message

On 4-8-2011 18:36, Darren New wrote:
> On 8/4/2011 9:28, andrel wrote:
>> If this is about color, it might indeed have been added later. What I am
>> using now does support it.
>
> Neither color nor images were supported by TeX in 1991 when I used it
> for my thesis.

images were when I did mine in 1996. pretty sure we also used them a few 
years before that.

>> there was a sort of generalized output format (or input format for the
>> printing device, depending on your POV).
>
> Well, more like only supported when there was a post-processor to put
> the images into the empty spots TeX left for them, and only supported
> when color printers were common. :-)

I haven't studied how they did it.


-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 8/4/2011 9:57, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> On 8/4/2011 9:22, Warp wrote:
>>>     Can you do it in a text terminal through ssh?
>
>> Why the hell would I do that?
>
>    Ah, the magic words. The always trusty answer when you can't do something.
>
>    A simple "no" would have sufficed, you know.

No, I'm serious. Why would I want to do that? Why wouldn't I just access the 
file remotely, instead of accessing the program remotely.

I can access it through an encrypted WIMP link (either VNC over ssh, or 
RDP), and I can access it through an encrypted file system link, so the 
ability to access it over a VDU just doesn't come into play, really.

Asking "can you access this powerful visual editor thru a serial port" is a 
silly question that shows just how little advantage the editor has over 
others. If I wanted to edit a spread sheet and generate HTML from it, I 
wouldn't feel the need to use a VT100 to do it. I'd copy the file locally, 
make the changes, and copy the changes back. Or I'd host the file remotely 
and I'd run the software locally. Or I'd use an encrypted channel to access 
the software remotely if that's the only place it was installed. I don't 
find using VT100 escape codes to edit spreadsheets in modern times a 
credible reason for calling an editor powerful any more than I'd say "hey, 
can your handset work on a crossbar-5 switch that doesn't support 
touchtone?" a credible reason for picking a particular phone over others.

Hence the "wtf" kind of response. :-)  I'd say the same thing if you said 
"yes, but can your text editor then serve up those pages like a web server?" 
While the answer for emacs is "yes", the answer for any normal person would 
be "why wouldn't I use a web server for that?"

>    The video might have asked that question, not me. I was just giving an
> example of why emacs has been traditionally deemed as a very powerful text
> editor in the unix world.

OK. You said "it's things like this", then pointed out a video showing off 
the customizability of emacs. VIM can do the same thing. TECO can do the 
same thing. PMate can do the same thing. Word can do the same thing (even 
without being customized). (And yes, all of those editors ran on all the 
popular OSes of their day except Word, and most were free.) Lots and lots of 
editors can be customized these days.

If you want to argue over editors that can run in a VT100 emulator (and, 
honestly, probably not on an actual VT100), then sure, there's a niche 
market for that.

But any computer beefy enough to run Emacs is going to be beefy enough to 
run a windowing system that lets you use an editor that's easier to use.

>    Are you sure you don't mean "my spreadsheet software, embedded in my
> word processor, can do that" instead of "my text editor can do that"?
> Not exactly the same thing.

Are you sure you don't mean "me elisp interpreter, embedded in my text 
editor, can do that"?

If I didn't have the ability to embed spreadsheets in Word automatically, 
then yes, I'd write a VBA or .NET macro to do that. Probably with a lot less 
code than it took to do it in elisp, given that tables are already built 
into Word. :-)

Embedding one program inside another has been around since Win3.1. It's a 
fundamental building block of the system. That's why Office is sold as a 
group. Excluding that (and its benefits) would be as nonsensical as asking 
if emacs can run without a file system underlying it.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

>>>     Can you do it in a text terminal through ssh?
>
>> Why the hell would I do that?
>
>    Ah, the magic words. The always trusty answer when you can't do something.
>
>    A simple "no" would have sufficed, you know.

Can I run it removely? Yes.

Can I run it remotely using 40-year old technology? No.

Would I want to? No.

>> and then showed embedding a spreadsheet into a text
>> document and regenerating HTML from that. And the answer is "yes, my text
>> editor can do that." I mean, come on, they're showing off that they can put
>> columns in a text file that adjust to the width of the text in the column?
>> Yes, indeed, my text editor can do that.
>
>    Are you sure you don't mean "my spreadsheet software, embedded in my
> word processor, can do that" instead of "my text editor can do that"?
> Not exactly the same thing.

One of the things they claim is so great about Emacs is that you can 
hook it up to external programs (grep, ls, diff, make, etc.)

Under Windows, it's way harder to do this via the CLI, but also way 
easier for the tiny number of systems that support stuff like COM.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 8/4/2011 10:01, Warp wrote:
>    That reminds me of all the people who complain how the Gimp can't do this
> and the Gimp can't do that, always comparing it to PhotoShop.

Except that's an actual, real example from my actual, real life. Once a 
year, I wind up with about 2000 rows of spreadsheet in a text document for 
the internal revenue service. :-)

NFW would I try to use emacs to lay out a spreadsheet to generate a 90-page 
report that has to fit properly the pre-printed forms the government 
expects. That's just not a text-editor thing.

I understand what you're saying. But I think a large number of people who 
(for example) say people are stupid for paying for something like Office are 
the people who don't use it in situations where it's worth paying for. They 
say things like "why would I need a 90-page-long table with totals under 
some columns embedded in the middle of some other text document, especially 
a table where some third party is going to control the width of the columns 
and the layout of the text?"

>    The thing is, the rare occasion I need to do some image editing, I'd
> rather use the *free* software rather than pay big bucks for the pro
> software which might be really superb, but costs a kidney and runs only
> on Windows. The free alternative might not have even a fraction of the
> features, but at least it's free and available for my system of choice.

Well, sure. You're not the target market. Every pro I've talked to who has 
tried Gimp says not only is it very limited, it's not organized in a way 
that matches the way one works on professional-size documents and layout. 
Sort of the way Andrew is complaining about Ctl-S vs ctl-x ctl-s not being 
intuitive or needing more keystrokes for the common case.

Imagine if you took Blender, and arranged the options in the windows at the 
bottom based on where in the code you implemented them, rather than putting 
all the texture stuff in one place and all the animation stuff in another 
place and all the modeling stuff in a third place. I might not find that 
distressing, but any professional used to some expensive package like Maya 
would say "who the heck designed this?"

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 10:16, andrel wrote:
> images were when I did mine in 1996. pretty sure we also used them a few
> years before that.

The only support for images was "leave a spot for an image this big here." 
Then you could plug stuff in later in the processing chain that would 
actually insert the image. Maybe.  Sometimes.  Not infrequent to spend two 
or three days just getting the 200-page copy printed out.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 10:25, Orchid XP v8 wrote:
> Under Windows, it's way harder to do this via the CLI, but also way easier
> for the tiny number of systems that support stuff like COM.

Almost everything on Windows supports COM. COM has been around since Win3. 
I'm not sure why you think it's a tiny number, except for the programs 
actually ported poorly from Unix, or the programs ported from Unix where 
people say "why would you ever want to automate this with a *standard* 
scripting language?"

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 10:17, Darren New wrote:
> OK. You said "it's things like this", then pointed out a video showing off
> the customizability of emacs. VIM can do the same thing. TECO can do the
> same thing. PMate can do the same thing.

I *will* grant you that elisp is easy to understand and write than any other 
of those macro systems, which is why it gets shown off, but they're all 
turing complete. :-)

The scripting languages in Windows tend to be pretty good, even better than 
elisp, tho.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 4-8-2011 19:30, Darren New wrote:
> On 8/4/2011 10:16, andrel wrote:
>> images were when I did mine in 1996. pretty sure we also used them a few
>> years before that.
>
> The only support for images was "leave a spot for an image this big
> here." Then you could plug stuff in later in the processing chain that
> would actually insert the image. Maybe. Sometimes. Not infrequent to
> spend two or three days just getting the 200-page copy printed out.

Interesting, I had lots of images in my thesis and that was only a few 
years later. Including "leitmotiv"s, small icons in the margin with 
recurring themes. So definitely not all pictures on the top of pages for me.
Strangely I can not find the source files ATM to see how I did it back 
then. I am sure I have seen them recently (i.e. less than a year ago). I 
intend to make it available as a pdf file one day, using the original 
source. And perhaps update a few things. ;)

-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

> I'll leave correcting you on several EMACS mistakes to the others. I
> just want to point out that you apparently have been looking at an
> *implementation* (under windows?). You should not confuse that with the
> /idea/ EMACS.

Oh, I'm sure a few of the things I couldn't figure out how to do are 
actually hidden away in some command or other that I didn't spend long 
enough trying to find. But anyway...

>> Maybe it's "the best" in the same way as TeX. The output of TeX is quite
>> simply the most beautiful thing I've ever seen. Nothing else even comes
>> remotely close to looking this damned good. Which is just as well,
>> because otherwise TeX would have been nuked from space long ago. The
>> /output/ is delightful. The /input/ is the stuff of nightmares.
>
> It isn't. It is more straightforward than e.g. Word. Everything you need
> to know is in plain sight.

Riiiiight. Tell me, how do I

>> It really doesn't handle colour,
>
> It does. No idea how you got that impression.
>
>> it really doesn't handle images,
>
> It does. No idea how you got that impression.

TeX does not "understand" colour or graphics.

Instead, people have created various packages with insert "specials" 
into the output DVI file, together with programs which interpret these 
specials to generate the appropriate output.

After many years of development, it has now reached the point where this 
kludge mostly works OK. The graphicx and color packages automatically 
detect which backend is in use and generate the correct specials. My DVI 
viewer supports the "dvips" specials, which is what graphicsx and color 
default to producing, while PDF-TeX has special drivers so that it works 
out of the box as well.

The system is still fragile, however. Literally, the colour changing 
commands are classified as "fragile" LaTeX commands, and you're supposed 
to use /protect and so forth. If you, for example, change colour in a 
section heading, that works fine in the section heading, but breaks in 
the table of contents and page running headings.

Basically, TeX has no idea what you're trying to do, and the various 
packages and drivers are desperately trying to work around the problem 
to make it "look like" the system can actually handle such things.

Oh, and I forgot to mention hyperlinks. But then, TeX is for /printing/, 
primarily, so that's excusible.

>> and it most certainly
>> does /not/ handle styling or customisation of any kind!
>
> It most certainly does. Style files are are at the heart of the system.

Sure. In theory.

Now suppose that for some reason I wanted all the document to come out 
in a different typeface for some reason. The body text, section 
headings, table of contents, figure captions, everything. Do you have 
any idea how intractibly difficult that is?

Fortunately, LaTeX has such nice defaults that you don't often /need/ to 
change anything. Which is very, /very/ fortunate, because it's hellishly 
hard to change stuff if you actually want to.

> As a small comparison: a friend of mine had written her thesis in Word,
> after her text was accepted by the committee she needed 3 weeks of hard
> work to convert it from an A4 draft version into a paperback format text
> that she could submit to the printer. I did it, with the help of a
> student, in one evening. And I had different layouts for chapters
> depending on whether it was published before or not.

See, what you just said there is "Word sucks". Which is true, but isn't 
my point.

Try writing a big HTML document. Now by applying some CSS to it, you can 
utterly transform it. Don't believe me?

http://www.csszengarden.com/

Click a few of the stylesheets. Watch the entire page radically 
transform instantly. TeX can't do that. (Recent versions of Word almost 
can... but don't expect it to work properly.)

>> Oh, and don't try debugging it.
>
> If you want to debug TeX

I have never found it necessary to do that, and I doubt I ever will. TeX 
may be old and crufty, but it's reliable as hell.

> If you mean debugging your text or layout, that is more simple than in a
> wysiwyg editor.

The page breaks look just fine. Then I write some more text, and the 
page breaks move. Wuh?

> If you mean debugging style files or bibstyle files you are correct,
> that is a nightmare if you don't know what you are doing. Simple advise:
> don't touch them.

Do you have any idea how much trouble I had trying to get it so that any 
text put inside a "tabbing" environment comes out green? In the end I 
was forced to give up. It just WILL NOT work consistently.

If this was HTML I was talking about, changing the colour of one block 
of text would be laughably simple. But TeX just can't handle it.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 04/08/2011 06:32 PM, Darren New wrote:
> On 8/4/2011 10:25, Orchid XP v8 wrote:
>> Under Windows, it's way harder to do this via the CLI, but also way
>> easier for the tiny number of systems that support stuff like COM.
>
> Almost everything on Windows supports COM. COM has been around since
> Win3. I'm not sure why you think it's a tiny number, except for the
> programs actually ported poorly from Unix, or the programs ported from
> Unix where people say "why would you ever want to automate this with a
> *standard* scripting language?"

Perhaps it's because almost everything I use is FOSS?

Does POV-Ray support COM? Is Windows the primary development platform 
for POV-Ray? Exactly.

Does 7zip support COM? How about Firefox? Google Earth? Sketchup?

None of these are exactly "small" or "obscure" or "primarily for Linux". 
And yet, no COM.

But in trying to come up with a list... yeah, most of the stuff I have 
is FOSS, which probably explains why no COM.

Now, aside from that matter, the thing which really puzzles me is this: 
If something *does* support COM, how the hell do you *use* it? You of 
all people are often talking about "hey, I used COM to connect my coffee 
machine to my diskwasher", but how the hell do you actually *do* that? 
I've never figured this out.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 8/4/2011 9:57, Warp wrote:
> > Darren New<dne### [at] sanrrcom>  wrote:
> >> On 8/4/2011 9:22, Warp wrote:
> >>>     Can you do it in a text terminal through ssh?
> >
> >> Why the hell would I do that?
> >
> >    Ah, the magic words. The always trusty answer when you can't do something.
> >
> >    A simple "no" would have sufficed, you know.

> No, I'm serious. Why would I want to do that? Why wouldn't I just access the 
> file remotely, instead of accessing the program remotely.

  I think there has been a miscommunication here.

  Emacs has always been deemed as a very powerful text editor during its
entire history, which goes back to the 70's (as incredible as that might
sound). The question was: Why? I gave one example of why. Back in the 80's
and early 90's, when the most common way of using a Unix system was through
a dumb terminal, or if you were lucky, telnet, you could already do stuff
like this. You could do this back when Windows didn't even exist, and Mac OS
was a monochrome low-resolution OS running on a bird house. (Granted, even
emacs was more primitive back then than it is today, but it was still pretty
powerful.)

  Please don't cling to this specific example and argue how this-or-that
program can also do the same. It was just one example.

  So I was answering the question of why emacs has traditionally been
considered a pretty badass program by unix freaks for most of computing
history.

  Have other software caught up and able to do similar things today?
Certainly. However, emacs still has its avid fans, due to its long history.

  And also, most text editors (even commercial ones) *can't* do the same
things as emacs can.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >>>     Can you do it in a text terminal through ssh?
> >
> >> Why the hell would I do that?
> >
> >    Ah, the magic words. The always trusty answer when you can't do something.
> >
> >    A simple "no" would have sufficed, you know.

> Can I run it removely? Yes.

> Can I run it remotely using 40-year old technology? No.

> Would I want to? No.

  You asked why emacs is considered so powerful. I answered why. Take into
account its historical *context*. The development of emacs first started
in the 70's.

  Time for an analogy: Someone asks why katanas are considered so cool,
and then objects that guns can be used for the same purpose. Context, boy,
context.

-- 
                                                          - Warp

Post a reply to this message

>> (Although they also tacked on Design By Contract, which isn't strictly
>> anything to do with OO.)
>
> If you didn't understand why DbC is fundamental to "perfect" OOP, you've
> missed a major point of the development of it. DbC *is* the OO. The
> actual bodies of the methods are an implementation detail. :-)

Or rather, the method bodies are the actual delivered application. DbC 
is merely a testing framework. ;-)

Anyway, point being, you can apply DbC to anything. It doesn't have to 
be OO.

>> A perfect language... shame the implementation sucks arse, eh?
>
> True. The first time I tried it, and this is like version 5.2 or so, you
> started a new project and it gave you a Hello World skeleton to start
> from. If you started a new project, then clicked "compile" without
> touching anything else, the compiler bombed out.

Epic fail.

I still chuckle at how if you ask GHC to compile your program with 
dynamic linking rather than static, it fails out of the box. No mention 
of this in the documentation, no discussion on how to fix it, no 
indication that it might even be a problem. (And no discussion on where 
the heck it actually looks for the DLLs...)

Emacs may be old and clunky, but to be fair, it worked perfectly out of 
the box.

>> Maybe it's "the best" in the same way as TeX. The output of TeX is quite
>> simply the most beautiful thing I've ever seen.
>
> Hopefully they've improved it. TeX is probably OK as long as you don't
> use it with metafont files, but the output with metafont is pretty sucky.

I don't get what's "sucky" about Metafont. (Other than that nobody uses 
bitmap fonts anymore unless they really have to...)

>> Or perhaps it's "the best" in the same way that Unix is: It's ancient and
>> basically obsolete, but nothing can match it for reliability, flexibility
>> and compatibility with a large library of existing stuff.
>
> I'd argue that Windows may have better flexibility (modulo not actually
> having the source to it, and not counting "portability" as
> "flexibility") and a larger library. It's certainly not a slam dunk for
> Unix. Plus, Unix isn't really all that reliable, either.

With Unix, you can decide to use a completely different filesystem that 
you just made up, you can change the thread scheduling algorithm, and 
then you can change the implementation of the ARP cache from a hashtable 
to a linked list. None of which is possible with Windows.

I have never, ever seen Linux crash unless I did something wrong. (E.g., 
it crashes because I just told it to format a device that's currently 
mounted.) My first Windows XP laptop crashed WITHIN 14 SECONDS of first 
being turned on. Didn't even finish the setup wizzard.

That said, over the years Windows has become more reliable. Our Windows 
servers basically never crash. I have to reboot them for some reason 
long before they fail.

Still, if I was going to run, like, a nuclear enrichment program, I 
wouldn't want to use Windows. The malware implications alone would be... 
oh, wait.

>> Suffice it to say, Emacs is /ancient/. From what I can gather, it's even
>> older than Unix
>
> The first versions were. I don't think it was called emacs at the time.
> It was also originally developed on an OS other than Unix, so the "meta"
> key was actually a separate key from "alt".

I gathered. ;-)

>> Ctrl+A ("aahhh... wuh??").
>
> Because Ctrl-H is help, you see.

And Ctrl+B ("beginning") is already "back". And Ctrl+F ("first") is 
already "forward"...

> That's the thing that always killed *me* about Emacs. The key mappings
> were half mnemonic and half abbreviation and half based on keyboard
> position. On the other hand, Wordstar I still remember every keystroke,
> in spite of not having used it since 1982 or so.

It wasn't actually as hard as I'd imagined it would be. Mostly. A few 
really common things have obscure commands.

>> Interestingly, while Ctrl+F moves the cursor one character forward, Alt+F
>> moves it one /word/ forward. (And similarly for Ctrl+B vs Alt+B.) I've
>> never seen a text editor that can do that.
>
> Really? Even notepad does that: ctrl-rightarrow. Every editor does this.

Well, yeah, I don't tend to open up a text editor and then press random 
key combinations to see if it activates a special feature I didn't know 
about.

>> (But then again, it's not exactly a feature you'd bother looking for.)
>
> Of course it is, especially if you're editing text.

Can you give one single example of where you'd want to do this rather 
than, say, just jab the arrow key a few times?

> It depends on the mode. A "word" is one token.

> Again, it depends on the mode. If you're editing a program, it's one
> statement, one s-expr, etc.

Figures. I only tried editing text; I figured anything else would be too 
hard.

>> (Presumably because on a
>> VT100 there's no way to turn off the cursor. :-P )
>
> No, it's because VT100s don't have scrollbars.

Sure. But there's no reason why Ctrl+V should move the cursor rather 
than let it scroll off the screen. Still, windows would mitigate the 
need for this. (If I could work them.)

>> Apparently by typing Ctrl+U 8 Ctrl+F, I can move the cursor exactly 8
>> characters left. I'm left wondering why in the name of God I would *ever*
>> want to do this.
>
> Because you want to draw a line of 30 hyphens across the screen. Or you
> want to skip to line 287 in your file.

I'm kinda surprised that there doesn't seem to be a "go to line 287" 
command. I mean, you can go to the top and then move down 287 lines. No, 
wait, that would take you to line 288. ARGH! >_<

>> There's a section on "when Emacs is hung". What, you're actually
>> expecting that to happen?
>
> If you're writing your own code, or you hand it a few megabytes and say
> "go indent this".

Wait, your own code can crash Emacs?

Generally you don't expect, say, Firefox to die just because you feed it 
some bad JavaScript.

Oh, wait am I saying? Your own code *is* Emacs!

>> Now, get this: Apparently a very rare operation such as "search" is
>> Ctrl+S,
>> but an extremely common operation like "save" (arguably the single most
>> important command that any file editor can ever have) is Ctrl+X Ctrl+S.
>
> I'm not sure why you think you'd save a file more often than you search.
> It boggles my mind to think you think searching for text in a file is
> highly specialized and uncommon. Oh, wait, this from the guy who doesn't
> use google. ;-)

A typical editor session generally involves lots of typing, maybe a bit 
of scrolling, and periodically saving. So you'd expect the commands for 
editing and scrolling to be quick, as well as the command for saving.

I'm trying to think of an instance where you'd actually want to search 
for something. Perhaps to find a given function name? To check whether a 
misspelt word appears anywhere in your text? To check that you replaced 
all occurances of something? These are all pretty rare, really.

>> ...which seems reasonable, although some of their decisions about what
>> constitutes "common commands" are /highly/ dubious!
>
> That's why you can remap the keys as you like. ;-)

And break compatibility with all the extensive library of code written 
for Emacs! :-D

>> Having tried the incremental search I discovered something quite nice: it
>> actually /highlights/ everything on the page that matches your search. A
>> trivial feature, but one which I haven't seen in any other software.
>
> Damn, man, you gotta get out more. I haven't seen any decent editor
> since Win95 that doesn't do that. Sure, not notepad, but everything else.

IMHO, Notepad doesn't even qualify as a "text editor". More like "thing 
I use if nothing better is available".

Fun thing: Open Firefox. Press F3. Start typing. It highlights the first 
match it finds, as you type. By pressing Next and Prev, you can make it 
select other matches. But it does /not/ highlight *all* of them at once. 
I haven't seen anything except Emacs do that.

> Nobody uber enough to use emacs would stoop to editing web pages with
> embedded javascript. ;-)

Riiiight. And I guess they also wouldn't edit C code with SQL embedded 
in it, or Makefiles with Bash scripts embedded in them. Or Lisp code 
that contains TeX fragments...

> Really, the code that recognises that stuff just needs to be updated.

The syntax highlighting works out of the box, which is nice. But the 
whole major mode / minor mode thing seems to preclude sorting out nested 
languages properly.

>> The HTML highlighting is actually nicer than most.
>
> You should check out VIM if you want a somewhat more rational editor
> that does all this stuff emacs does.

Last time I invoked Vi, I had to reboot the PC to get out of it again.

Actually, that's not true. I discovered that by pressing a certain 
keyboard combination, you can access "virtual terminals", which allow 
you to run "ps", search for the PID of vi, and issue a "kill" command. 
That way, you can exit without rebooting.

>> In short, after spending a few days playing with Emacs, I'm still not
>> finding anything that makes me to "wow!"
>
> Many of the nice features of emacs become redundant in an environment
> with windows, and especially in an environment with IDEs customised for
> the specific languages you're using.

>> I suspect you could probably make something /like/ Emacs, but with a
>> modern design, and it would work well.
>
> Yes. They call it an IDE. ;-) Or "a windowed desktop."

These.

 From what I can gather, Emacs was amoung the very first editors that 
let you SEE WHAT YOU'RE EDITING, and do this AT THE SAME TIME AS YOU 
EDIT IT. The other editors were apparently like that awful "sed" thing. 
I can see how this would be regarded as a massive leap forward.

Being able to view multiple files simultaneously on a VT100 would have 
been a significant technical achievement. It seems Emacs basically 
invented the multiple document interface / tabbed editing / whatever you 
want to call it.

Being able to invoke all your tools from within your editor and edit 
their output is again quite a powerful idea.

But you know what? All these things are basic features that *all* 
software has now. It's not revolutionary any more. It seems to me that 
Emacs just isn't /relevant/ any more.

The one thing I would say is that a good IDE is far better than Emacs 
will ever be. But every IDE I've seen has been massively beaurocratic 
and complicated to use. And usually there's almost no possibility of 
changing it. The one thing that Emacs appears to have got right is total 
customisibility.

Visual Studio is an IDE. It works for (say) C++. But if I decided I 
wanted it to work for Haskell... tough. Cannot be done. Not unless you 
hire a vast army of C++ programmers to write the necessary hooks and 
DLLs and God only knows what else to add the support to VS.

My current editor is SciTE. It supports many, many file formats. But 
Haskell is not one. I would have to compile it from source to add 
Haskell syntax highlighting (since none of the existing lexers are 
remotely similar, so I would have to add a new one).

Emacs doesn't support Haskell out of the box. But I know for a fact that 
there's several people who have developed major modes for it. If I 
actually cared, I could probably spend a day or two getting basic syntax 
highlighting to work.

I think there is probably still a place in the world for some kind of 
engine which is so configurable that you can build a complete 
development environment with it, for any conceivable target, without 
having to do really heavy stuff like writing low-level C code or 
compiling huge codebases from scratch.

Actually, the reason I'm looking at Emacs today rather than some other 
day is that I saw a rant online about how bloated and useless IDEs are 
and how Emacs is superior in every possible way. The rant concluded by 
saying "IDEs aren't a threat to Emacs. Firefox is."

If that sounds crazy, consider that a third party write an IRC client 
for Firefox. As far as I know, it's just a bunch of XML and JavaScript 
that the Firefox scripting and rendering engine runs. But it's a working 
(if minimal) IRC client.

Unlike Emacs, Firefox has a proper, grown-up GUI and excellent graphical 
capabilities. If you could make it configurable and scriptable to the 
point where you could build arbitrary applications with it... that would 
be pretty insane.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Can I run it removely? Yes.
>
>> Can I run it remotely using 40-year old technology? No.
>
>> Would I want to? No.
>
>    You asked why emacs is considered so powerful. I answered why. Take into
> account its historical *context*. The development of emacs first started
> in the 70's.

OK, I guess what I was really asking is why it's still considered the 
most powerful editor *today*.

I can see how it does several things which would have been very 
remarkable at one time. It appears to have practically *invented* 
interactive editing, syntax highlighting, multiple document interfaces, 
incrimental searching... all years before anything else did it.

But, given that these are all ubiquitous features *today*, is Emacs 
still relevant?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 04/08/2011 04:48 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> The more vocal proponents will tell you how Emacs is the most advanced,
>> sophisticated, powerful and generally /perfect/ piece of software that
>> Mankind has ever produced, and that no other editor could ever come
>> close to equalling its supreme perfection. And yet, none of them can
>> explain /why/ it's so perfect. (Except that, hey, you can *customise* it!)
>
>    It's things like this: http://www.youtube.com/watch?v=EQAd41VAXWo

Heh. Now, see, while it /is/ kind of neat that a terminal program can do 
that, it would be far neater if my text editor could pop up a real GUI 
for managing a table *properly*, and then convert that into HTML.

Actually, I notice the same artifact here as I did with "fill mode". In 
that mode, whenever you finish typing something, Emacs wraps it at 70 
characters for you. Which is nice and all, but you know what? As I'm 
typing this post right now, Thunderbird is going the same thing 
/interactively/. It doesn't wait until I've stopped typing and than 
rearrange all my text. It arranges it as I type, so I can immediately 
see what the result will be like.

Actually, I'm not sure why Emacs can't do that too. But then, this is 
from the editor who's *beginner* documentation tells you how to turn off 
certain screen updates "in case you're using a slow terminal". As if 
that's actually a valid thing to worry about in 2011. "Oh man, /why/ did 
I go with the VT101? Sure, the VT102 is more expensive, but it would 
make this task much easier!"

The editing above seems to have the same problem. It seems you have to 
press a certain key to realign all the cell boundaries, instead of them 
moving as you type. (The fact that the HTML doesn't update isn't a big 
deal. Presumably you'll only bother updating that when you're done.)

>    (As for the rest of your post, tl;dr, sorry.)

I had to go look that up... Ironically, the article is *very* short. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 4-8-2011 21:19, Orchid XP v8 wrote:
>> I'll leave correcting you on several EMACS mistakes to the others. I
>> just want to point out that you apparently have been looking at an
>> *implementation* (under windows?). You should not confuse that with the
>> /idea/ EMACS.
>
> Oh, I'm sure a few of the things I couldn't figure out how to do are
> actually hidden away in some command or other that I didn't spend long
> enough trying to find. But anyway...
>
>>> Maybe it's "the best" in the same way as TeX. The output of TeX is quite
>>> simply the most beautiful thing I've ever seen. Nothing else even comes
>>> remotely close to looking this damned good. Which is just as well,
>>> because otherwise TeX would have been nuked from space long ago. The
>>> /output/ is delightful. The /input/ is the stuff of nightmares.
>>
>> It isn't. It is more straightforward than e.g. Word. Everything you need
>> to know is in plain sight.
>
> Riiiiight. Tell me, how do I

Use your brain?

>>> It really doesn't handle colour,
>>
>> It does. No idea how you got that impression.
>>
>>> it really doesn't handle images,
>>
>> It does. No idea how you got that impression.
>
> TeX does not "understand" colour or graphics.
>
> Instead, people have created various packages with insert "specials"
> into the output DVI file, together with programs which interpret these
> specials to generate the appropriate output.
>
> After many years of development, it has now reached the point where this
> kludge mostly works OK. The graphicx and color packages automatically
> detect which backend is in use and generate the correct specials. My DVI
> viewer supports the "dvips" specials, which is what graphicsx and color
> default to producing, while PDF-TeX has special drivers so that it works
> out of the box as well.

indeed. Lots of packages to handle the most diverse needs. A reasonable 
on-line index and books with examples.

> The system is still fragile, however. Literally, the colour changing
> commands are classified as "fragile" LaTeX commands, and you're supposed
> to use /protect and so forth. If you, for example, change colour in a
> section heading, that works fine in the section heading, but breaks in
> the table of contents and page running headings.

If you mean that you wanted to change global behaviour in a heading, you 
deserve nothing better than a broken output.

> Basically, TeX has no idea what you're trying to do, and the various
> packages and drivers are desperately trying to work around the problem
> to make it "look like" the system can actually handle such things.
>
> Oh, and I forgot to mention hyperlinks. But then, TeX is for /printing/,
> primarily, so that's excusible.

I think I have even seen those.

>>> and it most certainly
>>> does /not/ handle styling or customisation of any kind!
>>
>> It most certainly does. Style files are are at the heart of the system.
>
> Sure. In theory.
>
> Now suppose that for some reason I wanted all the document to come out
> in a different typeface for some reason. The body text, section
> headings, table of contents, figure captions, everything. Do you have
> any idea how intractibly difficult that is?

Bloody easy. My theses was in Garamont (IIRC my student decide that 9.5 
points would be ideal). Noticed that too late in the process to change 
it to something

> Fortunately, LaTeX has such nice defaults that you don't often /need/ to
> change anything. Which is very, /very/ fortunate, because it's hellishly
> hard to change stuff if you actually want to.
>
>> As a small comparison: a friend of mine had written her thesis in Word,
>> after her text was accepted by the committee she needed 3 weeks of hard
>> work to convert it from an A4 draft version into a paperback format text
>> that she could submit to the printer. I did it, with the help of a
>> student, in one evening. And I had different layouts for chapters
>> depending on whether it was published before or not.
>
> See, what you just said there is "Word sucks". Which is true, but isn't
> my point.
>
> Try writing a big HTML document. Now by applying some CSS to it, you can
> utterly transform it. Don't believe me?
>
> http://www.csszengarden.com/
>
> Click a few of the stylesheets. Watch the entire page radically
> transform instantly. TeX can't do that. (Recent versions of Word almost
> can... but don't expect it to work properly.)

?? LaTeX can, haven't used plain TeX enough to have noticed any 
instances where it didn't work. Unless instantly is your operative word. 
Nothing is instantly in TeX, it was designed not to. Just as POV-ray btw.

>>> Oh, and don't try debugging it.
>>
>> If you want to debug TeX
>
> I have never found it necessary to do that, and I doubt I ever will. TeX
> may be old and crufty, but it's reliable as hell.
>
>> If you mean debugging your text or layout, that is more simple than in a
>> wysiwyg editor.
>
> The page breaks look just fine. Then I write some more text, and the
> page breaks move. Wuh?

Yes, what did you expect else? Somewhere I have this nagging feeling 
that you try to treat TeX as a something similar to Word. Just a program 
to convert raw text to nice output.

>> If you mean debugging style files or bibstyle files you are correct,
>> that is a nightmare if you don't know what you are doing. Simple advise:
>> don't touch them.
>
> Do you have any idea how much trouble I had trying to get it so that any
> text put inside a "tabbing" environment comes out green? In the end I
> was forced to give up. It just WILL NOT work consistently.

You mean messing with the standard tabbing environment or when creating 
a new green environment.

> If this was HTML I was talking about, changing the colour of one block
> of text would be laughably simple. But TeX just can't handle it.

Correction: you can not handle it. If I understood what you wanted to 
accomplish, I might feel tempted to try.


-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 8/4/2011 12:34, Warp wrote:
>    So I was answering the question of why emacs has traditionally been
> considered a pretty badass program by unix freaks for most of computing
> history.

That's fair. But that certainly wasn't implied by the video you linked to. 
Hence my confusion. :-)

And many other editors (like vi) of the time could handle similar stuff, yes.

I'll certainly agree that emacs is powerful for a text editor, and in the 
70s and 80s it was a pretty good powerful solution for working with text 
from a nerd-programmer point of view.

>    And also, most text editors (even commercial ones) *can't* do the same
> things as emacs can.

VIM macros are turing complete, *and* it can shell out parts of the code to 
other tasks, which is far more Unixy than emacs' approach, methinks. I guess 
maybe I just haven't used crappy editors enough to be hindered by the ones 
that don't have macros.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> OK, I guess what I was really asking is why it's still considered the 
> most powerful editor *today*.

  There aren't many text editors even today that reach the same level
of expressiveness.

  Most software development IDEs have editors that do a lot of things
(like syntax highlighting and such) but are not even nearly as powerful
as emacs. (The most annoying thing that they usually lack is the same
kind of autoindentation as emacs has had for centuries.)

-- 
                                                          - Warp

Post a reply to this message

>> Riiiiight. Tell me, how do I
>
> Use your brain?

I fail basic English. :'{

>> TeX does not "understand" colour or graphics.

> indeed. Lots of packages to handle the most diverse needs. A reasonable
> on-line index and books with examples.

Like I say, after hacking away at it for years, they've got it to 
sort-of work, most of the time. That's not the same as TeX *actually* 
supporting these things.

>> The system is still fragile, however. Literally, the colour changing
>> commands are classified as "fragile" LaTeX commands, and you're supposed
>> to use /protect and so forth. If you, for example, change colour in a
>> section heading, that works fine in the section heading, but breaks in
>> the table of contents and page running headings.
>
> If you mean that you wanted to change global behaviour in a heading, you
> deserve nothing better than a broken output.

No. If you just want to change the colour of one word in a seciton 
heading. Pretty easy with CSS (you can even have it apply only to the 
section heading and not the TOC listing, for example), but does evil 
things to TeX.

>> Oh, and I forgot to mention hyperlinks. But then, TeX is for /printing/,
>> primarily, so that's excusible.
>
> I think I have even seen those.

Yes. They're kludged in the same way as colour and graphics.

>>> It most certainly does. Style files are are at the heart of the system.
>>
>> Sure. In theory.
>>
>> Now suppose that for some reason I wanted all the document to come out
>> in a different typeface for some reason. The body text, section
>> headings, table of contents, figure captions, everything. Do you have
>> any idea how intractibly difficult that is?
>
> Bloody easy. My theses was in Garamont (IIRC my student decide that 9.5
> points would be ideal). Noticed that too late in the process to change
> it to something

...something...? Perhaps it is not only me that fails English. ;-)

>> Click a few of the stylesheets. Watch the entire page radically
>> transform instantly. TeX can't do that. (Recent versions of Word almost
>> can... but don't expect it to work properly.)
>
> ?? LaTeX can, haven't used plain TeX enough to have noticed any
> instances where it didn't work. Unless instantly is your operative word.

If I decided, for some insane reason, that I wanted section headings to 
be set vertically in the margin rather than how a sane person would set 
them... well, technically it's /possible/, but it would be damned /hard/ 
to do it.

>>> If you mean debugging your text or layout, that is more simple than in a
>>> wysiwyg editor.
>>
>> The page breaks look just fine. Then I write some more text, and the
>> page breaks move. Wuh?
>
> Yes, what did you expect else? Somewhere I have this nagging feeling
> that you try to treat TeX as a something similar to Word. Just a program
> to convert raw text to nice output.

Well, that's what it *is*. It's a program that converts your markup into 
something that looks nice.

(Word, of course, is more about *editing* text than actually making it 
look good...)

It's just baffling when a seemingly unrelated change causes part of the 
page flow to change for the worse. Or when you say "put this figure 
HERE" so LaTeX puts it five pages later. Or whatever.

>> Do you have any idea how much trouble I had trying to get it so that any
>> text put inside a "tabbing" environment comes out green? In the end I
>> was forced to give up. It just WILL NOT work consistently.
>
> You mean messing with the standard tabbing environment or when creating
> a new green environment.
>
>> If this was HTML I was talking about, changing the colour of one block
>> of text would be laughably simple. But TeX just can't handle it.
>
> Correction: you can not handle it. If I understood what you wanted to
> accomplish, I might feel tempted to try.

I merely wanted to create a new tabbing environment where all the text 
comes out green, set one quad in from both margins. (Apparently there's 
no way to prevent it flowing off the right edge of the page though...)

First I found that only the /first/ line came out green. So then I added 
a group around the body. That worked fine... until the environment went 
over a page break, at which point it broke again. Not to mention that by 
flipping from page to page, I actually managed to break the DVI viewer 
as well. (At one point the entire document turned green, just by me 
manipulating the view...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 04/08/2011 10:16 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> OK, I guess what I was really asking is why it's still considered the
>> most powerful editor *today*.
>
>    There aren't many text editors even today that reach the same level
> of expressiveness.
>
>    Most software development IDEs have editors that do a lot of things
> (like syntax highlighting and such) but are not even nearly as powerful
> as emacs. (The most annoying thing that they usually lack is the same
> kind of autoindentation as emacs has had for centuries.)

Interesting. Every IDE I've seen has had an autoindent feature that you 
can't turn *off*. (Which is annoying, because usually it works 
incorrectly...)

Anyway, I'm still not seeing the "not nearly as powerful" bit. Emacs 
lets you change stuff yourself. Most editors and IDEs aren't so 
flexible. That's the only difference I can see currently.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 8/4/2011 12:26, Orchid XP v8 wrote:
> None of these are exactly "small" or "obscure" or "primarily for Linux". And
> yet, no COM.

Well, there's another reason people rage about IE still being popular for 
intranet purposes. It's because people writing the new browsers ignore the 
environment they're in.

The problem with COM is that it's not something you can really paste on 
after the fact. If your system isn't very Model-view-controller, it's hard 
to make it interface with a COM interface.

> But in trying to come up with a list... yeah, most of the stuff I have is
> FOSS, which probably explains why no COM.

That and people who are doing firefox development don't *expect* you to use 
it in an automated way, or they expect you to automate it solely thru 
javascript.

Anyone building something for a *business* to use is going to use COM for 
the interface on Windows.

> Now, aside from that matter, the thing which really puzzles me is this: If
> something *does* support COM, how the hell do you *use* it?

http://msdn.microsoft.com/en-us/library/aa366757%28VS.85%29.aspx


-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Actually, I notice the same artifact here as I did with "fill mode". In 
> that mode, whenever you finish typing something, Emacs wraps it at 70 
> characters for you. Which is nice and all, but you know what? As I'm 
> typing this post right now, Thunderbird is going the same thing 
> /interactively/. It doesn't wait until I've stopped typing and than 
> rearrange all my text. It arranges it as I type, so I can immediately 
> see what the result will be like.

  I hate text editors that do some kind of automatic line splitting without
asking (especially if you can't turn the feature off). I like emacs because
it doesn't change anything in the file you open unless you explicitly ask
it to. You can open a *binary* file in emacs, save it, and it will be
identical to the original. The same cannot be said from most other text
editors (especially in Windows) which do tons of "smart" things automatically
(such as convert newline characters, unprintable characters, etc.)

  In fact, thanks to this property, you can use emacs as a hex editor.
It has a built-in hex-editing mode. (Yes, some other text editors have
that too. Not many, though.)

-- 
                                                          - Warp

Post a reply to this message

On 8/4/2011 14:17, Orchid XP v8 wrote:
> Well, that's what it *is*. It's a program that converts your markup into
> something that looks nice.

Technically, it's a program that converts your mark up into a bunch of empty 
boxes that would look nice if you filled them in with the right fonts and 
such. It's stuff like dvi2ps that actually creates something that looks nice.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 14:16, Warp wrote:
> (The most annoying thing that they usually lack is the same
> kind of autoindentation as emacs has had for centuries.)

The one time I got good at emacs was the time I needed better auto-indenting 
than I could get from a filter at the time. :-)

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Can you do it in a text terminal through ssh? Can you customize the
> functionality, change it, add new features or modify existing ones? Can
> you run it on Windows, Linux, MacOS X, BSD, Solaris, and basically any
> Unix-style OS in existence? Can you get that software for free?

  Oh, and another thing: You can do the work on a simple text file, meaning
that if you wanted, you could later edit the file with any other program you
like, rather than using a closed, proprietary file format that can only be
opened and edited with MS Office.

  Imagine if Photoshop only supported a closed proprietary image format to
do its job, rather than doing it on standard image file formats. Suddenly
Gimp would be a whole lot more desirable.

-- 
                                                          - Warp

Post a reply to this message

On 8/4/2011 12:26, Orchid XP v8 wrote:
> Does POV-Ray support COM? Is Windows the primary development platform for
> POV-Ray? Exactly.

It doesn't make a whole lot of sense for a batch-processing program to use 
COM for scripting. What would you script that you can't do from the command 
line?

> Does 7zip support COM? How about Firefox? Google Earth? Sketchup?

http://www.adamlock.com/mozilla/   Mozilla COM interface.

http://earth.google.com/comapi/  Google earth COM api. That wasn't even hard 
to find.

http://include.wutils.com/com-dll/constants/constants-SketchUp.htm
Sketchup COM interface.

> None of these are exactly "small" or "obscure" or "primarily for Linux". And
> yet, no COM.

And yet, no google fu. ;-)

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 13:01, Orchid XP v8 wrote:
> Anyway, point being, you can apply DbC to anything. It doesn't have to be OO.

Hmmmm. Not really.  I can't imagine how you'd apply it to old-school BASIC. 
Or C in any reasonable sense. (What would an invariant look like in C?)

Preconditions and postconditions apply to routines that have state. 
Invariants apply to routines that have state outside of the individual 
routines *and* which have instances. So none of those really apply to purely 
procedural or functional languages.

Exception management in the DbC way doesn't really apply to functional code.

> Emacs may be old and clunky, but to be fair, it worked perfectly out of the
> box.

It's a sad commentary when the normal state of software is "hey, I installed 
it, and it worked before I made any other changes!"

>>> Maybe it's "the best" in the same way as TeX. The output of TeX is quite
>>> simply the most beautiful thing I've ever seen.
>>
>> Hopefully they've improved it. TeX is probably OK as long as you don't
>> use it with metafont files, but the output with metafont is pretty sucky.
>
> I don't get what's "sucky" about Metafont. (Other than that nobody uses
> bitmap fonts anymore unless they really have to...)

The spacing sucks. The weight sucks. I'd have to show you two identical 
pieces of text, one set with metafont, one set on a real typesetter, for you 
to easily see the difference. But it's quite as much there as the jaggies on 
a 300DPI print-out compared to a 1200DPI print-out.

> With Unix, you can decide to use a completely different filesystem that you
> just made up, you can change the thread scheduling algorithm, and then you
> can change the implementation of the ARP cache from a hashtable to a linked
> list. None of which is possible with Windows.

That's not UNIX. That's Linux, and it's because you have the source code, 
not because it's UNIX. And yes, Windows you can use a completely different 
file system you just made up. And you can probably change the other stuff 
too - it just costs more.  And given that TCP/IP is an optional driver, I'd 
be very surprised to find you couldn't load your own version of that too if 
you wanted.

Kernel scheduling? Not so much, agreed.

But that sort of stuff isn't what I think of when I think of a "flexible" 
OS. I think of being able to do things flexibly, not the ability to change 
the source code because I happen to have the source code. I think of the 
ability to do things I couldn't do otherwise if the OS didn't have support 
or hooks for it.

> I have never, ever seen Linux crash unless I did something wrong. (E.g., it
> crashes because I just told it to format a device that's currently mounted.)
> My first Windows XP laptop crashed WITHIN 14 SECONDS of first being turned
> on. Didn't even finish the setup wizzard.

I've seen plenty of Linux crashes. You just didn't run it on flakey hardware 
like you did your XP, for example. (Or you just had a corrupted copy on your 
HD.)  Do you really think everyone who bought that laptop had it crash 
within 15 seconds of turning it on the first time?

> That said, over the years Windows has become more reliable. Our Windows
> servers basically never crash. I have to reboot them for some reason long
> before they fail.

Right.  Windows gets crufty if you keep dicking with it, basically.

> Still, if I was going to run, like, a nuclear enrichment program, I wouldn't
> want to use Windows. The malware implications alone would be... oh, wait.

No, I wouldn't used closed-source software for anything safety critical if I 
could avoid it.

> And Ctrl+B ("beginning") is already "back". And Ctrl+F ("first") is already
> "forward"...

That's exctly the problem with mnemonics.

> Well, yeah, I don't tend to open up a text editor and then press random key
> combinations to see if it activates a special feature I didn't know about.

Control right-arrow is a "random key combination"?

You know that holding shift while you move the cursor selects things too, right?

>>> (But then again, it's not exactly a feature you'd bother looking for.)
>>
>> Of course it is, especially if you're editing text.
>
> Can you give one single example of where you'd want to do this rather than,
> say, just jab the arrow key a few times?

Where I would want to search in a text file to find a word? You're kidding 
me, right?

I have the output from compiling a bunch of programs. The file is 4000 lines 
long. What was the command line used to compile firefox_scrollbar.c?

Heck, I have all the names and addresses in a text file. I want to look up 
my brother's fax number.

I have a program that's several screens long. I want to find everywhere the 
function LookForMe is used.

> I'm kinda surprised that there doesn't seem to be a "go to line 287"
> command. I mean, you can go to the top and then move down 287 lines. No,
> wait, that would take you to line 288. ARGH! >_<

There probably is. It was just an example.

>>> There's a section on "when Emacs is hung". What, you're actually
>>> expecting that to happen?
>>
>> If you're writing your own code, or you hand it a few megabytes and say
>> "go indent this".
>
> Wait, your own code can crash Emacs?

No, but it can hang emacs for long enough that you think it's crashed.

> Generally you don't expect, say, Firefox to die just because you feed it
> some bad JavaScript.

It doesn't, nor does emacs. That's why ctrl-G works, you see. Why do you 
think "interrupting my code where I accidentally wrote an infinite loop" is 
equivalent to "crashing emacs"? It's not crashed exactly *because* you can 
interrupt it.

> A typical editor session generally involves lots of typing, maybe a bit of
> scrolling, and periodically saving. So you'd expect the commands for editing
> and scrolling to be quick, as well as the command for saving.

You don't write a lot of code, do you? :-)

> These are all pretty rare, really.

I think it depends on what you do with an editor. :-) They're all pretty 
common for me.

> And break compatibility with all the extensive library of code written for
> Emacs! :-D

The code for emacs doesn't get invoked thru the keyboard mappings, any more 
than the code for COM does.

> Fun thing: Open Firefox. Press F3. Start typing. It highlights the first
> match it finds, as you type. By pressing Next and Prev, you can make it
> select other matches. But it does /not/ highlight *all* of them at once. I
> haven't seen anything except Emacs do that.

vim and visual studio both do. I don't use much else besides those three.

> Last time I invoked Vi, I had to reboot the PC to get out of it again.

If the last time you ran vi was before windows had close boxes on them, I 
can understand why you might be nervous.

Did you try reading a tutorial first?

>  From what I can gather, Emacs was amoung the very first editors that let
> you SEE WHAT YOU'RE EDITING, and do this AT THE SAME TIME AS YOU EDIT IT.
> The other editors were apparently like that awful "sed" thing. I can see how
> this would be regarded as a massive leap forward.

Nah. emacs didn't work on hard-copy terminals, which were still the dominant 
way of interacting with computers for a long time. As soon as tubes were 
common, so were visual editors.

> Being able to view multiple files simultaneously on a VT100 would have been
> a significant technical achievement. It seems Emacs basically invented the
> multiple document interface / tabbed editing / whatever you want to call it.

I'll grant you that one. :-)

> Being able to invoke all your tools from within your editor and edit their
> output is again quite a powerful idea.

vi had that too, except it was *all* your tools, with no need to write 
macros to handle it.

> Visual Studio is an IDE. It works for (say) C++. But if I decided I wanted
> it to work for Haskell... tough. Cannot be done.

http://research.microsoft.com/apps/pubs/default.aspx?id=67496

Guess how the IDE interacts with it?  COM!

 > Not unless you hire a vast
> army of C++ programmers to write the necessary hooks and DLLs and God only
> knows what else to add the support to VS.

Uh, one Bulgarian intern, on the weekends.

> My current editor is SciTE. It supports many, many file formats. But Haskell
> is not one. I would have to compile it from source to add Haskell syntax
> highlighting (since none of the existing lexers are remotely similar, so I
> would have to add a new one).

Or you could use vim and haskell mode and see if it works.

http://projects.haskell.org/haskellmode-vim/

> I think there is probably still a place in the world for some kind of engine
> which is so configurable that you can build a complete development
> environment with it, for any conceivable target, without having to do really
> heavy stuff like writing low-level C code or compiling huge codebases from
> scratch.

That's exactly why Microsoft invented COM, IBM invented REXX, standards 
bodies invented COBRA, etc etc etc.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 4-8-2011 23:17, Orchid XP v8 wrote:
>>> Riiiiight. Tell me, how do I
>>
>> Use your brain?
>
> I fail basic English. :'{
>
>>> TeX does not "understand" colour or graphics.
>
>> indeed. Lots of packages to handle the most diverse needs. A reasonable
>> on-line index and books with examples.
>
> Like I say, after hacking away at it for years, they've got it to
> sort-of work, most of the time. That's not the same as TeX *actually*
> supporting these things.

of course not, that is not how it works. You use packages if you want to 
do something other than basic typesetting.

>>> The system is still fragile, however. Literally, the colour changing
>>> commands are classified as "fragile" LaTeX commands, and you're supposed
>>> to use /protect and so forth. If you, for example, change colour in a
>>> section heading, that works fine in the section heading, but breaks in
>>> the table of contents and page running headings.
>>
>> If you mean that you wanted to change global behaviour in a heading, you
>> deserve nothing better than a broken output.
>
> No. If you just want to change the colour of one word in a seciton
> heading. Pretty easy with CSS (you can even have it apply only to the
> section heading and not the TOC listing, for example), but does evil
> things to TeX.
>
>>> Oh, and I forgot to mention hyperlinks. But then, TeX is for /printing/,
>>> primarily, so that's excusible.
>>
>> I think I have even seen those.
>
> Yes. They're kludged in the same way as colour and graphics.

Kludged?
People spend a lot of time creating packages for you to use without you 
having to understand the details.

>>>> It most certainly does. Style files are are at the heart of the system.
>>>
>>> Sure. In theory.
>>>
>>> Now suppose that for some reason I wanted all the document to come out
>>> in a different typeface for some reason. The body text, section
>>> headings, table of contents, figure captions, everything. Do you have
>>> any idea how intractibly difficult that is?
>>
>> Bloody easy. My theses was in Garamont (IIRC my student decide that 9.5
>> points would be ideal). Noticed that too late in the process to change
>> it to something
>
> ...something...? Perhaps it is not only me that fails English. ;-)

sorry was distracted and didn't notice I didn't finish the sentence.


>>> Click a few of the stylesheets. Watch the entire page radically
>>> transform instantly. TeX can't do that. (Recent versions of Word almost
>>> can... but don't expect it to work properly.)
>>
>> ?? LaTeX can, haven't used plain TeX enough to have noticed any
>> instances where it didn't work. Unless instantly is your operative word.
>
> If I decided, for some insane reason, that I wanted section headings to
> be set vertically in the margin rather than how a sane person would set
> them... well, technically it's /possible/, but it would be damned /hard/
> to do it.

Not really. It would if you had to catch all circumstances including 
headings that would partially fall of the page

>>>> If you mean debugging your text or layout, that is more simple than
>>>> in a
>>>> wysiwyg editor.
>>>
>>> The page breaks look just fine. Then I write some more text, and the
>>> page breaks move. Wuh?
>>
>> Yes, what did you expect else? Somewhere I have this nagging feeling
>> that you try to treat TeX as a something similar to Word. Just a program
>> to convert raw text to nice output.
>
> Well, that's what it *is*. It's a program that converts your markup into
> something that looks nice.

nope. It is a programming environment that happens to create documents 
as a side effect. ;)


> (Word, of course, is more about *editing* text than actually making it
> look good...)
>
> It's just baffling when a seemingly unrelated change causes part of the
> page flow to change for the worse.

You clearly don't understand TeX's philosophy. It is totally to be 
expected, unless you are brainwashed by wysiwyg environments.

> Or when you say "put this figure
> HERE" so LaTeX puts it five pages later. Or whatever.

You can not say that. You just suggest that this might be a good place. 
It is totally op to Don to grant your wish or not, depending on what he 
thinks looks best. In practice he will be more far often right than you. 
You just remember the occasions where you though you knew better better.

>>> Do you have any idea how much trouble I had trying to get it so that any
>>> text put inside a "tabbing" environment comes out green? In the end I
>>> was forced to give up. It just WILL NOT work consistently.
>>
>> You mean messing with the standard tabbing environment or when creating
>> a new green environment.
>>
>>> If this was HTML I was talking about, changing the colour of one block
>>> of text would be laughably simple. But TeX just can't handle it.
>>
>> Correction: you can not handle it. If I understood what you wanted to
>> accomplish, I might feel tempted to try.
>
> I merely wanted to create a new tabbing environment where all the text
> comes out green, set one quad in from both margins. (Apparently there's
> no way to prevent it flowing off the right edge of the page though...)
>
> First I found that only the /first/ line came out green. So then I added
> a group around the body. That worked fine... until the environment went
> over a page break, at which point it broke again. Not to mention that by
> flipping from page to page, I actually managed to break the DVI viewer
> as well. (At one point the entire document turned green, just by me
> manipulating the view...)

So is TeX to blame or your DVI viewer?



-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

Attachments:
Download 'test.tex.txt' (2 KB) Download 'test.pdf' (10 KB)

On 8/4/2011 15:02, andrel wrote:
> So is TeX to blame or your DVI viewer?

If you're going down that road, then TeX doesn't output any text at all. All 
it outputs is layout. ;-)

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 14:36, Warp wrote:
>    Oh, and another thing: You can do the work on a simple text file, meaning
> that if you wanted, you could later edit the file with any other program you
> like, rather than using a closed, proprietary file format that can only be
> opened and edited with MS Office.

You could do that with Word or Teco or VIM if you wanted to write the macro, 
sure.  I'll agree writing something like that in anything but Word (a la VBA 
or .NET) or elisp would be rather a PITA, since the macro languages of the 
others aren't what you'd call modular or easy to read. :-)

And emacs is pretty insular in its scripting language. You can't really talk 
to anything else from emacs' scripting language like you can with COM or 
REXX. You can't, for example, actually take that HTML you generated and 
display it formatted inline using an actual web browser, or take the 
formulas you used in the columns and store them in the table like with a 
spreadsheet. So there's strengths but also drawbacks of having a text-only 
format as well. The whole point of COM is to give you programmatic scripting 
access to the proprietary file formats.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 8/4/2011 12:26, Orchid XP v8 wrote:
> Now, aside from that matter, the thing which really puzzles me is this: If
> something *does* support COM, how the hell do you *use* it?

By the way, that was the link for implementing COM in your own code if you 
don't already have a COM interface built into your language. COM is 
basically a way of invoking object-oriented actions to a server (where 
"server" means your own or some other address space).

If you already have a library, you invoke it from your scripting language by 
using whatever function the scripting language has for creating an object 
from a COM server, then you just call it like it was a local object.

In Tcl, for example, you can do this
http://www.vex.net/~cthuang/tcom/chart.html
to start a copy of Excel and then create a spreadsheet and chart the values 
in it.

Or you can do this:
http://www.vex.net/~cthuang/tcom/server.html
to create a "server" side, which is to say, a program that can create COM 
objects for others to use.

VB6 had all this stuff built in, so you'd just say "hey, this is a com 
object" and you could instantiate it and call it and everything. That's what 
made VB6 so popular: if you wanted to do something funky with an excel 
spreadsheet, you could write a COM object in VB6 and call it from the Excel 
spreadsheet in a macro and have that COM object talk to other COM objects 
like web servers and so on.

Most of the languages that support COM just say "here's how you create a COM 
object, here's how you create the server side, go for it." And you mostly 
don't have to worry about how it works inside until something breaks. In a 
language that supports COM already, it's not noticeably harder than writing 
or invoking DLLs.

You may think it's difficult because you're trying to use it from Haskell, 
and COM is OO.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 04/08/2011 10:21 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> Actually, I notice the same artifact here as I did with "fill mode". In
>> that mode, whenever you finish typing something, Emacs wraps it at 70
>> characters for you. Which is nice and all, but you know what? As I'm
>> typing this post right now, Thunderbird is going the same thing
>> /interactively/. It doesn't wait until I've stopped typing and than
>> rearrange all my text. It arranges it as I type, so I can immediately
>> see what the result will be like.
>
>    I hate text editors that do some kind of automatic line splitting without
> asking (especially if you can't turn the feature off).

I have my text editor to do automatic line wrapping. Note that it only 
wraps the *display*, however. The actual file on disk is unchanged.

> I like emacs because
> it doesn't change anything in the file you open unless you explicitly ask
> it to. You can open a *binary* file in emacs, save it, and it will be
> identical to the original. The same cannot be said from most other text
> editors (especially in Windows) which do tons of "smart" things automatically
> (such as convert newline characters, unprintable characters, etc.)

My text editor allows you to *display* the line ends, so you can 
visually see which lines end with LF, which ones are CR, and also 
arbitrary combinations thereof. It can also display other non-printing 
characters if you wish (which is sometimes useful).

>    In fact, thanks to this property, you can use emacs as a hex editor.
> It has a built-in hex-editing mode. (Yes, some other text editors have
> that too. Not many, though.)

Now that might actually be useful. I've yet to find any hex editors.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Like I say, after hacking away at it for years, they've got it to
>> sort-of work, most of the time. That's not the same as TeX *actually*
>> supporting these things.
>
> of course not, that is not how it works. You use packages if you want to
> do something other than basic typesetting.

If TeX had been /designed/ to support such things, they would work far 
more reliably. (And you would probably be able to do things like /query/ 
what the current colour is, set a new colour relative to the old one, etc.)

>> Yes. They're kludged in the same way as colour and graphics.
>
> Kludged?
> People spend a lot of time creating packages for you to use without you
> having to understand the details.

They worked around the limitations as best as they could. They did quite 
well, considering. But it's still not the same as having real support 
for something.

>> ...something...? Perhaps it is not only me that fails English. ;-)
>
> sorry was distracted and didn't notice I didn't finish the sentence.

Ditto. ;-)

>> Well, that's what it *is*. It's a program that converts your markup into
>> something that looks nice.
>
> nope. It is a programming environment that happens to create documents
> as a side effect. ;)

If by "programming environment" you mean "text macro processor" then 
yes. Technically, PostScript is a Turing-complete programming language 
which optionally creates printed pages too. ;-)

>> I merely wanted to create a new tabbing environment where all the text
>> comes out green, set one quad in from both margins. (Apparently there's
>> no way to prevent it flowing off the right edge of the page though...)
>>
>> First I found that only the /first/ line came out green. So then I added
>> a group around the body. That worked fine... until the environment went
>> over a page break, at which point it broke again. Not to mention that by
>> flipping from page to page, I actually managed to break the DVI viewer
>> as well. (At one point the entire document turned green, just by me
>> manipulating the view...)
>
> So is TeX to blame or your DVI viewer?

The problem is that the DVI format (which TeX invented) doesn't really 
support colour, and neither does TeX itself. They managed to hack 
support for it into TeX and the DVI format, but it's not very reliable.

In a sense, DVI is just the preview. The final document is almost always 
PDF. But even the PDF version had colouring gone wrong. Like, if the 
environment broke over a page, the page number at the bottom turned 
green, and the running heading on the text page, but then all the rest 
of the text was black. Short of embedding a colour mark at the beginning 
of every line, I'm not sure how to fix that...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 05/08/2011 12:39 AM, Darren New wrote:

> By the way, that was the link for implementing COM in your own code if
> you don't already have a COM interface built into your language. COM is
> basically a way of invoking object-oriented actions to a server (where
> "server" means your own or some other address space).
>
> If you already have a library, you invoke it from your scripting
> language by using whatever function the scripting language has for
> creating an object from a COM server, then you just call it like it was
> a local object.

I wasn't even asking "how do I write a program that invokes this COM 
thing?". I was asking, more basically, "how do you do useful stuff with 
COM?" As best as I can tell, COM lets you create "objects" and invoke 
"methods" on them... that's as far as I was able to figure out.

> In Tcl, for example, you can do this
> http://www.vex.net/~cthuang/tcom/chart.html
> to start a copy of Excel and then create a spreadsheet and chart the
> values in it.

I'm fairly sure I tried that [or similar] in Tcl and it didn't work.

> VB6 had all this stuff built in

Yeah, I figured.

I also figured that the only reason that you can (say) embed an Excel 
spreadsheet in a Word document is because both products are produced by 
the same company. The "normal" software that you and I write can't do 
such sophisticated things. As far as I can tell, anyway.

> In a language that supports COM already, it's not noticeably
> harder than writing or invoking DLLs.

I've yet to see a language that can invoke DLLs either...

> You may think it's difficult because you're trying to use it from
> Haskell, and COM is OO.

I'd be perfectly happy doing COM from, say, JavaScript. It's not that 
Haskell is the problem, it's that I can't see *anything* that speaks COM.

I get the feeling that the only way to solve this is to use some 
horrifically awful language like VB...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 04/08/2011 11:01 PM, Darren New wrote:
> On 8/4/2011 13:01, Orchid XP v8 wrote:
>> Anyway, point being, you can apply DbC to anything. It doesn't have to
>> be OO.
>
> Hmmmm. Not really. I can't imagine how you'd apply it to old-school
> BASIC. Or C in any reasonable sense. (What would an invariant look like
> in C?)
>
> Preconditions and postconditions apply to routines that have state.
> Invariants apply to routines that have state outside of the individual
> routines *and* which have instances. So none of those really apply to
> purely procedural or functional languages.
>
> Exception management in the DbC way doesn't really apply to functional
> code.

DbC is a technique. In Eiffel it's supported in the language, in 
anything else it's a design pattern.

You can do functional programming in BASIC. It's God-damned hard, mind 
you, but it's possible. People were doing structured programming in 
BASIC way before they invented languages that properly support that out 
of the box.

A precondition is a Bool expression which must be true when a code block 
is entered. If it isn't true, the code block is allowed to malfunction 
arbitrarily badly. But if it /is/ true, then when the code block exits, 
the postcondition is required to be true.

I don't see anything in the above that requires the code blocks to be 
class methods, or even to be proper named constructs. If you were 
operating in BASIC, it might just be "when line 1580 is reached, X must 
contain a positive integer", and then "when line 1615 is reached, X must 
contain a new positive integer larger than the one that was there before".

An invariant looks like it should apply to any data structure of a given 
type (e.g., every tree node must contain a value lower than the one in 
its parent node), or perhaps to a given set of global variables (the 
nextID variable must always be positive and nonzero). Again, I don't see 
any especial reason why it has to apply only in an OO setting.

> It's a sad commentary when the normal state of software is "hey, I
> installed it, and it worked before I made any other changes!"

Indeed.

>> I don't get what's "sucky" about Metafont. (Other than that nobody uses
>> bitmap fonts anymore unless they really have to...)
>
> The spacing sucks. The weight sucks. I'd have to show you two identical
> pieces of text, one set with metafont, one set on a real typesetter, for
> you to easily see the difference.

Let me put it this way: It looks a crapload better than Word, Excel, 
PowerPoint, OpenOffice, or the HTML rendering of any browser I've tried.

Whether it looks better than a £20,000 piece of professional publishing 
software, I couldn't say. But given that I'm never going to own £20,000, 
it's kind of irrelevant.

> But it's quite as much there as the
> jaggies on a 300DPI print-out compared to a 1200DPI print-out.

Then why don't you just, um, increase the resolution? That's the entire 
/point/ of Metafont, after all. Its fonts are completely scaleable.

>> With Unix, you can decide to use a completely different filesystem
>> that you
>> just made up, you can change the thread scheduling algorithm, and then
>> you
>> can change the implementation of the ARP cache from a hashtable to a
>> linked
>> list. None of which is possible with Windows.
>
> That's not UNIX. That's Linux, and it's because you have the source
> code, not because it's UNIX.

Has there ever /been/ a Unix that isn't distributed in source form?

> And yes, Windows you can use a completely
> different file system you just made up. And you can probably change the
> other stuff too - it just costs more. And given that TCP/IP is an
> optional driver, I'd be very surprised to find you couldn't load your
> own version of that too if you wanted.
>
> Kernel scheduling? Not so much, agreed.

In reality, I'm not actually going to change such things, on either 
system. It would be far too hard. But in principle, it's possible with 
Linux. (And probably OpenBSD and a few others.) It's not possible with 
Windows. At least, not without paying real money.

> But that sort of stuff isn't what I think of when I think of a
> "flexible" OS. I think of being able to do things flexibly, not the
> ability to change the source code because I happen to have the source
> code. I think of the ability to do things I couldn't do otherwise if the
> OS didn't have support or hooks for it.

OK, fair enough.

Of course, "Windows" is a single monolithic piece of software, whereas 
"Linux" (the OS) is a vast array of independently replaceable bits. The 
latter is far more flexible, and also a damn site more messy.

> I've seen plenty of Linux crashes. You just didn't run it on flakey
> hardware like you did your XP, for example. (Or you just had a corrupted
> copy on your HD.) Do you really think everyone who bought that laptop
> had it crash within 15 seconds of turning it on the first time?

 From what I've heard... yes.

Do you not remember when XP first came out? Everybody *hated* it because 
it was so buggy and unstable. People paid good money to downgrade their 
PCs to something more reliable. Fortunately, most of those problems seem 
to be fixed now.

>> And Ctrl+B ("beginning") is already "back". And Ctrl+F ("first") is
>> already "forward"...
>
> That's exctly the problem with mnemonics.

Still, the shortcuts in FractInt aren't exactly logical either. (Press G 
to invoke the colouring algorithm options??) After a while, common 
combinations of commands become second nature. And I guess the thing 
about FractInt is that the currently available commands are permanently 
visible, all the same. If you see a command on-screen, you can use it by 
pressing that key.

I doubt Emacs could do it even if it wanted to. There are too many 
commands available.

>> Well, yeah, I don't tend to open up a text editor and then press
>> random key
>> combinations to see if it activates a special feature I didn't know
>> about.
>
> Control right-arrow is a "random key combination"?

Well, yeah. Not as random as, say, Shift+Alt+- (I'm looking at you, 
Emacs). But it's not the sort of thing you'd try just on the off-chance 
that maybe it does something.

> You know that holding shift while you move the cursor selects things
> too, right?

Not only do I know that, I meantioned it in my original post. :-P

>> Can you give one single example of where you'd want to do this rather
>> than, say, just jab the arrow key a few times?
>
> Where I would want to search in a text file to find a word?

Where you'd want a special key to move to the next word on the line. But 
sure, if you wanna do search instead...

> You're kidding me, right?

It's not that searching is pointless. It's just not something that's 
useful especially often.

> I have the output from compiling a bunch of programs. The file is 4000
> lines long. What was the command line used to compile firefox_scrollbar.c?

The output is 4000 lines line? In what universe...?? O_O

That's just scary.

> Heck, I have all the names and addresses in a text file. I want to look
> up my brother's fax number.

See, I would probably use a real database for that.

> I have a program that's several screens long. I want to find everywhere
> the function LookForMe is used.

Yeah. That's basically the only time I use search.

>> Wait, your own code can crash Emacs?
>
> No, but it can hang emacs for long enough that you think it's crashed.
>
>> Generally you don't expect, say, Firefox to die just because you feed it
>> some bad JavaScript.
>
> It doesn't, nor does emacs. That's why ctrl-G works, you see. Why do you
> think "interrupting my code where I accidentally wrote an infinite loop"
> is equivalent to "crashing emacs"? It's not crashed exactly *because*
> you can interrupt it.

It's just that the section heading says "if Emacs crashes..."

So I guess it's just badly worded then.

>> A typical editor session generally involves lots of typing, maybe a
>> bit of
>> scrolling, and periodically saving. So you'd expect the commands for
>> editing
>> and scrolling to be quick, as well as the command for saving.
>
> You don't write a lot of code, do you? :-)

What the heck do you think I use a text editor for? Writing code is just 
about *all* I do!

>> These are all pretty rare, really.
>
> I think it depends on what you do with an editor. :-) They're all pretty
> common for me.

What, are you writing C or something?

>> And break compatibility with all the extensive library of code written
>> for Emacs! :-D
>
> The code for emacs doesn't get invoked thru the keyboard mappings, any
> more than the code for COM does.

And you add some package that makes Alt+R do the same thing as Ctrl+R 
but slightly differently. Oh, I'm sorry, you changed Ctrl+R to be 
Ctrl+Z? Oh, well, nevermind... ;-)

>> Fun thing: Open Firefox. Press F3. Start typing. It highlights the first
>> match it finds, as you type. By pressing Next and Prev, you can make it
>> select other matches. But it does /not/ highlight *all* of them at
>> once. I haven't seen anything except Emacs do that.
>
> vim and visual studio both do. I don't use much else besides those three.

I use neither of those. (Or rather, I've used VS. In the time I was 
using it, I didn't need search. Especially since you can just click the 
tree view to find whatever function you want.)

>> Last time I invoked Vi, I had to reboot the PC to get out of it again.
>
> If the last time you ran vi was before windows had close boxes on them,
> I can understand why you might be nervous.
>
> Did you try reading a tutorial first?

No, the last time I ran Vi was on an early version of RedHat. Apparently 
Vi was the only text editor installed, and I was desperately trying to 
find something to edit the X configuration file so that I could make it 
start up. (I think I even managed to make it work eventually. After 
having looked up the scan frequencies of my monitor, type of RAMDAC in 
my video card, and other misc data...)

>> Being able to invoke all your tools from within your editor and edit
>> their output is again quite a powerful idea.
>
> vi had that too, except it was *all* your tools, with no need to write
> macros to handle it.

I should have forceen a Holy War. ;-)

>> Visual Studio is an IDE. It works for (say) C++. But if I decided I
>> wanted it to work for Haskell... tough. Cannot be done.
>
> http://research.microsoft.com/apps/pubs/default.aspx?id=67496

Ah yes, the old bitrotted VS plugin...

> Guess how the IDE interacts with it? COM!

Probably.

>> Not unless you hire a vast
>> army of C++ programmers to write the necessary hooks and DLLs and God
>> only knows what else to add the support to VS.
>
> Uh, one Bulgarian intern, on the weekends.

Did I mention the part about how it never really worked to everyone's 
satisfaction and was eventually abandoned?

>> My current editor is SciTE. It supports many, many file formats. But
>> Haskell
>> is not one. I would have to compile it from source to add Haskell syntax
>> highlighting (since none of the existing lexers are remotely similar,
>> so I
>> would have to add a new one).
>
> Or you could use vim and haskell mode and see if it works.

As I say, I know several people have build solutions for Emacs and Vim. 
My point was that this is an advantage for these editors; to do the same 
with my current editor, I'd have to recompile it.

>> I think there is probably still a place in the world for some kind of
>> engine
>> which is so configurable that you can build a complete development
>> environment with it, for any conceivable target, without having to do
>> really
>> heavy stuff like writing low-level C code or compiling huge codebases
>> from
>> scratch.
>
> That's exactly why Microsoft invented COM, IBM invented REXX, standards
> bodies invented COBRA, etc etc etc.

Accessing COM is nowhere near as easy as throwing together a few lines 
of elisp. (As far as I can tell.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> My text editor allows you to *display* the line ends, so you can 
> visually see which lines end with LF, which ones are CR, and also 
> arbitrary combinations thereof. It can also display other non-printing 
> characters if you wish (which is sometimes useful).

  I have emacs set so that it shows whitespaces at the end of lines with
blue background. It looks a bit annoying, completely on purpose. One
quickly develops a style of writing code such that you never end up with
empty spaces at the end of lines.

  When you open other people's code with emacs set up like that, in
approximately 90% of cases there will be tons of extra whitespace at
the end of lines.

  (Of course if you need to edit such code, emacs makes it easy to strip
those whitespaces with one smart search-and-replace.)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> (What would an invariant look like in C?)

  I suppose the closest thing is "assert(a < b);"

-- 
                                                          - Warp

Post a reply to this message