Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-16 Thread Peter Kümmel
Enrico Forestieri wrote:
 On Thu, Jul 15, 2010 at 04:31:26PM +0200, Stephan Witt wrote:
 Am 15.07.2010 um 15:53 schrieb Pavel Sanda:

 Stephan Witt wrote:
 I see in the constructor SystemcallPrivate::SystemcallPrivate 
 (SystemCall.cpp)
 the error output of the child process is collected only if it's going to 
 an terminal.
 I think it would be better to collect it unconditionally to show it in 
 the message window.
 What do others think?
 whats the point of collecting it if we are not going to show it?
 The point is that you can read it when looking for it in the message 
 window.
 That's currently not possible, the error messages are lost.

 Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
 startup.

 If I remove the os::is_terminal(os::STDERR) test the output becomes 
 visible.

 Another story is to show the errors in the alert popup. This can be 
 improved too.
 i'm not sure what are side effects of kicking out 
 os::is_terminal(os::STDERR) tests.
 when i shortly peeked to sources it seems to be little bit messy how we mix 
 variables
 which govern whether we ouput err messages on console and on window.
 the right thing might be to fix this than to remove the tests...
 Maybe. But I think to remove the check is a linear improvement and more I 
 cannot do for now.
 I don't say the next step shouldn't be done. But I cannot afford two steps 
 currently.
 Of course I can guard the change with an #ifdef ON_MAC but that's really 
 ugly.

 Perhaps Enrico and Peter - the authors - can have a look...
 
 I had a quick look. Removing os::is_terminal(os::STDERR) is not the
 right thing to do. I introduced that check for not outputting anything
 when a terminal is not connected. Then Peter coupled the output to a
 terminal with the output sent to the GUI, such that if no output should
 go to a terminal (because there is no terminal), no output is sent to
 the GUI, too, which seems wrong.
 
 IMO, the correct fix is changing all occurences of
 
 if (showerr_) {
   cerr  errdata_;
   ProgressInterface::instance()-appendError...
 }
 
 to
 
 if (showerr_)
   cerr  errdata_;
 ProgressInterface::instance()-appendError...
 
 and similarly for other cases. In this way, output meant to go to a
 terminal and output meant for the GUI gets decoupled. However, I only
 had a very quick look, so I could be missing something. I think it is
 better that Peter has a look.
 

This makes sens. When adding the output to the GUI I was irritated about the
showerr_ and showout_ flags and didn't understand they are only guards for
the terminal output. I've fixed it.

Peter




Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-16 Thread Stephan Witt
Am 16.07.2010 um 08:13 schrieb Peter Kümmel:

 Enrico Forestieri wrote:
 On Thu, Jul 15, 2010 at 04:31:26PM +0200, Stephan Witt wrote:
 Am 15.07.2010 um 15:53 schrieb Pavel Sanda:
 
 Stephan Witt wrote:
 I see in the constructor SystemcallPrivate::SystemcallPrivate 
 (SystemCall.cpp)
 the error output of the child process is collected only if it's going 
 to an terminal.
 I think it would be better to collect it unconditionally to show it in 
 the message window.
 What do others think?
 whats the point of collecting it if we are not going to show it?
 The point is that you can read it when looking for it in the message 
 window.
 That's currently not possible, the error messages are lost.
 
 Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
 startup.
 
 If I remove the os::is_terminal(os::STDERR) test the output becomes 
 visible.
 
 Another story is to show the errors in the alert popup. This can be 
 improved too.
 i'm not sure what are side effects of kicking out 
 os::is_terminal(os::STDERR) tests.
 when i shortly peeked to sources it seems to be little bit messy how we 
 mix variables
 which govern whether we ouput err messages on console and on window.
 the right thing might be to fix this than to remove the tests...
 Maybe. But I think to remove the check is a linear improvement and more I 
 cannot do for now.
 I don't say the next step shouldn't be done. But I cannot afford two steps 
 currently.
 Of course I can guard the change with an #ifdef ON_MAC but that's really 
 ugly.
 
 Perhaps Enrico and Peter - the authors - can have a look...
 
 I had a quick look. Removing os::is_terminal(os::STDERR) is not the
 right thing to do. I introduced that check for not outputting anything
 when a terminal is not connected. Then Peter coupled the output to a
 terminal with the output sent to the GUI, such that if no output should
 go to a terminal (because there is no terminal), no output is sent to
 the GUI, too, which seems wrong.
 
 IMO, the correct fix is changing all occurences of
 
