Georg Baum wrote:
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Georg" == Georg Baum
<[EMAIL PROTECTED]>
writes:
Georg> I is a new bug and a regression WRT 1.4: Now unknown arguments
Georg> are simply ignored. That should not happen, because that would
Georg> mean that I can make a typo and don't recognize it. The order
Georg> of command line evaluation should be the same as in 1.4:
Georg> - Let the frontend parse and remove all arguments that it knows
Georg> - Parse and remove all known arguments in the LyX singleton -
Georg> Give an error for all remaining ones.
Actually this is still wrong. The order in 1.4 is:
- Parse all known LyX arguments in the LyX singleton and store them
- Let the frontend parse and remove all arguments that it knows
- Complain for all remaining arguments that are not filenames in the LyX
singleton
The difference to the procedure above is that it is possible to override
frontend options in LyX.
I know, and this is mostly done this way already.
This is why I wrote that I was afraid of fixing it. The GuiApplication
object should be instantiated first, but only started if needed.
In particular, if the toolkit has arguments like "-c 3", the "3" will
be read as a file name...
But not if the toolkit eats all known arguments first. Or do I miss
something?
No, that's correct.
Which is bad. Would you accept a change WRT the argument interface?
No. I start LyX (and other programs) with filenames many times a day, and
always adding -f for LyX would be inconsistent and too much work.
Not always, the -f option would be implicit if the filenames are given
first. For example these 4 command lines would be OK:
lyx UserGuide.lyx Intro.lyx -c 3 -dbg key
lyx UserGuide.lyx -c 3 -dbg key -f Intro.lyx
lyx -c 3 -dbg key -f UserGuide.lyx Intro.lyx
lyx UserGuide.lyx -c 3 -dbg key -f UserGuide.lyx -f Intro.lyx
But this one (which we allow presently) would not be OK:
lyx -c 3 -dbg key UserGuide.lyx Intro.lyx
This last syntax IMHO this is bug prone and contains an inherent ambiguity.
Abdel.
