Enhancement - show number of lines in Statistics Line.

[grege2]

Nedit doesn't show the number of lines in the Statistics Line. We have filepath byte nnn of mmmm on the left, and on the right L:nnn C:nn. Possibly this is because it used to be expensive to constantly re-calculate the number of lines, esp. for a very large file - some sort of scan to the end of the buffer could be needed, after every keystroke maybe.

But I see from the code that nedit-ng is always recalculating stuff to do with line numbers, and may even know the total number of lines all the time.

And anyway I'm thinking nedit-ng is way more efficient than nedit-X11 (*), and computers are way faster with way more memory and SSD paging than in the 90's, and we could revise these sorts of limits by 100x or even 1000x.

IMO it would be very useful to see the total lines in the current buffer, displayed in the Statistics Line or elsewhere. I'm always going to the bottom of the buffer, just to see how many lines I have, a bit clunky.

To contribute something on this, here's a macro that displays the number of lines in the current buffer/tab/pane in a Dialog. It works fine, ie. responsive immediately, in say a 12,000 line code file, and in an artificial buffer of the same file copy/pasted to 1,000,000 lines.

define show_num_lines_in_file {
   orig_pos = $cursor
   orig_line_num = $line
   top_line_in_pane = $top_line
   end_of_file()
   total_lines = $line
   set_cursor_pos(orig_pos)    # restore cursor pos
   scroll_dist = $line - top_line_in_pane
   scroll_up(scroll_dist)      # adjust pane scroll position
   dialog("Lines = " total_lines, "Ok")
   # debug  
   # dialog("Lines = " total_lines   " (line " orig_line_num ", top pane line " top_line_in_pane ", scroll dist " scroll_dist, "Ok") 
}

For consideration at your leisure.

(*) transparent flattery

[eteran]

Not a bad idea at all, I'll see where it would make sense to add it to the status line :-)

[tksoh]

I believe we should take this opportunity to 'modernize' the stat line. There are a lot of good examples out there we can learn from.

First of all, I think the full path name display is not very economical -- the same info is already displayed on the window title, and the only use AFACT is to let user copy the path. If we provide the ability to copy the path, say on the tab context menu (notepad++ does that), then that would free up a huge chunk of space for other much more useful info.

Qt Creator has come interest use of the stat line of the the source code editor. And Notepad++ is probably a very typical example of the new breeds of editors.

We could brainstorm a bit on what are the potential candidates.

[tksoh]

This idea came after the other discussion on extending the language modes, where we talked about having a console to capture the warning/errors/messages from nedit...

Perhaps we can add a flashing red dot or something to alert users on the new messages, so we don't have to keep popping up the console, which can be annoying at times. Users can click on the dot to open the console to view the messages if they want, or we can add an option to bring up the console automatically.

[eteran]

A dot is a good idea!

[tksoh]

Just a thought. Should we considering adding a status bar at the bottom of the windows. It's very common practice these days, and we don't have to left the statistic line alone -- one less thing to worry about on the 'backward compatibility' list, so we are free to implement anything we see fits.

FWIW, I really like the ability to interact with the info on the status bar, like changing the EOL format, language mode, etc.

[tksoh]

Here's an example from PyCharm. Notepad++ is similar, but use the right-click instead.

[eteran]

A status line of that kind is something I've been thinking about for a while for sure.

[grege2]

The status "bar" looks good. You could pack a lot of summary status in it. Maybe you could flag any setting different from your default one in red.

[tksoh]

Off topic: folks here seems to view "status bar" as a misnomer. I wonder if there's something I am missing. Even Qt has a QStatusBar widget ;-)

https://en.wikipedia.org/wiki/Status_bar

[eteran]

LOL, I tend to use status-bar and status-line kinda interchangeably :-).

[tksoh]

Perhaps we should start discussing on what to add to the status bar? I will start the list of potential candidates below:

