On Thu, December 15, 2005 9:59 am, Philip Ganchev wrote: > On 12/12/05, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: >> On Mon, 2005-12-12 at 05:12 -0500, Philip Ganchev wrote: >> On startup, Fish evaluates /etc/fish, and then ~/.fish. I think this >> > means the user cannot customize some things like the Fish greeting, >> > and entails an initialization performance penalty. Isn't it better >> to >> > make Fish evaluate ~/.fish, and if and only if it doesn't exist, >> > evaluate /etc/fish? >> >> That would make it impossible to implement system-wide defaults. I >> think it makes a lot of sense to first do a system-wide setup, and >> then allow the user to override these defaults with his/her own >> settings. > > You're saying that customizing starting from a blank configuration is > less friendly, intuitive or error-proof than starting with a default > configuration, because usually the user would have to remember to > source the system script, since the defaults are sensible, and the > loss of configurability and the performance penalty are small.
The startup files aren't just configuration, fish won't work very well without them. emacs consists of a lisp interpreter and some screen handling code written in C and an editor written in Lisp. emacs is mostly written in Lisp, so the lisp parts aren't simply configuration files, they are the editor. Fish is mostly written in C, but the configuration files are several thousand lines of code, and not a neglectible part of the shell. I don't mean to imply fish is like emacs in general, though. Please don't hate fish just because you use vi. :) > >> As to performance penalties, the largest part of startup is used to >> read in the history. > > Couldn't new Fish sessions inherit the history as a universal variable > instead of reading it on startup? The first interactive process would > read it as a universal variable, and an exiting inter. process would > set it and write it to file, in the same way as an exiting process now > writes it. > > Or maybe the history can be read after the command line becomes > operational? If the history commands are used in the init script, it > can be read by the commands on-demand. > Yep. I'd like to do something clever with the history. Not sure what solution is the best, but something better should be possible. We'll see if I have the time. -- Axel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