if (showerr_) {
  cerr  errdata_;
  ProgressInterface::instance()-appendError...
}
 
 to
 
if (showerr_)
  cerr  errdata_;
ProgressInterface::instance()-appendError...
 
 and similarly for other cases. In this way, output meant to go to a
 terminal and output meant for the GUI gets decoupled. However, I only
 had a very quick look, so I could be missing something. I think it is
 better that Peter has a look.
 
 
 This makes sens. When adding the output to the GUI I was irritated about the
 showerr_ and showout_ flags and didn't understand they are only guards for
 the terminal output. I've fixed it.

Thank you Peter!

Stephan

Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-16 Thread Peter Kümmel
Enrico Forestieri wrote:
> On Thu, Jul 15, 2010 at 04:31:26PM +0200, Stephan Witt wrote:
>> Am 15.07.2010 um 15:53 schrieb Pavel Sanda:
>>
>>> Stephan Witt wrote:
>> I see in the constructor SystemcallPrivate::SystemcallPrivate 
>> (SystemCall.cpp)
>> the error output of the child process is collected only if it's going to 
>> an terminal.
>> I think it would be better to collect it unconditionally to show it in 
>> the message window.
>> What do others think?
> whats the point of collecting it if we are not going to show it?
 The point is that you can read it when looking for it in the message 
 window.
 That's currently not possible, the error messages are lost.

 Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
 startup.

 If I remove the os::is_terminal(os::STDERR) test the output becomes 
 visible.

 Another story is to show the errors in the alert popup. This can be 
 improved too.
>>> i'm not sure what are side effects of kicking out 
>>> os::is_terminal(os::STDERR) tests.
>>> when i shortly peeked to sources it seems to be little bit messy how we mix 
>>> variables
>>> which govern whether we ouput err messages on console and on window.
>>> the right thing might be to fix this than to remove the tests...
>> Maybe. But I think to remove the check is a linear improvement and more I 
>> cannot do for now.
>> I don't say the next step shouldn't be done. But I cannot afford two steps 
>> currently.
>> Of course I can guard the change with an #ifdef ON_MAC but that's really 
>> ugly.
>>
>> Perhaps Enrico and Peter - the authors - can have a look...
> 
> I had a quick look. Removing os::is_terminal(os::STDERR) is not the
> right thing to do. I introduced that check for not outputting anything
> when a terminal is not connected. Then Peter coupled the output to a
> terminal with the output sent to the GUI, such that if no output should
> go to a terminal (because there is no terminal), no output is sent to
> the GUI, too, which seems wrong.
> 
> IMO, the correct fix is changing all occurences of
> 
> if (showerr_) {
>   cerr << errdata_;
>   ProgressInterface::instance()->appendError...
> }
> 
> to
> 
> if (showerr_)
>   cerr << errdata_;
> ProgressInterface::instance()->appendError...
> 
> and similarly for other cases. In this way, output meant to go to a
> terminal and output meant for the GUI gets decoupled. However, I only
> had a very quick look, so I could be missing something. I think it is
> better that Peter has a look.
> 

This makes sens. When adding the output to the GUI I was irritated about the
showerr_ and showout_ flags and didn't understand they are only guards for
the terminal output. I've fixed it.

Peter




Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-16 Thread Stephan Witt
Am 16.07.2010 um 08:13 schrieb Peter Kümmel:

> Enrico Forestieri wrote:
>> On Thu, Jul 15, 2010 at 04:31:26PM +0200, Stephan Witt wrote:
>>> Am 15.07.2010 um 15:53 schrieb Pavel Sanda:
>>> 
 Stephan Witt wrote:
