3

You may have seen Recommended way of scripting: Ex commands or vimscript functions?; I commented below it that

This is going to be a difficult fit for Vi and Vim: we prefer questions whose answers can be judged objectively and are not (solely) based on opinion. See https://vi.stackexchange.com/help/dont-ask. I would like to find a way to make this question answerable, but I don’t see it offhand.

I think this might be a case for a constructive subjective question (cf. real questions have answers, what a title…).

I'm having a hard time coming up with a good way to phrase the question so that answer's like Vivian's (and my comment "some APIs are function-only, including the ones that operate on arbitrary windows/buffers") would align into a nice canonical answer describing the relative strengths of both programming interfaces.

Please suggest ways to improve the question's fit or argue that it should be closed. My hope is that we can salvage the question and collectively edit it and an answer into a nice pearl.

3 Answers 3

Reset to default
3

Both the question and the answers could be improved by providing concrete examples and use cases.

I was misled by the word "recommended" in the title to think it was an opinion-based question (and I voted to close for this reason). Reading this question and re-reading the original one made me realize it's not bad because it's subjective. It's bad because it lacks context and applicability. (I stand by my judgment that it's a bad question, sorry)

"Would you recommend to drink Coke or beer?" sounds a lot like a subjective question until I tell you that I know a guy with diabetes who drinks a lot of beer but would not touch any soda. If you're going to drive home, on the other hand...

It's the context that turns it into an answerable question.

There's a lot of very good advice in the software world based on seemingly random statements. Like that a function should not have more than three lines (Clean Code by Robert C. Martin) or five lines (Five Lines of Code by Christian Clausen - disclaimer: I haven't read that one but based on the title, I'd guess it's about functions having five lines of code). Obviously, you can't apply both.

The question should be rephrased as: "in this very specific case is it recommended to use commands or functions?" That would mean it would lose (harmful) generality. Even if the question is not, it does not preclude the answers from doing so: "in this case I'd prefer a function over a command because ..." or the opposite.

Include code snippets from VIMRUNTIME. Do they use commands or functions? In what case? Why?

