FlexGUI and PNut look and feel

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...
  • 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.
«1

Comments

  • RaymanRayman Posts: 10,435
    edited 2020-03-05 - 19:04:04
    You're in luck because Chip says they are updating the Propeller Tool for P2.

    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.
  • You're in luck because Chip says they are updating the Propeller Tool for P2.
    Yep. Jeff Martin told me that an alpha release may be available soon.
    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.
  • RaymanRayman Posts: 10,435
    edited 2020-03-05 - 19:37:57
    Jon, I replied in SpinEdit thread with a version that can compile and load with Pnut as an option...

    (It's just that the compile button doesn't do anything when PNut is selected).
  • Sorry, Ray, I missed that. I will go track it down.
  • ...
    • it would be nice if the return key would automatically indent the new line to the same row as the last line.
    • I also liked the "align" mode of the old propeller tool, not only "insert" and "overwrite"
  • I was really hoping these tools would get glued to Visual Studio Code. I might take a stab at it, at some point.

    Let's hope PropellerTool is upgraded to interface with Github.
  • I've done a Visual Studio Code highlighter and there's a thread buried somewhere about it.

    BTW I extended the work based on anothers work ;)
  • It is likely possible to do the indentation highlighting thing and context-sensitive align for Spin in a VSCode extension...
  • ManAtWorkManAtWork Posts: 546
    edited 2020-03-19 - 13:08:17
    ke4pjw wrote: »
    I was really hoping these tools would get glued to Visual Studio Code.

    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 don't like auto-correct, either. It changes "you" to "me", practically. Causes lots of headaches.

    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.
  • Wuerfel_21Wuerfel_21 Posts: 597
    edited 2020-03-19 - 12:17:53
    cgracey wrote: »
    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 have 4 spaces per tab in SpinEdit. Seems to be just fine...
  • Rayman wrote: »
    I have 4 spaces per tab in SpinEdit. Seems to be just fine...
    The key is to not actually put tab characters in the source file and do indentation with spaces. I think Chip is wanting to use actual tab characters but treat them as if they are only 4 spaces.

  • Tab characters in the file is a real pain for me...
    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!
  • I think Python flags tab characters in a file. They certainly interfere with block structure by indentation if everyone's editor doesn't use the same settings for tabs.
  • Yes, sorry. Spaces are better in a source file. The tab key can space to the next stop.
  • I'd like to see the ability to continue to use the Parallax font. I have lots of circuit layouts that use the line drawing and special characters (resistors, etc.) from that font.

    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.
  • cgraceycgracey Posts: 12,613
    edited 2020-03-19 - 15:11:05
    wmosscrop wrote: »
    I'd like to see the ability to continue to use the Parallax font. I have lots of circuit layouts that use the line drawing and special characters (resistors, etc.) from that font.

    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.
  • Relatedly: What is the license on the P1 ROM as a whole? Can it be included as-is in, say, a PC program that includes/is a P1 emulator? The math stuff is obviously not copyrightable, that leaves the encrypted booter+spinterpreter and the font. I don't even use the executable stuff and could put in a different font, but ideally I'd like to use the real ROM to avoid bugs that I can't reproduce on the emulator because the behaviour depends on an out-of-bounds memory read that ends up in ROM.
  • Wuerfel_21 wrote: »
    Relatedly: What is the license on the P1 ROM as a whole? Can it be included as-is in, say, a PC program that includes/is a P1 emulator? The math stuff is obviously not copyrightable, that leaves the encrypted booter+spinterpreter and the font. I don't even use the executable stuff and could put in a different font, but ideally I'd like to use the real ROM to avoid bugs that I can't reproduce on the emulator because the behaviour depends on an out-of-bounds memory read that ends up in ROM.

    Go ahead and do what you want with it.
  • RaymanRayman Posts: 10,435
    edited 2020-03-19 - 15:35:36
    I think Chip open sourced the whole P1 Verilog...
    I imagine the ROM is part of that...

    Oh, that's GPL'd though...
  • RaymanRayman Posts: 10,435
    edited 2020-03-19 - 15:39:56
    BTW: SpinEdit does not use multibyte characters like the Propeller Tool. Did that as an experiment, but sticking to it for now. But, it can open multibyte character files and still handle the special characters in the Propeller Font using some code page magic.

    This could be useful for trying to make an on-chip Spin editor later...
  • cgracey wrote: »
    Yes, sorry. Spaces are better in a source file. The tab key can space to the next stop.

    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?
  • You're missing the case that:
    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.
  • whicker wrote: »
    You're missing the case that:
    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?
  • AJL wrote: »
    whicker wrote: »
    .........
    ..........
    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?

    In answer to your question, every assembler/compiler I have ever used treat one or more spaces as a field/text separator. They may have had a limit to the number of spaces they would scan before giving an error, but I never reached that limit if it was there. Tabs were needed to speed up card punch data entry way back then.
  • tab does not move a fixed number of characters, it moves to the next multiple of characters.
    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.
  • Probably a waster of metaphoric breath to try to make my case, but here goes nothing.
    kwinn wrote: »
    AJL wrote: »
    whicker wrote: »
    .........
    ..........
    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?

    In answer to your question, every assembler/compiler I have ever used treat one or more spaces as a field/text separator. They may have had a limit to the number of spaces they would scan before giving an error, but I never reached that limit if it was there. Tabs were needed to speed up card punch data entry way back then.

    Let's not pretend that the tab key was invented by computer designers. It existed on typewriter keyboards for the very purpose of aligning text between lines and it was set by the user to the size that suited the purpose of the document they were producing.

    Use of multiple space characters instead of tabs is a kludge - a common one - but a kludge nonetheless.

    If you use whitespace for indentation purposes (like SPIN), the tool needs to count the number of space characters to determine the indentation level, and if you use multiple spaces per indent then you need to determine what to do when the number of spaces present in the file isn't a clean multiple; you either round up or down. If you use one space per indentation level then you might as well use tabs.
    Roy Eltham wrote: »
    tab does not move a fixed number of characters, it moves to the next multiple of characters.
    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.

    Thanks for the unnecessary lesson on how tabs work. It only gets messed up in two cases:
    1. You select a tab stop value that is less than the largest item in a field;
    2. You intermix spaces and tabs; this is a bad idea but you might not notice, others are the ones who suffer the consequences when they open your file in an editor with a different tab stop setting.

    Many editors let you select custom tab stop sets. That is the better option IMHO.

    Demonising the use of tabs seems like shortsightedness to me.
  • I felt you needed that "lesson", because you clearly are missing the issue (I feel intentionally now).
    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.
  • Uh, can we discuss the merits of coding in proportional fonts, instead of monospaced fonts? That should be even more interesting than tabs. I mean, there are a lot more proportional fonts to choose from. And does anyone know if 'Courier New' is really better than 'Courier'?
Sign In or Register to comment.