>>> I see in the constructor SystemcallPrivate::SystemcallPrivate 
>>> (SystemCall.cpp)
>>> the error output of the child process is collected only if it's going 
>>> to an terminal.
>>> I think it would be better to collect it unconditionally to show it in 
>>> the message window.
>>> What do others think?
>> whats the point of collecting it if we are not going to show it?
> The point is that you can read it when looking for it in the message 
> window.
> That's currently not possible, the error messages are lost.
> 
> Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
> startup.
> 
> If I remove the os::is_terminal(os::STDERR) test the output becomes 
> visible.
> 
> Another story is to show the errors in the alert popup. This can be 
> improved too.
 i'm not sure what are side effects of kicking out 
 os::is_terminal(os::STDERR) tests.
 when i shortly peeked to sources it seems to be little bit messy how we 
 mix variables
 which govern whether we ouput err messages on console and on window.
 the right thing might be to fix this than to remove the tests...
>>> Maybe. But I think to remove the check is a linear improvement and more I 
>>> cannot do for now.
>>> I don't say the next step shouldn't be done. But I cannot afford two steps 
>>> currently.
>>> Of course I can guard the change with an #ifdef ON_MAC but that's really 
>>> ugly.
>>> 
>>> Perhaps Enrico and Peter - the authors - can have a look...
>> 
>> I had a quick look. Removing os::is_terminal(os::STDERR) is not the
>> right thing to do. I introduced that check for not outputting anything
>> when a terminal is not connected. Then Peter coupled the output to a
>> terminal with the output sent to the GUI, such that if no output should
>> go to a terminal (because there is no terminal), no output is sent to
>> the GUI, too, which seems wrong.
>> 
>> IMO, the correct fix is changing all occurences of
>> 
>>if (showerr_) {
>>  cerr << errdata_;
>>  ProgressInterface::instance()->appendError...
>>}
>> 
>> to
>> 
>>if (showerr_)
>>  cerr << errdata_;
>>ProgressInterface::instance()->appendError...
>> 
>> and similarly for other cases. In this way, output meant to go to a
>> terminal and output meant for the GUI gets decoupled. However, I only
>> had a very quick look, so I could be missing something. I think it is
>> better that Peter has a look.
>> 
> 
> This makes sens. When adding the output to the GUI I was irritated about the
> showerr_ and showout_ flags and didn't understand they are only guards for
> the terminal output. I've fixed it.

Thank you Peter!

Stephan

Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-15 Thread Pavel Sanda
Stephan Witt wrote:
  I see in the constructor SystemcallPrivate::SystemcallPrivate 
  (SystemCall.cpp)
  the error output of the child process is collected only if it's going to 
  an terminal.
  I think it would be better to collect it unconditionally to show it in the 
  message window.
  What do others think?
  
  whats the point of collecting it if we are not going to show it?
 
 The point is that you can read it when looking for it in the message window.
 That's currently not possible, the error messages are lost.
 
 Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
 startup.
 
 If I remove the os::is_terminal(os::STDERR) test the output becomes visible.
 
 Another story is to show the errors in the alert popup. This can be improved 
 too.

i'm not sure what are side effects of kicking out os::is_terminal(os::STDERR) 
tests.
when i shortly peeked to sources it seems to be little bit messy how we mix 
variables
which govern whether we ouput err messages on console and on window.
the right thing might be to fix this than to remove the tests...

pavel


Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-15 Thread Stephan Witt
Am 15.07.2010 um 15:53 schrieb Pavel Sanda:

 Stephan Witt wrote:
 I see in the constructor SystemcallPrivate::SystemcallPrivate 
 (SystemCall.cpp)
 the error output of the child process is collected only if it's going to 
 an terminal.
 I think it would be better to collect it unconditionally to show it in the 
 message window.
 What do others think?
 
 whats the point of collecting it if we are not going to show it?
 
 The point is that you can read it when looking for it in the message window.
 That's currently not possible, the error messages are lost.
 
 Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
 startup.
 
 If I remove the os::is_terminal(os::STDERR) test the output becomes visible.
 
 Another story is to show the errors in the alert popup. This can be improved 
 too.
 
 i'm not sure what are side effects of kicking out os::is_terminal(os::STDERR) 
 tests.
 when i shortly peeked to sources it seems to be little bit messy how we mix 
 variables
 which govern whether we ouput err messages on console and on window.
 the right thing might be to fix this than to remove the tests...

Maybe. But I think to remove the check is a linear improvement and more I 
cannot do for now.
I don't say the next step shouldn't be done. But I cannot afford two steps 
currently.
Of course I can guard the change with an #ifdef ON_MAC but that's really ugly.

