Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

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

development
closed-fixed
Arne F�rlie
Program (402)
7
2003-08-12
2003-08-09
Michael Sullivan
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

  • 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

     
  • 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

     
  • 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".

     
  • 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".

     
  • 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