On Mon, Jul 22, 2013 at 12:21 PM, Arnel Legaspi <jalespr...@gmail.com>wrote:
> Would using something similar to Vim's mechanism (allowing Fossil to be > compiled with Lua/Ruby/MZScheme/Python/etc. support) be more acceptable? > If the core library has a sane interface, there's no reason we can't have ALL of those bindings - they just need to be implemented by someone. For example, as soon as fossil has a library API, i will certainly write a binding for it for my own personal scripting language (not because the world needs it, but because that's the type of thing i do in my free time), and being able to implement such bindings will be a point i focus on when designing any fossil library interface. > - use of Markdown formatting in tickets (unless, this is already possible?) > It might make sense long-term to combine the wiki/ticket editing features, or replace the wiki with the embedded docs system. There is no reason why we need separate editing systems (wiki vs tickets). Being able to attach a Content Type to a wiki page is on the todo list, so that people can flag their pages as being for a specific parser. > - +1 for full text search in tickets...and maybe embedded wiki files if > possible > It's more difficult than it sounds, unfortunately. My current thinking is that this would be best done via an add-on tool which normalizes the db structure into something we can search. > - support for kernel-style commit messages: > For example, you have a commit message like this: > > Capitalized, short summary line > > <Detailed explanatory text which can be long, preferably wrapped to around > 72 characters or less> > IMO fossil must not force arbitrary conventions like this onto the users. (To be clear: my opinion is not the one which ultimately counts!) (I tried altering the Timeline view CSS for this from a few threads back, > but it made the Timeline page graph ugly.) > Yes, it's difficult to modify the timeline view - it has grown into a truly complex beast over the years. When working on the JSON bits, the timeline part was certainly the most painful one to port. One of the goals of a new API would be to replace such monoliths with smaller parts. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
