>
>mehul
>
>
> On Fri, Dec 2, 2016 at 1:00 PM, Paul Landes wrote:
> The project’s owner and primary maintainer is now Mr. Wojnowski. He’s been
> the most active lately and shown to have a very good handle on the project.
> He’ll make a great project owner.
&
The project’s owner and primary maintainer is now Mr. Wojnowski. He’s been the
most active lately and shown to have a very good handle on the project. He’ll
make a great project owner.
I’ll still be a maintainer and help in ways I can. However, I no longer do
much in Java and I think the pro
The reason we talked about Clojure is it works nicely with Emacs Lisp. With
beanshell there's lots of moving around bits of code that have little meaning
in Emacs Lisp, which would be the case with Groovy.
That said, there's not a lot of development going on and if you wanted to try a
few thin
Hi Matthew.
This sounds great. In fact I actually borrowed much of your code several years
ago to build out pom.xml/maven code to configure JDEE. This would be a great
addition.
Please proceed.
Thanks very much.
Regards,
Paul
On Oct 7, 2016, at 3:13 PM, Przemysław Wojnowski wrote:
> Hi,
I'm thinking of some kind of straight forward REPL type functionality as a
separate module if someone really wants it. Not anything that would tie too
much into the guts of JDEE.
On Feb 12, 2016, at 10:23 AM, Phillip Lord wrote:
> Paul Landes writes:
>
>> I'm in f
I'm in favor of moving forward with the Clojure back end. Clojure tooling
makes the Emacs side of things much easier as Phil mentioned earlier.
I _do_ think it would be possible really to support both the Java REPL and
Clojure, however, it wouldn't make sense to duplicate core JDEE IDE type
fu
> On Mon, Dec 7, 2015 at 10:07 AM, Paul Landes wrote:
>> I'm not sure you can do this. The way I use cider (default) is start in a
>> directory that has a project.clj file in the same directory or parent
>> directory and then since it uses that to set up the classpath.
&g
I'm not sure you can do this. The way I use cider (default) is start in a
directory that has a project.clj file in the same directory or parent directory
and then since it uses that to set up the classpath.
Not sure of the details, but I think it would be the same situation where based
on a di
rver). The current code is not really
> maven-centric. I just happen to have used maven.
>
> Phil
>
> Paul Landes writes:
>
>> I agree with Phillip writes and add that supporting two back ends at
>> this point would be burdensome.
>>
>> For those that dislike
I agree with Phillip writes and add that supporting two back ends at this point
would be burdensome.
For those that dislike maven there isn't any reason some template config (pom)
file couldn't be used in a temp directory (or even memory). Either way it
would be pretty small since at best you'
Right, everyone is too busy to do anything but the bare essentials at this
point. I'm very happy that we made as much progress as we did a few months ago
(another thanks to the contributors).
I planned on starting (not extending) the Clojure work Phillip did but work
keeps getting in the way.
On Aug 26, 2015, at 11:19 AM, Phillip Lord wrote:
> Paul Landes writes:
>
>> On Aug 26, 2015, at 9:25 AM, Phillip Lord wrote:
>>
>>> Paul Landes writes:
>>> At the moment, I am concerned about how the build tool should be
>>> launched. Maven
On Aug 26, 2015, at 9:25 AM, Phillip Lord wrote:
> Paul Landes writes:
>
>> If it's a fork we might want to think about just staying with CIDER
>> indefinitely.
>>
>> I agree about CIDER--worked with it quit a bit and it is solid. To reiterate
>> what
about as far as possible --
> classpath for instance, and leave that to the build tool (whether that
> is maven, ant or gradle). But this is a big change and one likely to
> have many implications.
>
>
>
> Paul Landes writes:
>
>> So there is no dependency on Ci
So there is no dependency on Cider?
I'll take a look at some point soon as I'm up to my ears in work.
On Aug 25, 2015, at 5:17 PM, Phillip Lord wrote:
>
> Lee Hinman writes:
>>> I have advanced this somewhat now and would be interested in opinions.
>>> I now have a worked nREPL connection to
Thanks for all your contributions Przemysław.
On Aug 24, 2015, at 4:49 AM, Przemysław Wojnowski wrote:
> Hello everybody,
>
> Recently I did a couple of updates to move JDEE to MELPA:
> 1. Renamed every "jde" to "jdee" match project name and packaging naming
> conventions (rules?).
> This mea
When will the cask branch be ready to merge into master?
On Aug 18, 2015, at 3:12 AM, Przemysław Wojnowski wrote:
> W dniu 18.08.2015 o 00:28, Phillip Lord pisze:
>>> The jars (jde and bsh) from jdee-server are needed to preserve current
>>> functionality.
>> This is kind of my worry. I realise
People can and have different visions for a coordinated effort on open source
projects. This (in my experience) works best with one main project and sub
"projects" that are added as plugins.
We've talked about this a little and I bring it up again because I think this
should come first as it w
We need something a little more formal to sort what everyone wants and who's
tackling it. You've already started a list to this effect on GH--maybe we
expand on it.
On Aug 14, 2015, at 5:40 PM, Przemysław Wojnowski wrote:
> To begin with. My project vision is that JDEE will be (at least) som
Right. There is little gain from backward compat at this point.
> On Aug 14, 2015, at 10:30 AM, Przemysław Wojnowski
> wrote:
>
> W dniu 14.08.2015 o 01:00, Stephen Leake pisze:
>> I have another problem with this; it's backward incompatible. We'll get
>> lots of (well, some :) complaints "why
I am to blame for this nasty ant XML but at the time there weren't a lot of
great alternatives.
On Aug 13, 2015, at 6:07 PM, Stephen Leake
wrote:
> Phil Lord writes:
>
>> JDEE currently has the nightmare of Emacs Lisp build with ant. Let's
>> build emacs-lisp with cask, Java with maven. Any
I also like autoloads the way they are. As someone mentioned, an autoloads.el
file is created from all ;;;###autoload found in all files.
When the package is installed, can't we invoke some elisp code to call the
method that creates this autoloads file? We can't be the first to do things
this
I agree.
On Aug 4, 2015, at 6:50 AM, Phillip Lord wrote:
>
>
> (Again, apologies for lateness -- been offline)
>
>> Enter Maven. I use a web search engine (or built-in Eclipse feature,
>> but it's not very good) to find this:
>> http://search.maven.org/#artifactdetails|org.apache.commons|co
You're added.
On Jul 23, 2015, at 6:01 PM, Troy Daniels wrote:
>
>
> On Thu, Jul 23, 2015 at 6:12 PM, Paul Landes wrote:
> Nice to see you active again on JDEE Troy. Yes I'll add soon but I'm also
> traveling and can't do it right now. Forward me your Gi
I'd be in favor of getting rid of XEmacs code unless there are people still
using it. I'm a little surprised to see that people still are.
On Jul 25, 2015, at 11:19 AM, Jerry James wrote:
> Sorry for the late reply. I've been out of town.
>
> On Thu, Jul 16, 2015 at 8:06 AM, Przemysław Wojn
-emacs (https://github.com/jdee-emacs)
> organization, which would make JDEE related projects easier to find.
>
> To do that Paul Landes would need to add you to the organization and
> the repository can just be transfered - no need for migrations or
> anything like that.
>
>
Beanshell in the current JDEE already does what I'm proposing we replace CEDET
with Clojure/Cider + the "parse Java" API. It wouldn't be an external tool;
rather it would be an API we write clojure code glue code around.
On Jul 15, 2015, at 5:18 PM, Stephen Leake
w
at 5:12 PM, Stephen Leake
wrote:
> Paul Landes writes:
>
>> Yes, I did think about gradle, but I think it's probably over kill for
>> what we need.
>
> I think there are two separate issues here:
>
> - the system that builds the components of the JDEE2 p
Does anyone have any experience with the java.lang.model? Maybe this will give
us what we need:
http://stackoverflow.com/questions/6999500/java-source-code-parsers-generators
example:
https://today.java.net/pub/a/today/2008/04/10/source-code-analysis-using-java-6-compiler-apis.html#accessing-
I'm glad to see this project moving again!
On Jul 15, 2015, at 3:05 PM, Przemysław Wojnowski wrote:
> I've renamed the target to "test" and now it runs all the tests.
>
> I've tried to build elisp files with Cask (http://cask.readthedocs.org),
> but faild. Most probably because of: https://gi
Yes, like ant but more declarative and less procedural.
Yes, I did think about gradle, but I think it's probably over kill for what we
need. We could abstract out project information but that complicates things
and could be done in a later refactoring if gradle is desired. Leiningen, a
clojur
aths correctly. This was without JDEE. A
> thin wrapper to help set source paths and the classpath based on your project
> is something I would certainly use.
>
> Mike
>
> On Wed, Jul 15, 2015 at 1:46 PM, Paul Landes wrote:
> 1) Idea would be to move to a maven 3 projec
> 3 - How is code completion currently done? Is that the beanshell to clojure
> mentioned? Has then been started?
>
> I am sure I will have more questions, but I would like to help? Hoping my
> list subscription is worked out and this message goes through.
>
> Mike
>
>
er. Here are a few ideas:
- `jdt' as short for "JDEE [Version] 2"
- `jdn' or `jden' for JDEE Next Gen
I'd also like to separate as much as possible so I think we should create a
separate repo.
Thoughts?
On Jul 15, 2015, at 9:47 AM, Stephen Leake
wrote:
> Pa
1.8 = 8.
So does this mean you're volunteering? :)
You've been added.
On Jul 15, 2015, at 2:42 AM, Stephen Leake
wrote:
> Paul Landes writes:
>
>> Is there anyone available that knows font-lock well able to bring JDEE
>> up to 1.8? I still lacks 1.5 generic
Is there anyone available that knows font-lock well able to bring JDEE up to
1.8? I still lacks 1.5 generics fortification, which seems like a big one to
me.
On Jul 14, 2015, at 12:27 PM, Przemysław Wojnowski wrote:
> On 14.07.2015 15:57, Paul Landes wrote:
> [...]
>> - Inerti
I'd like to bring up the topic of a major refactoring. I don't think I'm in
the minority in the mode of thinking that JDEE needs a major refactoring given:
- Girth of the project: it's a lot to maintain and various plugins might not be
used any more
- Inertia: without a lot of activity there's
no real reason to move the mailing list.
>
>
>
> From: Przemysław Wojnowski [espera...@cumego.com]
> Sent: 14 July 2015 09:01
> To: Paul Landes
> Cc: Phillip Lord; Len Trigg; JDEE Development; len...@gmail.com
> Subject: Re: [jdee-de
Let's call it 24.3 then.
Another todo item: move to a github mailing list. Can someone provide
advantages and disadvantages (if they exist)?
Thanks.
On Jul 13, 2015, at 5:10 PM, Phillip Lord wrote:
>
> Cask, EVM and travis-ci are a good way forward for older version testing. I
> most of m
I'm currently on 24.5. 25 is still beta isn't it?
On Jul 13, 2015, at 3:31 PM, Przemysław Wojnowski wrote:
> Hello everybody,
>
> What version(s) of Emacs should be supported?
> Are we plan to still support Emacs lower than 25?
>
> IMHO there's no point in maintaining older versions. If some
d be "phillord" (that's me:-)
>
> ________
> From: Paul Landes [lan...@mailc.net]
> Sent: 13 July 2015 19:22
> To: Phillip Lord
> Cc: Przemysław Wojnowski; JDEE Development
> Subject: Re: [jdee-devel] using jdee with current Emacs master
>
> No doubt that he'
sitory - I guess the repository should be assigned to the team (in team
> settings).
>
> W dniu 2015-07-13 20:22, Paul Landes napisał(a):
>> No doubt that he's a guru in all things SCM. However, I think I have
>> it. Here's how I imported it:
>> SVNURL="
of which maybe 20
> are
> mine (changes for Emacs 25).
>
> It seems that it has to be imported in some other way.
>
> W dniu 13.07.2015 o 19:32, Phillip Lord pisze:
>> Why does the history start in 2010?
>>
>> From: P
Does previous author care about their email address in this author mapping file?
On Jul 13, 2015, at 12:48 PM, Paul Landes wrote:
> I'm trying to use git svn right now myself using this mapping:
>
> paullandes = plandes <...>
> lenbok = lenbok
> shyamalprasad = sh
>>>> some reason
>>>> it breaks on commit 104, but in my repository
>>>> (https://github.com/pwojnowski/jdee) there are 283 commits of which
>>>> maybe 20 are
>>>> mine (changes for Emacs 25).
>>>>
>>>> It seems
We're now on github:
https://github.com/jdee-emacs/jdee
I've removed all admins and developers from the sourceforge page and redirected
to the new github repo.
Stephen: What is your github account? I will add you as a developer.
Also, this is the first time I've created and admin'd a github
Good question. I did the SVN import as recommended.
Przemysław?
On Jul 13, 2015, at 12:32 PM, Phillip Lord wrote:
> Why does the history start in 2010?
>
> From: Paul Landes [lan...@mailc.net]
> Sent: 13 July 2015 18:29
> To: Stephen L
Given the desire to move to github I'm planning on doing that.
I tried to create a jdee organization, but as mentioned, the name is taken.
I've asked the repo author of the emacsmirror/jdee repo if they are willing to
give up the name. If not, I'll create a new repo and afterword close down the
015, at 3:01 AM, Przemysław Wojnowski wrote:
> W dniu 2015-07-07 01:11, Paul Landes napisał(a):
>> Nice. Anyway you can create a patch for the svn repo?
> Wouldn't it be better to move to github and create an organization? On GH
> it's much easier to cooperate than on SF - esp
and doing the same
> from scratch.
>
> Cheers,
> Przemysław
>
> W dniu 06.07.2015 o 17:14, Paul Landes pisze:
>> Stephen,
>>
>> This patch has been applied and tested. Thanks very much for your
>> contribution.
>>
>>
>>
>> O
Stephen,
This patch has been applied and tested. Thanks very much for your contribution.
On Jul 5, 2015, at 9:22 AM, Stephen Leake
wrote:
> I'm using jdee with the current Emacs master (from Emacs git). It throws
> errors when `oref' is passed a class rather than an object. The fix is
> to
JDEE has `jde-help-class' which is bound to C-c C-v d. It prompts for the
class and starts a web browser showing the documentation.
On Jul 5, 2015, at 10:27 AM, Stephen Leake
wrote:
> I'm writing an Android app, so I have lots of statements like "import
> android.app.Service". It would be ni
'll
> update the online user guide in a week or two. The trunk code now builds
> a 2.4.2 release (which can be whatever it now needs to be, fork or no
> fork).
>
> Cheers!
> Shyamal
>
>>>>>> "Paul" == Paul Landes writes:
>
>Paul&g
Fun fact: when your maven connects directly to public repositories, you're
> depending on non-free software to do your daily work. TODO: implement free
> replacement; run it locally AND publically.
> 3. But Maven liberated us from jar-hell.
>
> > -Original Message-
nt to have
> maven be a required dependency of JDEE.
>
> Troy
>
>
> On Mon, May 6, 2013 at 2:27 PM, Paul Landes wrote:
> Hi Troy,
>
> Nice to hear from you again and I appreciate your concern.
>
> You can invoke ant builds from maven and there is ant support
ourse. This is just the full compile use case.
There is another use case for fly compile to get real time errors, symbol
completion, javadoc etc.
On May 1, 2013, at 6:58 PM, Shyamal Prasad wrote:
>>>>>> "Paul" == Paul Landes writes:
>
>Paul> M
.
On May 1, 2013, at 6:15 PM, "Daniels, Troy (US SSA)"
wrote:
>
>
> From: Paul Landes [mailto:lan...@mailc.net]
> Sent: Wednesday, May 01, 2013 5:48 PM
> To: Gian Uberto Lauri
> Cc: JDEE Development; JDEE Users; Dave Paroulek
> Subject: Re: [jdee-devel] [jdee-us
On May 1, 2013, at 8:50 AM, Phillip Lord wrote:
> Paul Landes writes:
>> I actually did consider Clojure, nrepl, Leiningen etc. and I agree on all
>> points. The issue for me is it isn't Lisp. It's lisp like and has many of the
>> features, but still isn't
These are great details--Thanks Przemysław. However, I think first we need to
either come to a consensus as to whether it is worth forking or refactored.
BTW--There already is some code completion (`jde-complete') and method jumping
in its current form can be accomplished with CEDET's speedbar)
My thinking is that maven will be a dependency. JDEE supporting ant, maven,
javac compilations is one huge contributing reason for its bloat.
Would declaring offline mode in the ~/.m2/settings.xml and making all needed
dependencies available for download from SF be sufficient? Should be a one
Apr 30, 2013, at 5:44 AM, Phillip Lord wrote:
> Paul Landes writes:
>> The basic idea would be to pretty much move all the things that beanshell and
>> semantic currently do to Java packages. That means using things like
>> compilation tools that come with the JDK and oth
Shyamal,
It isn't possible to duplicate the beanshell functionality in elisp. It has to
be in Java or a Java scripting language since Java reflection is used for
templating/wizards etc.
On Apr 29, 2013, at 12:46 PM, Shyamal Prasad wrote:
>
>>>>>> &qu
>>>>>> "Henry" == Henry S Thompson writes:
>
>Henry> Paul Landes writes:
>
>>> dependent on CEDET. I have nothing bad to say about CEDET but
>>> it's current integration with Emacs post 23 has been non-compat
>>> and creat
urces to create
this all together! We don't need an army of devs, only a few that can work
with me and help me implement specific parts of the architecture. I'm strong
on Emacs Lisp, Java and decent with CL (I am weak on APIs out there).
Devs and users: please let me know!
-Paul L.
It was a post from a long time ago to the jdee-devel list. There should be
another list that is more detailed somewhere in the code base. I'll try to
find them and get back to you.
On Apr 29, 2013, at 9:33 AM, "Loyall, David" wrote:
>> From: Paul Landes
> [...
Resending due to a bounce (jdee-bounces):
I agree, we're overdue for a release. Shyamal: please proceed when you can and
let me know if I can help. We can get on chat and go through it together as
well if that's helpful.
Re bit rot: I have about as much time to admin the project but not as mu
I agree, we're overdue for a release. Shyamal: please proceed when you can and
let me know if I can help. We can get on chat and go through it together as
well if that's helpful.
Re bit rot: I have about as much time to admin the project but not as much time
for development. The work that Sh
Please proceed.
On Mar 6, 2013, at 1:21 PM, Shyamal Prasad wrote:
>
> Hi Paul,
>
> jde.el defines jde-semantic-require which seems to exist only to support
> CEDET in Emacs 23.2 (see r236, r238, r252).
>
> Given that JDE does not actually work with the Emacs version of CEDET
> would anyone m
It only supports GNU Emacs 23 and 24 at this point. No reason to get rid of
the XEmacs branches that are currently there, but until we have someone
maintaining it (unless you use XEmacs) we officially don't support it.
Is there anyone on this list that would like to start maintaining XEmacs?
Will you please send the entire file? Patch on OSX barfs on 46.
Thanks.
On Sep 10, 2012, at 4:17 PM, shya...@member.fsf.org wrote:
> Hi,
>
> I depend on JDEE and when it went away as a Debian package I found
> myself building my own from the subversion trunk.
>
> One thing I seem to have le
This has been added. Thanks for this fix, I know there are a lot of
people that have been waiting for it.
On Jun 7, 2011, at 10:21 AM, Lee Brinton wrote:
> I have posted a patch to use {jdk_dir}/bundle/Classes/classes.jar if
> found. My elisp ability is infantile so the solution may not be
Try it now.
On Nov 11, 2010, at 9:49 PM, Troy Daniels wrote:
On Tue, Jun 1, 2010 at 11:29 PM, Paul Landes wrote:
JDEE now uses the version of CEDET that ships with Emacs 23.2. This
is only applied to Emacs 23. Previous versions of Emacs should be
functionally the same as before the
Mansour found this link:
http://sourceforge.net/blog/some-good-news-SourceForge-removes-blanket-blocking/
I've switched the mentioned "export controls" and it should now be
available everywhere it was before. Those in the mentioned countries
please test.
Thanks.
On Jun 7, 2010, at 10:1
Absolutely agree with Philip.
Lennart: Thanks for pointing this out. I'll add this to the list.
What I'd really like is a second place to upload the code or hand it
off to someone else as Philip mentioned.
On Jun 7, 2010, at 10:19 PM, Lennart Borgman wrote:
> On Mon, Jun 7, 2010 at 4:02 PM,
Good suggestions. I'll look into them.
On Jun 7, 2010, at 8:00 AM, Jason McBrayer wrote:
Probably a mirror on github or bitbucket would minimally do the
trick. If you wanted to move project hosting, savannah.nongnu.org
might be possible.
--
Jason F. McBrayer
http://jfm.carcosa.net/
--
Looks like SF doesn't have much of a choice--this is an issue with the
US foreign policy, not FS:
http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/
I disagree that it's a any developer's obligation to engage in
poli
None, in fact my implementation is inferior to his. I'll be adding
this to the trunk soon.
Thanks for bringing this up Steven!
On May 11, 2010, at 10:27 AM, Steven Huwig wrote:
How different is this approach from the one taken in jde-mvn ?
http://bitbucket.org/espenhw/jde-mvn/wiki/Home
T
JDEE now uses the version of CEDET that ships with Emacs 23.2. This
is only applied to Emacs 23. Previous versions of Emacs should be
functionally the same as before the change.
I've backed out the jde-maven-util source code and respective libs
I've added as someone had mentioned had broug
ugh beanshell. Add a `t' after the `deps' to do it
via the command line with the script I gave below.
On May 9, 2010, at 7:17 PM, Paul Landes wrote:
> I've added new maven dependency support that expands on this idea.
>
> Ideally, I'd like to access the code ma
H jde.util.MavenUtils "$@"
--snip
On Apr 21, 2010, at 11:08 PM, James Ahlborn wrote:
> alright, think this will work, although it's a bit of an ugly hack.
> couldn't figure out a better way to get push and xml-node-attributes
> to play nice together.
&g
This is great. Thanks Len!
On Apr 30, 2010, at 2:01 AM, Len Trigg wrote:
>
> I have just committed the initial integration of Suraj Acharya's
> support for the eclipse java compiler as a JDEE compile server to the
> trunk. I have also added optional flymake support when using the ecj
> compiler.
I saw this a while back but can't recall the details. If you want,
you can dig back in the list archive, find the files, and integrate
them.
If memory servers, someone has already done all the work to get it to
work in 23. However, we still support 22.
I think it might even be in the curr
Will you please add a bug report in sourceforge?
We're pretty low on developers right now. Is there anyway you can a
solution and post a fix?
On Apr 13, 2010, at 6:28 PM, David Ventimiglia wrote:
Verified that this occurs in Linux, as well as in Windows.
-Best, David
From: David Ventimi
#x27;
to make these path conversions but I think you're time is better spent
using the GNU build of Emacs under NT.
On Mar 17, 2010, at 8:14 AM, Troy Daniels wrote:
On Sun, Mar 14, 2010 at 5:24 PM, Paul Landes wrote:
Please send the error message it complains with when compil
Please send the error message it complains with when compiling.
Thanks Troy.
On Mar 13, 2010, at 9:52 AM, Troy Daniels wrote:
I'm trying to make some changes to JDE, but I'm running into
problems just using emacs. I'm using cygwin on Windows NT.
I was able to get the emacs that comes with
When compiling the following:
(defcustom jde-help-wget-tries nil ""
:group 'jde-help
:type '(choice (const :tag "Try once" :value nil)
(const :tag "Never stop trying" :value 0)
(integer :tag "Number of retries" :value 1)))
(defclass jde-jdurl-wget-resolver
Fixed and checked into the trunk.
Thanks for spotting this.
On Jan 11, 2010, at 12:49 PM, Daniel Flesner wrote:
>
> it appears to have been broken in change #192.
>
> Debugger entered--Lisp error: (invalid-function " * Describe class ")
> (" * Describe class " (file-name-sans-extension (file-na
Many say that 1.0pre6 works well with it, but I'm still on an older
version myself.
On Jan 10, 2010, at 11:38 PM, poppyer wrote:
>
>
> Paul Landes writes:
>
>> Release 2.4.0 is now out. Binary and source packages have been
>> created and uploaded
Better to keep everything on list. I think it is helpful to all.
On Jan 10, 2010, at 3:33 PM, "Jeff Peck" wrote:
Upon reading the docstring for jde-import-get-insertion-point,
we see that it is expected to add new-lines when inserting the first
import
between package and class; so that is b
Release 2.4.0 is now out. Binary and source packages have been
created and uploaded to sourceforge:
http://sourceforge.net/projects/jdee/files/
Release notes:
http://sourceforge.net/projects/jdee/files/jdee/2.4.0/release-notes.html/download
This release has taken quite a while and doe
ing when I can find a moment or two,
> and pre7 is (based on reports) quite stable and likely to become 1.0.
>
> Eric
>
> Paul Landes wrote:
>> I'll be upgrading to 1.0pre6. Is this the version in Emacs?
>> On Jan 9, 2010, at 7:35 AM, Eric M. Ludlam wrote:
>>&g
I'll be upgrading to 1.0pre6. Is this the version in Emacs?
On Jan 9, 2010, at 7:35 AM, Eric M. Ludlam wrote:
>
>
> Paul Landes wrote:
>> On Jan 8, 2010, at 2:38 PM, Len Trigg wrote:
>
>>> The main problem seems to be with the wisent 1.5 grammar, and I
>
Hello all,
I think we have a stable 2.4.0 currently and I'd like to put out a
release candidate in the very short term. I'd like to make Java 1.5
the focus of 2.4.1. There are also several outstanding patches that
I'd still like to see put in the next release as well.
I was also of thinki
A couple of thoughts while we're touching this code: we might want to
think about separating the buffer modification code with the parsing/
finding insertion point code. As it is now, this code both finds and
returns an offset, but it also has a side affect. We might get more
reuse if we s
> And in my testing, it goes in the correct place, and does not
> introduce spurious new-lines.
>
> If you have a test-case that demonstrates the problem of "additional
> lines being inserted"
> I will investigate/resolve that.
>
>
> - Original Message
On Jan 8, 2010, at 3:15 PM, Jeff Peck wrote:
> Ok, i see, the repeated inserts are the side-effect that Len
> mentioned when
> he checked in the "default to wisent-java"
> We need to find out why the buffer is not reparsed after the insert
I've had the reparsing problem for a very long time.
On Jan 8, 2010, at 2:38 PM, Len Trigg wrote:
> Paul Landes wrote:
>> I found two bugs when using `jde-import-all':
> [...]
>> This all highlights the need for some kind of automated testing.
>> Also, these bugs took many hours to track down and fix so please do
>&
requires
> putting a new-line in a new place (a change of behavior).
> And in my testing, it goes in the correct place, and does not
> introduce
> spurious new-lines.
>
> If you have a test-case that demonstrates the problem of "additional
> lines being inserted&quo
.
Thanks to all of our for your contributions and hard work.
--
Paul Landes
landes at mailc dot net
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class
Hi Przemek,
Sorry I've taken so long to respond. I wanted to take a little extra
time to look at the code both to confirm and work out a fix, but also
to address you more broad concern about the complexity of the code.
To first address the latter, I do agree some of the functions are more
1 - 100 of 150 matches
Mail list logo
