On 2/27/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > On 2/27/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > > You are right, completions should be configurable. But not by editiing > > the default completion files, since such changes will be overwritten > > on the next upgrade. But fish lets both the sysadmin and the user can > > configure completions by adding their own completion files to > > /etc/fish.d/completions and ~/.fish.d/completions respectively. Any > [...] > > Yeah, you're tight.
Thank you. Aside from that, I also think that I am right. ;-) > > > > (3) ultimately achieves the same, but you have to jump throught the > > > hoops before you can try your new Fish installation and re-customize > > > it. (Presumably, "make uninstall" also prints a warning message and > > > renames the files.) > > > > True, the first two are a bit less of a bother. The reason I opted not > > to use (1) was partly that the computer might get things wrong. If a > > sysadmin who has never used any older fish version decides that he > > wants to add some additional configuration options to fish, and > > decides to call the file fish_functions.fish, his changes should not > > get silently deleted. Not very likely scenario, but not a very nice > > one either. With (2) and (3) things will work the way they should. But > > forcing user interactivity in make seems like an ugly hack to me, so I > > opted for (3). > > That's funny, I thought interactivity was the bonus because it happens > in the context of the task. But (2) does not force interactivity, it > still allows you to do things non-interactively by first canceling the > install, while (3) both interrupts the process and forces > non-interactivity. >From my point of view, (2) is interactive, since it can't be reliably scripted; the install may hang forever while waiting for user input. (3) is non-interactive because if it is not given enough information on how to handle older fish versions currently installed, the installation will simply fail. But for the user installing from the commandline, I agree that (2) would actually be nicer. I opted for (3) because of the scripting issue, and because it seemed slightly easier to maintain long term. This is a piece of code that will need to hang around for a year or two, and it would be good if doesn't need any maintainance. > > [...] > > Yes, I moved on. I though most people had said their piece on this. > > Sorry, hopy you don't feel run over. > > Nah, All I can ever do is try to understand your reasoning and offer > my suggestions. I move in mysterious ways... :-) -- Axel ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
