Community
Participate
Working Groups
As its names suggests most of operations in the scrapbook are temporary. Usually (in VAJ) I would open it, do some evaluations and close it. Now I have to specify a filename for the scrapbook. This makes me either have one scrapbook for project (and when I want to perform evaluations I need to find it), or to create & delete it each time. That file should be either internally created by eclipse (and stored in metadata), or at least when I have one scrapbook in a project, opening a scrapbook view (or pressing the scrapbook icon) should reopen the last used file. Also it should be ingored (by default) in CVS operations. For the first option, closing eclipse will either ask the user to save it, or save its content in the metadata.
This is questionable. A scrapbook page is certainly not a first class source file, however I might want to record it along with test cases, and share it. In this case, I need it to be a true resource file (as opposed to stored in .metadata).
The current UI for scrapbook pages works fell for snippets that should last and are sharable in a team. For evaluating temporary snippets there is currently overhead in that the user has to name a page. We should look into improving this. For example, an action that allows me to open a scrapbook page with a temporary name would be an improvement, e.g. a project\.scrapbook.jpage.
A default name would be a good start
Deferred
We the release of 2.0, scrapbooks are still implemented as files. We do not intend to change this.
Wont fix.
Closed.
why do you think it is a bad idea ? why not to leave it open for 3.0 ?
We use files for several reasons: (1) the file is created in a project which provides us with a classpath context for compiling, running, code assist, etc. The file provides a simple way to correlate a scrapbook with a project context. (2) The file persists the contents of the snippets, and provides a way to share snippets with a team (3) The editor framework in Eclipse is file based. Without a file/resource we will have difficulty fitting into the editor framework. (4) in the future we may support breakpoints in scrapbooks. This is also done via editor framework (ruler), and associating breakpoint markers with a scapbook is much simpler if the file resource exists (markers are resource based).
Basically, we avoid re-implementing the wheel.
can you start with a default name like "untitled", without creating a file on a disk, and when operations that require the contents to be in a file, require the user to save. I'm simply annoyed that when I want to do a simple test, like try to do "Socket s = new Socket(....); s.connect()" and see whether "s" connects ok, i need to create a new file, think where to put it, and it happened thaty i accidentally committed it to cvs. I like the VAJ approach - as long as the scrapbook was not closed, it could exist without a file, and even was persistent across sessions. what is this IWorkingCopy thing, is it related ? Genady
IWorkingCopy is only for working copies of compilation units - not generic files.
Deferred for post 2.0
*** Bug 37153 has been marked as a duplicate of this bug. ***
*** Bug 38870 has been marked as a duplicate of this bug. ***
****** Ensure to read the ideas presented in bug 38870.
Since we are post 2.0 now, can we reopen it ?
Currently, work on the scrapbook is still deferred - due to lack of resources and prioritization.
I have read in M2 notes that it is possible to open editors on files that do not exist. Does it bring this bug any closer to resolution?
*** Bug 77139 has been marked as a duplicate of this bug. ***
This would be a good test case for the new "nested workbench part" work which is just getting started by the UI team. In theory, the existing jpage editor should be reused by just dropping into a view which wrappers it. The only issue to iron out is the editor's fileinput.
marking as later again. We are investigating the use of embedded editors to assist with the scrapbook issue of "keeping up with the Java editor", and considering moving the scrapbook to a view/console, rather than an editor. However, we have not committed to it for 3.1, as it is dependent on resources, and embedded editor work.
*** Bug 129006 has been marked as a duplicate of this bug. ***
Is this going to happend for 3.3? There is already have Display view, why not allow to have multiple isntances of it and permit to execure outside of the debugged process...
The issue for our team is resources... i.e. we aren't planning to do this for 3.3 as we don't have the people power.
Darin, How much work do you estimate it to be? There is already support for editing files that don't link to files. Is it an editor issue or a debug issue (debug attributes like source attr?) Maybe somebody on the CC list can help....
This is mostly an editor issue. The current scrapbook is way behind the Java editor in terms on Java editing features (code suggest, etc). The Java editing features are not easily extended into other editors/views (i.e. cannot be re-used). The Display view also lags behind in Java editing features. This can lead to much code duplication. We have considered doing away with the scrapbook, and just supporting snippet evaluation from a Java editor.
With that said, there are also debugging issues. We use different evaluation engines based on context (i.e. an existing debug context or a scrapbook), and the evaluation actions would need to be enhanced to be able to handle this. It might not be rocket science, but it is a reasonable amount of effort. The exact amount of effort depends on what sort of editing features you want to get in the end result.
I think these are separate issues. This bug isn't about catching up with the Java editor, just making the scrapbook "file-less". Maybe the current implementation can be easily adopted. Anyway, what about the java-like editors (like JSP editor)? If I remember it right, there is something like that in eclipse now. Is it possible to base the scrapbook editor on that kind of editor? Anyway, I believe a simple workaround like having a default name would be ok for most people. I think you already auto-create and name files when pasting jave code from clipboard.
>The Java editing >features are not easily extended into other editors/views (i.e. cannot be >re-used). Just to clarify: this is not really true (at least not in regards with this PR). If you can't edit/run/debug a non-workspace and/or non-existing file then it's the lack of support from JDT Core (an/or Debug) - not the editor infrastructure. AFAIK the only missing editor code which you indeed have to copy into some "Open Untitled Scrapbook Page" action is: return new NonExistingFileEditorInput(fileStore, TextEditorMessages.NewTextEditorAction_namePrefix); and then you can call IWorkbenchPage.openEditor(input, editorId);
As suggested on EZ, I'm trying to get some more interest in this bug. CC guys: If it matters for you - pls vote for it before it gets resolved again.
I don't think this would be that hard to implement at all with the current Java editor. After all, you've got the ability to use the 'show source of selected item only' in a Java editor; in essence, everything in the scrapbook is (currently) implemented as a main method. So all you need to do is focus on the contents of that method, and have the current mechanism to add appropriate import statements. With the new resources not having to be backed by a file, it doesn't sound implausible that you wouldn't even need to have a file resource to make it happen. It doesn't even need to support highlighting specific code -- which seems to be a spectacularly bad UI design -- you could just run the whole block in one go.
*** Bug 158282 has been marked as a duplicate of this bug. ***
By the way, we also have Display view, which only work while in active debug session. I think that view can be reused for running some snippets using java project context (classpath and jre) from currently selected project/editor...
a temporary solution might be for the default scrapbook page to be created in the workspace and not on a per-project-basis. that would also allow use of scrapbook without having a project.
Nothing planned for 3.3. We simply do not have the resources.
Ah, another bug hits the RESOLVED NEVER bitbucket. Whilst I appreciate that there's only a finite amount of resources and a seemingly infinite number of bugs, what benefit does the RESOLVED LATER moniker actually do? Why not leave it in the OPEN state like all the other open bugs that haven't been resourced?
Each component manages open/resolved bugs in their own style. The debug component tries to keep the open bugs to a minimum (those we may fix in a release - noted with target milestones). We set others to RESOLVED-LATER. Admitedly, our inbox (open bugs without milestones) has grown between 100 and 200 over this release, but we will be addressing this over the next milestone.
Of course, I'm just an interested observer and have no right to say how other people should use bug tracking systems, but it's a fairly unique perspective in the open-source world. In fact, Bugzilla doesn't ship with a RESOLVED LATER state pretty much because no other open-source project tries to mask open bugs as resolved ones. It seems to me that setting a milestone to LATER whilst leaving the bug in an open state would allow the appropriate project reporting and filtering (in terms of deciding which bugs are left) and would in addition avoid the spam sent out when the bug changes state. Once in an open-later state, it would only need to be updated as and when it gets scheduled or fixed (or someone contributes a state). This bug is a good example of what happens to a bug which ping-pongs bewteen open and resolved. This bug has gone through 10 state changes in its life, along with the 13 Cc'ers and voters, and approximately the same has happened each time. Lastly, masking it as RESOLVED when it's still open means that anyone who's interested in submitting a new bug is far less likely to submit a duplicate one if it still shows up as open, instead of RESOLVED. This also has an effect when e.g. at last year's EclipseCon there is a set of statistics that show the number of NEW/ASSIGNED/RESOLVED bugs -- this category of bugs are still open, yet are being counted as closed. So, the question I'd like to find out the answer to is "why can't you use a target milestone of LATER instead of a separate RESOLVED state to categorise these bugs"? It seems that queries could easily be able to filter between these things. JDT/Debug has 477 RESOLVED LATER bugs: https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=JDT&component=Debug&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&resolution=LATER&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Bugs against JDT/Debug with a target milestone of not LATER (114): https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=JDT&component=Debug&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=target_milestone&type0-0-0=notequals&value0-0-0=LATER Bugs against JDT/Debug with a target milestone of LATER (0): https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=JDT&component=Debug&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=target_milestone&type0-0-0=equals&value0-0-0=LATER
Note that the Future and Later milestone targets are not available to the "Eclipse" project. On the Search page, if you select "Eclipse" as the project, those tags disappear/are not available. I didn't even know they were there...
Each product (e.g. JDT) can define its own milestones. That's why e.g. Eclipse is on 3.3, whereas (say) TPTP has milestones in the 4.4 range. The reason it disappears for the Eclipse project is that (currently) there is no milestone defined as 'LATER' but that's a trivial thing for a bugzilla admin to create. http://www.bugzilla.org/docs/2.16/html/programadmin.html
As to the bug itself, I don't hold much hope for this bug to be resolved. Of course I think it's a pity, because since 2001 when it was opened somebody could take the time to implement it (i don't think that for an somebody from the JDT team it would take more than 2 weeks to implement, test and write the news¬eworthy). (I also don't think it's an appropriate bug for a contribution because goes deep into the internal code and I've had some bad experience doing that.) Anyway, I actually see the scrapbook going from being one of the Eclipse hightlights to being buried deep in the ledgers of cvs history. I think that Alex is right about the intersting history of this and other bugs and their appropriate state. But does anybody have any statistics about bugs being fixed after being initially resolved as later (or with a LATER milestone)?
Re: comment #42, there was some discussion regarding the stats in bug 157642, suggesting that this level of bugs make up approximately 3% of eclipse generally. Of course, the numbers are somewhat skewed depending on which project you look at; for JDT/Debug, there's about 75% LATER to 25% open or thereabouts based on my earlier queries in #39.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
Hi, I'd like to reopen this bug for a reconsideration. Eclipse has evolved greatly since the bug was originally filed, and also since it was closed, and maybe it's easier to implement than it was 13 years ago.
