qeole / colorediffs Goto Github PK

Solution: add style "overflow:auto"

If there are no empty line between files in patch formatted letter, the
parser combine both files into one.

Hi Vadim, thanks for notifying me of the 0.4b1 version!

I notice an issue with the background colour in side-by-side diffs: the
text runs all the way to the bounding box, the background colour has a
margin; and when scrolling the text, the background colour is moving away.

See the two screenshots, hopefully clarifying what I mean.

it would be very useful to be able to show the diff with whitespace changes
ignored.

For example, if the diff involves a block of code being indented, the
entire block is shown as being removed and added, which makes it difficult
to spot any actual changes to the code in the block.

This is equivalent to diff -wB.

I'm not sure if this is outside the scope of what this extension is
intented to do, but I would find it extremely useful. :)

The language of code should be determined (probably by file extension) and
highlighted.

I'm using Thunderbird 2 beta 2 on Windows XP. I can't get it to work, it
seems. I've disabled other extensions that might interfer, I've tried with
both inline and attached diffs. It just never shows any colors :-(

Any clues, anything I can or should do?

Kind regards,
Rolf.

[deleted issue]

Sometimes it's not easy to scroll down till the next file or chunk.
Navigation buttons should help there.

When a commit message includes a line that starts with a dash (-), that
line is marked as red, like the removed lines.

Screenshot attached.

That said, I'm not sure if there's any way to tell that this is not a
removed line.

Big files can't be shown correctly in side-by-side mode. That probably
because number of div/span elements is limited.
Possible solution: if chunk is big optimize layout by making one div for
each added or deleted section

colorediffs does not color diffs in encoded messages, e.g. if messages are 
encoded as base64 and sent as multipart/alternative - see attached 
screenshot colorediffsfailed4encoded.jpg.

1. Receive forwarded diff with from SVN notification that is encoded as 
multipart/alternative by base 64 
or
2. Try to view colored diff , e.g. in default "unified" view and see that 
diff part of the message is not highlighted as expected (see screenshot)

Product version: colored_diffs-0.4.1-tb.xpi over Mozilla Thunderbird 
2.0.0.6 (20070728)
OS: MS Windows XP Proffesional SP2

Does not work for all my SVN notifications...
A sample message is attached as "FW_SVN_notification.eml"

Some times, the "Author" link is badly formatted.
See the attached file.

Config: thunderbird 2.0.0.6 (20070728) for Windows.

What steps will reproduce the problem?
1. Produce a diff containing a filename with a common extension as basename
(e.g. php.php or c.php)
2. The links for this file is trashed at the first recognized extension,
all following files are ignored

What is the expected output? What do you see instead?
Expected was just normal links; but I see trashed links with parts of HTML
exposed instead (Might be XSS-able???).

What version of the product are you using? On what operating system?
0.4.2

Please provide any additional information below.
GeSHi produces such diffs regularly as most files are named by languages
and thus incidentially equal some common extensions.

Context view is a little outdated and doesn't support selection between
only new, only old or both diff parts. It works great with deleted or added
files though.

It would be very nice if there was a toolbar option to change the number of
spaces to a tab used in the diff display.

It seems that Thunderbird doesn't provide any way to alter the number of
spaces to a tab in email text, but even if it did, I think it would be very
useful to be able to change it in the colordiffs extension independently.
(You might want to review an XML file using 2 space and and other file
using 4 for example).

It would be great if I could use this with TB3, thanks!

While Thunderbird gets the update from this server it could be hacked with
man-in-the-middle attack. Special key should make updates secure.

See http://developer.mozilla.org/en/docs/McCoy for additional information.

[deleted issue]

Context patches format isn't supported

I have one instance where the log message does not display in unified,
context, side-by-side view. The beginning of the output from the unified
view is shown below for the attached email:


Revision: 9942
          http://swig.svn.sourceforge.net/swig/?rev=9942&view=rev
Author:   gga73
Date:     2007-09-19 02:00:59 -0700 (Wed, 19 Sep 2007)

Log Message:
=======================================

Modified Paths:
=======================================

    trunk/Lib/typemaps/swigtype.swg


The plain view does display the log message. Great tool otherwise btw.

What steps will reproduce the problem?
1. "ColDiff 0.4.2" xpi installed on TB 2.0.0.6 on OS10.4.10,Intel platform
2. Navigate:  Tools>Add-ons;Extensions: Colored Diffs;Preferences
3.

What is the expected output? What do you see instead?
Expected preference pane with two tabs, each having several visible
options.  The pane itself is visible and a pictorial representation of what
the 'color' preferences would look like, but the 'options' (and tabs) are
not visible; only a blank area.

What version of the product are you using? On what operating system?
Version:  0.4.2
OS:  Apple 10.4.10
TB:  2.0.0.6

Please provide any additional information below.
Extension works fine on RHEL5 (kernel 2.6.18-8.1.14.e15) with TB 1.5.0.12
(20071018) and version CD0.4.2

I'm using Colored Diff 0.4.2 and the patch in the attached message is only
partly displayed making it look like the patch doesn't contain anything.
Viewed with the 'unified' option.

What steps will reproduce the problem?
1. this is a example email content:
Author: fooman
Date: 2008-10-14 13:02:41 -0700 (Tue, 14 Oct 2008)
New Revision: 376

Modified:
   trunk/src/assets/css/inbox.css
Log:
inbox.css tweak

Modified: trunk/src/assets/css/inbox.css
===================================================================
--- trunk/src/assets/css/inbox.css      2008-10-14 19:27:34 UTC (rev 375)
+++ trunk/src/assets/css/inbox.css      2008-10-14 20:02:41 UTC (rev 376)
@@ -12,10 +12,12 @@
     width:60%;
     float:left;
     margin-left:10px;
+color:#000;
 }

 .msg_body {
     overflow:hidden;
+color:#000;
 }

 .closelink {



What is the expected behavior? What do you see instead?
expected: line numbers show up when i click on the show/hide line numbers
button
actual: nothing happens when i click.

expected: diffs would be colored.
actual: no colors are showing.

What version of the product are you using? On what operating system?
Colored Diffs 0.4.2 on Linux thunderbird 2.0.0.16

Please provide any additional information below.
the installation went smooth, no errors.

Please also attach a broken mail as an eml file to this bug. It will really
help me to fix it faster.
done.
thanks :)

