mcedit search/replace in selection: `s/^/foo/` unexpectedly replaces EOL of last line

[GfEW]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

GNU Midnight Commander 4.8.33-334-g9ec954aaf
Built with GLib 2.80.0 (using GLib 2.80.0)
Built with S-Lang 2.3.3 and terminfo database (using S-Lang 2.3.3)
With builtin editor
With subshell support as default
With support for background operations
With mouse support on xterm
With support for X11 events
With internationalization support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;

Operating system

Linux codespaces-08a020 6.8.0-1030-azure #35~22.04.1-Ubuntu SMP Mon May 26 18:08:30 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

Example text:

echo foo
echo "start selection at beginning of this line"
echo "extend selection moving strictly downwards (never left/right) across lines"
echo "this is the last line to be included in the selection"
echo "finish selection at beginning of this line"
echo bar

Search pattern:

^

Replacement pattern:

\t#

Options:

• Pattern type: Regular expression
• Case sensitive
• Backwards
• In selection
• Whole words
• All charsets

Expected behavior

Expected result:

echo foo
        # echo "start selection at beginning of this line"
        # echo "extend selection moving strictly downwards (never left/right) across lines"
        # echo "this is the last line to be included in the selection"
echo "finish selection at beginning of this line"
echo bar

I. e., all BOLs in the selected lines, and nothing else, should be replaced.

Actual behavior

Actual result:

echo foo
        # echo "start selection at beginning of this line"
        # echo "extend selection moving strictly downwards (never left/right) across lines"
        # echo "this is the last line to be included in the selection"   # 
echo "finish selection at beginning of this line"
echo bar

I. e., EOL in the last selected line is also replaced.

Additional context

This bug looks just as closely related to #4072 as #4743, #4744, #4745, but unlike the latter, it is still present.

[zyv]

I think the issue is that the selection includes a final newline. The result is almost correct, even if it's unexpected. I say "almost" because I wouldn't expect the newline to be "eaten." However, I think it's more of a problem in the replacement code than in the search code.

Sublime behaves similarly, only it doesn't eat the newline:

Like other GUI editors, Sublime has an indicator showing whether the selection includes the final newline. We don't have that feature. If you make sure your cursor stays on the last line, you can get the behavior you want in Sublime.

To me, if anything needs fixing, it's the eating of the final newline. I don't think we can do something like a selection without the last newline in mcedit. If we change the logic without making this possible, it will be confusing for those who want to work with the final newline.

[GfEW]

Sublime behaves similarly, only it doesn't eat the newline:

I'd actually consider that a bug, as well.
In a truely multiline selection (as opposed to e. g. NUL terminated where ^ or $ may denote the beginning or end of selection, resp.), the BOL anchor ^ is supposed to match the zero-width position at the beginning of each line, i. e. the beginning of any content that follows a line break or BOF.

Like other GUI editors, Sublime has an indicator showing whether the selection includes the final newline. We don't have that feature. If you make sure your cursor stays on the last line, you can get the behavior you want in Sublime.

If the selection ends at EOL (i. e. before the newline terminating that line), it doesn't span solely entire lines, so replacements like foo\n -> \nbar that work on entire lines may give unexpected results. (I don't have sublime at hand to test.)

To me, if anything needs fixing, it's the eating of the final newline. I don't think we can do something like a selection without the last newline in mcedit. If we change the logic without making this possible, it will be confusing for those who want to work with the final newline.

Consider a selection which spans an exact multiple of one entire line (i. e. each instance including its respective terminating newline) (*):
^ foo $ \n ^ foo $ \n ^ foo $ \n

Then the selection contains

• no content after the third line break, hence
• no fourth line, hence
• no fourth BOL, either.

Therefore, S/R in a multiline selection that spans no more than exactly three entire lines should never get four lines replaced.

More generally:

• A pattern that never matches more than a single line at a time, should treat all entire lines within the selection the same, regardless of their relative position (first/middle/last).
• In no case should "replace in selection" match a non-selected line.
• Replacing one entire line at a time should give the same result as replacing all lines at once.

Each of these principles is currently violated by the inconsistency addressed here (in both variants, mc and Sublime).

(*)

symbolic representation of matchable parts