Community
Participate
Working Groups
Created attachment 134414 [details] Picture of the editor tab. I was testing another bug and added a Hebrew java class. The Filename in the tab is backwards, and the hover tooltip for the tab is totally mangled. These are usually fixed by adding text processor. Tomer, Have you seen an open bug on this before (it seems like a pretty obvious one)? PW
You are correct. No,I am not aware of any specific defect on this issue. Those issues are ubiquitous. Please observe that the name of file is also not shown properly in Navigator view, while in Package Explorer view it is shown properly. Indeed TextProcessor should help here.
We'll have to defer this to 3.6 - the strings in question are coming from downstream plug-ins, and we don't know if they are already compensating for the fact that we don't currently run those strings through TextProcessor. Does anyone know if TextProcessor.process is idempotent?
When this is fixed, don't forget the other places where editor names and tooltips are shown, for example in the editor dropdown (Ctrl+E).
Remy is now responsible for watching the [EditorMgmt] component area.
(In reply to comment #2) > Does anyone know if TextProcessor.process is idempotent? This appears to be the case. // do not process a string that has already been processed. if (str.charAt(0) == LRE && str.charAt(str.length() - 1) == PDF) { return str; }
On further reflection, we might have to document this. I don't think we can blindly run our label through TextProcessor. 1) only the editor part knows what it is. Most of the time it is the editor input, and most of that time it is a IFileEditorInput (providing us with a filename). But that tab can have any kind of title, and things like database inputs or CVS repo specs don't conform to a filename. 2) the extension of #1 is that if we implement bug 179191 and bug 183164 we would expect the provider of the title (who understands what it is) to pick the processing to use. It sounds like the way to "get it right" is to force the clients to start using TextProcessor on anything the provide as a label. PW
(In reply to comment #6) > 1) only the editor part knows what it is. Most of the time it is the editor > input, and most of that time it is a IFileEditorInput (providing us with a > filename). But that tab can have any kind of title, and things like database > inputs or CVS repo specs don't conform to a filename. Right, so what you mean is that the default control characters from TextProcessor may not be what's desired for a particular client so they should use TextProcessor themselves.
(In reply to comment #6) > 1) only the editor part knows what it is. Most of the time it is the editor > input, and most of that time it is a IFileEditorInput (providing us with a > filename). But that tab can have any kind of title, and things like database > inputs or CVS repo specs don't conform to a filename. > > 2) the extension of #1 is that if we implement bug 179191 and bug 183164 we > would expect the provider of the title (who understands what it is) to pick the > processing to use. Well in this scenario the provider of the title is us. How about instead of randomly running TextProcessor on an editor's title and tooltip we change our FileEditorInput and FileStoreEditorInput implementations to use TextProcessor? That would certainly fix this particular bug anyway.
We will not be doing anything about these editor tab problems for now.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
