http://invisible-island.net/personal/
Copyright © 2019 by Thomas E. Dickey
I have been developing computer programs for a while, and fairly recently (since the mid-1990s) have been making many of those freely available.
Enough said about that.
I got involved in the freely-available software initially by thinking that I would improve some of the tools that I would find useful at SPC—when development began again. That did not happen. Moving on to a different job, I had in mind the mismatch between ideas (which no one wants to pay for developing into products) versus existing products (which get funded).
Occasionally someone attempts to fit me into some ideology, but just ideas (and how they evolve into useful tools) is all that I will work with.
While ideas are important, it is only the way they interact (with other ideas and affect the resulting product) which matters. The observation is well-known. I have to-do lists with design notes, problem notes, wishlist notes. On writing this in May 2019, those amount to just under 30,000 lines, with more than 6500 different notes. Besides that, there are about 6000 files which give further information for those notes. All of that is outside the program sources. Reflecting on the amount of time I have spent, that actually does not sound like much. But the numbers keep increasing.
These tacit guidelines work well enough for developers who contribute to the projects I work on:
Not all developers choose to contribute (and not everyone is a developer). Either way, contributors are those who do the work.
Not everyone who interacts with my projects is a contributor. Some have a dose of ideology (some more than a little).
Some people prefer to be critics, rather than contribute.
Criticism may be constructive, or it may not be.
As I said in answering a question
short: it doesn't do that.
long: nothing like that is in the manual page.
There's no point in asking for a new feature, since it's not been touched for a while (see website). There is another website promoting itself as a "maintained ctags", but a quick read of its manual page shows little difference (none of what you're looking for).
If it's important, keep in mind that these projects are self-service: if you need a feature, you might get it faster if you do the work.
A while back (1995 perhaps, or early 1996), someone wanted a new feature for the less pager. Normally that scrolls up/down. They wanted to go left/right. As I recall it, their message ended something like “There are programs on other systems which do this. Come on, boys and girls, get with it.”
Or maybe that was “guys and gals” (none of the mail archives go back that far; memory only goes a short distance).
I responded that if they thought the developers were doing a poor job, they were welcome to try to maintain it. Others on the mailing list made excuses, saying that was not necessary. No one mentioned the actual developer who was doing the work; the excuses were made to appease the person who was criticizing.
Probably the developer read the mailing list, but the source-code shows no sign of that. In mid-August 1996, he added this feature:
ESC-) or RIGHTARROW
Scroll horizontally right N characters, default half the screen
width (see the -# option). If a number N is specified, it
becomes the default for future RIGHTARROW and LEFTARROW com‐
mands. While the text is scrolled, it acts as though the -S
option (chop lines) were in effect.
ESC-( or LEFTARROW
Scroll horizontally left N characters, default half the screen
width (see the -# option). If a number N is specified, it
becomes the default for future RIGHTARROW and LEFTARROW com‐
mands.
The
version.c file lists 108 “thanks”
for feedback and fixes, but no mention is seen for the left/right
scrolling feature which was added August 13, 1996.
The point is that if you are in a hurry, but don't understand how to do the work, it helps to be polite. Even though ideas (and problems to solve) are more abundant than the available time, someone might remember a suggestion.
The preceding was one type of antipattern for contributors. There are others.
For instance, rather than abuse the developers, one might choose to use softer tones, to persuade. I have encountered several of that sort. In some cases, there is no improvement.
A while back, when I was a graduate student, I used a PDP-10 to work on documentation. I was
assigned a
DECtape to store my files when I was away. On asking how to
get the tape mounted, I was told that I had only to send a
message to the operator, using the PLEASE command
(see page 602 of the
PDP-10 manual, which is 2-140 in the navigation tab). Given
the large manuals, and
large computer system, that seemed good advice. However, the
computer operators were also students. After a few repetitions of
PLEASE, one came out of the computer room, slammed
my tape down on the table and said
Electrical engineering graduate students are expected to mount their own tapes.
Point made: “please” has its place, but not to make demands.
On occasion, someone attempts to persuade a developer to make changes to a program, and rather than contributing to the development effort, makes demands. It is not rare; I have encountered this several times.
In one recent instance (within the usual reader's lifetime), a developer proposed some more friendly interaction than others from his group had done in the past. He sent a couple of fixes/improvements for a program which I maintain which was related to one to which he made occasional contributions. He also reported a few problems found by studying differences between the two programs. Some of that was useful, but I noticed shortly after that the developer (in bug reports and mailing lists)
Regarding the fixes: one was a single line of code, while the other copied a feature from a third program. The suggestions were more useful than the fixes.
The developer wanted new features in another program which I
develop. He offered no patches, saying that he was not a (fill in
program name)-developer. Rather than explaining
PLEASE to him, I updated my FAQ to explain where his
request fit into the overall scheme of things (i.e., not right
now because other ongoing things would have to be completed
first, etc.).
Of course, he could have contributed to the development effort (following the self-service model), but (see above) he was unwilling to do this as a “friendly” competitor. Instead, he treated it as a topic to mention in discussion with others, never mentioning the FAQ but stating that I had no intention of doing the work. Actually that is not what the FAQ said.
Because he ”requested” a program feature without being willing to participate, and chose to retaliate when I did not respond rapidly, that made the request a demand.
Self-service is a more productive model for development than expecting people to respond to “criticism” or “requests.” I have that in mind when I occasionally respond to other developers' feature requests and program improvements with