Unfluffing the Dictionary

[tperry2x]

Yes, the PDF talks heavily about SGIrix (unix workstations).
In the 90s.

I think everybody has moved on to other formats (SVG etc).
If there was a dictionary entry that could be pruned, it's probably this one.
By the way, if you do ditch any, please put them in a folder - just so we know which ones.

It's a thankless (and soul destroying) task going through the dictionary.

[richmond62]

Re Ditching (and Hedging come to think of things):

I am "pushing things aside" rather than ditching them, as, ultimately I do not feel 100% qualified whether to actually ditch anything.

Anyway: what with various 'obstructions' today, I have only managed to look at 33 documents (out of 209) today, and now have to stop,

But, I'll do a Schwarznegger and be back just as soon as possible to plough through the rest.

Oh, and by the way: attempting ditching with a plough is all a bit daft.

Mind you, I would jalouse you could use a single coulter with a spavined nag.
-

trencher.jpg (7.76 KiB) Viewed 545 times

[tperry2x]

This all had me wondering, since it was supposed to be a 90s thing...
I wonder when EPS support started to fall apart. It seems in Revolution 1.0 it was only semi-implemented.
The option was disabled:

rev-old.png (124.71 KiB) Viewed 541 times

BUT - with a bit of script editing, you can re-enable the menu again.
You can see the inspector ("Properties") kind of supports it, and this is where the 'currentpage' option comes from I'm sure.
However, it's non functional.

half-supported.png (334.81 KiB) Viewed 541 times

[richmond62]

Scrubbable, methinks.

[richmond62]

I am attending a funeral today, so will probably onyl manage 120 minutes this evening.

But this month as I do not start work unti 2.30 every afternoon, but have to be at ym work from 10 am, I should break the camel's back with the 'Unix' files sometime this week.

I shall then put them back with the rest and use BBEdit to perform a group find for Macintosh, then MacOS, then MacOS X.

[richmond62]

However, it's non functional.

Because 'they' just took all the stuff from the MetaCard documentation and did NOT bother to edit it in anyway, and here, 23-24 years later these bits and bobs from running MetaCard on UNIX are still lying around being pains-in-the-bum, and tripping up unsuspecting newcomers.

When I look at those 24 years (I encountered MC almost exactly 24 years ago, and RunRev about 6 months later), what IS incredible is how, while, undoubtedly doing a lot of work to extend the language and so forth (erm: Unicode), they still left so much work undone: whether intentionally or not, the IDE is chock full of bugs, errors, and incorrect information, which could be called 'bad house-keeping'.

Over those last 20+ years I reiterated my criticism about going 'hell for leather for the latest thing' while not sorting out so many, many annoying glitches, to be slammed again and again by both the producers and the choirboys.

Of course that company can slide out of any moral obligations as in 2027 they say they are dropping the thing completely; to be replaced by a 'better' thing. I would not trust the claims as far as I could chuck them, as I expect the new thing to be developed in the same fairly slapdash way as what it is meant to replace.

[FourthWorld]

However, it's non functional.

Because 'they' just took all the stuff from the MetaCard documentation and did NOT bother to edit it in anyway, and here, 23-24 years later these bits and bobs from running MetaCard on UNIX are still lying around being pains-in-the-bum, and tripping up unsuspecting newcomers.

Disappointed UNIX users would require that there be any significant percentage of UNIX users in the 21st century - it seems we're safe there:

Screenshots_2024-12-01-09-09-06.png (235.07 KiB) Viewed 458 times

When it comes to documentation errors and, to a lesser degree, IDE bugs, those are two areas where the company's argument against the benefits of open source are supported by your complaint: while no one expected an audience of scripters to contribute many C++ pull requests, the IDE and docs were two areas where the community can, and did, contribute.

During those eight years, did you submit docs refinements removing references to UNIX? I didn't, and apparently no one else did either.

There were a great many revisions submitted by the community, and while I no longer have stats my recollection was that the ratio of contributing to non-contributing users, esp in the first several of those years, was on par or slightly better than with other open source projects of similar scope and complexity.

But apparently community contributions didn't catch everything.

So now the open source initiative continues onward with this fork.

We can spend our time lamenting what others didn't do for us many years ago, or roll up our sleeves in the here-and-now and have it done.

[richmond62]

Sorry people, funerals (especially the open-coffin type here in Bulgaria) have a bad effect on me, so, NO, went home and drank far too much wine.

ANYWAY: just encountered another reason why trudging through these documents individually rather than doing a simple Find-And-Replace is justified:

Darwin glossary.txt

Darwin
(glossary)

Syntax:
Synonyms:
darwin, darwin layer

