Community
Participate
Working Groups
Many times I've used different editors instead of Eclipse to see how many characters are selected or at which offset (from beginning of the document) the cursor is positioned. I have no idea why Eclipse does not provide this basic information - by default, it shows only current line and column in the editor status line. So currently we see this: 42:1 for the cursor at line 42 at the line begin. I propose to additionally show current cursor offset, or, if editor has selection, count of selected characters. So 42:1 => 42:1:1234 without selection (cursor at offset 1234) and 42:1 => 42:1[123] with selection containing 123 characters. I understand that this is some basic feature of all text based editors in Eclipse, so we probably want to add an option to switch this information off, for those who should be offended by a new feature. I will provide a patch to demonstrate what I mean.
New Gerrit change created: https://git.eclipse.org/r/146707
See screen shots at https://javaclipse.blogspot.com/2019/07/pimping-status-line.html
(In reply to Andrey Loskutov from comment #0) > So > 42:1 => 42:1:1234 without selection (cursor at offset 1234) > and > 42:1 => 42:1[123] with selection containing 123 characters. While I like the overall feature, I'm not sure about the readability of all this. I suggest something more explicit, like "line:42 column:1 offset:1234" and "line:42 column:1 length:123" to clarify it.
(In reply to Mickael Istria from comment #3) > (In reply to Andrey Loskutov from comment #0) > > So > > 42:1 => 42:1:1234 without selection (cursor at offset 1234) > > and > > 42:1 => 42:1[123] with selection containing 123 characters. > > While I like the overall feature, I'm not sure about the readability of all > this. > I suggest something more explicit, like "line:42 column:1 offset:1234" and > "line:42 column:1 length:123" to clarify it. There is no place in the status line for such info, I think many editors just show the pure data. Also since this is "live" data, it is easy to understand what is what just by watching the changes.
(In reply to Andrey Loskutov from comment #4) > There is no place in the status line for such info, Both in my IDE and on your screenshots, I see a lot of space on the status bar left, and also a lot of space wasted by other "cells". So I'm not convinced that "there is no place". > Also since this is "live" data, it is easy to > understand what is what just by watching the changes. So it means that this feature requires a change on cursor position to be usable. It's indeed a common case, but why making it a requirement when we could improve the text directly to make it understandable even if there is no change?
I think there are valid arguments both for making the output more readable and for using as little space as possible. Maybe we can make the compromise between the plain text being short, but a hover on it displaying the full text as requested by Mickael? We could even have the current text in the statusbar remain as it is right now, and only provide a hover that has all the information, including the textual prefixes suggested by Mickael. That being said, I personally find the notation x:y:z very confusing. If we really want to display all 3 numbers without any text, I would suggest using a different separator for the offset (and more space in front of the offset than between x and y). "x:y @z" maybe? PS: I have not checked if hovers are actually available for plain statusbar contributions. I vaguely remember this to be difficult...
What about "l.32 c.1 i.123" with i for "index" (which is more common than "offset" in the outer world)
(In reply to Mickael Istria from comment #7) > What about "l.32 c.1 i.123" with i for "index" (which is more common than > "offset" in the outer world) Mickael, I would propose to move this discussion to the dedicated bug *how* do we represent values in the status line and how this could be improved. We can discuss there if we should increase the area of the status line where this info is shown, etc. (In reply to Michael Keppler from comment #6) > I think there are valid arguments both for making the output more readable > and for using as little space as possible. Maybe we can make the compromise > between the plain text being short, but a hover on it displaying the full > text as requested by Mickael? > We could even have the current text in the statusbar remain as it is right > now, and only provide a hover that has all the information, including the > textual prefixes suggested by Mickael. This is good idea. You will see that today if the status line has not enough place, it shows the full content (without any extra info) in the tooltip. We can improve that and provide *longer* version of the content with clear wording "Line: 123, Column: 42, Cursor : 123456". Unfortunately, after quick check how the code is structured, I fear this is a bit more complicated as it sounds, because the affected code in AbstractTextEditor is protected and so we can't change interface etc easily. > That being said, I personally find the notation x:y:z very confusing. Same applies to x:y, which seem to have not collected any attention so far. I've quickly checked what the other programmers editors do and I see following: * IntelliJ Idea: x:y * vim / gvim: x,y * emacs: Lx by default or "x,y" if "show column" is there * PSPad : x : y / z [ total ] and X x Y [z] in selection case * Notepad++ : Ln :x Col: y Sel x|y * VSCode Ln: x Col: y I didn't noticed anyone writing "Line: x Column : y" yet, but this is not representative list of course. Let say, the market leader uses x:y and the second one too, and I guess this representation is what is OK for most users, or they simply don't care, which is also OK (low importance). > If we > really want to display all 3 numbers without any text, I would suggest using > a different separator for the offset (and more space in front of the offset > than between x and y). "x:y @z" maybe? I would propose to move this discussion to the dedicated bug *how improve the representation* of the values in the status line. It is like it is since day one, and no one complained yet, so I perceive the representation part as not so urgent, compared to the missing data part. Don't get me wrong: I *want* improve usability - step by step. First step is to provide some data, in the similar format as before, to get first usability gap fixed - missing information. Second step would be to think how we can improve representation of this data and the status line in general. Trying to do both on one task will kill both, simply due the lack of resources. We should be realistic here. I'm interested in point 1, but I have no time to work on point 2, so if we say "we want to do both in one shot", I'm not available for that, therefore I vote / ask for separation of tasks. As usually, I would like to propose the compromise *for this concrete enhancement*: 1) To keep things as simple as they can be, we will NOT enable "Show cursor position" by default - so NOTHING will change in "simple edit" use case, but users that need an offset data (me) can enable this in preferences. From the usability point of view, nothing changes for the default case, and we get a missing functional part fixed for "feature on" case. 2) Since x:y[z] for selection appears only for selection, it should be immediately clear for users that the part enclosed by brackets "[]" represent selected part of the text - so we could enable this by default without big changes in the status line representation, and without sacrificing on the usability part. WDYT?
I think this would better be enabled by default without an option to remove it. Adding options adds complexity, unless it's really clear some people won't want it at all for a reason or another, it's IMO not worth giving choice for such nice-to-have things.
As prompted from the email thread, we implemented something like this in WTP's StructuredTextEditor class as a separate status field for debugging purposes (enabled by a trace option, added from the editor contributor, it's entirely normal for people to have never seen it). I opted to have the selection's offsets, start to end, shown in square brackets, but that's largely an aesthetic choice. The value's updated with the other status fields (https://github.com/alinaMarin/webtools.sourceediting/blob/master/bundles/org.eclipse.wst.sse.ui/src/org/eclipse/wst/sse/ui/StructuredTextEditor.java#L3505) and on cursor location changes (https://github.com/alinaMarin/webtools.sourceediting/blob/master/bundles/org.eclipse.wst.sse.ui/src/org/eclipse/wst/sse/ui/StructuredTextEditor.java#L2458). https://i.imgur.com/aqx0ASa.png The main drawback is that it increases the minimum width of the window in order to show the field at all.
(In reply to Mickael Istria from comment #9) > I think this would better be enabled by default without an option to remove > it. Adding options adds complexity, unless it's really clear some people > won't want it at all for a reason or another, it's IMO not worth giving > choice for such nice-to-have things. Michael, the people are different, and providing an option is one way to make different people happy. Since this piece of code is central for many Eclipse based text editors (and so affects a lot of products) it would be better to give all those different consumers a chance to keep the "last known good" configuration - in this case via options. What about this proposal : we release the patch "as is" for M2, and if there will be no complains about the new status line, we hide the UI settings part of the patxh (but still leave the preference for product integrators)?
(In reply to Andrey Loskutov from comment #11) > Michael, the people are different, and providing an option is one way to > make different people happy. I don't trust people happiness as a metric of goodness. To me, if a feature was valuable for one user once, it is generally useful for many users who didn't realize it, and unless a feature can have negative impact, there is no need to hide it or make it optional. Making it optional just raise the development and maintenance cost. I suggest this cost gets paid by those who need it if ever they need it. > Since this piece of code is central for many > Eclipse based text editors (and so affects a lot of products) it would be > better to give all those different consumers a chance to keep the "last > known good" configuration - in this case via options. > What about this proposal : we release the patch "as is" for M2, and if there > will be no complains about the new status line, we hide the UI settings part > of the patxh (but still leave the preference for product integrators)? Those consumers should basically be the one who contribute to make it optional. Maybe you're own of them and it's fair, maybe you're not and you've invested IMO more than necessary to 1. give possibilities to people who should contribute and 2. hide new value to the million of end-users; also it brings a future potential work item to the todo-list of the project. I personally wouldn't have made it optional; but you're right, as it's here now and you implement it, no objection to merge it at it, and even leave the option forever, after all, we're not 1 checkbox more or less in preferences, are we ? ;)
Gerrit change https://git.eclipse.org/r/146707 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=9c6cbef8ec2954b57ab08f672742041eb615beb5
The status line is not updated when the preference is changed. (but when caret moves after the change) So changing the preference and pressing Apply I can not immediately see how the status text will look with changed settings without closing the preference dialog.
(In reply to Paul Pazderski from comment #14) > The status line is not updated when the preference is changed. (but when > caret moves after the change) So changing the preference and pressing Apply > I can not immediately see how the status text will look with changed > settings without closing the preference dialog. Depending on what the result state will be we may hide the preferences all together. I've initially assumed the caret changes all the time, so the change should be visible almost immediately and so we don't need extra code for prefs update. But yes, if we leave preferences, we should polish the patch.
Do you want to show the byte count or character count or both?
(In reply to Carsten Hammer from comment #16) > Do you want to show the byte count or character count or both? Just the visible character count.
What's the status here?
(In reply to Mickael Istria from comment #18) > What's the status here? I was pretty busy this days, so had no chance to work on this. So far we had no feedback about new preferences or status line itself, so I assume everyone don't care or finds it OK as it is. I've created bug 550377 for comment 14 and will address this in 4.14 time frame, because I'm going on vacation for two weeks from now, without access to PC. I would live the rest "as is" and close this bug, if there are no objections. I will try to push N&N today too.
New Gerrit change created: https://git.eclipse.org/r/148217
Gerrit change https://git.eclipse.org/r/148217 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=0c2a18b46c3dc89e5c358b8ce9d49585b67dcec9
(In reply to Eclipse Genie from comment #21) > Gerrit change https://git.eclipse.org/r/148217 was merged to [master]. > Commit: > http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/ > ?id=0c2a18b46c3dc89e5c358b8ce9d49585b67dcec9 N&N added.
(In reply to Andrey Loskutov from comment #19) > So far we had no feedback about new preferences or status line itself, so I > assume everyone don't care or finds it OK as it is. Actually my enthusiasm for this feature increased since I found use for it some times. (find offset in string while writing tests)
(In reply to Paul Pazderski from comment #23) > Actually my enthusiasm for this feature increased since I found use for it > some times. (find offset in string while writing tests) Ha, you know now where I'm coming from :-)
@Andrey, Even if I switch off the preference for selection, Isee the size of selected text like 15:82:4, After enabling the preference, I see it as 15:82[4] Am I missing anything? What is the advantage?
When text is selected, it shows only the length of the selection? It's a bit jarring.
(In reply to Sarika Sinha from comment #25) > @Andrey, > Even if I switch off the preference for selection, Isee the size of selected > text like 15:82:4, After enabling the preference, I see it as 15:82[4] > > Am I missing anything? What is the advantage? Sarika, I assume that you see the offset. I'm offline till 10.09, so I can't verify, but the idea is to show either selection size or offset, so if you see selection size *instead* of offset *and* the preference is off for selection, it must be a bug.
(In reply to Andrey Loskutov from comment #27) > (In reply to Sarika Sinha from comment #25) > > @Andrey, > > Even if I switch off the preference for selection, Isee the size of selected > > text like 15:82:4, After enabling the preference, I see it as 15:82[4] > > > > Am I missing anything? What is the advantage? > > Sarika, I assume that you see the offset. I'm offline till 10.09, so I can't > verify, but the idea is to show either selection size or offset, so if you > see selection size *instead* of offset *and* the preference is off for > selection, it must be a bug. Sarika, please check and open a new bug if this is the case. cc me.
(In reply to Dani Megert from comment #28) > Sarika, please check and open a new bug if this is the case. cc me. Created Bug 550486 and cced.
Some status and feedback, using standard 4.14.0: I discovered this bug report while googling for ways to turn this *off*. (So, evidence that the position stated in comments 9 and 12 is objectively incorrect. Things that one person thinks are generally useful should not be forced down users' throats.) Line and column numbers are very useful to me; a byte count offset in source code is not -- at least, not *by default*. It would be very useful to me if I were editing a binary file using a hex editor, but I'd expect to manually turn it on. If we could not turn this off, I would have reverted to an older Eclipse until that bug was fixed. The only problem with the implementation was the one filed as bug 550486 and already fixed. So, all good!
