#301 "nc -do ..." creates extra window

development
closed-fixed
Program (402)
7
2003-08-12
2003-08-09
No

Back when I used NEdit in Unix-land, I had a perl script
that issued a "nc -do 'someFunction()'" and it worked
great. I just got around to porting that code to my
Windows/Cygwin/Lesstif environment and now, that "nc -
do ..." code causes a blank untitled window to open in
NEdit, followed by the execution of my macro.

At first I thought it was my macro so I commented all
the code in the macro out. The blank window was still
being created. It's the exact same behavior as running
the following:

nc (creates new untitled window)
nc -do someFunction (runs macro)

I can't tell if this is a NEdit/nc problem, or an X server
communication problem. Any thoughts?

Discussion

  • Michael Sullivan

    Logged In: YES
    user_id=836812

    I'm sure everyone reading this already knows my setup, but
    here it is again:

    NEdit 5.4RC1
    Jul 16, 2003

    Built on: Unknown, 386, GNU C
    Built at: Aug 4 2003, 10:27:02
    With Motif: 2.1.0 [@(#)GNU/LessTif Version 2.1 Release
    0.93.18]
    Running Motif: 2.1 [unknown]
    Server: Hummingbird Ltd. 8000
    Visual: 24-bit TrueColor (ID 0x23, Default)
    Locale: C

     
  • Michael Sullivan

    Logged In: YES
    user_id=836812

    I also reproduced this using the XFree86 4.2.0 X server.

    Here are the relevant .Xdefaults I'm using:

    nc.serverCommand: nedit -server
    nc.autoStart: true

     
  • Michael Sullivan

    Logged In: YES
    user_id=836812

    I logged in with CVS and tracked this problem back to the change
    made in server.c; v1.21, in the processServerCommandString()
    function.

    If you run a command like "nc -do 'someMacro()'", the new code will
    walk thru the list of windows trying to find one to execute the macro
    in. Unfortunately, the algorithm refuses to use an existing window if
    it has already been saved or modified. That's not how it worked in
    5.3 and I don't understand why such a restriction should be put in
    place now.

    If this new behavior is really desired, perhaps a new option can be
    added like "-forceNewWindow".

     
  • Michael Sullivan

    Logged In: YES
    user_id=836812

    I logged in with CVS and tracked this problem back to the change
    made in server.c; v1.21, in the processServerCommandString()
    function.

    If you run a command like "nc -do 'someMacro()'", the new code will
    walk thru the list of windows trying to find one to execute the macro
    in. Unfortunately, the algorithm refuses to use an existing window if
    it has already been saved or modified. That's not how it worked in
    5.3 and I don't understand why such a restriction should be put in
    place now.

    If this new behavior is really desired, perhaps a new option can be
    added like "-forceNewWindow".

     
  • Michael Sullivan

    Logged In: YES
    user_id=836812

    I logged in with CVS and tracked this problem back to the change
    made in server.c; v1.21, in the processServerCommandString()
    function.

    If you run a command like "nc -do 'someMacro()'", the new code will
    walk thru the list of windows trying to find one to execute the macro
    in. Unfortunately, the algorithm refuses to use an existing window if
    it has already been saved or modified. That's not how it worked in
    5.3 and I don't understand why such a restriction should be put in
    place now.

    If this new behavior is really desired, perhaps a new option can be
    added like "-forceNewWindow".

     
  • Eddy De Greef

    Eddy De Greef - 2003-08-11
    • labels: --> Program
    • milestone: --> 103146
    • priority: 5 --> 7
    • status: open --> pending-accepted
     
  • Eddy De Greef

    Eddy De Greef - 2003-08-11

    Logged In: YES
    user_id=73597

    We are working on a fix. Thanks.

     
  • Eddy De Greef

    Eddy De Greef - 2003-08-12
    • assigned_to: nobody --> arnef
    • status: pending-accepted --> closed-fixed
     
  • Eddy De Greef

    Eddy De Greef - 2003-08-12

    Logged In: YES
    user_id=73597

    A fix has been committed to the BETA-5-4 branch.

     
  • Scott Tringali

    Scott Tringali - 2003-08-12

    Logged In: YES
    user_id=11321

    Changed to "development" -- I don't think this bug made it
    out to a final release, right? (I still consider 5.4RC# as
    "development".)

     
  • Scott Tringali

    Scott Tringali - 2003-08-12
    • milestone: 103146 --> development
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks