>>>The script should not be re-run if we don't preserve it.  Pressing F8 
>>>essentially restarts the viewer.  Possible solutions:
>>>
>>>1) Get rid of the scripts, use system() or something like that.  The
>>>reason to use scripts was to enforce Bourne shell syntax (see comment in
>>>ext.c).  But I think that all advanced scripting should be kept out of 
>>>mc.ext.
>>>
>>>2) Preserve scripts until the viewer exits.
>>
>>This is old behaviour.  Require roll back some changes from CVS.
> 
> 
> Right, the self-removing scripts were introduced for gmc, that would
> fork() an process and never erase the script itself.
> 
> If we decide that we never run anything asynchronously on F3, we can clean
> scripts for the viewer when the viewer is done.  But I'm almost sure that
> somebody will want to run an viewer for X on F3 and expect mc to be ready
> for the next command before the viewer finishes.
> 
> Anyway, it's a good short-term solution for the viewer.
> 
> The long-term solution would be to eliminate the need in the temporary
> scripts whenever possible, and or implement garbage collection for the
> rest.  External viewers should be given some time to load local copies of
> the remote files (possibly the VFS timestamping can be reused).


It will be fine to keep these scripts in memory and execute this as
'sh -c' command or give these ones as sh stdin.
These scripts are rather short usually.

>>>Maybe we could set SUBDIRS in doc/Makefile.am to @LINGUAS@ ?  By the way, 
>>>configure.in should be using LINGUAS, not ALL_LINGUAS.
>>
>>I agree with LINGUAS change, and does not require many changes.
>>Unfortunatelly automake fails if any of directories from SUBDIRS does 
>>not exist.  And automake know nothing about GNU make functions.
> 
> 
> But they do exist in the sources!  I understand you want to control which 
> of them to install, right?
> 


There are 33 entries in the LINGUAS and only 5 translated manuals in the 
doc.




_______________________________________________
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Reply via email to