Params:

Examples:
Description:
Operating system that is the underlying core of OS X, written by Apple Computer. Darwin is a variant of Unix.

It is possible to run Darwin by itself, without the Aqua user interface and other services that make up OS X. The Darwin version of the OpenXTalk engine supports only command line|command-line scripting.

Values:

OS:

I would have looked a 'right prawn' had 'Unix' there been changed to 'Linux'.

BUT:

The Darwin version of the OpenXTalk engine

Erm: is there a Darwin version of the OpenTalk engine?

(come to think of things; was there EVER a Darwin version of the LiveCode engine?)

[richmond62]

99% of this whole jingbang comes down to plain and simple sloppiness.

Consider that most of the documents that mention UNIX in text then finish off like this:

OS:
mac,windows,linux,ios,android

-

cheeseBrain.jpg (6.9 KiB) Viewed 290 times

-
If one of my employees was THAT slack they would be out of a job fairly quickly.

[richmond62]

dontUseQT property.txt

dontUseQTEffects property.txt

I really wonder how relevant these 2 are as QT (Quicktime) was dumped by Apple quite a few versions of their OS back.

Although (michty queer) I see that my MacOS 15.2 beta * has a QuickTimePlayer in the Apps folder.

[richmond62]

Yeah, yeah, yeah . . .

EPS object.txt

This object type is supported only on Unix systems with Display PostScript installed.

That's one for the rubbish bin.

[richmond62]

eventAltKey function.txt

I have inserted an extra line here after:

The eventAltKey and eventOptionKey function(glossary)|functions return the same value. Which one to use is a matter of preference. The terminology varies depending on platform. Users of different operating systems may know this key as the Option key (Mac OS systems), Meta key (Linux systems), or Alt key (Windows systems).

"This differentiation (Opt / Alt / Meta) is to a large extent now redundant as almost all contemporary USB keyboards have the key on the right of the left-hand Control key marked as 'Alt."
-

meatKey.jpg (9.72 KiB) Viewed 279 times

[tperry2x]

This differentiation (Opt / Alt / Meta) is to a large extent now redundant...

I agree with that bit

...almost all contemporary USB keyboards have the key on the right of the left-hand Control key marked as 'Alt.

All of my keyboards in the building, which is over 320 at rough count, have this layout.

hmm.png (50.92 KiB) Viewed 276 times

Where the alt/opt key is to the right of the left-hand Windows key.

[richmond62]

extendKey property.txt

Possibly on some ancient UNIX box.

But I am completely unaware of that with Linux.

Another one for the bin, possibly?

[richmond62]

Mac2002.jpg (12.92 KiB) Viewed 273 times

-
An embarrassingly dirty Apple keyboard from 2002 that is marked 'ALT' (mainly because the last time I saw 'Opt' was on an Apple ADB keyboard in about 1995).

[richmond62]

Files I am NOT altering, and NOT copying into my 'Linux' folder are getting the purple spot treatment:
-

SShot 2024-12-02 at 12.11.48.png (64.6 KiB) Viewed 273 times

[tperry2x]

An embarrassingly dirty Apple keyboard from 2002 that is marked 'ALT' (mainly because the last time I saw 'Opt' was on an Apple ADB keyboard in about 1995).

Yes, Apple did always put the ALT next to CTRL, whereas PC keyboards (at least in the UK) all have the ALT key to the right of the windows key (to the left of the spacebar)
They also move the @ and " keys around too from my point of view.

[tperry2x]

extendKey property.txt

Possibly on some ancient UNIX box.
But I am completely unaware of that with Linux.

Another one for the bin, possibly?

I use xModmap in XFCE (exam laptops) to also limit the use of the right-hand mouse button.
It's not an ancient OS-level thing, it's very much in use in any debian distro - it's also a handy way to remap keyboard inputs.

I hadn't much tried with the extendkeys and special characters in Linux, but I just tried this in OXT:

interesting.png (9.73 KiB) Viewed 268 times

hold CTRL then SHIFT then U (keep those held and type 1212 for example) to get this character.... which you'd know what it means, I don't have the foggiest.

[richmond62]

US English keyboards have the @ above the 2, and the " above the '.

GB English keyboards have them the other way round.

As I started using keyboards that were NOT connected to a VAX terminal in the US I prefer the US layout (buth, then, getting confused over which side of the road to drive on, I always drive down the middle, everywhere).

[richmond62]

Hex 1212 is Ethiopic 'HHI'.

I can see all the school children in Norfolk jumping for joy knowing they can produce Ethiopic glyphs with Linux.

So extendKey.text should stay.

Thanks for the help.