FlightGear wiki talk:Instant-Refs: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(→‎Misc notes: we need an alternative output + removed outdated observations)
Line 115: Line 115:
=== support/ignore highlighted keywords/smilies ===
=== support/ignore highlighted keywords/smilies ===
see [[Understanding Forward Compatibility]] for examples
see [[Understanding Forward Compatibility]] for examples
: {{done}}. However, before resorting to simply using the alt text, I tried by matching on the image name, so I had a series of replace() and tested it [http://forum.flightgear.org/viewtopic.php?f=14&t=23020&p=209367&hilit=syntax+highlighting#p209367 here]. It worked, but if I selected a larger extent of text, again one of the regexes would go crazy and eat up half the message. That's clearly the same that's happening [[#recognizing wiki images|above]], I'd really love to understand what's happening there. I tried using a new variable instead of reassigning to the same, but it changed nothing (I expected that.)
: {{done}} --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)
: --[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 15:13, 17 June 2014 (UTC)
 
=== Chopped strings and stripped \n's: we need an alternative output ===
At first, the limitation of the alert dialog was only on the length of the text. Now radi reports that Firefox strips the newlines (as in \n) making the string hardly readable, and I can confirm this on Iceweasel (Debian's re-branded Firefox). It seems that the most flexible way out of this is a superimposed div. I made some experiments and a basic style for such a div, simply appended inside <body> is:
 
    position: fixed;
    width: 80%;
    height: 57%;
    z-index: 1000;
    margin: 10%;
    padding: 1%;
    background: white;
    border: solid black;
    word-wrap: break-word;
    overflow: auto;
 
However it seems that all of this could be handled easier through some library like jQuery. I think I don't even know how to include a library inside a JS script. To escape the html code to show it in the html body (like br's and others) a nice and easy solution is [http://stackoverflow.com/a/12034334 here].

Revision as of 13:30, 22 June 2014

more sources

at some point, we may also want to add support for other sources, such as:

that should cover all important sources. And it would allow us to also use the same script to help populate FlightGear Newsletter & changelogs, but also Release plan/Lessons learned. So this could be a real time-saver. --Hooray (talk) 14:40, 1 June 2014 (UTC)

Automatic update of script and old quotes

Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the downloadURL attribute[1] so that scripts can auto-update --Hooray (talk) 22:51, 11 June 2014 (UTC)

selection/clipboard buffer or alert() limits ?

There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --Hooray (talk) 14:11, 12 June 2014 (UTC)

I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a security issue.
--Bigstones (talk) 22:02, 13 June 2014 (UTC)
right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--Hooray (talk) 23:16, 13 June 2014 (UTC)

Issues

phpBB code snippets not displayed using syntaxhighlight

Cquote1.png What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:
<periodic>
     <min>-180</min>
     <max>180</max>
</periodic>

will transform a value of -190 to +170 for example. But that's probably not what you asked for.


Cquote2.png

recognizing wiki images

I just tested the script using one of my recent forum postings:

Cquote1.png
RevHardt wrote in http://wiki.flightgear.org/MapStructure ... map_dialog
(see the linked image)

You can basically create arbitrary layers, even for custom objects/positions:
(see the linked image)

The same method can be used for creating a "live" radar display:
http://wiki.flightgear.org/Canvas_Radar
(see the linked image)

But maps and layers can be fairly sophisticated, too - all 100% scripted:
http://wiki.flightgear.org/FlightGear_N ... Map_dialog
(see the linked image)

As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments

Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure
— Hooray (Sat Jun 14). Re: Get objects to show up on Map/Radar.
Cquote2.png

I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --Hooray (talk) 16:45, 14 June 2014 (UTC)

Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <cite>RevHardt... part.)
Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image pages (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.
One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.
(Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)
--Bigstones (talk) 17:37, 14 June 2014 (UTC)
I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work unless I include in the selection also the first link. That seems to break the regex.
--Bigstones (talk) 21:35, 14 June 2014 (UTC)
Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...
--Bigstones (talk) 21:51, 14 June 2014 (UTC)
Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --Hooray (talk) 21:58, 14 June 2014 (UTC)


Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just [[FOO]] would make more make sense than having something http://wiki.flightgear.org/FOO ? --Hooray (talk) 11:32, 15 June 2014 (UTC)
Done Done, however it looks fine only with single words (it's not converting the underscores to spaces).--Bigstones (talk) 20:02, 18 June 2014 (UTC)

too greedy non-greedy regexes

The problem described in the previous section regarding regexes that eat up half messages seems to be related to my misunderstanding of the non-greediness. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in this edit and that's clearly cumbersome, not to say that it can still be incorrect: say I have <a someprop="href" href="http://www.link.org" ... > If I want to mach anything between a and href, I use [^(?:href)]*, but that would match only up to the text inside someprop, so I'd have to check that it's not inside doublequotes... Well, I guess this is getting too complicated for handling it the Chtulu way.

So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground. Or, rewrite it all using only xpaths *sobs*. --Bigstones (talk) 16:49, 17 June 2014 (UTC)

regex vectors

When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--Hooray (talk) 16:46, 16 June 2014 (UTC)

Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --Hooray (talk) 16:46, 16 June 2014 (UTC)

Syntaxhighlighting

Need to investigate what needs to be updated to support quoting code sections, as per [2] --Hooray (talk) 22:33, 14 June 2014 (UTC)

Postings that break our script for some reason

Cquote1.png t should be possible to procedurally render charts like these using Canvas and some custom styling:

Airport_Diagram_Generator
File:423px-Adg-KSFO-0.png File:423px-Adg-KSFO-1.png

(the main advantage would be that these would be 100% in sync with actual FG nav data!)


— Hooray (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png

Misc notes

Detecting failed XPaths

you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed.

Paragraphs / br (trailing slash)

There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote

Done Done. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.
--Bigstones (talk) 14:03, 17 June 2014 (UTC)

support/ignore highlighted keywords/smilies

see Understanding Forward Compatibility for examples

Done Done --Bigstones (talk) 15:13, 17 June 2014 (UTC)

Chopped strings and stripped \n's: we need an alternative output

At first, the limitation of the alert dialog was only on the length of the text. Now radi reports that Firefox strips the newlines (as in \n) making the string hardly readable, and I can confirm this on Iceweasel (Debian's re-branded Firefox). It seems that the most flexible way out of this is a superimposed div. I made some experiments and a basic style for such a div, simply appended inside <body> is:

position: fixed; width: 80%; height: 57%; z-index: 1000; margin: 10%; padding: 1%; background: white; border: solid black; word-wrap: break-word; overflow: auto;

However it seems that all of this could be handled easier through some library like jQuery. I think I don't even know how to include a library inside a JS script. To escape the html code to show it in the html body (like br's and others) a nice and easy solution is here.