FlexGUI and PNut look and feel
ManAtWork
Posts: 2,176
in Propeller 2
Both, PNut and FlexGUI have a rather "Spartan style" user interface, until now. I think it would be nice to add some colours and all the goodies we are used to from the old Propeller tool that make life much more comfortable. I know, at the moment functionality and bugfixes have priority over cosmetics. So don't take this as complaint about missing features but rather as sort of private wish-list that can wait until next christmas...
... to be continued.
- A "recent files" menu would be nice, orr an option to load the last top level file at startup. I often switch between different projects so each time I have to browse through the directory tree.
- A navigation list of the file hierarchy (dependency tree with objects and sub-objects) of the current project would also be handy. It allows to quickly open the files you need to edit once the top level file is compiled
- Syntax highlightning helps to spot typos and syntax errors quickly. You know it... You edit a part of code and wonder why nothing happens. Then you find out that the whole part was commented out. With syntax highlighting you'd notice this immediately. There are some open source editors with configurable syntax parsers. If this is too much work simple scanning for reserved words, operators and comments would be sufficient for now.
- separate background colors for CON, PUB, DAT ... sections. This is unique to the Propeller Tool. It makes the editor window look a bit like a candy shop but I like it. You can scroll through large files and find the section you look for faster.
... to be continued.
Comments
If you don't want to wait for that, you can try SpinEdit:
https://forums.parallax.com/discussion/169259/spinedit-editor-for-spin-spin2-and-fastbasic/p1
BTW: See the end of the thread for a version that supports "Load Ram" and "Load Flash" for Spin2.
Also, try the "Brightness" slider. It keeps the same feel, but makes it easier to read text and find the cursor.
For the time being, I am using Geany. I really miss the color coding, but as I'm getting used to Spin2, I am having few issues that force me to load the file into PNut to find.
@Rayman Have you considered adding PNut to SpinEdit? For the time being, I want to stick with the official Spin2 compiler.
(It's just that the compile button doesn't do anything when PNut is selected).
Let's hope PropellerTool is upgraded to interface with Github.
BTW I extended the work based on anothers work
That reminds me of another thing: Auto-completion. Please DO NOT add this to the editor. If it's unavoidable, please make it optional. Auto-completion is handy for processors that have a 2000 pages datasheet and where you need 100s of include files with 1000s of register names. You can't remember them all so it sometimes helps if you get suggestions after typing the first characters.
But I absolutely hate it if the keyboard mapping gets context sensitive. With auto-completion the editor decides at some random point that the tab, return and cursor keys suddenly have a different meaning. That's absolutely annoying if you are used to type blindly while looking at some other window (data sheet, code example, forum site...). When you look back to what you just have typed you discover that the editor messed everything up.
With the propeller you don't need this. You can remember all important keywords and typing is a lot faster when you don't have to frequently react to surprising popup-menus.
I kind of wish, for the sake of Spin2, we had 4 spaces per tab. This would work for PASM, too, but all existing code would get messed up and Spin2 indention would look different to the compiler.
PropTool as is doesn't use tabs, spaces only. Or am I misunderstanding what you mean?
(My general opinion is that 4 spaces per indent level is good. However, PropTool's indent highlighting makes 2 spaces suffice. Spin also generally doesn't allow splitting one line into multiple (without abusing block comments to comment out the newlines), so I think 2 is better for Spin)
I think I have them converted to 8 spaces to match PNut…
But, I don't think it always works...
I wish they weren't there!
Speaking of that font... I have a couple of spin programs that use the 16x32 font from ROM on the P1. Can I legally copy that font into a P2 application? This is for noncommercial use. Not trying to stir up a hornet's nest on this.
Please do.
EDIT: I mean, please go ahead and use the font.
Go ahead and do what you want with it.
I imagine the ROM is part of that...
Oh, that's GPL'd though...
This could be useful for trying to make an on-chip Spin editor later...
Folks, please help me understand, from a user’s perspective, why multiple spaces are better than individual tabs.
If the scheme is N spaces per indentation level what then happens when the tool reads N-1 or N-2 spaces? Or put another way, what happens to my program structure if I accidentally delete a single space character?
What if I prefer a different number of spaces per indentation level? (Screen size, aesthetic preference, etc.)
This is one of the reasons the tab character exists: so that Tab spacing can be used to align blocks on separate lines.
What an I missing here?
1) there is no standard tab spacing. Is it 8 spaces?, 5? 4, 3, 2?
2) tabs can be replaced with spaces. Spaces never get converted back to tabs. Both tabs and spaces are invisible.
3) A mixture of tabs and spaces can visually look the same between given lines, and then suddenly shift around if the number of spaces in a tab is altered. Or in almost every case ever, opened in a different editor.
4)Tab is a command key like enter/return or backspace. It really should not be stored in the text file as is, but emit the configured number of space characters when pressed. But here we are in 2020 still trying to "save memory".
4) given how large the space key is, and that we put spaces between our words in sentences, it's nigh impossible to train people to only hit the tab key at the beginning of a line.
5) the solution to this problem back in the 60s and 70s was to do block level formatting. Open bracket, close bracket. If...endif. For... next. They didn't even trust a carriage return and forced that blasted semicolon upon us as the one true end-of-statement
6) if you accidentally delete a space and are only using spaces as whitespace, wsiwyg! It's visible.
1) I'm not missing that; It is part of my point. Using a single tab character - instead of some predefined number of spaces - allows different systems and people to use different tab stops to suit their preferences without disagreeing on the content.
2) Ok, but why convert tabs to spaces; if left as tabs you don't get the problems you are calling out.
3) Agreed, so people shouldn't be supported in using spaces where tabs are correct; We don't support the use of semicolons where periods should be.
4) I'm not trying to save memory, I'm arguing for consistency of representation between systems. So why convert a tab character to 'my truth' for the configured number of space characters?
4) There's an intrinsic problem in what you've written: The tab key should be used between all of the fields on the line, not just at the beginning to skip the label field. When coding we type many sequences that don't appear in natural language; moot point. You claim nigh impossibility to train people to only use a tab at the beginning of a line, but have you tried?
5) No comment; it happened before I was involved in coding, and I'm not privy to the factors involved in their decisions, even if you are.
6) Sure, with non-proportional fonts and careful attention to detail. The same is true - but more obvious - when using tabs between fields. The forum software here is a case in point: depending on the browser and font used, you can get different alignment of text using spaces while the use of tabs between fields should be consistent (although the browser never seems to accept tab characters).
Of course, you haven't actually answered the question asked: What does the tool do to my program structure if the fields are at 8 space separation and I only put 7? More importantly, why should it be making decisions this way when the use of tabs to delimit fields in text files has a long history and is one the three most commonly used in delimited files?
If you are at character column 10 and hit tab with a size 8 tab, it will take you to the 16th column. However, if the tab size is 4, then the tab will take you to the 12th column.
This is the issue when moving between editors with different tab sizes. Something that looks fine with size 8 tabs will look all messed up when view with size 4 tabs. Same goes for any tab size, I just used 4 and 8 because they are common.
If you use tabs converted to spaces instead then it's always the same no matter what editor, because it's always spaces.
1. In code (which is the context here) you are not really working with fields. You have variable length strings of code, so you either need a very large tab size or you always fail (your case 1).
2. I don't mix tabs and spaces, I use only spaces.
I've had to deal with cleaning up hundreds of thousands of lines of code with tabs that assumed the wrong size in my lifetime of coding. I and everyone I know coding for a living uses spaces instead of tabs for the very reasons I explained in my "lesson" that you dismiss.
re: "tool counting spaces"
The spin compiler doesn't care about the size of the indent when making a new scope (which is what the indenting does in spin), just that it's more than the previous scope indent amount.
You can have your first indent be 3 spaces, then your second be at 14, and your third at 20. It doesn't care at all about the tab stops or any multiple of spaces like you described, there is no rounding up or down.