Perhaps Enrico and Peter - the authors - can have a look...

Stephan

Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-15 Thread Pavel Sanda
Stephan Witt wrote:
  i'm not sure what are side effects of kicking out 
  os::is_terminal(os::STDERR) tests.
  when i shortly peeked to sources it seems to be little bit messy how we mix 
  variables
  which govern whether we ouput err messages on console and on window.
  the right thing might be to fix this than to remove the tests...
 
 Maybe. But I think to remove the check is a linear improvement and more I 
 cannot do for now.
 I don't say the next step shouldn't be done. But I cannot afford two steps 
 currently.
 Of course I can guard the change with an #ifdef ON_MAC but that's really ugly.
 
 Perhaps Enrico and Peter - the authors - can have a look...

Peter, can you have a peek?
i guess message window should get unified with those checks...

pavel


Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-15 Thread Enrico Forestieri
On Thu, Jul 15, 2010 at 04:31:26PM +0200, Stephan Witt wrote:
 Am 15.07.2010 um 15:53 schrieb Pavel Sanda:
 
  Stephan Witt wrote:
  I see in the constructor SystemcallPrivate::SystemcallPrivate 
  (SystemCall.cpp)
  the error output of the child process is collected only if it's going to 
  an terminal.
  I think it would be better to collect it unconditionally to show it in 
  the message window.
  What do others think?
  
  whats the point of collecting it if we are not going to show it?
  
  The point is that you can read it when looking for it in the message 
  window.
  That's currently not possible, the error messages are lost.
  
  Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
  startup.
  
  If I remove the os::is_terminal(os::STDERR) test the output becomes 
  visible.
  
  Another story is to show the errors in the alert popup. This can be 
  improved too.
  
  i'm not sure what are side effects of kicking out 
  os::is_terminal(os::STDERR) tests.
  when i shortly peeked to sources it seems to be little bit messy how we mix 
  variables
  which govern whether we ouput err messages on console and on window.
  the right thing might be to fix this than to remove the tests...
 
 Maybe. But I think to remove the check is a linear improvement and more I 
 cannot do for now.
 I don't say the next step shouldn't be done. But I cannot afford two steps 
 currently.
 Of course I can guard the change with an #ifdef ON_MAC but that's really ugly.
 
 Perhaps Enrico and Peter - the authors - can have a look...

I had a quick look. Removing os::is_terminal(os::STDERR) is not the
right thing to do. I introduced that check for not outputting anything
when a terminal is not connected. Then Peter coupled the output to a
terminal with the output sent to the GUI, such that if no output should
go to a terminal (because there is no terminal), no output is sent to
the GUI, too, which seems wrong.

IMO, the correct fix is changing all occurences of

if (showerr_) {
cerr  errdata_;
ProgressInterface::instance()-appendError...
}

to

if (showerr_)
cerr  errdata_;
ProgressInterface::instance()-appendError...

and similarly for other cases. In this way, output meant to go to a
terminal and output meant for the GUI gets decoupled. However, I only
had a very quick look, so I could be missing something. I think it is
better that Peter has a look.

-- 
Enrico


Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-15 Thread Pavel Sanda
Stephan Witt wrote:
> >> I see in the constructor SystemcallPrivate::SystemcallPrivate 
> >> (SystemCall.cpp)
> >> the error output of the child process is collected only if it's going to 
> >> an terminal.
> >> I think it would be better to collect it unconditionally to show it in the 
> >> message window.
> >> What do others think?
> > 
> > whats the point of collecting it if we are not going to show it?
> 
> The point is that you can read it when looking for it in the message window.
> That's currently not possible, the error messages are lost.
> 
> Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
> startup.
> 
> If I remove the os::is_terminal(os::STDERR) test the output becomes visible.
> 
> Another story is to show the errors in the alert popup. This can be improved 
> too.

i'm not sure what are side effects of kicking out os::is_terminal(os::STDERR) 
tests.
when i shortly peeked to sources it seems to be little bit messy how we mix 
variables
which govern whether we ouput err messages on console and on window.
the right thing might be to fix this than to remove the tests...

pavel


Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-15 Thread Stephan Witt
Am 15.07.2010 um 15:53 schrieb Pavel Sanda:

