Re: JDE-CVS-Commit
Paul Kinnucan [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Update of /pack/anoncvs/jde/lisp In directory sunsite.dk:/tmp/cvs-serv11659 Modified Files: jde-xref.el Log Message: Made jde-xref-store-prefixes non-optional. I think if we didn't do this, most people would leave it blank, therefore significantly impacting both size of the database and the time and memory it takes to make it. Hi Andy, How about making nil default to the package of the class in the current source buffer? I'm not sure I want to make any assumptions. Typically, people would want their database to encompass more than one package. Plus, I anticipate that this will not always be invoked from a Java buffer. For instance, you could rebuild the database every night, and in that case you wouldn't be in a buffer. Also, I'd like to suggest renaming jde-xref-store-prefixes to jde-xref-packages as that more clearly indicates the variables purpose. Let me think about this one. The thing is, the variable doesn't contain package names, it contains package prefixes. But the name is a bit confusing, I agree. - Paul
Re: JDE-CVS-Commit
Andrew Hyatt writes: Paul Kinnucan [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Update of /pack/anoncvs/jde/lisp In directory sunsite.dk:/tmp/cvs-serv11659 Modified Files: jde-xref.el Log Message: Made jde-xref-store-prefixes non-optional. I think if we didn't do this, most people would leave it blank, therefore significantly impacting both size of the database and the time and memory it takes to make it. Hi Andy, How about making nil default to the package of the class in the current source buffer? I think it's nice to have all the jde-xref variables to have defaults that allow a new user to try it out quickly without having to do any preliminary setup, which is now required with your latest change. Previously, the default for this variable was to cross-ref the universe by default. I'm suggesting that we change it to cross-ref the current package. Is this what the user is likely to want ultimately? No, but it's a good starting point. The new user should quickly notice that the xrefing is limited and this should lead them to the doc to find out why. I'm not sure I want to make any assumptions. Typically, people would want their database to encompass more than one package. Plus, I anticipate that this will not always be invoked from a Java buffer. For instance, you could rebuild the database every night, and in that case you wouldn't be in a buffer. Also, I'd like to suggest renaming jde-xref-store-prefixes to jde-xref-packages as that more clearly indicates the variables purpose. Let me think about this one. The thing is, the variable doesn't contain package names, it contains package prefixes. What's the difference? But the name is a bit confusing, I agree. I think this variable, whatever its name, should allow the user to specify the packages that the user wants to xref, including specifying that all subpackages of a package be xrefed, e.g., if I have a package structure like this: pkgA pkgAa pkgAb I should be able to specify pkgA and have everything in pkgA, including pkgAa and pkgAb, xrefed. On the other hand, if I specified pkgA.pkgAb, I'd expect only pkgAb to be xrefed. - Paul
Re: JDE-CVS-Commit
Paul Kinnucan [EMAIL PROTECTED] writes: I think it's nice to have all the jde-xref variables to have defaults that allow a new user to try it out quickly without having to do any preliminary setup, which is now required with your latest change. Previously, the default for this variable was to cross-ref the universe by default. I'm suggesting that we change it to cross-ref the current package. Is this what the user is likely to want ultimately? No, but it's a good starting point. The new user should quickly notice that the xrefing is limited and this should lead them to the doc to find out why. Xref already requires the user to set up the jde-xref-db-base-directory as well as the jde-built-class-path. There may be a way to automatically guess these things, but I couldn't see how with the jde variables already there. The base directory should usually correspond to something in the sourcepath, but we don't know which entry. And the jde-built-class-path cannot be figured out from the classpath, it's actually a subset of the classpath, but again we don't know what subset. So we need the user to fill out two things, with my latest change, it's now three things. I would rather force the user to fill out a reasonable value. I think not doing so will confuse users, and they may assume it doesn't work right.We could try to guess this one, but I think it would be an error prone process.I would like to minimize confusion and potential bugs, that's why I like the user to fill this one out. Let me think about this one. The thing is, the variable doesn't contain package names, it contains package prefixes. What's the difference? Well, it's that package (in the sense that something like com or org is a package), and all children of that package. To be specific, it's just whatever packages match that any of the prefixes in this variable, so the prefix co would match com.foo.bar. But the name is a bit confusing, I agree. I think this variable, whatever its name, should allow the user to specify the packages that the user wants to xref, including specifying that all subpackages of a package be xrefed, e.g., if I have a package structure like this: pkgA pkgAa pkgAb I should be able to specify pkgA and have everything in pkgA, including pkgAa and pkgAb, xrefed. On the other hand, if I specified pkgA.pkgAb, I'd expect only pkgAb to be xrefed. This is the way it works now. - Paul
Re: JDE-CVS-Commit
Andrew Hyatt writes: Paul Kinnucan [EMAIL PROTECTED] writes: I think it's nice to have all the jde-xref variables to have defaults that allow a new user to try it out quickly without having to do any preliminary setup, which is now required with your latest change. Previously, the default for this variable was to cross-ref the universe by default. I'm suggesting that we change it to cross-ref the current package. Is this what the user is likely to want ultimately? No, but it's a good starting point. The new user should quickly notice that the xrefing is limited and this should lead them to the doc to find out why. Xref already requires the user to set up the jde-xref-db-base-directory as well as the jde-built-class-path. There may be a way to automatically guess these things, but I couldn't see how with the jde variables already there. The base directory should usually correspond to something in the sourcepath, but we don't know which entry. And the jde-built-class-path cannot be figured out from the classpath, it's actually a subset of the classpath, but again we don't know what subset. So we need the user to fill out two things, with my latest change, it's now three things. I would rather force the user to fill out a reasonable value. I think not doing so will confuse users, and they may assume it doesn't work right.We could try to guess this one, but I think it would be an error prone process.I would like to minimize confusion and potential bugs, that's why I like the user to fill this one out. In my ideal world, no setup would be required. If you did nothing, the JDEE would xref the code in the current package (or perhaps prompt you to enter a list of packages with the default being the current package) and store the result in the root of the project directory (i.e., where the prj.el file is stored). Further, you would not need to specify a classpath in addition to jde-global-classpath. The JDEE would be smart enough to process only those portions of jde-global-classpath where the packages that you specify live. Further, you would not even need to build the xref db. If there is no xref db in the db directory, the JDEE would build it the first time you executed jde-xref-first-caller. This would work great for the project I am currently working on here at the Mathworks. There are a lot of classes but they all live in the same root package. If the JDEE were set up the way I described, I'd just have to call jde-xref-first-caller to get started. No tedious setup. - Paul Let me think about this one. The thing is, the variable doesn't contain package names, it contains package prefixes. What's the difference? Well, it's that package (in the sense that something like com or org is a package), and all children of that package. To be specific, it's just whatever packages match that any of the prefixes in this variable, so the prefix co would match com.foo.bar. But the name is a bit confusing, I agree. I think this variable, whatever its name, should allow the user to specify the packages that the user wants to xref, including specifying that all subpackages of a package be xrefed, e.g., if I have a package structure like this: pkgA pkgAa pkgAb I should be able to specify pkgA and have everything in pkgA, including pkgAa and pkgAb, xrefed. On the other hand, if I specified pkgA.pkgAb, I'd expect only pkgAb to be xrefed. This is the way it works now. - Paul
Re: JDE-CVS-Commit
Paul Kinnucan [EMAIL PROTECTED] writes: In my ideal world, no setup would be required. If you did nothing, the JDEE would xref the code in the current package (or perhaps prompt you to enter a list of packages with the default being the current package) and store the result in the root of the project directory (i.e., where the prj.el file is stored). Further, you would not need to specify a classpath in addition to jde-global-classpath. The JDEE would be smart enough to process only those portions of jde-global-classpath where the packages that you specify live. Further, you would not even need to build the xref db. If there is no xref db in the db directory, the JDEE would build it the first time you executed jde-xref-first-caller. This would work great for the project I am currently working on here at the Mathworks. There are a lot of classes but they all live in the same root package. If the JDEE were set up the way I described, I'd just have to call jde-xref-first-caller to get started. No tedious setup. - Paul Your suggestions are interesting, and they are doable, I think. And I agree that having a no-setup solution is desirable. My problem would be that they do require some guesswork, and that guesswork may go awry, causing problems. Let me see if I can code something up that does what you suggest.
