jdiff-devel Mailing List for JDiff - HTML report of API differences
Brought to you by:
mdoar
Menu
▾
▴
jdiff-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
|---|
|
From: mike d. <md...@st...> - 2000-10-11 15:15:20
|
On Wed, 11 Oct 2000, Daniel Lemire wrote:
> What I am really looking for is replacement for the "diff" command line tool.
> Just like diff isn't bundled with a text editor... I don't see why jDiff
> should necessarily be.
one of the first things i did after finding the underlying diff code that's
behind the scenes in jDiff was to create a simple command line diff. it only
dumped in the default diff(1) format ('>', '<', etc. no unified output), but it
was useful in getting an idea of what i could do with this diff implementation.
unfortunately, that code is long gone, but IIRC, it wasn't too hard to put
together.
-md
|
|
From: mike d. <md...@st...> - 2000-10-11 15:08:03
|
On Wed, 11 Oct 2000, Slava Pestov wrote: > Why can't it be both an app and a plugin? Doing this is not terribly hard, > and can be done with one code base. i don't think that was the issue. more that very little application framework code has been written yet, whereas much of the code for actually creating and displaying diffs is already done. i think it was a matter of where to put limited development effort. -md |
|
From: Daniel L. <Dan...@Vi...> - 2000-10-11 12:13:22
|
Good day, I tend to agree with Slava here. Building everything into one monolitic (à la Emacs) tool is fine. I like jEdit a lot and I use it everyday. I might enjoy it very much if there was a jDiff plug-in. But at the same time, with all the plug-ins I've got running under jEdit, it is becoming a crowded place so I'd probably enjoy using jDiff both as a plug-in and as a separate app. Well, in any case, I'm using jDiff as a separate tool right now and it works! Now that it was hacked it so it doesn't have to be used as a command line tool and we can actually use file dialogs, I find it very useful. What I am really looking for is replacement for the "diff" command line tool. Just like diff isn't bundled with a text editor... I don't see why jDiff should necessarily be. > (Mike -- is this dude subscribed to jdiff-devel?) > > mike dillon wrote: > > i believe the latest concensus was that jDiff as a separate application should > > cease to exist and instead should continue on only as a jEdit plugin. for those > > who would have liked to see jDiff move toward being more of a visual diff _and_ > > merge tool, this is not too satisfying. being that i am more than happy with > > command line diff and patch, this didn't bother me personally, but i was kind > > of saddened by the curtailing of potential usefulness. > > Why can't it be both an app and a plugin? Doing this is not terribly hard, > and can be done with one code base. > > Slava > -- > > jDiff-devel mailing list > jDi...@li... > http://lists.sourceforge.net/mailman/listinfo/jdiff-devel -- Daniel Lemire http://www.ondelette.com/ ICQ: 8733252 |
|
From: Slava P. <sp...@gj...> - 2000-10-11 11:09:51
|
(Mike -- is this dude subscribed to jdiff-devel?) mike dillon wrote: > i believe the latest concensus was that jDiff as a separate application should > cease to exist and instead should continue on only as a jEdit plugin. for those > who would have liked to see jDiff move toward being more of a visual diff _and_ > merge tool, this is not too satisfying. being that i am more than happy with > command line diff and patch, this didn't bother me personally, but i was kind > of saddened by the curtailing of potential usefulness. Why can't it be both an app and a plugin? Doing this is not terribly hard, and can be done with one code base. Slava |
|
From: mike d. <md...@st...> - 2000-10-10 16:10:58
|
ditto. -md ---------- Forwarded message ---------- Date: Tue, 10 Oct 2000 08:56:05 -0700 (PDT) From: mike dillon <md...@gj...> To: Victor Volle <v....@co...> Subject: Re: JDiff On Mon, 9 Oct 2000, Victor Volle wrote: > Hi! hi! indeed! > The only thing I miss from jEdit is a diff-mode/tool. You have been > developing JDiff, but AFAIK you have stopped any further development. this is true. i have posted a number of messages to both the jDiff mailing lists and to the jEdit mailing lists seeking advice as to how to proceed, but no one has been more than passively interested. until now. i believe the latest concensus was that jDiff as a separate application should cease to exist and instead should continue on only as a jEdit plugin. for those who would have liked to see jDiff move toward being more of a visual diff _and_ merge tool, this is not too satisfying. being that i am more than happy with command line diff and patch, this didn't bother me personally, but i was kind of saddened by the curtailing of potential usefulness. > I am interested in stepping in if you don't mind, but need to further > evaluate the code of jEdit, since I would like to use much of its codebase. > Therefore I do not want to commit myself, yet. great! and it's fine that you aren't sure. take your time to make a proper decision and don't get sucked in. the main reason why my motivation to work on this project sputtered was that i have never really had any need for jDiff myself. i haven't used WinDiff or anything like it in actual work. using jEdit as a code base is a good idea, since it has a lot of solid code. also, as it says in the jDiff CREDITS file, and in the derived sources themselves, much of the jdiff.gui package is based on the excellent text area Slava wrote for jEdit 2.0. in addition to that, i myself am probably the second-most familiar with the jEdit source of anyone in the world (except maybe Andre Kaplan), so i should be able to provide you with worthwhile and insightful feedback to comparisons or design issues that arise. (and, Slava is both on the jDiff project and on the mailing lists, so he can discuss as well) > But before I explore any further: Is anybody else doing something in this > area? I am not "pressed" doing it myself. It is just a feature I really would > like to see implemented. Andre Kaplan took a rather early version of the jDiff code and turned it into a usable jEdit plugin, which i is still available from his development page at http://jedit.sourceforge.net/devel/people/akaplan/. that plugin has not been updated in quite a while. i don't know whether it will work with a current version of jEdit. it was never on Plugin Central. Daniel Lemire recently committed some small changes to the jDiff code to allow files to be chosen and compared from within jDiff, but i don't think he has any interest in doing further development. i'll close for now, but i urge you to at least join the jDiff-devel mailing list so that we can discuss in public. i look forward from hearing back from you. -md p.s. woo hoo! |
|
From: mike d. <md...@gj...> - 2000-10-10 16:10:28
|
making the private public. -md ---------- Forwarded message ---------- Date: Mon, 09 Oct 2000 13:51:26 +0200 From: Victor Volle <vic...@ep...> Reply-To: v....@co... To: md...@gj... Subject: JDiff Hi! The only thing I miss from jEdit is a diff-mode/tool. You have been developing JDiff, but AFAIK you have stopped any further development. I am interested in stepping in if you don't mind, but need to further evaluate the code of jEdit, since I would like to use much of its codebase. Therefore I do not want to commit myself, yet. But before I explore any further: Is anybody else doing something in this area? I am not "pressed" doing it myself. It is just a feature I really would like to see implemented. Bye Victor |
|
From: <md...@st...> - 2000-03-22 19:14:34
|
howdy all- i just wanted to let you know that jDiff is not dead. i've just been busy with jEdit work lately and haven't done much in the last week. i have decided to go ahead with the "name change". what was to be JDiff 3.0 shall henceforth be known as jDiff 1.0. -md |
|
From: <Ste...@lr...> - 2000-03-15 18:19:20
|
After working with jEdit and jCVS, jDiff somehow seems more "natural". Based on the extent of the changes, knocking back to a 1.0 release seems reasonable. Steve Jakob Programmer/Analyst London Regional Cancer Centre Ste...@lr... |
|
From: mike d. <md...@st...> - 2000-03-15 09:49:21
|
howdy- i just commited/imported/added my newest set of changes to JDiff. although i wish i could have released a pre1 last week, it looks like it will have to be some time later this week. however, this code is getting there. some things are even complete (although most parts are still iffy and subject to change without notice). i switched from the previous "single buffer" interface to a more flexible interface that should allow a lot of different viewing modes. i haven't touched multiple top-level windows yet, but i did implement the buffer management in such a way that it is trivial to switch between a JTabbedPane view and a JDesktopPane view (as well as potentially other sorts of views). i think the default mode will be JTabbedPane, but the current CVS is setup to use the JDesktopPane (mainly for kicks). i've also started the action system, but the only actions available (new-diff and about) don't even do what they are supposed to yet. a few other things probably got in there as well, and i definitely still have a long way to go before 3.0 final. -md p.s. since this app has almost nothing to do with the original JDiff, should the current branch really be the 3.x series? people seem to keep mistakenly calling the app jDiff anyways, so maybe we should "rename" it from JDiff to jDiff and knock the version back to a more reasonable version number, like 1.0 pre1. |
|
From: <md...@st...> - 2000-03-07 19:15:25
|
On Tue, 7 Mar 2000 Ste...@lr... wrote: > I had occasion to test out your initial jDiff release to compare a > couple of Windows registry exports today. Very slick! It made the job > much easier. thanks. i've actually made it somewhat better in the last few days, but i broke the CVS on Saturday and it wasn't fixed until this morning. i should check more code in tonight, and i'll let everyone know when i do. > An enhancement request: How about integrating your jEdit gutter code > to supply line numbers? it is a planned feature, but i didn't want to put the cart before the horse. there will likely be a gutter in JDiff almost exactly like jEdit (except that it will accommodate gaps in the line numbering). > Some thoughts re: console mode. Sounds like a good idea. Options like > "--console" and "--gui" (or perhaps "--nogui" and "--gui") to indicate > the desired mode seem reasonable. Having jDiff "remember" the last > mode would certainly be helpful. The only thing I would suggest NOT > doing would be to have GUI as the default mode and require the > "--console" option for command line use, as this would require more > typing when using console mode (which seems backwards to me). i like your idea about "nogui" and "gui". as for "remembering", i'm not sure that i like that idea as much as a properties file. i think that since the command used to invoke JDiff will typically be a shortcut of some kind anyways (not the full 'java -classpath ... jdiff.JDiff --nogui -i file1 file2'), another good way to do the --gui/--nogui transparently would be to provide two different scripts, one that calls JDiff with the --gui option and another that calls it with --nogui. > Also, thanks for mentioning the Java getopt package. I wasn't aware of > this before. I think it could come in handy for a command-line file > purge utility I wrote a while back. yeah, i was quite pleased to find it myself. it definitely makes things easier, since i can get a really good, standard command line parser for slightly less effort than it would take me to hack a less featureful ad-hoc parser. the part i like best is that it acts like every other getopt program, so people don't have to scratch their head as much (provided that --help says something moderately useful). -md |
|
From: <Ste...@lr...> - 2000-03-07 18:39:32
|
Mike, I had occasion to test out your initial jDiff release to compare a couple of Windows registry exports today. Very slick! It made the job much easier. An enhancement request: How about integrating your jEdit gutter code to supply line numbers? Some thoughts re: console mode. Sounds like a good idea. Options like "--console" and "--gui" (or perhaps "--nogui" and "--gui") to indicate the desired mode seem reasonable. Having jDiff "remember" the last mode would certainly be helpful. The only thing I would suggest NOT doing would be to have GUI as the default mode and require the "--console" option for command line use, as this would require more typing when using console mode (which seems backwards to me). Also, thanks for mentioning the Java getopt package. I wasn't aware of this before. I think it could come in handy for a command-line file purge utility I wrote a while back. I'm looking forward to the next release. Steve Jakob Programmer/Analyst London Regional Cancer Centre Ste...@lr... |
|
From: mike d. <md...@st...> - 2000-03-06 09:17:29
|
hi- i've been working a lot today with JDiff and have made decent progress, but since i haven't been able to access cvs.jdiff... for a while, i can't commit any changes. so far, i've added labels above the left and right text areas to indicate the file names. i have also integrated Java getopt and started the argument handling code. i need to do some more work before i can make stuff like --ignore-case and --ignore-space-change work, but it shouldn't be too hard. i'm hoping to implement a large portion of those GNU diff command line options that are appropriate to JDiff. another thing i've been interested in is getting this to work as a command line tool. i've already implemented the "-" file name functionality to compare a file to System.in so '|' and '<' should work. also, while i was originally testing Stuart's diff code, i hacked up a simple merged print mode and an emulation of the default diff(1) output. so, the output is pretty straightforward, but how do we toggle between console and GUI mode? we could add a long option '--console' to use JDiff in text-only mode. if i add user properties at some point, people could then put "console=true" in their properties file to default to text mode. -md |
|
From: mike d. <md...@st...> - 2000-03-06 01:36:07
|
hello future JDiff devotees- i have completed the first CVS imports for what is to be JDiff 3.0. the CVS is located at cvs.jdiff.sourceforge.net:/cvsroot/jdiff. the module name is JDiff. the anonymous CVS username is 'anonymous'. the password is blank (i.e. <Enter>). since i was having a bit of trouble with the overview widget, i've decided to postpone it for a while to work on other, more important stuff. the code in the CVS only works when the two files to be diff'ed are specified on the command line. i'm going to work on the file loading actions and then i'll make it so you can run JDiff with no args and choose the file from the GUI. you should then also be able to "refresh" the diff. i hope to have this in the CVS tonight, so i'll post a message here when i've done so. -md p.s. as a caution to those of you examining the code, some parts of it are RAW!!! they will probably be scrapped. i consider the current code a proof of concept, so much of it may be rewritten or redesigned before 3.0 final. |
