On Sat, Feb 4, 2012 at 10:36, Richard Hipp wrote:
> On Sat, Feb 4, 2012 at 10:24 AM, Leo Razoumov wrote:
>> Retro diff (2) looks really bad in Google Chrome-16 and in
>> Firefox-3.6.24, see attached chrome screen-shot (Ubuntu-10.04).
>
> Huh. On Ubuntu 11.10 running the latest Firefox sources (c
On Sat, Feb 4, 2012 at 10:36, Richard Hipp wrote:
>> > Here is an example, two different websites showing the same Fossil
>> > project
>> > (TCL), one with the traditional colorful diff and the other with the new
>> > retro diff:
>> >
>> > (1) http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
>> > (
On Sat, Feb 4, 2012 at 10:24 AM, Leo Razoumov wrote:
> On Sat, Feb 4, 2012 at 07:24, Richard Hipp wrote:
> > Here is an example, two different websites showing the same Fossil
> project
> > (TCL), one with the traditional colorful diff and the other with the new
> > retro diff:
> >
> > (1) ht
On Sat, Feb 4, 2012 at 07:24, Richard Hipp wrote:
> Here is an example, two different websites showing the same Fossil project
> (TCL), one with the traditional colorful diff and the other with the new
> retro diff:
>
> (1) http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1
> (2) http://mirror1.tcl.
o me. I can read the old-style unified diffs faster. In (2), on the
>>> other hand, I can clearly and immediately see that one line has changed.
>>> The change "pops" out at me. I don't have to think about it - it is just
>>> there.
>>>
>>>&
t have to think about it - it
>> is just there.
>>
>>
>>>
>>> - Altu
>>>
>>> > - Original Message -
>>> > From: Weber, Martin S
>>> > Sent: 02/03/12 11:03 PM
>>>
as changed. The
> change "pops" out at me. I don't have to think about it - it is just there.
>
>
> - Altu
>
> > - Original Message -----
> > From: Weber, Martin S
> > Sent: 02/03/12 11:03 PM
> > To: Fossil SCM user's discussion
> &
t;>
>> > ----- Original Message -
>> > From: Weber, Martin S
>> > Sent: 02/03/12 11:03 PM
>> > To: Fossil SCM user's discussion
>> > Subject: Re: [fossil-users] Retro side-by-side diffs
&g
On 02/04/12 11:08, altufa...@mail.com wrote:
> Same here. I like the colorful diff.
>
> But I would like to know (sorry if I missed) what's th eproblem with color
> sbs and what are we getting with retro sbs?
The reason is that we have two different places in the code which do
the same thing
gt; From: Weber, Martin S
> > Sent: 02/03/12 11:03 PM
> > To: Fossil SCM user's discussion
> > Subject: Re: [fossil-users] Retro side-by-side diffs
> >
> > On 2012-02-03 12:31 , "Remigiusz Modrzejewski"
> wrote:
> >
> >
scussion
> Subject: Re: [fossil-users] Retro side-by-side diffs
>
> On 2012-02-03 12:31 , "Remigiusz Modrzejewski" wrote:
>
> >I'm for color-coded. All of the reasons have already been listed in the
> >thread.
>
> Same here.
>
> -Martin
>
&
On Fri, Feb 03, 2012 at 08:33:41PM +0100, Stephan Beal wrote:
> How much work would it be to put together a proof-of-concept sbsdiff
> > colorizer?
>
>
> The new diffs can't reliably be colored using JS because of potential
> syntactic ambiguities. It would work "often" but not "always."
The s
On Fri, Feb 3, 2012 at 8:17 PM, Jan Danielsson
wrote:
> 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
>
i agree but having them in the middle makes it literally impossible to
reliably determine where/
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
> re
I'd be happy with Stephan's suggestion, since it would satisfy both parties
with a little work on the colorizing side. I think the only additional
point is to have the or whatever surrounds the code to have a good
descriptive class we can latch on to with JS.
Tomek
On Fri, Feb 3, 2012 at 12:40 P
On Fri, Feb 3, 2012 at 6:33 PM, Weber, Martin S wrote:
> On 2012-02-03 12:31 , "Remigiusz Modrzejewski" 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 e
On 2012-02-03 12:31 , "Remigiusz Modrzejewski" wrote:
>I'm for color-coded. All of the reasons have already been listed in the
>thread.
Same here.
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:808
On Feb 3, 2012, at 16:25 , Richard Hipp wrote:
> I find the "retro" side-by-side diff to be much more readable, which is why
> I am using it on the SQLite and Fossil websites, as well as on my desktop.
> And I've heard no complaints from users about the retro sbsdiffs on the
> website. But before
On Fri, Feb 3, 2012 at 11:56 AM, Andreas Kupries
wrote:
> On 2/3/2012 7:25 AM, Richard Hipp wrote:
>
>> For some time now, the SQLite and Fossil websites have been running on the
>> "retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
>> simplified format for the side-by-side
On 2/3/2012 7:25 AM, Richard Hipp wrote:
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors and
decoration and provides plain
On Fri, Feb 03, 2012 at 11:19:38AM -0500, Richard Hipp wrote:
> On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
> wrote:
>
> > - I haven't looked at the code lately, but does the web sbsdiff
> > support the width argument in some manner? For quite a few diffs I've
> > been looking at lately, sta
On 02/03/12 17:19, Richard Hipp wrote:
[---]
>> - I haven't looked at the code lately, but does the web sbsdiff
>> support the width argument in some manner? For quite a few diffs I've
>> been looking at lately, static 80 characters wide panes leaves a lot of
>> empty "wasted" space, due to short
On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson
wrote:
> - I haven't looked at the code lately, but does the web sbsdiff
> support the width argument in some manner? For quite a few diffs I've
> been looking at lately, static 80 characters wide panes leaves a lot of
> empty "wasted" space, due t
On 02/03/12 17:01, Tomek Kott wrote:
> My preference would be to keep the color SBS diffs, at least as a skin
> option or something, since I find it easier to notice changes and match
> them up. Maybe somewhere in the documentation on the header / skin, there
> could be css for a default coloring o
On Fri, Feb 3, 2012 at 8:25 AM, Richard Hipp wrote:
> For some time now, the SQLite and Fossil websites have been running on the
> "retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
> simplified format for the side-by-side diffs that omits all of the colors
> and decoration
My preference would be to keep the color SBS diffs, at least as a skin
option or something, since I find it easier to notice changes and match
them up. Maybe somewhere in the documentation on the header / skin, there
could be css for a default coloring of the sbs diffs that one could copy
into the
On 02/03/12 16:25, Richard Hipp wrote:
[---]
> Are there strong preferences one way or another?
There are two aspects I prefer with the original:
- I think color coding makes it easier to get a quick overview of
what's happened in a diff. ("I see a lot of red" is roughly
"optimizations", "I
On Fri, Feb 03, 2012 at 10:25:41AM -0500, Richard Hipp wrote:
> For some time now, the SQLite and Fossil websites have been running on the
> "retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
> simplified format for the side-by-side diffs that omits all of the colors
> and de
For some time now, the SQLite and Fossil websites have been running on the
"retro-sbsdiff" branch of Fossil. The retro-sbsdiff branch uses a vastly
simplified format for the side-by-side diffs that omits all of the colors
and decoration and provides plain-text output - essentially the same output
29 matches
Mail list logo
