Other file concept

[psprint]

The patch adds ability to quicky switch between C/C++ headers and sources. It is the concept of "other file" or "alternate file" known e.g.: in vim (​example plugin). The action is called OtherFile? and is bound to Alt-a by default. If the current file doesn't have any header/source alternate, nothing happens. The recognized extensions are: .c .cpp .h .hpp.

[andrew_b]

alt-a is already used.

Why {.c, .cpp, .h, .hpp}? Why not {.v, vh, sv}, {.pas, .inc} and something other? Why hardcoded? mc is a general purpose tool and it should not prefer some languages over others.

Apparently won't fix.

[psprint]

Fix sigsegv

[psprint]

My intention was to not go on closed for feedback till the very end.

The customization is needed – probably 2 options editor_otherfile_headers/…_sources – but overall the patch is worth merging, yes? From my experience it is a liberating extension, to finally not look in the fluctuating WindowList-action listbox for the corresponding header/source, and instead just press a shortcut.

I've checked all the places (mc.default.keymap & emacs, keybind-defaults.c) and I didn't find alt-a. For what it is used in your opinion?

[psprint]

Hoping that the feature will be merged I've revisited the patch, and:

• added two new options: editor_other_file_1_exts and editor_other_file_2_exts, which are comma separated lists of file name extensions of either the present file, or the other file,
• I've then extended the default extensions of C/C++ after ctags --list-map-extensions, which contained multiple new, valid extensions like .hxx or .cc,
• the matching is done case insensitively,
• I've also documented the feature in the man page mcedit.1,
• perceiving alt-a as an unused binding, after thorough search/verification of it, I've left it as the OtherFile? action's mapping, for a ↔ alternate file.

[psprint]

revisited

[andrew_b]

This is c/c++-only feature. The mceditor core code is not proper place for it.

[psprint]

That's a huge disappointment :( Please, at least try to use it and feel the liberation that it provides… When a boring but frequent situation occurs: "Oh, what was the field in the struct called again? OH NO, I have to go and open that !@#^$ header again…" It is very expected that when working on implementation, one very often needs to look at and have an easy access to the interface… Such switches ARE very OFTEN needed… This is a very common topic in editing, example Vim plugins ​1, ​2, ​3, ​4, ​5, ​6, ​7, etc. If Vim can, then why not MCEdit?

I've digged for an other programming languages that use paired files, and these are:

• Ada,
• Objective C,
• most assemblers,
• F#,
• Erlang,
• ASP.NET (.aspx <-> .aspx.cs / .aspx.vb),
• and probably multiple others.

Is there a chance for reopening ticket ? I can write changes for the patch if that will be needed.

[ossi]

of course this is a totally useful function ... for an IDE.

the first part of andrew's rationale for closing is objectively wrong, as you already generalized the patch. it still feels rather specific, though.

otoh, this is a bit hypocritical, as esp. the command menu contains some items that are undeniably "ide-like", if not even c-specific.

anyway, as is very clear from what andrew actually wrote, you need to pursue scripting again if you want such functionality. python was deemed unrealistic and slang did not meet much love so far, so maybe pick up mc^2 as suggested before. but whatever you choose, you need to actually show commitment before being allowed to import such an amount of code, and you really have done your best to prove the opposite so far.