Since every time you are reading the diff you actually reviewing it, it is
essential to be able to mark pieces of code you'd like to be changed and
share those with code's author.
The idea is to make this possible in two ways
1. Send a letter to author with code excerpts and your thoughts about them.
2. Send your notes along with positions in code that it describes to a
secured server so that anyone who has exactly the same patch and this
extension installed could also view them right in the TB window.

When viewing a particular email message (will attach it) the first part of
the message contains some HTML garbage:

   <<a href='#'>a href='#'>Here comes a bug

with the first "a" hyperlinked. Instead it should just be:

   Here comes a bug

If I set 'diff format' to 'plain' using drop-down on toolbar (which I
assume effectively disables the plugin functionality), it displays fine.

Colored Diffs 0.4.2
Mozilla Thunderbird 2.0.0.18 (20081119)
Linux x86_64, Fedora 9

What steps will reproduce the problem?
1. Read any merge email on the bazaar mailing list
2. Note how the first hunk is never highlighted

What is the expected behavior? What do you see instead?

I'd expect the first hunk to be highlighted along with the rest of them.
This happens in all view types. Not sure if it's a problem with how bzr
send formats the email, or if it's a corner case not handled in the Colored
Diffs plugin's parsing. Either way, this seems like a good place to start
getting it resolved.

What version of the product are you using? On what operating system?

0.4.2. I've noticed this from both Linux and Vista. 

Please provide any additional information below.

If you are not on the bzr mailing list please let me know and I would be
happy to forward you an example email that can be used to reproduce this
problem.

Extension should check the code against set of predefines rules as lint
does. Would be great to have ability to create user defined rules also, may
be with some kind of xpath looking expressions (to search through a parsed
code tree).

If you're looking at very long piece of changed code there are no obvious
way to scroll horizontally because scrollbars aren't visible. Probably it
is possible to add special scrollbar for that.

That will make extension more robust when it deals with medium and large
size patches.

Often programmers write a bug number in log text, it should be converted
into the link to bug tracking system so bug description would be reachable
by single click.

[deleted issue]

Apparently in mails from google all tabs chars got converted into spaces.
That's wrong of course but anyway should be supported.

In the current realization of tabs handling they sometimes could be messed
up  a little, that means the code indentation could be different from what
is seen in the editor. Blindly replace them to the spaces is an option but
I think it is possible to handle them accurately without throwing them
away. That is especially important when visible white spaces are turned off.

Probably before any text manipulation tabs width should be calculated for
each of them and then at the end of the transformation chain they should be
translated into mix of tabs and spaces. Although padding might result being
broken.

That needs more thought be put into it.

Hi Vadim, me again :-)

I am following cvs commits through a news group (nntp, news.gmane.org,
gmane.comp.bug-tracking.mantis.cvs) but those messages are not coloured.

If I copy the message to my inbox, it is in colour.

Can you make it work for news (and perhaps rss) too?
Cheers :-)
Rolf.

What steps will reproduce the problem?
1. Just view svn commit on imap account.

What is the expected output? What do you see instead?
Expected - colorized and formatted diff, but I have just plain text value.

What version of the product are you using? On what operating system?
Thunderbird 3.0a1 or Thunderbird 2.0.0.6 on Ubuntu Linux.

