I note that there’s not a ton of freedom in the code editor to format long calls in ways where you’re in control of indenting.
My personal preference is to format arguments on their own line and to indent them just inside the opening paren of the argument list, if the args will not all fit handily on a reasonably short (printable) line.
As it is, the behavior is that if you have a line continuation, it just aligns at some tab stop under the first line, which is not awful, but as a person who prefers spaces to tabs so this isn’t left to the vagaries of the editor, I find it kind of annoying. This would be a feature under Preferences / Coding, probably a checkbox labeled “Align arguments beneath each other on line continuations” or similar and maybe would also require the choice of indenting with tabs or spaces, and a setting for # of spaces per “tab stop”. These settings are typically available in code editors.
Maybe there’s some other way to achieve this that I just haven’t found but that is what I am after. If this is something most users don’t care about and would be a lot of work, I understand, and TBH while I can manually align with spaces in Visual Studio and Ryder, my former tools of choice, sometimes code reformatting screws it up anyway.
I also note that the code editor on Mac defaults to the System font which isn’t mono-spaced, so I understand the above would require that I use a monospaced font.
I’m curious what other’s thoughts on this and on editor configuration in general is.
In Monterrey, PT Mono is built in and is also a pretty good monospaced font. I’m using it for listbox-as-grid because in my particular application it’s needed for the user to easily see subtle character-by-character differences in adjacent values. I might try that or one of the other mono fonts for the code editor, but the problem is that the editor will not let you insert spaces (or tabs) to align, regardless of the font. Spaces vs tabs in code is a religious issue for some devs (it’s just a preference to me, and arguably less important when your code is balkanized into little snippets like it is in this environment), so might be worth accommodating since the product’s “ask” is that you submit to its built-in editor and tools to get the lift from the framework. It might be more part of a long term editor upgrade strategy, so maybe this is a good place to discuss and prioritize wish list items like that. If no one has those then I accept that Xojo has hit some kind of sweet spot for its user base, and – life being short – I will let go of this request
Yep I understand that but regardless of font it won’t let me insert tabs or spaces at the start of continued lines, which is the basic ask here. If it let me break a line and then align that below the line above however I wanted, I would use a mono spaced font and call it good.
As a side matter, VB.NET lost the compiler requirement for the underscore as line continuation character a quite a few years ago, in all but a few edge cases having to do with expressions spread out over multiple lines. It would be nice not to have those as well – but it’s a not a battle I’m picking right now
Allowing the insertion of white space at the beginning of the line would probably require a change to Xojo’s grammar and parser. That ain’t happening anytime soon.
It is just a matter of ignoring whitespace (he said naively).
I have yet to encounter a language that cares about whether two terms are separated by one whitespace or line ending character, or by any number of them. There just has to be at least one. Already, it looks like Xojo can cope with considering a space after a comma in an argument list to be optional. This seems like a slightly simpler ask than that.
If they don’t want to change the grammar, they could just collapse all consecutive whitespace runs to a single space before passing it to the compiler, if that’s what the compiler demands. Or remove all leading whitespace from line continuations – or whatever itch it’s trying to scratch.
I’m not as surprised that no one shares my code formatting preferences (you all have a right to be wrong, lol) but that no one seems to have other things in the code editor that they are sort of tolerating. A developer’s coding environment is kind of a big deal. Surely if you don’t care about how line continuations are formatted (or don’t care to even use them), there must be other limitations you’d like to see lifted.
Or maybe there’s just a different psychology in an environment where you aren’t writing code into a single file with multiple methods. Just snippets that get inserted in auto-generated method definitions, which, generally, are inherently smaller code contexts means people just don’t care as much about style.
I can live with that, but knowing myself, some of these things will start to feel claustrophobic after a period of time. I expect I’ll get enough lift from the framework abstractions that I will be able to rationalize being forced to format (and read) code in a certain way. Just trying to get a feel for how much the community cares about code editor features and flexibility.
What I’m getting so far is, I would be a lone voice crying in the wilderness on such topics and maybe should stay away from it. I believe in picking one’s battles.
At least I get to put empty lines around code blocks and don’t have to have them mashed together, so there’s that
It’s not a matter of spaces or tabs. Your code is formatted on the fly in the IDE and then displayed in an indented manner. All leading white space is automatically stripped.
is perfectly valid with extra spaces at the start (it does take a little trick to accomplish). The IDE will try its best to force its formatting on you because I guess the IDE thinks it knows best.
An IDE reformat code script couldn’t do this as the white space is automatically trimmed by the IDE before its added to the line.
The trick to get the spaces in there is to turn off “apply standardize format after ending the line” add more spaces on the end the line, move the cursor back then press enter, moving the spaces onto the next line, you can then start typing a number of spaces across. To add more put the caret into the spaces and not at the start of the line. You can now turn back on formatting and just don’t go near that line or you lose the spaces. Yeah, intuitive and easy to use =\
I have a feeling that simply allowing whitespace at the start of a line would have weird side effects with Xojo’s project format files, given how they handle text. I know this having written a parser to read that format…
In VBA I had to format the code myself. It was a huge bore.
What made me really really hate Python was the way the language treated whitespace. The indentation had meaning. Wrapping some lines in an if meant carefully adding whitespace to the containing code.
In Xojo I don’t have to think about whitespace at all. If a line gets too long I add the – . Finished. I don’t bother with any code formatting.
People who format even the variable declarations like
