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

Close

#637 nedit can be killed by ctrl+C

closed-invalid
nobody
None
1
2014-08-13
2008-07-07
Anonymous
No

nedit can be killed by ctrl+C, while 'xemacs' can't.

NEdit release of Aug 20, 2004

Built on: Linux, 386, Intel C++
Built at: Jun 19 2008, 16:03:17
With Motif: 2.2.3 [@(#)Motif Version 2.2.4]
Running Motif: 2.2 [unknown]
Server: The X.Org Foundation 60802000
Visual: 24-bit TrueColor (ID 0x21, Default)
Locale: en_US.UTF-8

Discussion

  • Bert Wesarg
    Bert Wesarg
    2008-07-07

    Logged In: YES
    user_id=122956
    Originator: NO

    "nedit can't be killed by ctrl+C"
    "nedit can be killed by ctrl+C, while 'xemacs' can't."

    Isn't there something wrong with these two statements?

     
  • Logged In: NO

    Sorry!

    I meant if would be better if nedit can't be killed by ctrl+C. I tried with xemacs, and the window can't be killed by ctrl+C -- I like this but I don't know if it is easy to implement for nedit.

    Thank you.

     
  • Bert Wesarg
    Bert Wesarg
    2008-07-07

    Logged In: YES
    user_id=122956
    Originator: NO

    I think most users of NEdit use it in server mode and the NEdit client to communicate with the server. So the use of Ctrl+C is mostly useless, because the client releases the shell after communicating with the server.

    BTW: could you give a better rational as "It would be better" or "I like this", thanks. I really can't see a reason why this could be good.

     
  • Logged In: NO

    1) Sometime I killed my nedit window accidently by pressing ^C, so I started to think if nedit couldn't be killed by ^C it would be better...

    2) Because vi and xemacs can't be killed by ^C, I think there must be some good reasons to design them into this way...

     
  • Logged In: NO

    1) Sometime I killed my nedit window accidently by pressing ^C, so I started to think if nedit couldn't be killed by ^C it would be better...

    2) Because vi and xemacs can't be killed by ^C, I think there must be some good reasons to design them into this way...

     
  • Logged In: NO

    Hi,

    Ctrl+C is bound to Copy, so NEdit must not killed by this key.
    You use "old" Nedit-5.5 code with "modern" Motif 2.2.
    Please, try to compile NEdit 5.6 available at
    http://www.nedit.org/ftp/snapshot/nedit-latest-sources-HEAD.tar.gz
    Though this code is stable, it is not released yet.
    NEdit is really frozen now.

    Alexey Kuznetsov

     
  • Eddy De Greef
    Eddy De Greef
    2008-07-08

    • summary: nedit can't be killed by ctrl+C --> nedit can be killed by ctrl+C
    • status: open --> closed-invalid
     
  • Eddy De Greef
    Eddy De Greef
    2008-07-08

    Logged In: YES
    user_id=73597
    Originator: NO

    You should really give the NEdit server mode a try: instead of starting NEdit via the "nedit" command, you should use the NEdit client, which is usually called "ncl" or "nc", depending on your distribution.
    When started in this way, NEdit can't be killed by Ctrl-C in your terminal window any more. Using the server mode has several other advantages (shared search history, shared preferences, remote control possibilities, ...). Check out Help>Client/Server Mode.

     
  • Eddy De Greef
    Eddy De Greef
    2008-07-08

    • status: closed-invalid --> closed
     
  • Andrew Hood
    Andrew Hood
    2008-07-08

    Logged In: YES
    user_id=36856
    Originator: NO

    It's fairly trivial to add a signal handler to nedit.c (at least on some platforms) for SIGINT to run the CloseAllFilesAndWindows() routine so you can choose to save everything.

    nc might need one too so that "nc -wait" can do some level of error recovery.

     
  • Scott Tringali
    Scott Tringali
    2008-07-09

    • priority: 5 --> 1
    • status: closed --> closed-invalid
     
  • Scott Tringali
    Scott Tringali
    2008-07-09

    Logged In: YES
    user_id=11321
    Originator: NO

    You are pressing ^C in the shell, not nedit. That tells the shell to kill nedit. It's doing what you told it to.

    vi and emacs are text mode applications, so it takes over your terminal - the shell is in the background and not running.

    All other Unix GUI apps like firefox and openoffice shut down when you fire SIGINT (it with a ^C at the shell), as it's supposed to.

     
  • Andrew Hood
    Andrew Hood
    2008-07-11

    Logged In: YES
    user_id=36856
    Originator: NO

    As long as you never accidentally press ^C with the focus in the shell window rather than the NEdit window I would agree. With "focus follows pointer" (personal opinion the only way to go) it is too easy to hit the wrong window and lose some or all of your edit. From my nedit.c on Linux:

    snip 1
    +#include <signal.h>

    snip 2
    +void sigTERM(int signum) {
    + signal(signum, SIG_DFL);
    + CloseAllFilesAndWindows();
    +}

    snip 3 near the top of main()
    + signal(SIGINT, sigTERM);
    + signal(SIGTERM, sigTERM);

     
  • Bert Wesarg
    Bert Wesarg
    2008-07-11

    Logged In: YES
    user_id=122956
    Originator: NO

    Andrew, I think we need to re-arm the signal handler, after a user says "no" to the close dialog.

     
  • Andrew Hood
    Andrew Hood
    2008-07-11

    Logged In: YES
    user_id=36856
    Originator: NO

    Treat it as a proof of concept. That code is enough to give you a chance to close all the windows and shut down cleanly, but to be able to ^C twice and have it die. Have the handler re-arm itself?

    snip 2 mark 2
    +void sigTERM(int signum) {
    + signal(signum, SIG_DFL);
    + CloseAllFilesAndWindows();
    + signal(signum, sigTERM);
    +}

    If you want to keep editing you have to click "Cancel" twice, so more thought is required.

    A complete solution would probably
    1) have a "Do you really want to kill this NEdit session?" dialog, and
    2) exit if there were no unsaved windows.

     
  • Logged In: NO

    You can't make those calls from a signal handler. In particular, you may be inside CloseAllFilesAndWindows when the signal fires, and now you've gone from simply losing your changes to making swiss cheese out of your files. --SJT