#295 Clicking in text area requires save

Program (402)

The following sequence causes me to have to save a file even
though I haven't changed it:

1) Run a macro that does the following: opens a window,
executes a command that returns text, adds the executed
commands text to the window, saves the window to a file.

2) Click anywhere in the text area of the saved window.

Clicking in the text area should not require the file to be re-

Here's the version info:

NEdit 5.4RC1
Jul 16, 2003

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


  • Nobody/Anonymous

    Logged In: NO

    Can't reproduce the problem. Please submit an example macro
    that causes the problem.


  • Michael Sullivan

    Logged In: YES

    It took quite a while to get a simple macro that does this, and
    it's still intermittent. Here's the macro:

    vFilePath = "/tmp/test"
    vResult = shell_command( "ls", "" )
    focus_window( "last" )
    insert_string( vResult )
    set_cursor_pos( 0 )
    save_as( vFilePath )
    shell_command( "/usr/bin/rm -f \"" vFilePath "\"", "" )

    You may have to try this several times before the window
    requires a save -- I don't know why it's so hard to reproduce:

    1) Run the macro.
    2) Select a portion of the text that appears.
    3) Wait 5 seconds.
    4) Right click somewhere away from the hilited text and
    select the "Copy" contextual menu option.
    5) Close the window.

    About every third time I do this, the window pops up
    the "Save File" dialog box.

  • Eddy De Greef

    Eddy De Greef - 2003-08-06
    • labels: --> Program
    • milestone: --> 103146
  • Eddy De Greef

    Eddy De Greef - 2003-08-06

    Logged In: YES

    This is the clue:
    > shell_command( "/usr/bin/rm -f \"" vFilePath "\"", "" )

    You probably have turned off Preferences->Default
    Settings->Warnings->Files Modified Externally.
    NEdit notices that the file has been removed (it checks this
    when you focus the window, eg. by clicking) and normally
    warns you that the file has gone missing and asks whether
    you want to save it again.
    When the warning is turned off, though, you don't get
    notified, but NEdit still gives you a chance to save the
    missing file when you
    close the window.
    I don't know whether this qualifies as a bug. It is intended
    behaviour, but it can be confusing, I admit. The save dialog
    could be a little more verbose about the reason to save.
    The fact that the dialog only shows up when the window has
    been focussed is questionable too. Maybe we should also
    check for file modifications when the window is closed.

    What you really want, probably, is a kind of scratch window
    feature: a window that doesn't correspond to a physical file
    and whose content can be discarded without NEdit nagging
    about saving it. I miss such a feature too, and I know
    others do too.
    (I intend to add it for the next release.)

  • Eddy De Greef

    Eddy De Greef - 2003-08-06

    Logged In: YES

    On second thought, I think it qualifies as a (5.4) bug.
    When the external modification check is turned off, there
    should be no Save dialog for a missing file. A missing file
    is just an extreme case of an external modification, and
    when the user chooses to ignore external modifications,
    NEdit should shut up.

  • Michael Sullivan

    Logged In: YES

    I agree. I have the "Files Modified Externally" warning turned
    off and in 5.3 that used to be sufficient for the macro code
    I'm using to work the way I wanted it to work.

    I probably wouldn't use a scratch window feature because
    the macros I've written use the location of the saved file
    (even though it no longer exists) for subsequent macro calls.

  • Michael Sullivan

    Logged In: YES

    I've been thinking about your scratch window idea and I think
    I could make use of it. In fact, if there was a function called
    set_modified( [0|1] ), then the work would be done.

  • Eddy De Greef

    Eddy De Greef - 2003-08-13
    • status: open --> closed-fixed
  • Eddy De Greef

    Eddy De Greef - 2003-08-13

    Logged In: YES

    A fix is in CVS (BETA-5-4 branch). Same fix as for #784442.

  • Eddy De Greef

    Eddy De Greef - 2003-08-13
    • milestone: 103146 --> development
    • assigned_to: nobody --> edg

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