> Stephan Witt wrote:
 I see in the constructor SystemcallPrivate::SystemcallPrivate 
 (SystemCall.cpp)
 the error output of the child process is collected only if it's going to 
 an terminal.
 I think it would be better to collect it unconditionally to show it in the 
 message window.
 What do others think?
>>> 
>>> whats the point of collecting it if we are not going to show it?
>> 
>> The point is that you can read it when looking for it in the message window.
>> That's currently not possible, the error messages are lost.
>> 
>> Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
>> startup.
>> 
>> If I remove the os::is_terminal(os::STDERR) test the output becomes visible.
>> 
>> Another story is to show the errors in the alert popup. This can be improved 
>> too.
> 
> i'm not sure what are side effects of kicking out os::is_terminal(os::STDERR) 
> tests.
> when i shortly peeked to sources it seems to be little bit messy how we mix 
> variables
> which govern whether we ouput err messages on console and on window.
> the right thing might be to fix this than to remove the tests...

Maybe. But I think to remove the check is a linear improvement and more I 
cannot do for now.
I don't say the next step shouldn't be done. But I cannot afford two steps 
currently.
Of course I can guard the change with an #ifdef ON_MAC but that's really ugly.

Perhaps Enrico and Peter - the authors - can have a look...

Stephan

Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-15 Thread Pavel Sanda
Stephan Witt wrote:
> > i'm not sure what are side effects of kicking out 
> > os::is_terminal(os::STDERR) tests.
> > when i shortly peeked to sources it seems to be little bit messy how we mix 
> > variables
> > which govern whether we ouput err messages on console and on window.
> > the right thing might be to fix this than to remove the tests...
> 
> Maybe. But I think to remove the check is a linear improvement and more I 
> cannot do for now.
> I don't say the next step shouldn't be done. But I cannot afford two steps 
> currently.
> Of course I can guard the change with an #ifdef ON_MAC but that's really ugly.
> 
> Perhaps Enrico and Peter - the authors - can have a look...

Peter, can you have a peek?
i guess message window should get unified with those checks...

pavel


Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-15 Thread Enrico Forestieri
On Thu, Jul 15, 2010 at 04:31:26PM +0200, Stephan Witt wrote:
> Am 15.07.2010 um 15:53 schrieb Pavel Sanda:
> 
> > Stephan Witt wrote:
>  I see in the constructor SystemcallPrivate::SystemcallPrivate 
>  (SystemCall.cpp)
>  the error output of the child process is collected only if it's going to 
>  an terminal.
>  I think it would be better to collect it unconditionally to show it in 
>  the message window.
>  What do others think?
> >>> 
> >>> whats the point of collecting it if we are not going to show it?
> >> 
> >> The point is that you can read it when looking for it in the message 
> >> window.
> >> That's currently not possible, the error messages are lost.
> >> 
> >> Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
> >> startup.
> >> 
> >> If I remove the os::is_terminal(os::STDERR) test the output becomes 
> >> visible.
> >> 
> >> Another story is to show the errors in the alert popup. This can be 
> >> improved too.
> > 
> > i'm not sure what are side effects of kicking out 
> > os::is_terminal(os::STDERR) tests.
> > when i shortly peeked to sources it seems to be little bit messy how we mix 
> > variables
> > which govern whether we ouput err messages on console and on window.
> > the right thing might be to fix this than to remove the tests...
> 
> Maybe. But I think to remove the check is a linear improvement and more I 
> cannot do for now.
> I don't say the next step shouldn't be done. But I cannot afford two steps 
> currently.
> Of course I can guard the change with an #ifdef ON_MAC but that's really ugly.
> 
> Perhaps Enrico and Peter - the authors - can have a look...

I had a quick look. Removing os::is_terminal(os::STDERR) is not the
right thing to do. I introduced that check for not outputting anything
when a terminal is not connected. Then Peter coupled the output to a
terminal with the output sent to the GUI, such that if no output should
go to a terminal (because there is no terminal), no output is sent to
the GUI, too, which seems wrong.

IMO, the correct fix is changing all occurences of

if (showerr_) {
cerr << errdata_;
ProgressInterface::instance()->appendError...
}

to

if (showerr_)
cerr << errdata_;
ProgressInterface::instance()->appendError...

