Arch Linux

done in -5.

What if the user wants different settings?

You can use XResources, can you not?

Besides, aren't you allowed to edit files in /etc? Just replace them with the values you want and on upgrade pacman will do its .pacnew thing.

A user isnt allowed to edit files in /etc no. If one user in the system wants to use autocutsel this way you're forcing everyone to use it.
And this is changing the default way of dealing with the X clipboard, so its rather important IMO.

A user may not do so. But an admin may install autocutsel. With doing so, he wants to archive something for his users. And as far as I understood, it is most likely that the entries made in the file in .xinitrc.d are the sanest defaults. If he does not like these defaults, it is better not to install autocutsel at all.

BTW, the user can have his own .xinitrc and redefine things there.

You are overcomplicating things for absolutely no reason and implementing this is plain wrong, VERY wrong.
The default should be X's default, not the autocutsel's custom configuration. & yes it should be the default even if autocutsel is installed.
It would be better to add documentation to the package if you think its lacking it, maybe a custom README file for users too lazy to consult the wiki.
This is overkill.

I do not get your point, if there is any.

I am not sure which would be right either way.

Greg's point is that you should not enable autocutsel in the X config just by
installing it. Some might call this 'The Arch Way', which I generally agree
with. Since I don't plan on installing autocutsel it would not bother me though.

If I was a user that wanted autocutsel I might be annoyed at having to perform
an extra step of enabling it in the config. There are some packages that irritate
me though because they do have things enabled by default which I don't think they
should, and it causes me extra work to remove that.

Its not about the Arch Way and philosophies. Its entirely practical. I've come up with an example where doing such a thing actually is useful, hoping you'll be able to understand why this is a bad idea. See the application lesspipe: http://www.archlinux.org/packages/community/i686/lesspipe
Instead of the user defining in his environment the LESSOPEN variable (breaking the Arch Way blah blah blah useless useless useless) ,
it does so globally by a script in etc/profile.d/ which reads:
"export LESSOPEN='|/usr/bin/lesspipe.sh %s'" thus forcing the use of lesspipe on all users on the system same as your autocutsel.sh.
There are two major differences between the two:
a) Unlike autocutsel, lesspipe doesnt take arguments. You either use it or you don't.
b) More importantly, it doesnt change the way less works. it just extends it. Autocutsel on the other hand changes the way a used by everyone feature works. It should be left up to the user to enable it should he wishes to. Not the other way around.

But, you are completely disregarding those people who find that 'extension'
of less annoying. This is really the same thing.

http://gicl.cs.drexel.edu/people/tjkopena/wiki/pmwiki.php?n=SWAT.LESSOPEN

OK,what about a) though?
In the lesspipe example LESSOPEN is an environment variable i can just unset and set as i please on my own user environment.
What happens if the user wants to change the autocutsel behaviour but has no rights to edit in /etc? And how do two running instances of autocutsel behave invoked with different arguments?

Could someone please provide an example where this being implemented would cause (a) headache(s)?

I don't know autocutsel but from what I read about this now, autocutsel should definitely not become a default or get a system wide config which can't be changed by the users.

I regularly use both standard X buffers and I need both. I need the Ctrl+C/Ctrl+V method as well as just pasting the selection with the middle mouse click. Btw., usually the clipboards of most DEs - at least the ones of KDE and Xfce - already let the user decide and configure how both buffers are handled, if they are synchronized or if they are separated.

So I don't think there's a need for such a tool like autocutsel and it definitely doesn't have to become a default, means a dependency. Users who want autocutsel can, of course, install it. But there shouldn't be any system wide config which forces the users to use it the way the admin wants them to use it.

And if this tool is poorly documented it should first be documented. What shall users do with a tool about which they don't know anything?

Okay, maybe the best compromise is to take the change back and write a short message in an install file. Done in -6.