bugGNU nano - Bugs: bug #67120, when position history has...

 
 

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

bug #67120: when position history has duplicate entries, cursor gets placed unexpectedly

Submitter:  Benno Schulenberg <bens>
Submitted:  Tue 13 May 2025 03:31:57 PM UTC
   
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Fri 13 Jun 2025 08:05:12 AM UTC, comment #4: 

Starting with nano-8.5, the position-history file has the most recent entry first.

Benno Schulenberg <bens>
Group administrator
Sat 17 May 2025 07:09:32 AM UTC, comment #3: 

Fixed in git, commit b37cc32d.

Benno Schulenberg <bens>
Group administrator
Thu 15 May 2025 10:48:50 AM UTC, comment #2: 

Attached is a patch that reverses the order of the position-history items, and thus the order in the filepos_history file.

(file #57225)

Benno Schulenberg <bens>
Group administrator
Wed 14 May 2025 09:19:41 AM UTC, comment #1: 

A duplicate entry can occur when first a nano that knows about anchor saving is used (and achors were saved), and then an older nano is used to edit the same file.  This older nano does not know about the anchor line numbers before the filename, so it does not recognize the filename and makes a new entry.  Then the file-position history contains two entries for the same file: one with anchors, and one without.

Benno Schulenberg <bens>
Group administrator
Tue 13 May 2025 03:31:57 PM UTC, original submission:  

To reproduce, edit your ~/.nano/filepos_history file and duplicate one of the last entries, and then give each entry a different cursor position.  For example:

/home/ben/Sources/NANO/NEWS 11 11
/home/ben/Sources/NANO/NEWS 44 44

Then repeatedly open and close the relevant file, and see how every time the cursor is at a different position.

The thing is: once there is a duplicate entry in the position history, and the user regularly edits that file, nano always first finds the oldest entry, and thus places the cursor not where it was in the previous session but in the one before that.  :/

The solution is to not store the newest entry at the end, but at the top.  (Or to start searching from the end -- but that would be awkward as we only have a pointer to the top item.)

Benno Schulenberg <bens>
Group administrator

 

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Submitted the item)
  •  

    There are 0 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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-06-13 bens Open/ClosedOpen Closed
    2025-05-17 bens StatusReady for test Fixed
    2025-05-15 bens StatusIn progress Ready for test
    2025-05-15 bens Attached File- Added 0001-history-reverse-the-order-in-the-file-positions-list.patch, #57225
    2025-05-14 bens Severity3 - Normal 2 - Minor
        StatusNone In progress

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code