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

Close

#533 nc -wait does not wait when closing a file opened in a tab

release
closed-fixed
Arne F�rlie
Program (402)
9
2006-11-28
2006-07-20
Anonymous
No

Hello,

nc -wait file.txt

does not wait until file.txt is closed when in nedit
window a new file is opened in a tab and this new tab
is closed.

Example:

nc -svrname xxx -wait file.txt
File -> Open... -> file2.txt
[Ctrl+W] in file2.txt tab

Discussion

  • TK Soh
    TK Soh
    2006-07-20

    Logged In: YES
    user_id=411637

    > nc -svrname xxx -wait file.txt
    > File -> Open... -> file2.txt
    > [Ctrl+W] in file2.txt tab

    I don't understand why you are trying to achieve with
    opening and closing file2.txt, while asking nc to wait for
    file.txt.

     
  • TK Soh
    TK Soh
    2006-07-20

    Logged In: YES
    user_id=411637

    Also, why did you post the same bug twice?

     
  • Arne F�rlie
    Arne F�rlie
    2006-07-21

    Logged In: YES
    user_id=75224

    As one of the original authors of the nc -wait feature, I
    consider it a bug. I run into it all the time, but it just
    hasn't annoyed me enough to fix it.

    If we set Preferences->Tabbed Editing->Open File In New Tab
    to OFF, nc -wait works as expected. If it is ON, we get the
    behaviour described by OP.

    nc -wait shouldn't care about how the files are displayed,
    hence I consider this a bug.
    I'll have a stab on this later.

     
  • Arne F�rlie
    Arne F�rlie
    2006-07-21

    Logged In: YES
    user_id=75224

    I think I found the problem.
    In window.c (CreateDocument function) the new document
    inherits attributes from the parent window, including the
    fileClosedAtom. Hence, when the second document is closed,
    it deletes the atom that belongs to the document opened with
    nc -wait.

    The fix seems to be trivial:
    Add the line
    window->fileClosedAtom = None;
    at window.c line 3247

    OP, if you can compile nedit from source, can you confirm
    that this change solves the problem?

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-11

    Logged In: YES
    user_id=119143

    I don't see the problem:
    Enhanced NEdit 5.5
    Nov 24, 2005

    Built on: Linux, 486, GNU C
    Built at: Jan 2 2006, 20:46:10
    With Motif: 2.2.3 [@(#)Motif Version 2.2.3]
    Running Motif: 2.2 [@(#)Motif Version 2.2.3]
    Server: The XFree86 Project, Inc 40399902
    Visual: 16-bit TrueColor (ID 0x22, Default)
    Locale: de_DE

     
  • Thorsten Haude
    Thorsten Haude
    2006-09-17

    Logged In: YES
    user_id=119143

    So is this a bug or not? Do you have the fix?

     
  • Arne F�rlie
    Arne F�rlie
    2006-09-18

    Logged In: YES
    user_id=75224

    I was waiting for Original Poster to verify that the fix
    worked for him before proceeding.

    I also would like TK to comment on the fix;
    was there any particular reason why fileClosedAtom was
    inherited from parent, and not reset for the new tab?

    I'll build a new NEdit and start using this patch, and come
    back with an update in a week.

     
  • Thorsten Haude
    Thorsten Haude
    2006-10-06

    Logged In: YES
    user_id=119143

    @OP, does the fix work?

    @TK, what do you think about the bug/fix?

    @Arne, do you have an idea why I don't see the bug?

     
  • Thorsten Haude
    Thorsten Haude
    2006-10-06

    • milestone: --> release
    • priority: 5 --> 9
    • assigned_to: nobody --> arnef
    • status: open --> open-accepted
     
  • TK Soh
    TK Soh
    2006-10-06

    Logged In: YES
    user_id=411637

    I'd like to, but probably have to wait for another week or
    two before I can find the time.

     
  • Thorsten Haude
    Thorsten Haude
    2006-11-22

    Logged In: YES
    user_id=119143
    Originator: NO

    Any news here?

     
  • Arne F�rlie
    Arne F�rlie
    2006-11-23

    Logged In: YES
    user_id=75224
    Originator: NO

    Below you will find a small patch that inserts debugging code that demonstrates the problem. Apply it to server.c (as of 23 Nov. 2006).

    Then perform the following:

    % touch file1 file2
    % nc -wait file1

    That should print something like
    Found fileClosedAtom 0x29e
    to the console.

    Then Ctrl+O and open file2
    It should open in a new tab (if it doesn't ensure that Preference "Tabbed editing->Open File in New Tab" is set, and restart the exercise)

    Then close the tab that holds file2.
    That should print something like
    Deleting fileClosedAtom 0x29e
    to the console.
    Note also that nc -wait file1 returns.

    THIS IS THE BUG, fileClosedAtom BELONGED TO file1, BUT IS DELETED WHEN file2 IS CLOSED

    Then close file1. That should also print
    Deleting fileClosedAtom 0x29e
    to the console.
    THIS WAS THE DELETE THAT WAS SUPPOSED TO TERMINATE nc -wait

    Now insert
    window->fileClosedAtom = None;
    at line 3326 of window.c and repeat the exercise.
    You will find that everything now works, confirmed by the printouts from server.c

    % nedit -V
    NEdit release of Aug 20, 2004

    Built on: Linux, 386, GNU C
    Built at: Nov 23 2006, 22:30:37
    With Motif: 2.1.31 [@(#)Motif Version 2.1.31]
    Running Motif: 2.1 [unknown]
    Server: The X.Org Foundation 70000000
    Visual: 24-bit TrueColor (ID 0x23, Default)
    Locale: en_US

    Index: source/server.c

    --- source/server.c (revision 16)
    +++ source/server.c (working copy)
    @@ -269,6 +269,7 @@
    if (window->filenameSet) {
    window->fileClosedAtom = findFileClosedProperty(window->filename,
    window->path);
    + fprintf(stderr, "Found fileClosedAtom %p\n", window->fileClosedAtom);
    }
    }

    @@ -278,6 +279,7 @@
    void DeleteFileClosedProperty(WindowInfo *window)
    {
    if (window->filenameSet) {
    + fprintf(stderr, "Deleting fileClosedAtom %p\n", window->fileClosedAtom);
    deleteProperty(&window->fileClosedAtom);
    }
    }
    @@ -286,6 +288,7 @@
    const char* pathname)
    {
    Atom atom = findFileClosedProperty(filename, pathname);
    + fprintf(stderr, "Deleting fileClosedAtom %p\n", atom);
    deleteProperty(&atom);
    }

     
  • Thorsten Haude
    Thorsten Haude
    2006-11-23

    Logged In: YES
    user_id=119143
    Originator: NO

    I hope you didn't create the demo on my account. I believe you if you say it's fixed, I just wanted to ask for an update.

     
  • Arne F�rlie
    Arne F�rlie
    2006-11-26

    Logged In: YES
    user_id=75224
    Originator: NO

    I am still curious on what you observe when running with my debugging code.

    I suggest that I commit my fix in a few days, hoping that at least one developer can confirm the bug and fix in the meantime.

     
  • Thorsten Haude
    Thorsten Haude
    2006-11-26

    Logged In: YES
    user_id=119143
    Originator: NO

    Ok, sure, sorry for the misunderstanding.

    Yes, I see what you are describing:
    yooden@eumel % nc -svrname xxx -svrcmd ~nedit/nedit.arne-wait/source/nedit -wait file1
    Found fileClosedAtom 0x459

    ...and on closing file2:
    Deleting fileClosedAtom 0x459

    ...and after closing file1 again:
    Deleting fileClosedAtom 0x459

    Line 3247 for the fix is off already, I put it somewhere in the init block in CreateDocument(). Now it works as documented and I get:
    Found fileClosedAtom 0x459

    ...after closing file2:
    Deleting fileClosedAtom (nil)

    ...after closing file1:
    Deleting fileClosedAtom 0x459

    Seems to work!

     
  • Arne F�rlie
    Arne F�rlie
    2006-11-28

    • status: open-accepted --> closed-fixed
     
  • Arne F�rlie
    Arne F�rlie
    2006-11-28

    Logged In: YES
    user_id=75224
    Originator: NO

    Checked in fix for this (a single line in window.c)