#550 No spaces in paths for "Open Selected"

release
open-accepted
nobody
Program (402)
5
2006-09-25
2006-09-25
Tony Balinski
No

If you try to use "File>Open Selected" for a selection
containing spaces, NEdit attempts to find a file using
a path built from all the non-space substrings of the
selection. This assumes that you never have spaces in a
valid path. The assumption is wrong, especially when
running NEdit under Windows/Cygwin or on a non-Windows
(*nix) server which is used as a Windows file server.

Attached is a patch that changes this behaviour by:
- stripping leading/trailing spaces
- stripping seleced newlines

I believe this patch provides better support in these
cases, without compromising the current codebase.

Discussion

  • Tony Balinski
    Tony Balinski
    2006-09-25

    Open Selected allows spaces in path

     
  • TK Soh
    TK Soh
    2006-09-25

    Logged In: YES
    user_id=411637

    > - stripping leading/trailing spaces
    > - stripping seleced newlines

    What about spaces within the filename?

     
  • Thorsten Haude
    Thorsten Haude
    2006-09-25

    • labels: --> Program
    • milestone: --> release
    • status: open --> open-accepted
     
  • Thorsten Haude
    Thorsten Haude
    2006-09-25

    Logged In: YES
    user_id=119143

    I use spaces all the time for a certain set of files, so
    this is not restricted to Windows.

    However, stripping \n and leading/trailing \s does also
    break the convention (everything but \0 and /). The first
    may improve usabilty, but I think that only trailing \n
    should be stripped. I don't see a case where stripping an
    inner \n might be useful.

    (In fact I think that the code should simply open whatever
    it's told to open and all modifications should happen in
    file_name_hook().)

     
  • Tony Balinski
    Tony Balinski
    2006-09-25

    Logged In: YES
    user_id=618141

    Thorsten: actually, I'd be happy with keeping all selected
    whitespace (although practically I never want to see
    newlines in a valid file path, nor leading/trailing spaces).
    My patch is a compromise measure.

    TK: Sorry I wasn't precise enough - the spaces are removed
    from the string copy of the selection, before an attempt to
    open the file specified by the selection (file (path and)
    name) is attempted, following removal of any C-style
    #include stuff. The current code just collapses all spaces.