wrong default to mc instead of mc -e

[god12]

Right now mcedit is just a symlink which is equivalent to "mc -e"
However in many systems using /etc/alternatives/ the default "editor" binary is symlink to editor as well.
This leads to following symlink chain:
editor -> mcedit -> mc
If you call 'editor' it will trigger 'mc' which will check ARGV[0] to be != 'mcedit' and start default mc.
Expected behavior is to check ARGV[0] != 'mcedit' OR ARGV[0] != 'editor' to default to 'mc -e' in case it's called as 'editor' to match the user expectations.

[ossi]

one could argue that distributors should patch that, as alternatives are their system.

if mc is to be patched, then it should check for 'mc' rather than any variation of 'editor'. i suppose it's way less likely that mc is aliased under a generic name (sensible-twin-panel-manager? :D).

[god12]

Replying to ossi:

one could argue that distributors should patch that, as alternatives are their system.

Single trivial fix by mc devs seems easier than 5 different distro-specific workarounds :)

if mc is to be patched, then it should check for 'mc' rather than any variation of 'editor'. i suppose it's way less likely that mc is aliased under a generic name (sensible-twin-panel-manager? :D).

I like this approach too.

Either way it looks like an easy fix which is highly unlikely to break anything.

[andrew_b]

Replying to ossi:

one could argue that distributors should patch that, as alternatives are their system.

Agree.

[onlyjob]

Few thoughts about this one:

A) the proposed solution is safe. Moreover this is merely an improvement to existing workaround:

-    if (strncmp (base, "mce", 3) == 0 || strcmp (base, "vi") == 0)
+    if (strncmp (base, "mce", 3) == 0 || strcmp (base, "vi") == 0 || strcmp (base, "editor") == 0)

B) There is hardcoded 'vi' in the source code, which is not nearly as neutral and generic as 'editor'.

When 'vi' appears to inappropriate to be symlink to 'mcedit', 'editor' would be just right.

C) The workaround is just a little bit specific to distribution, but through Debian and its derivatives this forwarded patch represent an improvement for vast majority of GNU/Linux users. Why reject it then? Why did this bug was closed without clear justification or even discussion?

Please reconsider.

Thank you.

[gotar]

Wasn't EDITOR env variable designed for this purpose? I see entire /etc/alternatives idea a really bad one.

[onlyjob]

No need to resist supporting feature which majority of GNU/Linux users benefit from, merely because you don't like it. :)

For many reasons /etc/alternatives is powerful - for example, it reflect current availability of alternatives automatically when EDITOR becomes useless the moment you uninstall package providing whatever is hardcoded in EDITOR.

Also with 'update-alternatives' you can list (and choose from) what's available as alternatives not just for editor but also for many other system components like JVM or GLX providers etc.

Worth mentioning that when alternative is updated, change occurs immediately without logoff/logon or manual update of EDITOR variable.

Indeed long time ago EDITOR was designed for that purpose but now we have better tool to manage alternatives.

IMHO this improvement is harmless yet valuable.

[onlyjob]

It would be nice to know why 'wontfix'?? Could you explain please?

So far only benefits of this change were highlighted while no cons were expressed at all, apart from 'not like'. What harm would it be to fix?

Thanks.

[angel_il]

you feel free to reopen if you need :)

[onlyjob]

I'd love to but it might be considered rude if I reopen for the second time...
The change is really innocent but developers are reluctant to accept it for whatever reason...

[gotar]

Replying to onlyjob:

No need to resist supporting feature which majority of GNU/Linux users benefit from, merely because you don't like it. :)

I doubt that 'majority' of Linux users is GNU/Linux users.
I doubt that 'majority' of Linux users uses mc or text environment at all.

And those who do, can easily write mcedit.sh containing 'mc -e $@' and link to it.

But remember, every kosher GNU/freak should use emacs!

For many reasons /etc/alternatives is powerful - for example, it reflect current availability of alternatives automatically when EDITOR becomes useless the moment you uninstall package providing whatever is hardcoded in EDITOR.

Why would anyone uninstall main system EDITOR, which HE chosen on HIS own preference?

Also with 'update-alternatives' you can list (and choose from) what's available as alternatives not just for editor but also for many other system components like JVM or GLX providers etc.

Yeah, mostly unusable 'alternatives' are NOT alternatives. They are just system misconfiguration. Do you run nVidia driver on Intel-based graphics? Or maybe you have USB video card? There is currently no alternative to any JVM (there was IBM implementation a few years ago), Flash or anything that you might want to replace (no, really, give a break with not working GNU/prothesis). If you don't like nVidia binary driver and don't install it, there's no alternative (the question is, why did you buy this card), and if you do - noveau or nv are no alternatives. And please don't tell me you switch them frequently.

I see over 200 entries in /etc/alternatives on system that I (sadly) have. Not a single one is usable in real-world. None. Unless I'm GNU/freak and unrar-nonfree consider abomination.

Of course, one can choose krb5 over heimdal or giflib over libungif etc., however first kind is not switchable, and for second hardly anyone cares.

Worth mentioning that when alternative is updated, change occurs immediately without logoff/logon or manual update of EDITOR variable.

If alternatives are so powerfull, why they can't cope with mc -e?

Indeed long time ago EDITOR was designed for that purpose but now we have better tool to manage alternatives.