and similarly for other cases. In this way, output meant to go to a
terminal and output meant for the GUI gets decoupled. However, I only
had a very quick look, so I could be missing something. I think it is
better that Peter has a look.

-- 
Enrico


Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-12 Thread Pavel Sanda
Stephan Witt wrote:
  Yes, but tex2lyx fails when run from LyX as converter. The output of this 
  operation I'm looking for.
  E. g. with adding a -v to the converter config line or something similar.
  But possibly there is some output already and it is lost somehow...
 
 I see in the constructor SystemcallPrivate::SystemcallPrivate (SystemCall.cpp)
 the error output of the child process is collected only if it's going to an 
 terminal.
 I think it would be better to collect it unconditionally to show it in the 
 message window.
 What do others think?

whats the point of collecting it if we are not going to show it?
pavel


Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-12 Thread Stephan Witt
Am 12.07.2010 um 13:43 schrieb Pavel Sanda:

 Stephan Witt wrote:
 Yes, but tex2lyx fails when run from LyX as converter. The output of this 
 operation I'm looking for.
 E. g. with adding a -v to the converter config line or something similar.
 But possibly there is some output already and it is lost somehow...
 
 I see in the constructor SystemcallPrivate::SystemcallPrivate 
 (SystemCall.cpp)
 the error output of the child process is collected only if it's going to an 
 terminal.
 I think it would be better to collect it unconditionally to show it in the 
 message window.
 What do others think?
 
 whats the point of collecting it if we are not going to show it?

The point is that you can read it when looking for it in the message window.
That's currently not possible, the error messages are lost.

Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
startup.

If I remove the os::is_terminal(os::STDERR) test the output becomes visible.

Another story is to show the errors in the alert popup. This can be improved 
too.

Stephan

Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-12 Thread Pavel Sanda
Stephan Witt wrote:
> > Yes, but tex2lyx fails when run from LyX as converter. The output of this 
> > operation I'm looking for.
> > E. g. with adding a -v to the converter config line or something similar.
> > But possibly there is some output already and it is lost somehow...
> 
> I see in the constructor SystemcallPrivate::SystemcallPrivate (SystemCall.cpp)
> the error output of the child process is collected only if it's going to an 
> terminal.
> I think it would be better to collect it unconditionally to show it in the 
> message window.
> What do others think?

whats the point of collecting it if we are not going to show it?
pavel


Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-12 Thread Stephan Witt
Am 12.07.2010 um 13:43 schrieb Pavel Sanda:

> Stephan Witt wrote:
>>> Yes, but tex2lyx fails when run from LyX as converter. The output of this 
>>> operation I'm looking for.
>>> E. g. with adding a -v to the converter config line or something similar.
>>> But possibly there is some output already and it is lost somehow...
>> 
>> I see in the constructor SystemcallPrivate::SystemcallPrivate 
>> (SystemCall.cpp)
>> the error output of the child process is collected only if it's going to an 
>> terminal.
>> I think it would be better to collect it unconditionally to show it in the 
>> message window.
>> What do others think?
> 
> whats the point of collecting it if we are not going to show it?

The point is that you can read it when looking for it in the message window.
That's currently not possible, the error messages are lost.

Here on Mac if I start LyX the stdin, stdout and stderr are redirected on 
startup.

If I remove the os::is_terminal(os::STDERR) test the output becomes visible.

Another story is to show the errors in the alert popup. This can be improved 
too.

Stephan

Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-11 Thread Stephan Witt
Am 07.07.2010 um 13:12 schrieb Stephan Witt:

 Am 07.07.2010 um 13:02 schrieb Vincent van Ravesteijn:
 
 The import of rtf file fails at the tex2lyx step and there is no output 
 from tex2lyx.
 Is there any possiblity to make it more verbose and collect the output for 
 presentation
 in message window?
 
 When tex2lyx is run from the command line, the file is converted
 correctly right ? So, I think that there is no output of tex2lyx.
 
 Yes, but tex2lyx fails when run from LyX as converter. The output of this 
 operation I'm looking for.
 E. g. with adding a -v to the converter config line or something similar.
 But possibly there is some output already and it is lost somehow...

