Changed by egmont (@egmontkob) on Jul 16, 2013 at 17:42 UTC (comment 1)

By the way, I don't get this whole lineno feature...

First of all, for most applications it just doesn't work right now because they require the line number to precede the filename, with apparently 'vim' and 'mcedit' being the only exceptions (they accept both possible orders). E.g. 'emacs +10 /etc/services' opens that file at line 10, but 'emacs /etc/services +10' as currently invoked by mc simply ignores the line number. So mc.lib should look like

   blahblah=+%lineno %filename

Second, as mc has no way of knowing the previous or the desired offset, I believe this feature is only useful if I toggle between using external and internal editor (or viewer), so mc can open with the external utility at the position I left it using the internal one. Seems to be a very rare use case for me. Or I might miss something.

Joe (and probably others too) has a feature that it remembers the last offset on its own and opens the file there, unless overridden from command line. So, in case of 'joe', correctly passing the line number by mc would cause more harm than good, it would enforce mc's own belief of the desired line number, rather than the last one seen by a previous invocation of joe.

Seems to me that a bad design luckily doesn't work because it's implemented incorrectly :D

I might be wrong of course, and YMMV.

Changed by andrew_b (@aborodin) on Aug 18, 2013 at 10:42 UTC (comment 2)

See also #3058.

Changed by andrew_b (@aborodin) on Oct 8, 2013 at 10:19 UTC (comment 3)

• Milestone changed from 4.8.10 to Future Releases

Changed by slavazanko (@slavaz) on Oct 9, 2013 at 9:39 UTC

• Blocked by set to #3051

Changed by andrew_b (@aborodin) on Nov 25, 2013 at 9:50 UTC

• Blocked by #3051 deleted

Changed by andrew_b (@aborodin) on Nov 25, 2013 at 9:52 UTC (comment 6)

• Status changed from new to closed
• Milestone changed from Future Releases to 4.8.11
• Resolution set to fixed

Fixed: [49805a3].

Changed by egmont (@egmontkob) on Nov 28, 2013 at 8:28 UTC (comment 7)

As per comment 1, this is really not fixed. The line number after the filename doesn't work in most the apps. Even if it worked, the feature would have questionable usefulness, probably would cause more problem than advantage. Shall we reopen this one, or file a new bug?

Changed by andrew_b (@aborodin) on Nov 29, 2013 at 6:06 UTC (comment 8)

• Resolution fixed deleted
• Status changed from closed to reopened

Changed by andrew_b (@aborodin) on Nov 29, 2013 at 10:07 UTC (comment 9)

• Status changed from reopened to accepted
• Owner set to andrew_b

Changed by andrew_b (@aborodin) on Nov 29, 2013 at 10:09 UTC (comment 10)

• Resolution set to fixed
• Status changed from accepted to testing
• Branch state changed from no branch to merged
• Votes set to committed-master

Fixed: [4e6dc8c].

Changed by andrew_b (@aborodin) on Nov 29, 2013 at 10:09 UTC (comment 11)

• Status changed from testing to closed

Changed by egmont (@egmontkob) on Nov 30, 2013 at 11:11 UTC (comment 12)

Sorry, I still don't get it. You closed it a second time by addressing the easy parts and not the real issue. Repeating, for your convenience:

"as mc has no way of knowing the previous or the desired offset, I believe this feature is only useful if I toggle between using external and internal editor (or viewer), so mc can open with the external utility at the position I left it using the internal one. Seems to be a very rare use case for me. Or I might miss something.

Joe (and probably others too) has a feature that it remembers the last offset on its own and opens the file there, unless overridden from command line. So, in case of 'joe', correctly passing the line number by mc would cause more harm than good, it would enforce mc's own belief of the desired line number, rather than the last one seen by a previous invocation of joe."

I'm using the joe editor. With the old buggy order of command line parameters the conceptually faulty desired behavior of passing a line number luckily didn't work, hence joe opened the file where the cursor was recently (joe remembered this itself). With the new partial "fix" joe always opens the file at the first line, since a "+1" is always passed to it preceding the filename. mc has no way of knowing the desired line number, and it asks joe not to use the one joe itself remembered. Makes absolutely no sense to me, and I find it a significant usability regression from 4.8.10.

Could you please clarify what's the intended behavior, and how is mc supposed to know the desired line number that it passes to the applications?

I believe that for any editor that remembers the last cursor position for the files it opens (joe is one of these, I'm not sure about any other editors), %lineno should not be passed to the editor at all.

Changed by andrew_b (@aborodin) on Nov 30, 2013 at 13:03 UTC (comment 12.13)

Replying to egmont:

I believe that for any editor that remembers the last cursor position for the files it opens (joe is one of these, I'm not sure about any other editors), %lineno should not be passed to the editor at all.

What about #2206?

Changed by egmont (@egmontkob) on Nov 30, 2013 at 13:08 UTC (comment 14)

With that in mind, I believe the right solution would be to:

• Use mc.lib's entries (with lineno substitution) when opening the viewer/editor through the "word search in files (M-?)" feature
• Ignore that and simply launch the editor without special parameters when pressing F4 on the file.

What do you think?

Changed by andrew_b (@aborodin) on Dec 3, 2013 at 6:57 UTC (comment 14.15)

Replying to egmont:

With that in mind, I believe the right solution would be to:

• Use mc.lib's entries (with lineno substitution) when opening the viewer/editor through the "word search in files (M-?)" feature
• Ignore that and simply launch the editor without special parameters when pressing F4 on the file.

What do you think?

It sounds reasonably. But I think this is an issue for new ticket nevertheless.

Changed by egmont (@egmontkob) on Dec 3, 2013 at 11:06 UTC (comment 16)

Okay, let's continue in #3117.