Search through the code of popular plugins. What do they do? If tpope writes commands over two screens long (I'm making this up), who am I to argue?

And don't forget to listen to your gut feeling. I recently wrote a command of seven lines and it made me feel uneasy. I wanted to use a function. I'm not very experienced writing Vimscript. Maybe the seasoned Vimmers can put a finger on it. Trust your developer instincts!

And don't forget there are objective differences between commands and functions. A good answer should elaborate on their implications and consequences. Functions have a conventional interface but are insanely hard to :call. For commands, it's quite the opposite. It's all about using the right tool for the job.

What is the job? We don't know because neither the question nor the answers tell us.

13
  • @Fredrich Perhaps you missed it, but the post mention the use-case. In the very beginning it is written: "When scripting..." which identify the case of writing scripts (not only configuring .virmc, plugins, interacting with the command line/command window etc). Examples are also present. A user further added a related question with interesting insights that applies to the general scripting use-case, and not only to the normal usage use-case.
    – Barzi2001
    Commented Jun 6 at 7:29
  • 1
    @Barzi2001 It was 11 at night and I ranted a bit... I probably missed a lot :-) 1) "When scripting" does not decrease generality. Vim usage is scripting. Except (maybe) when in insert mode. I understand you're talking about writing plugins. To me, this isn't obvious from your question. 2) Examples are present but they seem random and unrelated, furthering the impression that a one-size-fits-all answer is sought for. Tying them together might also improve.
    – Friedrich
    Commented Jun 6 at 7:50
  • No worries. I also wrote a complete answer instead of adding a comment due to some everyday-fatigue :D As always happens in sw engineering, issues arise from lack of rigor when defining stuff, in contrast with mathematics (which is my real background) where definitions leave zero room for misinterpretation. I am playing a bit the devil’s advocate here, but mathematically we are both right and wrong because we have no clear definition of script. When I am using the command-line, am I scripting? What about when I am writing plugin? Recommendations that apply when writing plugins (continue)
    – Barzi2001
    Commented Jun 6 at 8:03
  • (continue) shall also apply when writing .vimrc file? What about ftplugins and compilers? What about other corner cases that we are not considering right now? The best approximation I can think of is everytime you write a .vim file then you are scripting. But that would require a deeper thinking to check that such a definition is well-posed. For example, what is the difference between a plugin and a script?
    – Barzi2001
    Commented Jun 6 at 8:05
  • 1
    Some good points there. My interpretation of "scripting" is inconsequential, it's up to you to define it in your question.
    – Friedrich
    Commented Jun 6 at 8:32
  • With all the due respect, but in-spite I could provide my own interpretation, it would be a poor approach. Next person would give it another interpretation. Next, another interpretation. We would not solve the problem but we would only bounce it back and forth without. A better approach would be to find a common agreement on what we mean by “script” here. For vim specific case, I would vote for “every .vim file is a script” (note the verb “is” rather than “can be considered as”).
    – Barzi2001
    Commented Jun 6 at 9:14
  • You understood my criticism and even agreed to some degree yet you refuse to act on it. This is going nowhere.
    – Friedrich
    Commented Jun 6 at 10:58
  • With all the due respect: can you see my points? Apparently not. I try to rephrase in natural language: when a problem show up and it is well-defined, "swiping it under the carpet for now" is generally bad practice and absolutely wrong in mathematics, especially when it comes into definitions. But if someone dare write a bold statement claiming that "this is sw engineering and not mathematics" or "we don't have to be so formal" thus requiring the question to be changed, well fine.
    – Barzi2001
    Commented Jun 6 at 12:32
  • To answer your latter observation. I refuse to act for the same reason that I would refuse to act based on claims such that the earth is flat even if I agree to some degree that can be locally approximated as flat. That is, the main thesis is objectively wrong and your proposal is absolutely a bad suggestion. As said, a better approach is to define "scripts" now - we have a good chance - and refer to it for all posts from now on vi.stackexchange. We could also propose to specify it in the :help file in the same way are defined e.g. tabs, buffers and windows.
    – Barzi2001
    Commented Jun 6 at 12:54
  • Already done, see :help script.
    – Friedrich
    Commented Jun 7 at 6:04
  • Ok. I missed that update. Yet, there are no clear definitions there. Hence, the problem persists. Actually that page makes it even more confusing given that it sometimes refers to Vim scripts as files and sometimes it refers to Vim script as a language.
    – Barzi2001
    Commented Jun 7 at 9:27
  • 1
    @Barzi2001 Your idea that we should work here to define "scripting" is a recipe for failure of a question because this isn't a discussion forum where we can meander around until we can decide what question we're really asking. (I'm not doing that doing that isn't useful, I'm just saying that this isn't a good place to try to do that.) So you should try to define, as best you can, what you mean by "scripting" here and, if it becomes clear that you asked the wrong question, ask another question.
    – cjs
    Commented Jun 16 at 15:49
  • :s/doing that doing that/saying that doing that/
    – cjs
    Commented Jun 17 at 0:58
2

People reading questions on StackExchange sites tend to be a little quick off the mark in accusing questions of soliciting "opinion-based" answers, even when they are fairly clearly not. (I've been there before.) That said, this question could use a rewrite that would make it more clear that the author is not soliciting opinions.

The first step is to rephrase the title (and parts of the question) to ask about the advantages and disadvantages of using ex commands vs. Vimscript functions. This will not only make it more clear that the author is not asking for an opinion, but is trying to dig into what the differences are.

The second is to, as Friedrich says, provide a little more context about where and how these are being used. "While scripting" is pretty vague: in what context are these commands being run? Are they executed automatically as part of the user's startup files? Are they something you execute manually somehow?

The idea expressed in the OP's comments on Friedrich's answer that "while scripting" should be left ill-defined so that the answers can try to work it out isn't suitable for StackExchange; it's not that it's a bad thing to do, but that this is a QA site, not a discussion site. The correct approach on a QA site is to define your situation or intended situation as well as is necessary (and as you can) for decent answers, and ask another question if you find that the situation you were trying to describe doesn't match the situation in your original question.

0

I think that the question, as it is formulated, seeks for an objective answer. In-fact asking for recommendations implies the search of answers that are supported by objective evidence in first instance, which can degenerate in seeking for opinions when there is no objective evidence. This is in contrast when asking for suggestions, opinions, personal preferences, etc. A doctor recommending a specific treatment usually bases this advice on clinical studies, medical guidelines, and patient history. In contrast, a friend suggesting a restaurant may do so based on their personal taste rather than broad consensus or reviews.

The accepted answer could be improved with a bold statement like "There are none. In this case, it all boils down to personal preferences. eventually further explaining pros and cons of each approach.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .