To correctly show changed lines, Signify uses 'fossil diff --unified -c 0 -- %f'. However, the result is wrong as "-c 0" is just ignored.

If your intent is to show an infinite number of context lines, use a negative value. If that's now your intent, what is 0 supposed to do?

Zero currently has the meaning "use the default," and changing it might break things for people.

Thanks for the reply!

The intent is to show zero context lines, very simple.

I know that this would be suboptimal if the diff was used as a patch, however it is a perfectly valid request. Looking through fossil's changelog, I have seen a change like "make --context 0 work" a couple of years ago, so I am sure that it was supported at some point.

It's not clear to me why a value of 0 should be assigned the meaning "use the default" if 0 has a valid logical meaning. If it is really necessary to have an option with a value that has the same effect as if the option was not set at all (which does not need to be so since the absence of an option has informative value), then it might be better to use value -1 for that special purpose, and any other negative value meaning "infinite".

It's not clear to me why a value of 0 should be assigned the meaning "use the default" if 0 has a valid logical meaning.

That's a fair point, but i'd argue that 0 is not a valid context value for a diff. Technically, perhaps, but not for practical purposes. Diffs are largely for human consumption, and a diff without context is extremely difficult to read (as is a diff with too much context).

If it is really necessary to have an option with a value that has the same effect as if the option was not set at all (which does not need to be so since the absence of an option has informative value), then it might be better to use value -1 for that special purpose, and any other negative value meaning "infinite".

That's not wrong, but the fact is that changing the current semantics may disrupt other users and, so far, there's no compelling reason to permit diffs with 0 context lines. If you can present a compelling reason to change it, such that 0 actually means 0, we could certainly consider changing it.

FWIW, I also believe 0 has its use, as the other VCS show - I myself asked for such things earlier with hg.

I also don't think there are that many legacy scripts counting on the current behaviour, so I vote for it.

It seems that a spectrum of other VCS systems does allow 0 context lines, as per this list defined in vim-signify:

That's a pretty compelling argument :). This change is now on the short-term TODO-list.

@All: if there are any objections to a change in behavior for (diff -c 0), please voice them. The current behavior is that 0 uses the default value (hard-coded at 5). The new behavior would be to elide all context lines.

I, personally, like the logical consistency of giving the same numerical meaning to all non-negative values.

However, I doubt that anybody cares much who looks at diff outputs.

Also, as I read the allegedly compelling rationale, I was unimpressed by the argument, "Everybody else does it." I can still remember my father's stern voice when he told me, in no uncertain terms, that such justification was a poor and pathetic excuse, and why it was so poor.

That said, I support the change for a further reason: Why have a special value convention to say "take the default" for a parameter which, if left unspecified, takes a default? I can imagine this happening as an accident or quirk of coding, but I cannot fathom it as a well considered choice. (I intend no offense to whoever might have considered it so.)

Why have a special value convention to say "take the default" for a parameter which, if left unspecified, takes a default?

Indeed.

I can imagine this happening as an accident or quirk of coding, but I cannot fathom it as a well considered choice. (I intend no offense to whoever might have considered it so.)

IIRC, when adding support for negative values the question came up of how to handle zero and literal zero made (still makes!) little sense to me in the context of a diff, so it was simply treated as the default. We can chalk it up to a lack of imagination on my part.

@Daniel: thank you for the fix.

I mean this is no criticism. Saying "I cannot fathom" is what I call "a statement of ignorance".

Often, when considering details of how some user-facing feature is to work, I think about how complex it will be to describe and comprehend. This usually works to keep things as logically consistent as I can manage.

I mean this is no criticism.

Considered criticism is always welcome.

Saying "I cannot fathom" is what I call "a statement of ignorance".

Absolutely! i've no shortage of those ;).

Often, when considering details of how some user-facing feature is to work, I think about how complex it will be to describe and comprehend.

An excellent tip, thank you.

More than once, I’ve abandoned a commit on finding myself writing a novelette to describe it. :)

This is now changed on trunk.