I see in the constructor SystemcallPrivate::SystemcallPrivate (SystemCall.cpp)
the error output of the child process is collected only if it's going to an 
terminal.
I think it would be better to collect it unconditionally to show it in the 
message window.
What do others think?

Stephan



Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-11 Thread Stephan Witt
Am 07.07.2010 um 13:12 schrieb Stephan Witt:

> Am 07.07.2010 um 13:02 schrieb Vincent van Ravesteijn:
> 
>>> The import of rtf file fails at the tex2lyx step and there is no output 
>>> from tex2lyx.
>>> Is there any possiblity to make it more verbose and collect the output for 
>>> presentation
>>> in message window?
>> 
>> When tex2lyx is run from the command line, the file is converted
>> correctly right ? So, I think that there is no output of tex2lyx.
> 
> Yes, but tex2lyx fails when run from LyX as converter. The output of this 
> operation I'm looking for.
> E. g. with adding a -v to the converter config line or something similar.
> But possibly there is some output already and it is lost somehow...

I see in the constructor SystemcallPrivate::SystemcallPrivate (SystemCall.cpp)
the error output of the child process is collected only if it's going to an 
terminal.
I think it would be better to collect it unconditionally to show it in the 
message window.
What do others think?

Stephan



Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-07 Thread Vincent van Ravesteijn
 The import of rtf file fails at the tex2lyx step and there is no output from 
 tex2lyx.
 Is there any possiblity to make it more verbose and collect the output for 
 presentation
 in message window?

When tex2lyx is run from the command line, the file is converted
correctly right ? So, I think that there is no output of tex2lyx.

Vincent


Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-07 Thread Stephan Witt
Am 07.07.2010 um 13:02 schrieb Vincent van Ravesteijn:

 The import of rtf file fails at the tex2lyx step and there is no output from 
 tex2lyx.
 Is there any possiblity to make it more verbose and collect the output for 
 presentation
 in message window?
 
 When tex2lyx is run from the command line, the file is converted
 correctly right ? So, I think that there is no output of tex2lyx.

Yes, but tex2lyx fails when run from LyX as converter. The output of this 
operation I'm looking for.
E. g. with adding a -v to the converter config line or something similar.
But possibly there is some output already and it is lost somehow...

Stephan

Re: #6805: Cannot convert file importing from RTF, but works on the command line

2010-07-07 Thread Stephan Witt
Am 07.07.2010 um 13:12 schrieb Stephan Witt:

 Am 07.07.2010 um 13:02 schrieb Vincent van Ravesteijn:
 
 The import of rtf file fails at the tex2lyx step and there is no output 
 from tex2lyx.
 Is there any possiblity to make it more verbose and collect the output for 
 presentation
 in message window?
 
 When tex2lyx is run from the command line, the file is converted
 correctly right ? So, I think that there is no output of tex2lyx.
 
 Yes, but tex2lyx fails when run from LyX as converter. The output of this 
 operation I'm looking for.
 E. g. with adding a -v to the converter config line or something similar.
 But possibly there is some output already and it is lost somehow...

