Feature/line numbers - issue #79

[nigelkerr]

A draft pull-request for issue #79, feature-request for line numbers. I have used the build Github Action as-is successfully in my fork of this repository,

Add line numbers to the editor display, configured with a preference.

The LineNumbersView class is added, providing a rowHeader to the JScrollPane component of OurSyntaxWidget, based on data and events from the JTextPane pane. LineNumbersView receives updates to the line-numbers preference, and also to the font-name and font-size preference, because we draw the line-number display in the same font as the main document. LineNumbersView follows the anti-aliasing strategy expressed by the OurAntiAlias class, by anti-aliasing when we believe we are on a Mac or on Windows. The view of the line numbers scrolls with the contents of the text pane, and the line of text where the caret is will have it's line number in red. The LineNumbersView sets itself to 0 width, or a calculated width, depending on whether OurSyntaxWidget constructed or informs it later whether to display.

The line-numbers display well up through 999, having a margin designed currently for three digits of the current font and font-size. If Alloy specs in the wild commonly go to a longer length than that, this needs revisiting.

The preference for displaying line-numbers is in the Alloy Preferences window, in the Editor tab, at the end of the list of preferences there. The current value appears in the Options menu at the end of the third section, in the same section with the preferences from the Editor tab.

My user level testing has involved:

• a Windows 11 machine, building with java8
• a Macos 11 machine, building with java 8
• sequences of:
  • launch with the preference set already, or unset
  • open three tabs through a mix of opening documents, and typing in blank tabs
  • scroll each document
  • toggle the preference, expecting the line-number area to appear or disappear
  • type something in each document at the start and end
  • introduce errors in the Alloy spec, execute something to get the error recognized and the caret to be at the error
  • toggle the preference, expecting the line-number area to appear or disappear
  • exit

Has not been tested notably as a user on a Linux machine at all, other than the Github Action for pull-requests on this repository.

I would value comment and critique, and if any here have ideas about more substantive unit testing.

[nigelkerr]

Hello @pkriens , I think I've made a few faux pas here with this draft pull request. One of them was not drawing anyone's attention to it directly, and since the PR has been open, I've thought of better ways to do the thing. Unless you have a reason to not, I'd like to close this without comment and come back a bit later.

If there are other things I've not done well, do advise. I did use the github actions in my fork, I didn't bother trying to set up travis-ci, since that seems to be the way things work now, though I admit I may have that wrong, too.

All the best, Nigel Kerr

[pkriens]

Np, take your time ...

The travis stuff will disappear soon since it works on Github Actions now. However, shouldn't make a difference for a PR like this?