Hello Axel! I am honored to hear from you. I must thank you for fish. It was (and still is) an inspiration for me, both in its technical design, and also its user-facing simplicity and elegance relative to its peers. After several iterations of learning and forgetting bash, I gave fish a try. I will never forget how its syntax highlighting and completions just worked. It felt like my first lungful of air after breathing water all my life.
fish was clearly onto something great, but I had an itch to scratch too: it was hard to use on slow NFS shares, because the syntax highlighting would do blocking I/O. In my naiveté, I set out to make the syntax highlighting multithreaded. I figured it would take a week at most. (Hah.) Anyways, I feel very flattered by your comments, and I hope my work can carry on your vision. Regarding the web site, I'm not involved with the fishshell.com site or its beta, and I don't know who is currently maintaining fish. I would be glad to work with the maintainers, or take over maintenance of the site and/or the repo if the current maintainer(s) want out. I'd like to try to speak to your comments: > I'd like the suggestions to by kind of subdued by default I'm glad you agree with the design decisions for autosuggestions. There is indeed a $fish_color_autosuggestion, which is by default #555 (a subdued gray). If you're not seeing it, it's probably because I neglected to bump the version __fish_init_1_23_0 in fish_config_interactive, so it won't apply the first-launch defaults for current fish users (oops). Or it may be because your term doesn't support term256 - I'll work on a solution for non-term256 users. > I would have either moved it to a separate process and communicated over a > socket or used cooperative threading, but I guess there is a chance that > simply means I'm very, very old. Or maybe wise. Combining threads with forks is very...delicate, and had I appreciated just how delicate it was, I might not have attempted it. It can be done safely and portably, and I claim to have done so, but it does require some contortions. > To make these changes, you must have a really good understanding of the code > base. Well done! Thank you, but the credit is yours, for designing a maintainable code base. > To whoever did it: Thanks for making the file descriptors close on exec using > fcntl instead of manually closing them. Fret not. For what it's worth, O_CLOEXEC only arrived on OS X last year. > On my machine, most key bindings seem to be broken. Thanks for the report. I filed https://github.com/ridiculousfish/fishfish/issues/24 to track this. > configure does not check if doxygen is installed, which means the build will > break kind of silently. This, I believe, is a bug you inherited from me! :-) I attempted to change the Makefile to allow building without doxygen, though you'll lose some man pages (since it relies on doxygen to generate man pages from the docs). > I'm not a big C++ fan, but I can see that basic_string and vector are much > nicer than what's possible to implement in straight C. I wouldn't > (and didn't) choose to use C++, but not really my choice to make anymore. > Use the language you like. I am neither a a C++ fan or a hater. The story is, I thought halloc was liable to cause problems in a multithreaded environment, and so I went looking for a new memory model. C++ seemed like a simple and readily available solution. I view C++ like drinking from a beer bong: a little is nice, but if you don't control yourself it's easy to swallow too much and wake up the following day with a protected abstract virtual base pure virtual private destructor in your bed. And nobody wants that. So my hope is to use C++ in a limited scope, and resist the urge for increased abstraction, templates, boost, etc. By the way, initially I viewed halloc with some fear and revulsion, not really understanding it. Later I learned to appreciate its cleverness. Was this your own idea, or did you learn the technique from somewhere else? > The old fish source code uses tabs for indentation Thanks for pointing this out. I confess to some sloppiness with mixing indentation and coding styles, and I ought to standardize. > All source files have been renamed .c => .cpp, but the .h files are still > named .h. I'm glad to know this. Sadly, it looks like there is no extension that will satisfy emacs by default. Please correct me if I'm wrong. > The repo at https://gitorious.org/~ridiculousfish/fish-shell/fishfish to be > significantly older than the tarball on the website. Is there an actual public > repo with the latest code available anywhere? If yes, sorry for the noise, if > no, I urge you to move to a more open development model. Making awesome > surprise release announcements is nice and seems to actually work pretty well > for Apple, but doesn't really gel with the open source model. fish development and maintenance seems to have been centralized at https://gitorious.org/fish-shell/, which reports all my changes. I did not announce anything (except to those who inquired directly) because I have a bad habit of getting excited, promising the moon, and then disappearing. I agree completely with using an open development model. > Why do bug tracking on github and repo tracking on gitorious? fish trunk is hosted on gitorious, and I wanted to stay close to that. But gitorious doesn't have an issue tracker (I sure wish it did). So the current dorky plan is to use gitorious for all development, and use github only for bug tracking. This, of course, sucks. How have issues been tracked in the past with gitorious? How do people feel about moving everything to github? > Point of interest. I never ever wrote fish to be fast - there are metric tons > of really obvious low hanging fruit, but I never saw the need because I never > had any performance problems with fish, even when using NFS on my 300 MHz > Pentium II with 256 MB of RAM. What parts of fish were running slowly and > needed > optimization? Other than the aforementioned syntax-highlighting-on-slow-NFS-shares issue, startup was where I noticed the largest performance issues, especially when my system was under load. After some tests, I concluded this was due to the sheer number of files touched: every command requires a check for an autoloading function, in multiple directories. My Core i5 may smoke your Pentium II, but my 5400 RPM hard disk sure won't! One idea I plan to try is to read the /functions/ directory entries up-front. I also suspect (but have not yet proven) that OS X has slower fork calls compared to Linux, and that this is especially bad in low-memory situations, which I encounter a lot. I plan to use posix_spawn() instead of fork() when possible, because posix_spawn requires less memory on some systems, and has some other nice benefits. I've not encountered any CPU performance issues. Axel, thank you again for your shell, and for your willingness to "pass the torch" as it were. It is a mystery to me why no other shell seems to place any importance on its UI, but I am sure glad you do. _fish (Incidentally, ridiculous_fish has been my online persona for about 15 years; it's a happy/confusing accident that I got involved with the fish shell.) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
