A new feature: periodic background command

[psprint]

Hi,
I heavily use tags and often hit a need of regenerating them. So I thought about a feature:

• create a dialog where user can enter a command to run and also: a time in seconds or a number of events,
• then create an idle hook basing on the hook API in MC,
• so the hook will be invoked basically after each keypress from frontend_dlg_run() which invokes the idle_hooks,
• it then counts the event (+1) and checks whether interval passed or that enough keys have been pressed,
• if yes, it then runs the command via g_spawn_async fully in background, unnoticeably,
• after the run it then starts measuring time and events again.

What do you think? It's a special feature, I didn't see such one in any editor before, but since it is so gracefully integrated and small codebase, maybe it is worth adding?

​asciicast

[ossi]

well, guess what? i hate it.

you built a context sensitive "cron" + manager.
there is no way anyone would ever need this for something else than exactly what you did, so this is another fake generalization.

this isn't even a particularly good solution for your problem, as you plain cannot rely on the tags being up-to-date when you need them, which is a major usability problem.

i would find it way more useful to have an explicit "update tags" command.
one could even automatically launch an update command whenever a file is saved.
mcedit has explicit integration with tags, so it wouldn't be outrageous to hardcode that as well.

you can also address this problem outside of mcedit by using a script based on inotifywatch to re-run ctags after files actually changed.

if you want to go completely overboard, you can turn mcedit into a much better IDE in a way that is possibly acceptable to the maintainers by implementing a language server protocol client. i mean, seriously, ctags is so '80s.

[psprint]

Replying to ossi:

well, guess what? i hate it.

you built a context sensitive "cron" + manager.

It can react to how much changes have been introduced.

there is no way anyone would ever need this for something else than exactly what you did, so this is another fake generalization.

Yes and no – an application can appear once the mechanism is there.

this isn't even a particularly good solution for your problem, as you plain cannot rely on the tags being up-to-date when you need them, which is a major usability problem.

This is a general ctags problem, not problem of the solution. The solution is the best that one can do for ctags – to trigger it according to the # of changes to the source.

Basing on the previous reactions I didn't expect anything positive to such an uncommon idea, and I haven't been disappointed.

[ossi]

Yes and no – an application can appear once the mechanism is there.

yes - hypothetically. but the historical track record of nobody ever asking for anything like that during my tenure here (well over a decade) suggests that it likely won't happen.

This is a general ctags problem, not problem of the solution. The solution is the best that one can do for ctags – to trigger it according to the # of changes to the source.

this is a general problem of anything that qualifies as a "code model" (that's the term used by qt creator; other IDEs have their own terms, but you certainly get the idea). modern IDEs just assume sufficient computing power and re-parse after every changed character (with some minimal event compression). but unless i missed something, the ctags integration is bound to the on-disk representation of the files, so using the saving of files as the synchronization point seems exactly right.

Basing on the previous reactions I didn't expect anything positive to such an uncommon idea, and I haven't been disappointed.

how mature of you to suggest that everyone here is an anti-innovation grinch, rather than accepting the possibility that your solutions simply aren't as great as you think they are.

[psprint]

Replying to ossi:

how mature of you to suggest that everyone here is an anti-innovation grinch, rather than accepting the possibility that your solutions simply aren't as great as you think they are.

But you are anti innovation, like most of maintainers, which can be examplified by e.g.: neovim like forks.

[ossi]

we are not anti-innovation, but anti-scope-creep, and anti-destabilization. it's perfectly possible to be highly innovative within that framework, as long as you accept that mc upstream isn't your personal playground.

[psprint]

What do you mean by 'anti-scope-creep'? I don't treat upstream as a playground, I'm submitting well coded patches.

[ossi]

What do you mean by 'anti-scope-creep'?

i mean that mc, like every other software, shouldn't try to solve every problem in the world. attempting to do that makes it less usable for the vast majority of the users, and makes it a maintenance nightmare on top.

I don't treat upstream as a playground, I'm submitting well coded patches.

it's not so much how you code things, but what you code, and related to that, what mindset you bring to the table. while actual code speaks a lot louder than even the best design on paper, it certainly does make sense to discuss your issues and ideas in advance with an open mind.

[andrew_b]

Replying to ossi:

i mean that mc, like every other software, shouldn't try to solve every problem in the world.

Exactly.