bugGNU nano - Bugs: bug #34898, [Wish] jump to existing buffer...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #34898: [Wish] jump to existing buffer when opening an already-open file

Submitter:  Kelsey Hightower <kelseyhightower>
Submitted:  Fri 25 Nov 2011 04:49:47 PM UTC
Votes: 100
 
Severity:  1 - Wish Status:  None
Assigned to:  None Open/Closed:  Closed

Mon 28 Nov 2022 08:40:26 AM UTC, comment #4: 

The original request was about avoiding to open the same file in two separate buffers and instead jump to the existing buffer when the user attempts to open an already-open file again.  Wishing to have multiple viewports open on the same file (and in the same nano) is an entirely different request.  It also has nothing to do with file locking -- that was just a suggestion to help the user to avoid opening the same file twice.  How file locking behaves is not the subject of this issue.  Closing this as too polluted.

 Benno Schulenberg <bens>
Group administrator
Wed 23 Nov 2022 04:44:00 PM UTC, comment #3: 

My preferred outcome would be, if the file is already open elsewhere, to provide an option to open the file in view mode (like with the -v switch).

Combined with this, if there was a way for a file to be 'refreshed' during viewing mode (or even better, refreshed live rather than on demand), this would make it ideal for having a file open in two places for viewing, and editing elsewhere with changes reflected in the views.

PS. Currently 'refresh' only refreshes the screen. Not file contents. It is relatively trivial to write a macro that refreshes the file (i.e. a macro that opens in new tab, exits previous tab), but in view mode it is not possible to grab the name of the file (because writeout is disabled), so the filename will have to be hardcoded into the keystroke binding. Also, in theory there's no guarantee of 'refreshing' at the same line, though in practice, for some reason I don't understand, this seems to actually work if exiting and relaunching in view mode from the same terminal :)

 Tasos Papastylianou <tpapastylianou>
Sun 26 Dec 2021 09:22:30 PM UTC, comment #2: 

The goal the user has in mind when they are using multibuffer mode and try to open a file is to view (and possibly edit) that file's contents. For that reason, a "nothing happens" outcome from the "File xx is being edited; open anyway?" prompt is the least useful outcome.

So with that in mind, IMHO that prompt and its behaviour should be:

"File xx is already being edited; open in a new buffer?"
Yes -> Open the file in a new buffer.
No -> Switch to the existing buffer for that file, if at all possible (i.e. when it's the current nano process that has locked the file).
Cancel -> Nothing happens.

Rather than the current:

"File xx is being edited; open anyway?"
Yes -> Open the file in a new buffer.
No -> Nothing happens.
Cancel -> Nothing happens.

Duncan Holm <holmdunc>
Sat 14 Jun 2014 04:19:10 PM UTC, comment #1: 

With the new locking code, trying to open (into a new buffer) a file that nano already has opened, now results in the statusbar message "File being edited (...) continue?"  So you will not accidentally have the same file opened twice.

But I don't like the behaviour when answering No or Cancel: it opens an empty buffer, instead of renouncing the whole opening action entirely.

 Benno Schulenberg <bens>
Group administrator
Fri 25 Nov 2011 04:49:47 PM UTC, original submission:  

When using multiple buffers, nano creates a new buffer for each file that I open, even if that file is already open in an existing buffer.

This does not seem like a bug, but more of a usability issue. Many text editors check to see if a file is already "opened" in an existing buffer, if so instead of opening the requested file in a new buffer, switch to the existing one.


nano --version
 GNU nano version 2.2.3 (compiled 10:55:27, Nov 22 2011)
 (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
 2008, 2009 Free Software Foundation, Inc.
 Email: -email is unavailable- Web: http://www.nano-editor.org/
 Compiled options: --disable-wrapping-as-root --enable-color --enable-extra --enable-multibuffer --enable-nanorc --enable-utf8

 Kelsey Hightower <kelseyhightower>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tpapastylianou (Posted a comment)
  • -email is unavailable- added by holmdunc (Posted a comment)
  • -email is unavailable- added by holmdunc (Voted in favor of this item)
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by kelseyhightower (Submitted the item)

    •  

    There are 100 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-11-28 bens Open/ClosedOpen Closed
    2022-03-14 bens Summary[Request] reuse existing buffers when adding files [Wish] jump to existing buffer when opening an already-open file
    2021-12-26 holmdunc Carbon-Copy- Added holmdunc
    2018-02-18 bens Severity3 - Normal 1 - Wish
    2014-06-14 bens Summary[Feature Request] Reuse existing buffers when adding files [Request] reuse existing buffers when adding files

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code