On 26/10/15 11:00, Mark Waddingham wrote:
On 2015-10-24 22:47, Mark Wieder wrote:
On 10/24/2015 12:21 PM, Peter TB Brett wrote:
* hilite -> highlight
Actually I filed a bug report on that six years ago.
http://quality.runrev.com/show_bug.cgi?id=8211
It got confirmed and ignored.
I just submitted a pull request.
Figured I might as well fix this myself.
There's a slippery slope here (in terms of the current engine parsing
implementation at least) which means that just adding synonyms because
the lack of them 'annoy' a small set of people (and/or because you
can) really isn't something which makes sense.
It is clear that originally 'hilite' was the chosen spelling for that
operation - it is an 'informal' spelling of 'highlight' which has been
historically used in GUI frameworks (probably because it is a good
deal shorter than 'highlight' - something which those who are fond of
'grp', 'fld', 'ac, 'cd' etc. should feel at home with ;))
There was obviously clearly some contention over whether 'dehilite' or
'unhilite' should be the antonym - given that even 'dehighlight' nor
'unhighlight' tend to appear in dictionaries this is probably not
surprising.
So, clearly someone 'complained' at some point (which is probably why
dehilite and unhilite both exist) and 'highlight' was added. Indeed,
there are actually the following fundamental synonyms for 'hilite' in
the engine:
- highlight
- highlighted
- highlite
- highlited
- hilite
- hilited
So that is 6 ways to write exactly the same thing. (It gets better in
a moment)
We now have the following 'compound' property names involving 'hilite':
- hiliteborder
- hilitecolor
- hilitefill
- hiliteicon
- hilitepattern
- hilitepixel
We also have the following 'compound' property names involving 'hilited':
- hilitedbutton
- hilitedbuttonid
- hilitedbuttonname
- hilitedicon
- hilitedline
- hilitedtext
There are also the following 'other' properties:
- autohilight
- autohilite
- linkhilitecolor
- multiplehilites
- noncontiguoushilites
- sharedhilite
- showhilite
- threedhilite
- togglehilites
So, there are (in fact) the following variations on 'hilite' currently
in use in the engine:
- hilite
- highlite
- hilight
- highlight
Which, if accounted for in synonyms would mean we would end up with (I
believe) 72 keywords if we ignore the 'ed' forms, and 144 if we have
both the preset and past participles. Also, it means that every time
anyone wants to add a property containing 'hilite', they need to add 4
(maybe 8) variants. This kind of 'blow-up' suggests that there is
something wrong with the approach.
So, I do think that in this case it would be far better to *choose*
what variant spelling is the normative one and deprecate all the other
synonyms at least until there is a much better mechanism in place for
parsing and resolving synonyms (i.e. when compound properties are
specified as separate words, and synonyms are substitutions done as a
pre-processing step).
For anything like there has to a policy and my policy has always been
- you choose a single representative for a single concept and you
stick to it. In this case 'hilite' is a perfectly valid word to use
(given its domain - i.e. GUIs); indeed, it is just as valid a choice
for 'highlight' as 'color' is for 'colour' and 'behavior' is for
'behaviour'. At the end of the day this is a computer language and as
such logical and sensible choices have to be made. (One could also
argue that the problem of synonyms and abbreviations is far better
handled in the script-editing environment... Although nobody ever
seems to agree with me on that one - even though the resulting effect
would be identical for all intents and purposes ;)).
Now, I'm not saying this won't change - clearly there is a want for
synonyms as a fair few people seem quite fond of them. However, there
needs to be a good mechanism in place to deal with them in the engine
and there currently is not (particularly when considering compound
forms) so caution is hugely advisable.
Warmest Regards,
Mark.
+1
As 'hilite' is the de facto standard, whether anyone likes or not, that
would seem to be the one to stick with.
I feel similarly about all those North Americanisms: speaking as someone
who was born in Scotland, spent all his school days
in England, and holds a Masters degree (in Linguistics) from a
University in the States, although instinctively my lip curls at
American spellings, I am well aware that:
1. That is nothing more than my cultural subjectivity.
2. American English IS the dominant form of English in the world right
now (and probably for the forseeable future).
So "bu**er" [not, that isn't 'butter'] the British spellings and stick
with the Americanisms . . .
And, quite frankly, if somebody really starts banging on about "British"
spellings [i.e. English English spellings] I shall get
awfy thrawn anent Scotticisms; qhilka dae nae fowk onie guid at aa!
What might be a GOOD IDEA is to work out all the synonyms for each term
in LiveCode [no, I will not, I am not THAT nerdy or a*al]
and list them against a term: so, for instance, if someone searches for
"colour" they will come to a section in the dictionary that
basically states 'for "colour" => "color" '.
Personally, while I am very proud to be a Scot (mainly because I live
and work in Bulgaria: go figure), that does not mean I am
anti American usage.
Polyglottism is all very well and fine, but it would bring the LiveCode
engine to its knees: and I, for one, am not prepared to wait
20 minutes for some script to execute, which currently takes 10 secs,
because the thing has to trawl through endless look-up
tables of variant spellings and words: a dish made with aubergines is
still a dish made with eggplants even if the chef calls
them brinjals, melongenes, guinea squash or whatever: so let's all call
then 'eggplants' (the American word) and be done with it.
Richmond.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
