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