• file size and total lines (click to show full file stat)
• language mode (click to select another mode)
• line, column number of current cursor position (click to change line, or offset from 1st char)
• line-ending style (click to change)
• encoding (click to change)
• tab size (click to bring up Tab Stops dialog)
• Insert/overwrite mode (click to toggle)
• read-only mode (click to toggle)
• VCS info and/or status (click to show detail and menus)
• a flashing dot/bell for error/warning/messages from t_print, etc (click to open log window)

We can hover to show more info, so we can make each item more compact, thus allowing more room for other items.

Please share your suggestions.

[eteran]

Excellent list. I can say that file size is technically in there since we show:

/path/to/filename byte <index> of <size>

[tksoh]

Excellent list. I can say that file size is technically in there since we show:

/path/to/filename byte <index> of <size>

Do you mean we don't need to display that info on the status bar also?

[eteran]

Oh! You are thinking of the Statusbar as a seperate thing from the "status line"? I see.

I was originally thinking that we'd be enhancing the status line and making it able to be either at the top or bottom of the editor.

[anjohnson]

A comment on the current status line: I rarely have it visible, just enabling it when I want to see the line or column. I see the file path there as a waste of space since I already have the path visible in the window's title bar and the filename in the tab as well:

Note that there is no "byte <index> of <size>" there either, not sure where @eteran is seeing that (or is my path just too long for it to appear?).