I called tex2lyx with illegal parameters: the output is not collected by lyx :(

22:59:34:228ms: (window-new)
22:59:54:410ms: Importiere ~/cvs/lyx/Acknowledgements.lyx...
22:59:54:420ms: 
/Users/stephan/cvs/lyx/lyx-build/LyX-2.0.0svn.app/Contents/MacOS/tex2lyx -v 
-f Acknowledgements.tex 
Acknowledgements.lyx/Users/stephan/cvs/lyx/lyx-devel/src/support/Systemcall.cpp(237):
 Systemcall: 
'/Users/stephan/cvs/lyx/lyx-build/LyX-2.0.0svn.app/Contents/MacOS/tex2lyx -v 
-f Acknowledgements.tex Acknowledgements.lyx' finished with exit code 1
Error: Die Datei kann nicht konvertiert werden

Bei der Ausführung von
/Users/stephan/cvs/lyx/lyx-build/LyX-2.0.0svn.app
ist ein Fehler aufgetreten
23:00:00:035ms: Datei wurde nicht importiert!
23:00:00:035ms: (buffer-import latex)

The same command line call produces an error message:
% /Users/stephan/cvs/lyx/lyx-build/LyX-2.0.0svn.app/Contents/MacOS/tex2lyx -f 
Acknowledgements.tex -v Acknowledgements.lyx
tex2lyx: Unknown option `-v'.

Usage: tex2lyx [options] infile.tex [outfile.lyx]
Options:
-c textclass   Declare the textclass.
-e encodingSet the default encoding (latex name).
-f Force overwrite of .lyx files.
-help  Print this message and quit.
-n translate a noweb (aka literate programming) file.
-s syntaxfile  read additional syntax file.
-sysdir dirSet system directory to DIR.
-userdir DIR   Set user directory to DIR.


Stephan

Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-07 Thread Vincent van Ravesteijn
> The import of rtf file fails at the tex2lyx step and there is no output from 
> tex2lyx.
> Is there any possiblity to make it more verbose and collect the output for 
> presentation
> in message window?

When tex2lyx is run from the command line, the file is converted
correctly right ? So, I think that there is no output of tex2lyx.

Vincent


Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-07 Thread Stephan Witt
Am 07.07.2010 um 13:02 schrieb Vincent van Ravesteijn:

>> The import of rtf file fails at the tex2lyx step and there is no output from 
>> tex2lyx.
>> Is there any possiblity to make it more verbose and collect the output for 
>> presentation
>> in message window?
> 
> When tex2lyx is run from the command line, the file is converted
> correctly right ? So, I think that there is no output of tex2lyx.

Yes, but tex2lyx fails when run from LyX as converter. The output of this 
operation I'm looking for.
E. g. with adding a -v to the converter config line or something similar.
But possibly there is some output already and it is lost somehow...

Stephan

Re: #6805: "Cannot convert file" importing from RTF, but works on the command line

2010-07-07 Thread Stephan Witt
Am 07.07.2010 um 13:12 schrieb Stephan Witt:

> Am 07.07.2010 um 13:02 schrieb Vincent van Ravesteijn:
> 
>>> The import of rtf file fails at the tex2lyx step and there is no output 
>>> from tex2lyx.
>>> Is there any possiblity to make it more verbose and collect the output for 
>>> presentation
>>> in message window?
>> 
>> When tex2lyx is run from the command line, the file is converted
>> correctly right ? So, I think that there is no output of tex2lyx.
> 
> Yes, but tex2lyx fails when run from LyX as converter. The output of this 
> operation I'm looking for.
> E. g. with adding a -v to the converter config line or something similar.
> But possibly there is some output already and it is lost somehow...

I called tex2lyx with illegal parameters: the output is not collected by lyx :(

22:59:34:228ms: (window-new)
22:59:54:410ms: Importiere ~/cvs/lyx/Acknowledgements.lyx...
22:59:54:420ms: 
"/Users/stephan/cvs/lyx/lyx-build/LyX-2.0.0svn.app/Contents/MacOS/tex2lyx" -v 
-f "Acknowledgements.tex" 
"Acknowledgements.lyx"/Users/stephan/cvs/lyx/lyx-devel/src/support/Systemcall.cpp(237):
 Systemcall: 
'"/Users/stephan/cvs/lyx/lyx-build/LyX-2.0.0svn.app/Contents/MacOS/tex2lyx" -v 
-f "Acknowledgements.tex" "Acknowledgements.lyx"' finished with exit code 1
Error: Die Datei kann nicht konvertiert werden

Bei der Ausführung von
"/Users/stephan/cvs/lyx/lyx-build/LyX-2.0.0svn.app
ist ein Fehler aufgetreten
23:00:00:035ms: Datei wurde nicht importiert!
23:00:00:035ms: (buffer-import latex)

The same command line call produces an error message:
% /Users/stephan/cvs/lyx/lyx-build/LyX-2.0.0svn.app/Contents/MacOS/tex2lyx -f 
Acknowledgements.tex -v Acknowledgements.lyx
tex2lyx: Unknown option `-v'.

Usage: tex2lyx [options] infile.tex [outfile.lyx]
Options:
-c textclass   Declare the textclass.
-e encodingSet the default encoding (latex name).
-f Force overwrite of .lyx files.
-help  Print this message and quit.
-n translate a noweb (aka literate programming) file.
-s syntaxfile  read additional syntax file.
-sysdir dirSet system directory to DIR.
-userdir DIR   Set user directory to DIR.


Stephan