Changes between Initial Version and Version 8 of Ticket #36


Ignore:
Timestamp:
01/11/14 16:03:46 (12 years ago)
Author:
ossi
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #36

    • Property Status changed from new to closed
    • Property Severity changed from to no branch
    • Property Reporter changed from slavazanko to s68
    • Property Component changed from mcedit to mcview
    • Property Version changed from to 4.6.1
    • Property Branch state changed from to no branch
    • Property Milestone changed from to 4.7
    • Property Resolution changed from to invalid

  • Ticket #36 – Description

    initial v8  
    77||Release:||current (CVS or snapshot)||Operating System:||All|| 
    88 
    9 Discussion: 
     9Original submission: 
    1010{{{ 
    11 Fri 04 Aug 2006 11:55:16 AM UTC, comment #5: 
     11While trying to scroll to end of large file mc reads all of the  
     12file, that can continue up to couple of minutes. While viewing  
     13large but <2Gb file scrolling to end is momentally. Bug (?) appears  
     14in FreeBSD & MacOS X.  
     15}}} 
    1216 
    13 Maybe my conclusion was a bit hasty. It is indeed useful to be able  
    14 to scroll up from the end of the file. 
     17Comment 1 by Roland Illig <rillig> at Tue 14 Feb 2006 10:28:56 AM UTC: 
     18{{{ 
     19It's true that the viewer takes a long time to scroll at the end of  
     20a large file. 
    1521 
    16 Maybe the current logic should be extended with a "from end of  
    17 file" logic. Line cache should only be filled when a goto is  
    18 executed, and while the user is scrolling through the file (either  
    19 down from the top, or up from the bottom). 
     22Did I understand you correctly that scrolling to the end of a file  
     23< 2 GB is momentarily, but it takes long only for files > 2 GB? I  
     24would have expected it the other way round, so that files < 2 GB  
     25take a long time and files > 2 GB are quick (which might indicate a  
     26bug in the code). 
    2027 
    21 Reopening. 
    22         Leonard den Ottolander <leonardjo> 
    23 Project Member 
    24 Fri 04 Aug 2006 11:31:34 AM UTC, comment #4: 
     28There is currently no way to avoid the waiting. It is used for line  
     29number generation, and perhaps that calculation could be delayed a  
     30bit or be done in the background. This would complicate the code,  
     31as the current commands for "one line up", "one line down", and so  
     32depend on the line numbers to be there. But it is certainly  
     33possible. 
    2534 
     35Roland 
     36}}} 
     37 
     38Comment 2 by yaroslav <s68> at Tue 14 Feb 2006 02:20:14 PM UTC: 
     39{{{ 
     40> Did I understand you correctly that scrolling to the end of a  
     41file < 2 GB is momentarily, but it takes long only for files > 2 GB? 
     42 
     43Yes. 
     44 
     45> There is currently no way to avoid the waiting. It is used for  
     46line number generation, and perhaps that calculation could be  
     47delayed a bit or be done in the background. 
     48 
     49So sorrow :-/ But it is strange for me that time of calculation  
     50significantly increases just at point of 2Gb... 
     51}}} 
     52 
     53Comment 3 by Pawel Misiak <pavelsky> at Fri 24 Feb 2006 09:39:43 PM UTC: 
     54{{{ 
     55I have almost same problem, but my mc reads entire file whenever I  
     56press END key in every text file. Small files doesn't count, but eq  
     57120MB+ logs on a busy server matters. 
     58mc-4.6.1a-4.FC4 few instances on few machines, i386.rpms and  
     59recompiled from sources - no diffrence. 
     60}}} 
     61 
     62Comment 4 by Leonard den Ottolander <leonardjo> at Fri 04 Aug 2006 11:31:34 AM UTC: 
     63{{{ 
    2664Try F5 to a line around the end of the file. This might be faster  
    2765in the old viewer. Now goto a line at the beginning of the file.  
    … …  
    4179 
    4280Closing "not a bug". 
    43         Leonard den Ottolander <leonardjo> 
    44 Project Member 
    45 Fri 24 Feb 2006 09:39:43 PM UTC, comment #3: 
     81}}} 
    4682 
    47 I have almost same problem, but my mc reads entire file whenever I  
    48 press END key in every text file. Small files doesn't count, but eq  
    49 120MB+ logs on a busy server matters. 
    50 mc-4.6.1a-4.FC4 few instances on few machines, i386.rpms and  
    51 recompiled from sources - no diffrence. 
    52         Pawel Misiak <pavelsky> 
    53 Tue 14 Feb 2006 02:20:14 PM UTC, comment #2: 
     83Comment 5 by Leonard den Ottolander <leonardjo> at Fri 04 Aug 2006 11:55:16 AM UTC: 
     84{{{ 
     85Maybe my conclusion was a bit hasty. It is indeed useful to be able  
     86to scroll up from the end of the file. 
    5487 
    55 > Did I understand you correctly that scrolling to the end of a  
    56 file < 2 GB is momentarily, but it takes long only for files > 2 GB? 
     88Maybe the current logic should be extended with a "from end of  
     89file" logic. Line cache should only be filled when a goto is  
     90executed, and while the user is scrolling through the file (either  
     91down from the top, or up from the bottom). 
    5792 
    58 Yes. 
    59  
    60 > There is currently no way to avoid the waiting. It is used for  
    61 line number generation, and perhaps that calculation could be  
    62 delayed a bit or be done in the background. 
    63  
    64 So sorrow :-/ But it is strange for me that time of calculation  
    65 significantly increases just at point of 2Gb... 
    66         yaroslav <s68> 
    67 Tue 14 Feb 2006 10:28:56 AM UTC, comment #1: 
    68  
    69 It's true that the viewer takes a long time to scroll at the end of  
    70 a large file. 
    71  
    72 Did I understand you correctly that scrolling to the end of a file  
    73 < 2 GB is momentarily, but it takes long only for files > 2 GB? I  
    74 would have expected it the other way round, so that files < 2 GB  
    75 take a long time and files > 2 GB are quick (which might indicate a  
    76 bug in the code). 
    77  
    78 There is currently no way to avoid the waiting. It is used for line  
    79 number generation, and perhaps that calculation could be delayed a  
    80 bit or be done in the background. This would complicate the code,  
    81 as the current commands for "one line up", "one line down", and so  
    82 depend on the line numbers to be there. But it is certainly  
    83 possible. 
    84  
    85 Roland 
    86         Roland Illig <rillig> 
    87 Project MemberIn charge of this item. 
    88 Tue 14 Feb 2006 09:07:15 AM UTC, original submission: 
    89  
    90 While trying to scroll to end of large file mc reads all of the  
    91 file, that can continue up to couple of minutes. While viewing  
    92 large but <2Gb file scrolling to end is momentally. Bug (?) appears  
    93 in FreeBSD & MacOS X.  
     93Reopening. 
    9494}}}