Especially on user-basis... Especially when any cmd line switch is required... Keep dreaming.

IMHO this improvement is harmless yet valuable.

This 'improvement' is distro-specific and as such should be kept in distro repo. That's the way we do it in PLD - just do not push upwards your personalization. Unless other mainstream tools comply and it is de-facto standard - is it?

[onlyjob]

Gotar, I'm sorry to say that you've chosen to argue instead of discussing pros and cons.

What's the point attacking my wording when I'm sure you understand that by "majority of GNU/Linux users" I meant majority of MC users on GNU/Linux??

Please think what do we loose if we implement the proposed patch
and what do we gain by not implementing it.

By the way you got the alternatives concept all wrong. :(

Negative thinking is not helping to improve MC because almost any improvement can be rejected
by exercising the very attitude you demonstrated.

Again let me remind that what you called "distro-specific" is valid for over 120 Debian derivatives while do not conflict with any others.

Please excuse me for noticing that some of your arguments are not regarding MC but criticism of alternatives in very narrow situation for single-user system when no habits or users or hardware is ever changing. This is when alternatives may not or may be useful. You're not trying to understand when it is may be useful. But you lack of effort to understand or your failure to see how it may be useful is blocking the improvement for those who would happily use it the way you've never imagined.

IMHO what we have is not technical problem but a decision-making one.

Regards,
Dmitry.

[god12]

Re-tested with 4.8.3 - the bug is still there.

[andrew_b]

Replying to god12:

Re-tested with 4.8.3

As you can see in these comments, there are not any fixes. Please don't put useless comments.

the bug

This is NOT a bug.

As ossi and gotar said, distro-specific stuff should be kept in distro repo.

Of cause, you can reopen this ticket again. But... Currently, we have ~400 open tickets. Yet another thicket will not change the entire picture.

[gotar]

Replying to onlyjob:

Gotar, I'm sorry to say that you've chosen to argue instead of discussing pros and cons.

There are no pros (assuming your distro has maintainers with patching skills).
Con: cluttering code by distro-specific stuff. What next? RH-related, or maybe some Asian translation of 'editor'? And some specific modes, banners?

What's the point attacking my wording when I'm sure you understand that by "majority of GNU/Linux users" I meant majority of MC users on GNU/Linux??

I do undestand. And do you undestand the difference? Like - percent of such users? Do you undestand what 'personalization' word means?

Please think what do we loose if we implement the proposed patch
and what do we gain by not implementing it.

We gain nothing. Please think what do YOU gain by improving your 'alternatives' mechanism.

By the way you got the alternatives concept all wrong. :(

Sorry, 15 years in Linux world learned me, that temporary hacks sometimes grow to 'brilliant concepts', instead applying proper solution. Do not force it outside, just fix it.

Negative thinking is not helping to improve MC because almost any improvement can be rejected
by exercising the very attitude you demonstrated.

Please go check my tickets.

Again let me remind that what you called "distro-specific" is valid for over 120 Debian derivatives while do not conflict with any others.

Still, it's not any standard or RFC at all. See the counter at the top? It prints '1'. I guess half of these derivatives doesn't even update mc package. Other half might as well use other keyword and then what? Or - maybe, some of them are smart enough to use existing standards, like XDG (xdg-open) or mailcap (isn't it Debian where run-mailcap was born?).

Please excuse me for noticing that some of your arguments are not regarding MC but criticism of alternatives in very narrow situation for single-user system when no habits or users or hardware is ever changing.

It's exactly ...opposite - there is a single system ADMINISTRATOR by definition (it might consist of multiple persons, if they agree on fundamentals) responsible for system-wide and hardware configuration. And alternatives is only system-wide configuration, enforcing regular user to use admin's favorite news reader. It does not support multi-user environments.

This is when alternatives may not or may be useful. You're not trying to understand when it is may be useful.

Have you seen similar solution in Windows, OS X, Android, other Unix maybe? As there already are file type handlers, mailcap, XDG. Do you really see a point in switching mawk to gawk on system configuration level?

You're bravely fighting problems not known in other systems. You can:

• try to standarize your solution (small chance, it's to dumb and useless),
• enhance alternatives to support applications,
• use shell 1-liner,
• send patch to proper distro maintainer.

You should not:

• try to make world adapt to your solution.

[onlyjob]

Hi Gotar,

I did not challenge your work - you and all other developers are doing a great job here and I'm sincerely grateful for your work.

However I do challenge your arguments and debating style. You repeatedly answering my non-questions and trying to discredit my arguments. If all what you're saying is true, how can you tolerate "temporary hack" for vi in the very line of code I suggested to change??
Proposed change is not against existing code.

If this is meant or worth to be a configurable parameter, as upstream you should not expect downstream customisations in code.

Perhaps you could consider accepting the proposed workaround as temporary solution, probably accompanied by comment to re-factor it later to configuration.

Also one may say more productively would be to consider making exception for most important and influential GNU/Linux distribution ever, especially if the workaround was forwarded more than once.

We're all want the same thing so there is no reason to waste any more time on this.
I found your arguments and examples not convincing and sometimes remotely related. But I do respect your decision so I'll rest the case here. It's not worth the effort trying to convince you that the world is not perfect and that even not perfect technical workarounds (like the proposed one) may be useful and safe until better solution will be available.

Regards,
Dmitry.