This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 6050

Summary: Faster alternative to EditorCookie
Product: platform Reporter: Jaroslav Tulach <jtulach>
Component: TextAssignee: issues@editor <issues>
Status: RESOLVED WONTFIX    
Severity: normal CC: dkonecny, issues, jglick, mpetras, pkuzel
Priority: P2 Keywords: API, ARCH, PERFORMANCE
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 38273    

Description Jaroslav Tulach 2000-03-28 20:50:45 UTC
[JST]

First of all let`s rename the cookie to UnicodeCookie or
EncodingCookie. Then let`s delete the FileObject parameter
from the parameter, so we get

Reader getReader ();
Writer getWriter ();

And now lets talk about the EditorSupport. I think that it

should implement the cookie and when someone asks for a
reader from already opened document it should receive the
content of the document not the file on disk. Similar
approach could be used when somebody needs to Write to an
opened document. The document should be emptied and the
output written to it.

Does this sound better?


[Jesse]

Sounds better to me at least. If I had KC 0,50 for every time I have written code such as:

	Document d = edsupp.getDocument ();
	if (d == null) {
	  fileobj.getInputStream () ....
	} else {
	  d.remove (0, d.length ());
	  d.insertString (...);
	}

This is a pain. BTW I assume that printing to the writer will leave the document modified? Only if the document was already open, only if already open and modified, or always?


A related thing...there is no FileObject.getOutputStreamAppend(FileLock) or similar. So if you need to append to something you have to read its contents, then write them back, then write more stuff. M
inor annoyance. Same annoyance with getWriter(). Implementing getWriter in append mode would be just as easy as overwrite mode. And for most FileObject impls, an append output stream would be very eas
y to do, or as a default concrete implementation use a static method in FileUtil to read, save, get output stream, write back, and return the output stream still open and ready to append.
Comment 1 Jaroslav Tulach 2001-03-13 10:34:37 UTC
Is somebody really intersted in this? I can see no huge requests...
Comment 2 Jaroslav Tulach 2001-06-04 16:48:06 UTC
Marek, if you have time, consider adding this cookie and implementing it
correctly in CloneableEditorSupport.
Comment 3 mslama 2001-10-15 11:19:24 UTC
Reassign to new owner of openide/editor
Comment 4 _ pkuzel 2003-12-18 18:41:36 UTC
This cookie could be used by scanners. Currently search and TODOs
functionality. I plan to profile scanning from Documents to find out
whether document loading is bottleneck or not.
Comment 5 _ pkuzel 2004-01-14 19:39:30 UTC
For JavaDataObject I get 50% gain by using direct access
(Util.getContent() in java module) comparing to document based access.

Document loading was 20% of my overall algorithm so I got 10% speedup.

I do not know if anybody needs the Writer (also there is the semantics
prob Jesse described).

One semantical note, the Reader should eliminate guarded section markers.
Comment 6 _ pkuzel 2004-01-28 09:31:09 UTC
Definitelly more important than issue #38218.
Comment 7 Jesse Glick 2004-05-17 04:49:00 UTC
Ah, here is the long-lost RFE I was looking for. :-)
Comment 8 Jaroslav Tulach 2007-10-18 08:34:01 UTC
There FileEncodingQuery now:
http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-queries/apichanges.html#FileEncodingQuery
Comment 9 Jesse Glick 2007-10-18 17:00:35 UTC
FileEncodingQuery would be helpful in implementing this, but it is not the same. This is about having a single method
pair to read or write from a given file - using the Document if it exists, else directly using the FileObject streams
(which would require FEQ).
Comment 10 Antonin Nebuzelsky 2008-04-17 15:14:36 UTC
Reassigning to new module owner mslama.