The Window Title is customizable (nice) and others might not include that, but maybe the status line could be similarly customizable? You could even use the same set of components (and the same dialog box?) for both. Adding flags to the format to set the alignment of different parts would be interesting too, so maybe "left < center > right" (not sure if that's possible for the window title though). I might add the line number & column to my Window Title instead of enabling the status line.

[eteran]

I agree that the path is redundant and frankly, so is the filename. I see "CONFIG_COMMON" in three places in your screenshot!

Adding a "copy path" to the tab context menu @tksoh is an elegant solution for sure. I know some users will be temporarily confused by it though. So perhaps there should be a config option of "modernStatusLine" for the transition period of 5->6.

And once we have most users using "nedit-6", we can start making the modern stuff just how it works?

I dunno, open to suggestions on that one. Maybe we can just say "new major version, some things are gonna be different"?

As for the details of what's shown, there are actually two variants possible depending on if you have show line numbers enabled :-). Not 100% why the two MUST be connected, but they indeed are in nedit5.

[anjohnson]

depending on if you have show line numbers enabled

Ahh, that explains it. BTW when I turn that on (which doesn't immediately refresh the status line BTW so I have to move the cursor for the status line to change format) the total bytes number gets clipped, presumably because of my long paths. It should show 16517 here:

[eteran]

Yea, if there's no room, it will get truncated. Not much we can do about that so long as we are showing the path.

[anjohnson]

Not much we can do about that so long as we are showing the path.

The path already has the ability to be truncated (there's an ellipsis in the middle of it here):

I suspect the problem is that the math for the max width of the path text doesn't properly allow for the longer "byte n of m" message when line numbers are displayed. It would be better to truncate more of the path than to clip those numbers.

[grege2]

My thoughts ..

The only thing I've consistently missed over the years is the total lines in the buffer (hence this RFE). But I never need the "byte" of "total bytes" info. I'd be happy to have that replaced by "lines / total lines", and the bytes info could be demoted to somewhere optional. That would free up some room. Or the L:123 C:55 could become L:123 of 456 C:55 (that would be fine for me).

All the other info that could be in the Statistics Line, or a Status (Under-)Bar looks great. I guess if both are present they should be dismissable/recallable with the same command. Two lines of status is using up a bit of your editing space. Especially if you're working in a "squeezed" way trying to keep a lot of stuff open and reasonably visible.

I can throw in a thought here. The screen space used by nedit things may be more, or less, important to different users. Since X11-nedit was created, the world has moved on to much bigger and higher-res screens, Retina screens that make denser info nicer, dual or triple screens. Some users may be squeezed for space on a little laptop device, or on a train/plane, others may be sitting in front of a couple of big hi-res screens with tons of room. Maybe we could consider a "compact" and an "extended" display of some things.

Ciao.

[eteran]

@grege2 I totally agree that NEdit's minimal wasted space in the UI is a big part of its appeal.

[tksoh]

Personally, I prefer a new status bar at the bottom, or even on top (as long as it's configurable), of the editor window.

I've been reading Joel Spolsky's blog lately (thanks to @sjtringali, though I wished I had discovered it 20 years earlier), specifically this one in this case. Status bar is becoming quite a norm on IDE/editors nowadays, especially on Windows. If we, hopefully, intend to attract new users, then we need to adapt to the norm a little, as long as it doesn't take away NEdit's uniqueness. This is of course somewhat philosophical :-)

Having a new status bar will preserve the original statistic line, so whoever might still be loving it so much can continue to maintain their romantic relationship, while the rest of us get the the spanking new status bar with all the info that help make our practical life more productive -- best of both world. Being nedit, we will always get an option to decide which one to use, or both. That goes to the issue of transitioning.

BTW, hacking on trains/planes should be considered harmful ;-)

[tksoh]

Adding a "copy path" to the tab context menu @tksoh is an elegant solution for sure. I know some users will be temporarily confused by it though

I hate confusions. Perhaps we can put it under the File menu instead. This is after all about a file.

While we are there, maybe we should also add a menu to open the folder containing the file? ;-)

[tksoh]

A dot is a good idea!

I added this to my original list

[eteran]

I hate confusions. Perhaps we can put it under the File menu instead. This is after all about a file.

Well, I think that would be a pretty unconventional feature for a File menu. I don't think I've seen any editors that offer something like a "copy filename to clipboard" feature under File. So I think adding it to the tab context menu is a decent option.

To be clear, I don't think there would be confusion over how it works. More like confusion over "I used to be able to copy from the statistics line, and now that went away".

I don't think a NEdit user would intuitively decide to look anywhere else in particular for such a feature. Be it a tab context menu, or an entry under the file menu. I'm not sure they'll assume it "moved" at all. But then again, I'm just guessing at what other people would be thinking 🤷

So if we're gonna move it away from the stats line, we probably should just pull the bandaid and move it, with a note in the changelog.

One thing to keep in mind.

I've been thinking about when to do the "Nedit-6 release" and what should be the milestone to shoot for.

I think that we've done a good job of ironing out nearly all of the little differences between NG and nedit5 that aren't deliberate choices. And that the last few remaining macro functions are really the big blocker. I think that once I've implemented those last macros, that we should call it "6.0" and officially re-brand things a NEdit-6.

Then 6.1 could target more of these wishlist changes where we would be actively altering UI behavior and stuff.

Does that make sense?

[tksoh]

To be clear, I don't think there would be confusion over how it works. More like confusion over "I used to be able to copy from the statistics line, and now that went away".

So if we're gonna move it away from the stats line, we probably should just pull the bandaid and move it, with a note in the changelog.

The general assumption is that nobody reads manuals, let alone changelog. I think we should keep stats line in 6.0, that way hopefully by the time we remove/hide it in 6.1, they should already know about the context menu.

I've been thinking about when to do the "Nedit-6 release" and what should be the milestone to shoot for.

Backward compatibility is certainly on top of the list, which include macros too, naturally. But IMHO, we would need something significant enough to entice the existing nedit-5 users to switch/transition in. I don't think they care if it's now based on Qt, instead of Motif. Instead, we will probably want them to think "here's a new nedit, which works like the old one, and then there's this great new feature that would help make my life much easier". The availability on Windows is a great leap technically, but that probably mean nothing to those on Linux (not sure about Mac)

[eteran]

But IMHO, we would need something significant enough to entice the existing nedit-5 users to switch/transition in. I don't think they care if it's now based on Qt, instead of Motif. Instead, we will probably want them to think "here's a new nedit, which works like the old one, and then there's this great new feature that would help make my life much easier". The availability on Windows is a great leap technically, but that probably mean nothing to those on Linux (not sure about Mac)

Sure, I do think that NG has some pretty noteworthy advancements beyond just using a new toolkit :-). The list I'd make probably includes:

• HiDPI support
• Antialiased fonts
• native macOS and Windows support
• Better font support
• modernized UI
• Minor bug fixes

Personally, I would consider that enough to justify a point release for any application, but obviously, a lot of this boils down to opinion.

One way or another, we should establish some target milestones to say "this is enough of an improvement to justify a release", what that list of milestones is, I'm definitely open to discussing :-)

[sjtringali]

Here is my suggestion. Soon, stop new feature development, or at least, move them over to a separate branch destined to be 6.1. (You could also elect to use the SF site as a 6.0 release branch, somehow I doubt it.) Focus like a laser on making as compatible as possibly, avoiding features, and bug-free as possible. Pretty standard in the industry and how I ran NEdit, I would branch off for the beta. People interested in features continued on the mainline, the branch was restricted to bugfixes and RCs, the final release is done off the branch, and merged back to mainline. These days the branches might be swapped around a bit, but that's orthogonal to the concept. I've noticed a few bugs, that I've not yet reported. Ctags didn't work, the nc/nedit server interaction wouldn't raise focus, nc -wait seems broken, the externally modified file notification seems unreliable, lots and lots of dialog mneomnics are missing. Additionally, it means means, making all the core editing and top-level UI elements as close as possible to classic. Menus, mnemonics, shortcuts, dialogs (are not replaceable by canned ones, see below). All that keyboard muscle memory built up over time, is worth preserving. Break it at your own peril. Adding things like anti-aliased fonts don't break muscle memory, so they are in a category where it's essentially cost-free to users. As when to changing UI elements intentionally: The thing to remember is a lot of the weirder things in NEdit were to work around limitations of Motif. For example, there is no point in preserving the old font chooser or file-open dialog box. Motif's was a flaming trainwreck of usability horror, and we tried to beat in into shape. The font chooser had to work around X's rather obscure font specifications. When there is a standard/familiar equivalent, changing standard dialogs is a good place to break compatibility. I think the status line eventually should be on the bottom, it's what people expect. These things are straightforward transformations that don't add features. TLDR: 6.0 - Keep the UI as close as possible to Classic, except for horribly awful dialog boxes that have canned Qt equivalents 6.1 - Refactor the UI to be less messy and take advantage of Qt's modern widget set, but generally avoiding add new UI features. Same UI feature set, just cleaner. 6.2+ - Anything! As always, refactoring stuff in the codebase is always a good idea. On Thursday, December 31, 2020, 11:39:12 AM EST, Evan Teran <[email protected]> wrote: But IMHO, we would need something significant enough to entice the existing nedit-5 users to switch/transition in. I don't think they care if it's now based on Qt, instead of Motif. Instead, we will probably want them to think "here's a new nedit, which works like the old one, and then there's this great new feature that would help make my life much easier". The availability on Windows is a great leap technically, but that probably mean nothing to those on Linux (not sure about Mac) Sure, I do think that NG has some pretty noteworthy advancements beyond just using a new toolkit :-). The list I'd make probably includes: - HiDPI support - Antialiased fonts - native macOS and Windows support - Better font support - modernized UI - Minor bug fixes Personally, I would consider that enough to justify a point release for any application, but obviously, a lot of this boils down to opinion. One way or another, we should establish some target milestones to say "this is enough of an improvement to justify a release", what that list of milestones is, I'm definitely open to discussing :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[sjtringali]

