On 03/30/2014 10:41 AM, Alexander Mezin wrote: > 2014-03-28 23:24 GMT+07:00 Tim Niemueller <tim@xxxxxxxxxxxxx>: >> In general, do you intend to extend the bash, or have something started >> with the bashrc/profile/your-shell-file-here? > The preferred way for me is "something from bashrc/etc." > However, I don't know how to change prompt dynamically when user > doesn't run any commands/press keys. I never meant to change prompt dynamically. But if that's somehow possible then it would definitely be nice to have. > > Maybe both ways could be implemented: patch/extension for shell, and > something that generates PS1 every time as fallback. > Though I don't think bash devs will be happy to accept such patch. > > Mikolaj, what do you think about it? I always thought of generating code and sending it to shell for execution. This way we could support basically any shell and it would be possible to go further and do things like setting variables or aliases depending on directory. (For example if I change to directory containing git repo, shell sets alias log='git log', if i go to subversion then it becomes 'svn log' and so on. Of course you could create a wrapper that would detect the repo type and run appropriate command, but the point is that generating shell code is more flexible.) > >> One typical complaint >> about stuff executed each time to form the prompt is that it can slow >> things down considerably. Here your libgit solution could help, but how >> would this scale to more plugins without a large performance penalty? >> Maybe some info about the architecture this would use could help here. > Actually, performance problems is what I personally want to solve in > this project. > Daemon loads only once, so loading a lot of plugins shouldn't be a problem. Performance is one of the major problems I was trying to solve too. The second problem: Traditionally shell prompt code is maintained by users themselves in their config files. But code to support git can become quite complex and annoying to maintain and extend. It's also impossible to share with other people. Creating a customizable daemon allows the same code to be shared in the community, while everyone can keep it customized to their own needs. > > I didn't try to think about architecture yet. Designing good > architecture is a part of the project, and I will start working on it > only after I will have everything working for git. > However, I don't think there will be something complex. > >> The daemon idea shounds sensible, talking via dbus? > D-bus isn't neccessary here. Socket should be sufficient. I think that D-bus is an overkill here. A simple IPC (like socket or FIFO) should be preferred. This would make it possible to port the project to systems that don't use D-bus (BSD?) > >> Still, how would this be integrated with the command line. > Actually, answer to this question is at beginning of the message. > >> And ahead of time: sounds like >> it could become a second tracker/beagle desaster caching tons of unused >> data being one more nuisance... > As I noted in my proposal, the only way I see here is trial-and-error. > But I am sure something will work. The amount of caching can always be adjusted. Memory constraints can be introduced, and so on. I don't see this as a problem. > >> I do think this is useful, there are just so many questions and details >> unclear currently. > It's boring when everything is clear from the beginning, isn't it? As it was mentioned somewhere before, design is part of the project, so not everything can be clear from the start. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk _______________________________________________ summer-coding mailing list summer-coding@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/summer-coding
