• Andrew Hodgkinson's avatar
    Got the deferred reformatter working properly. It doesn't do that 'OK, the... · 5e7b0a62
    Andrew Hodgkinson authored
    Got the deferred reformatter working properly. It doesn't do that 'OK, the page is fetched and reformatted, but just to annoy you, I'm going to wait 5 seconds and then suddenly reformat the whole thing again' trick anymore. The fetcher was calling the reformatter in a delayed form even when the reformatter was already running, so it would carry on past the reformat point or from below what had become and invalidated line, and some time later, get back to the delayed reformat. Now, reformatting is only delayed by the fetcher when the reformatter is not running. In practice this means body text reformats as it fetches, but large tables will show delayed reformatting - which was exactly the intended behaviour of the feature when it was originally thought of.
    
    fetch_token_data_address removed; it was only needed in two places,
    both of which already knew when to read tp->text and when to ignore
    it. Its functionality is duplicated in an 'if' involving reformat_istext,
    anyway.
    
    !Run[D] files taken back to requiring HTTP 0.33, since 0.36 introduces
    many weird and wonderful problems.
    
    Typo in Messages files, 'All current images (sic.) fetches finished' -
    'images' is now 'image'.
    
    Shift+Click saving - you could save to an application. No problem. But
    the equivalent (just clicking on a link that led to an unknown datatype
    and getting the save dialogue that way) didn't work. It does now.
    Another problem was saving to an application that didn't support the
    datatype - oops, the dialogue would close but the fetch would sit there
    waiting to be told where to save. It doesn't close now (as expected).
    
    NB, doing several simultaneous fetches to a text editor may have problems
    as the editors are too clever for their own good. Despite receiving
    DataLoad messages for <Wimp$Scrap> for files of different types, sizes
    and datestamps, the editors can decide it's still the same file and:
    
    Zap      - Hats off, it gets it right, almost. You do get warned 'Multiple
               copies - one on disc is newer' as everything after the first
               text loads, but they do load, and in separate windows.
    StrongED - Does not load the subsequent files, so the browser gives 'Data
               transfer failed' errors and opens up Scrap. Turning off 'Don't
               load same file twice' fixes it - each file is loaded in a new
               window with no warnings. At least in the first case, you don't
               lose data, since the files are kept in Scrap.
    Edit     - Each time it loads the file, it *replaces* the other one in
               memory, using the same window for each. This is the worst
               behaviour as it isn't configurable (well, I don't know of a way
               to change it...) and results in data loss as successive texts
               get trounced by the new data.
    
    I can't see how I can fix this in the browser as it's basically silly
    behaviour on behalf of the editors. Other applications which don't try
    to work out if it's a new file or not are fine!
    
    When conducting image fetches, proxying is allowed unless reloading.
    When conducting page fetches, proxying was never allowed - so web cache
    stuff would have been, er, interesting. It now sets X-NoProxy: in the
    request header when reloading, but otherwise this is not included.
    
    AnimSpeed is, at last, independent of browser poll speed. They used to
    be tied together. Guess how the animation code used to work ;-)
    
    'Can't handle this datatype' - deprecated now that save dialogues can be
    popped up. The 'can't save objects in full screen mode' error would never
    be shown due to a bug, anyway; this now replaces 'can't handle', which
    has been removed from all Messages files.
    
    RefoWait, RefoHang and RefoTime moved from Controls back to Choices.
    
    Trying to get rid of strlen in the reformatter - it can get very slow
    (e.g. strlen of 8K chunks of text, or if a 330K text file is transferred
    from a text editor straight to the browser, strlen of a 330K string...).
    There will be unfinished bits of code in the reformatter that may seem
    unnecessary - they've just not been plugged in yet (since they don't
    actually work). Don't remove them!
    5e7b0a62
!RunD,feb 3.5 KB