Please provide any additional information below.
Everything works fine on POP3 accounts.

The suggested format is "old:old_name:old_line, new:new_name:new_line"

If a SVN commit message is longer then 1000K the script takes really long
to process the message.  It would be nice if there was a way to configure
it to ignore messages that are over a configurable size.

What steps will reproduce the problem?
1. Use example mail of Issue #35
2. Replace the Modified:-Block with the following lines:

---
Modified: trunk/docs/Doku.odt
===================================================================
(Binary files differ)

---

What is the expected output? What do you see instead?
The Mail isn't detected as changelog at all ALTHOUGH this block is standard
(verbatim) output of svnlook and thus should be "treated" as "compatible".

What version of the product are you using? On what operating system?
0.4.2 on Win2K with TB 2.0.0.9

Please provide any additional information below.
cf. #35 for a basic mail to adapt for this issue as given above.

Extension should highlight actual difference between similar lines

And while reporting the other issue, I also noticed that the horizontal
scrollbars for the code changes are nicely linked, but the ones for the
filename box are not. Would be good to link those two, I think?

See screenshot.

Currently it does not install into my browser (Iceweasel 2.0.0.14).  

I would be happy to see colors in diff-attachments from a mailing list archive:
http://www.winehq.org/pipermail/wine-patches/attachments/20080313/9d7f1eac/attac
hment.txt

or diffs inlined into the messages directly:
http://www.winehq.org/pipermail/wine-patches/2008-March/051474.html

What approximate amount of work is needed to make this happen?  After some
training at JScript (or JavaScript?) I probably would be able to contribute
some code.

What steps will reproduce the problem?
1. A mail that contains non-diff text after the changes\diff

What is the expected output? What do you see instead?
Someone would expect such text to simply be written to the output window.
Instead whole paragraphes are hidden.

What version of the product are you using? On what operating system?
0.4.2 (just updated) on Win2K with TB 2.0.0.9

Please provide any additional information below.
Have a look at the example mail attached. The last two paragraphes between
the end of the Changelog and the contact section are missing in the output

Further Info: This bug sometimes leeds to inconsistencies that makes
Enigmail fail to validate signed mails.

Diffs with HTML in them will have Thunderbird interpret the HTML, not show
plain text.

(This may be a security issue.)

Thunderbird tend to convert anything link looking into actual link, but
extension break that ability. And however link are useless inside the
actual code, they might be useful in message log section and precode
section and should be restored.

Often people complain about wrong coloring of some of the diff files. The
best way to me to fix this would be to have the same file on my machine but
some of the code is closed and couldn't be forwarded.
As a suggestion there might be a button which will create a mail to me
replacing all the letter in the original one to 'x'. It is important to
just create it without sending right away so user might check that nothing
secret going to be sent.

What steps will reproduce the problem?
1. I receive git diffs
2. I open email
3. I see this header in united mode:

<<<a href='#'>a href='#'>a href='#'>The branch, master has been updated
       via  63b14eab24531428c4f46279bf086b50cb926881 (commit)
      from  304faa709ea3d126ca7df79663a22be69bbf5257 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.


What is the expected behavior? What do you see instead?

The branch, master has been updated
       via  63b14eab24531428c4f46279bf086b50cb926881 (commit)
      from  304faa709ea3d126ca7df79663a22be69bbf5257 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.


What version of the product are you using? On what operating system?

0.4.2

Please provide any additional information below.


Please also attach a broken mail as an eml file to this bug. It will really
help me to fix it faster.

What steps will reproduce the problem?
1. Take working (unified diff) mail with blank, unchanged line as first one
of a context
2. Sign this mail with GnuPG (Enigmail) --> Lines get trimmed
3. Send to someone and view the result

What is the expected output? What do you see instead?
The parser should try to reconstruct that this blank line is a valid
(unchanged) line of the context and thus should ignore it not having a
space as first char. The actual (current) behaviour is a rewrite of the
context boundaries containing 0 lines if the trimmed line was first.

What version of the product are you using? On what operating system?
0.4.2 on Win2K with TB 2.0.0.9

Please provide any additional information below.
Maybe the parser should try to ignore minor errors on non-armorred
characters like spaces to improve interoperatibility with security tools
like GnuPG\Enigmail.

If the person send you and email with patch placed inside it extension
would detect the whole email as patch and would try to color it. But since
it doesn't have appropriate formatting (tabs would be missed, that's for
sure) it fails to do that and some of the code disappears. While it's
really really hard to color that patches correctly, it's relatively easy to
detect them and switch extension off.

Right now when you're changing any of the prefs, mail is re-parsed again.
It's not really necessary, it could be just re-transformed and re-converted
to HTML. Even all the transformation shouldn't be run actually.

Solutions:
  1. Cut filenames by path delimiters to make them smaller
  2. Add a option to show line numbers at the beginning of line.