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