On 02/03/12 18:40, Stephan Beal wrote:
>>> I'm for color-coded. All of the reasons have already been listed in the
>>> thread.
>>
>> Same here.
> 
> If not color coded, perhaps adding add/change/remove markers to the _start_
> of each line, since that would make JS-scripting the colorification
> relatively simple? (Loop over the lines, do a regex check on the start
> (change type + line number), and wrapping the affected line(s) in a styled
> span.)

   I wouldn't like that change very much. I think the way < and > are
used now is very intuitive, and it creates a nice separator column with
relevant meta data. I think it would be changing something which is more
intuitive to something less intuitive (for the human reader), just to
make it easier to regexp, which I don't really like.

   With that being said, it's just a personal preference, and not
something I'd put up a fight against.

   Though it occurs to me that if almost everyone will anyways be
sticking colorized diffs into their fossil repositories via javascript
hacks, then perhaps it should be able to output them without any
additions. :-/ When I started working on side-by-side diffs it was
suggested to me that it could be done using javascript instead, but I
thought to myself "If everyone is going to be pasting these javascripts
(or references to them) into every project they have, it's the sort of
feature fossil should handle itself.".

   How much work would it be to put together a proof-of-concept sbsdiff
colorizer? (I would do it myself, but I'm sorry to say my javascript-fu
is so weak that I wouldn't even be able to assist anyone wanting to take
on the project).

-- 
Kind regards,
Jan Danielsson

_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to