> Please try to convince Jean-Marc to use configure.py instead, We don't > have the reasources to do this double work.
Hmm, JMarc? We have been using configure .py for a while and it working all right. We indeed do not have time to port whatever change to configure.py to configure.m4. > > +bool autoViewFile(std::string const & filename, std::string const & > mode="open"); You are right. > This function is misnamed: a "View" method should not "edit". The mode > argument is also misnamed. Please use something like > > bool autoViewFile(std::string const & filename); > bool autoEditFile(std::string const & filename); Two separate implementation? Macro? autoEditFile calls autoViewFile? > enum openFileMode { > view, > edit > }; > bool openFile(std::string const & filename, openFileMode mode = view); openFile has been used in too many places, so I used view. Maybe shellOpenFile or shellExecuteFile? > > +def autoFormatEntries(): > > This is error prone. When I want to add a new format I have to touch two > different places. Please hold back the configure.py change. I have an > almost finished different solution that does not need it. > > The rest is fine with me. Not a problem. Just remember that this autoFormatEntries may be used for mac or kde as well. No immediate plan though. > What it's saying is tht autoViewFile is called if !format or if > format->viewer() is empty. That's wrong. (The remaining test > is correct of course.) > I think that the code should be something like. > bool able_to_view = (format && !format->viewer().empty()); > if (able_to_view && format_viewer() == "auto") { > able_to_view = autoViewFile(filename, "open"); > } When lyx somehow knows nothing about a file (no format, no viewer), I just let users to decide since he requested to view a file. This action may remind a user to install a viewer program since a 'choose a program' dialog will be shown if windows does not know what to do either. Bo