Nano's Go-to-Line: the fastest way to land on the line your error message named

A compiler, test runner, or log entry just told you exactly where the problem is: line 173. The slowest possible response is opening the file and leaning on Page Down. GNU nano has a built-in Go-to-Line command that takes you straight to a numbered line, and it needs no plugins, no macros, and no changes to the file.

The problem Go-to-Line actually solves

Incremental search (Ctrl+W) is great when you know a word or symbol near the target. But many tools report locations as bare line numbers: gcc errors, pytest tracebacks, grep -n output, stack traces, lint reports. Searching for a keyword in a 5,000-line log can land you on the wrong match; a line number is unambiguous. Go-to-Line turns that number into a single action instead of a navigation session.

The keybindings, and why you should check yours

In most nano builds, Go-to-Line is Ctrl+_ (Ctrl+underscore, which on many keyboards means Ctrl+Shift+minus). Many builds also bind Alt+G to the same action. Which one works on your machine depends on the nano version, the distro build, and whether your terminal emulator passes the key combination through untouched — some terminals intercept Alt combinations or produce a different character for Ctrl+underscore.

Do not assume Ctrl+Y: in nano that is traditionally page-up, not Go-to-Line. The authoritative reference for your installation is nano's own help screen. Open nano and press Ctrl+G, then look for the "Go To Line" entry. That takes ten seconds and settles the question permanently for that machine.

A worked example with a large log

Say grep -n "ERROR" app.log reports a hit at line 173 of a 200-line file. The workflow:

1. Open the file with line numbers visible so the jump is verifiable: nano -l app.log (equivalently nano --linenumbers app.log). Run this in any terminal; no special permissions are needed beyond read access to the file.
2. Press Ctrl+_ (or Alt+G if your build uses it). A prompt appears at the bottom asking for a line number.
3. Type 173 and press Enter. The cursor lands on line 173, and because line numbers are displayed, you can confirm at a glance that you are on the logical line grep reported.
4. Use search (Ctrl+W) only for nearby context — for example, finding the next ERROR after that point — rather than as your primary navigation.

If you keep line numbers off by default, adding -c (--constantshow) keeps the cursor's line and column visible in the status area, which gives you the same verifiability without the gutter.

Trade-offs and gotchas

Line numbers count logical file lines. If soft wrapping is on, one long file line may occupy several display rows, but Go-to-Line still targets the file line — which is what your compiler or grep meant, so this is usually what you want. Just don't confuse wrapped display rows with line numbers when eyeballing the screen.

For very large files a direct jump is far faster than repeated Page Down, but extremely long individual lines (minified files, single-line JSON dumps) can still make rendering sluggish after you arrive. That is a display cost, not a navigation failure.

Finally, because bindings vary, avoid hard-coding one shortcut in team documentation. Document the feature and point people at Ctrl+G for their local binding.

Verify it in two minutes

Generate a quick test file and try the whole flow: seq 1 200 > /tmp/lines.txt then nano -l /tmp/lines.txt. Invoke Go-to-Line, enter 173, and confirm the cursor sits on the line numbered 173. If your first shortcut does nothing, try the alternate binding before concluding the feature is missing — and check whether your terminal is swallowing the keystroke. Once it works, you have a permanent answer to "the error is on line N": open, jump, fix.