PS: I think the modern font support ALONE is worth a 6.0, let alone the extra niceties we get for free from Qt. We had to wait forever for Motif support it. By the time they did, we lost the developers to code it in the main text widget. I hated the nasty fonts and and changed the widgets over ASAP, but that was long after development stagnated. On Thursday, December 31, 2020, 12:10:50 AM EST, TK Soh <[email protected]> wrote: To be clear, I don't think there would be confusion over how it works. More like confusion over "I used to be able to copy from the statistics line, and now that went away". So if we're gonna move it away from the stats line, we probably should just pull the bandaid and move it, with a note in the changelog. The general understanding is that nobody read manuals, let alone changelog. I think we should keep stats line in 6.0, that way hopefully by the time we remove/hide it in 6.1, they should already know about the context menu. I've been thinking about when to do the "Nedit-6 release" and what should be the milestone to shoot for. Backward compatibility is certainly on top of the list, which include macros too, naturally. But IMHO, we would need something significant enough to entice the existing nedit-5 users to switch/transition in. I don't they care if it's now based on Qt, instead of Motif. Instead, we will probably want them to think "here's a nedit, which works like the old one, and then there's this great new feature that would help my life easier". The availability on Windows is a great leap technically, but that probably mean nothing to those on Linux (not sure about Mac) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[eteran]

I've noticed a few bugs, that I've not yet reported. Ctags didn't work, the nc/nedit server interaction wouldn't raise focus, nc -wait seems broken, the externally modified file notification seems unreliable, lots and lots of dialog mneomnics are missing.

Please do file bug reports so I can iron out all those details!

I can say that some things on this liat appear to work fine for me, so reproduction instructions would help a LOT! 🙂

[eteran]

@sjtringali

So I think I have addressed all of the missing accelerators, please let me know if any are outstanding.
I also think that the nc not raising the window has been fixed in an already merged PR.

Regarding the other issues, please let me know what else is still not quite right. Especially regarding ctags not working, an example file triggering the failure would be fantastic if it's still an issue.

[sjtringali]

Yeah. I noticed a few things when using it for work, I’m usually pressed for time and hack at him. Will get to it.. if not fix it myself.

…

On Dec 31, 2020, at 10:37 PM, Evan Teran ***@***.***> wrote:  @sjtringali So I think I have addressed all of the missing accelerators, please let me know if any are outstanding. I also think that the nc not raising the window has been fixed in an already merged PR. Regarding the other issues, please let me know what else is still not quite right. Especially regarding ctags not working, an example file triggering the failure would be fantastic if it's still an issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[grege2]

In the discusion of what is worth putting in a 6.0 release, don't forget that as of Catalina the Mac cannot run the old 32-bit Nedit5 binaries. Which is what made me go hunting for a solution and ended up here. So the Mac users will be incredibly grateful for a 6.0 release, whatever it is. Catalina is about 15 months old now and Big Sur is out, and the pressure for Mojave users to upgrade is building.

I wonder is there any way to estimate the user community numbers ? Windows, Linux, Mac.

[sjtringali]

I agree completely. Best to put all new features on a separate branch and focus on bugfixing and feature completeness. On Tuesday, January 12, 2021, 11:57:49 PM EST, Greg E <[email protected]> wrote: In the discusion of what is worth putting in a 6.0 release, don't forget that as of Catalina the Mac cannot run the old 32-bit Nedit5 binaries. Which is what made me go hunting for a solution and ended up here. So the Mac users will be incredibly grateful for a 6.0 release, whatever it is. Catalina is about 15 months old now and Big Sur is out, and the pressure for Mojave users to upgrade is building. I wonder is there any way to estimate the user community numbers ? Windows, Linux, Mac. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[tksoh]

I agree completely. Best to put all new features on a separate branch and focus on bugfixing and feature completeness.

I'm not familiar with that term, what do you mean by feature completeness here?

[sjtringali]

Complete as being a 5.6 clone (keeping the new Qt stock dialogs like the file chooser). I'd honesty extract any new visible UI changes into the branch if it's easy. On Wednesday, January 13, 2021, 08:36:27 AM EST, TK Soh <[email protected]> wrote: I agree completely. Best to put all new features on a separate branch and focus on bugfixing and feature completeness. I'm not familiar with that term, what do you mean by feature completeness here? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.