Ticket #3044 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

mc.lib typo: linenog

Reported by: egmont Owned by: andrew_b
Priority: minor Milestone: 4.8.11
Component: mc-core Version: 4.8.9
Keywords: Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description

mc.lib has a typo. "less=%filename +%linenog" instead of "+%lineno"

(forwarded from https://mail.gnome.org/archives/mc-devel/2013-April/msg00001.html)

Change History

comment:1 Changed 4 years ago by egmont

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.

comment:2 Changed 4 years ago by andrew_b

See also #3058.

comment:3 Changed 3 years ago by andrew_b

  • Milestone changed from 4.8.10 to Future Releases

comment:4 Changed 3 years ago by slavazanko

  • Blocked By 3051 added

comment:5 Changed 3 years ago by andrew_b

  • Blocked By 3051 removed

comment:6 Changed 3 years ago by andrew_b

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

comment:7 Changed 3 years ago by egmont

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?

comment:8 Changed 3 years ago by andrew_b

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:9 Changed 3 years ago by andrew_b

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

comment:10 Changed 3 years ago by andrew_b

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

comment:11 Changed 3 years ago by andrew_b

  • Status changed from testing to closed

comment:12 follow-up: ↓ 13 Changed 3 years ago by egmont

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.

comment:13 in reply to: ↑ 12 Changed 3 years ago by andrew_b

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?

comment:14 follow-up: ↓ 15 Changed 3 years ago by 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?

comment:15 in reply to: ↑ 14 Changed 3 years ago by andrew_b

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.

comment:16 Changed 3 years ago by egmont

Okay, let's continue in #3117.

Note: See TracTickets for help on using tickets.