Merging legacy_0.2.9 and sty+ct+ap again

[Z-Man]

The problem: sty+ct+ap is currently partially formatted with DOS style line endings, CR+LF; our branches have UNIX style line endings, only LF. Any straight merge gives conflicts of the form "the whole file has changed".

I have a plan, successfully tested. It requires cooperation to be permanently successful.

In our source branches, there is now an .editorconfig file that defines the UNIX style as the style to use, among other things: Four spaces for C++ indentation, tabs for XML and Makefiles. Not because I prefer that, but because that's what the code uses, and changes are complicated.
Many editors respect .editorconfig out of the box, most others have a plugin. So as soon as that file is in sty+ct+ap, there should be no more problems.
(There is the problem that the vscode extension does not yet support charset, so it won't know it needs to switch to latin1 for the language text files.)

Thankfully, getting there is simple. Take the current state of sty+ct+ap, apply the dos2unix program on all code files. Commit that. Merge legacy_0.2.9. Git does not care about the DOS style line endings in in-between revisions, only the last common state and the two end states, so only real conflicts need to be resolved.

The result of the test I did some way back is here: https://gitlab.com/zmanuel/armagetronad ... type=heads
One reformat commit, one merge, done. You have to scroll down to Sept 15 to get the last sty+ct+ap revision, just in case you are wondering.

I'd redo that work now, more CRs have appeared and I'd like the history to be as clean as possible.

And I'd elevate the result to a higher status; I'd let the regular CI system make builds for them and publish them along the base ones. As there are now significant client additions, that only makes sense.

[Z-Man]

Scratch that waiting, I just did the process again, there are not too many conflicts:
https://gitlab.com/zmanuel/armagetronad ... type=heads

[aP|Nelg]

This is my write up (with some assumptions) as to what happened: a slightly dumb text editor (probably the codeblocks in-built text editor) was used in a lot of commits which supported mixed line endings but did not autodetect the line endings used for some reason. Whenever any new lines were added, it would've used CRLF while leaving the rest LF. When I hacked away at the source, I was at first using (I believe) the Kate text editor which apparently did not support mixed line endings. However its autodetection of line endings would see CRLF line endings on some lines (even though the file was always more LF than CRLF) and just convert the whole file to CRLF line endings. This had the effect of making it the diffs look like you are erasing the whole file and replacing it with the exact same contents for (in the most extreme case) 99% of the file as LF gets changed to CRLF, but showing no change for the 1% of lines where the line endings are already CRLF. (example). I was unsure of why diffs looked like that at the time, but later when I did figure it out, I looked for text editors that supported mixed line endings in the same file so that it wouldn't occur. I was actually using Notepad++ under WINE for a while exclusively for working on +ap, while still using Kate for most everything else, until eventually discovered Geany also supported mixed line endings and switched to that.

Most sensible text editors designed for code should really try to autodetect line endings, tab types, and encoding. Chances are high that a text editor that doesn't have the option for autodetection for any of that also hasn't implemented .editorconfig support out of the box. And someone who uses a text editor that doesn't implement either of those may not set the text editor to the correct settings or install the plug-in needed (even if it's mentioned somewhere, who wont read it?). So, I'm not truly convinced having an editorconfig would actually solve the problem, but it's probably better than nothing.

By the way, this is also the reason why gServerBrowser's aspect ratio fixes did not merge cleanly into 0.2.9; I believe the copy in +ap had been converted entirely to CRLF line endings while the copy in 0.2.9 was LF line endings. Yeah, the way the server browser looks in 0.2.9.1 still bothers me, but arguably that way is better for ultrasupermegawide screens anyway.

Anyway, instead of converting the line endings myself or attempting to merge a git branch into bzr, I downloaded the patch from that gitlab branch and applied it against the +ap branch. And then, of course, did a merge from 0.2.9. Yeah, I'm still using bzr... I'm not unwilling to switch to git, but I could never figure out a way to do so smoothly where everything continues to be synced between git and the ~armagetronad-ap -owned bzr repo. I tried running the git<->bzr bridge myself but it did not actually work for me, instead consuming all system memory until I killed the process. So, I gave up and just continued using bzr. I'm not actually sure if it would've created a result that was completely mergable with the other armagetronad git repositories anyway; that would be quite important. Ideally compatible with the +ap branch in the main gitlab as well.

Enough rambling for now though. Basically, task done. Now, to hope merging the line ending changes into branches based on +ap goes well...

[Z-Man]

About editor auto-detecting the desired formatting standards: That is what your Kate did, apparently, only that it did not conclude mixed line endings would be tolerated... Really, editors should just leave lines you don't edit alone, and only apply whatever settings they divined (via user settings, project settings, .editorconfig or autodetection) on the line you touch.
git-clang-format is a good example for such a behavior: It applies clang-format on all of the lines you have local git changes in. The workflow is slightly awkward if you only want to commit part of your changes.
You can apparently configure giit on a per-repository basis to apply line ending transformations. That would have also prevented the kerfuffle... had you been using git. https://docs.github.com/en/get-started/ ... ne-endings No such thing seems to exist in bzr.

git/bzr syncing: Yeah, that is incredibly fiddly. The one thing you need to get right is the git-remote-bzr version, I use my own branch for everyting:
https://github.com/zmanuel/git-remote-bzr The version determines how bzr revisions are turned into git revisions, mostly how the metadata is transferred. One deviation there and your bzr branch is going to turn into a completely different git branch.
The next issue is that most new revisions were done in git, then transferred over to bzr. It is not 100% guaranteed that they would produce the same git revision back. That can't be avoided in git-remote-bzr, it is an issue with how git exports and imports data for the git-remote mechanism.
And, of course, as bzr generates its revision unique identifiers randomly and not from the content, mapping from git to bzr will give you different bzr branches if you do it twice independently.

Against all three problems, there is help: the marks files. They are maps from already established equivalences between git and bzr revisions. They are stored locally in the repositores you use for syncing. I let my syncer export them: https://download.armagetronad.org/~baza ... ron/marks/ I never actually checked how one would import them, though... they're for backup purposes only, I suppose, because even if you use them to kickstart your own syncing repository, any new revisions from upstream won't be included.

Have you tried interacting with git repositories with breezy, the new replacement for bazaar? That is no solution to the sync problem, but it may provide a friendlier interface. Maybe that can ease you over. The thing is, I really don't know how long the git/bzr syncing is going to continue to work. It's based on Python 2, and I already had to jump some low hoops to get everything installed on the build server when the raspi it was on previously decided it did not want to boot any longer.

And, why don't you point me to the branches you want synced and I just add them to my configuration? It's just a line somewhere for me, and no trouble with future changes. I understand if you want to be as autonomeous as possible, though, so if you want to set up your own syncing, with all the risks (well, worst case, if you stick to working with bzr for now, the git branch you produce will diverge from upstream), tell me what operating system you want it to run on and I'll try to put together a guide. It's just four ingredients to install, git, python2, bzrlib, and git-remote-bzr.

[Monkey]

I was actually using Notepad++ under WINE for a while exclusively

I just vomited in my mouth and swallowed it again.

Kate, Geany, blah blah

Ok so Geany doesn't look too bad as editors/IDEs go but, seriously, I'm surprised you don't use vi/ex or Vim. I used Vim many years ago but then realised it was far too bloated so switched to vi/ex and I haven't looked back. Yes, the key bindings and modal operation are superb but it's not just about them. If you can master using the combination of vi and ex together, it's just unbeatable. I know you like a bit of bloat so maybe try Vim; it has syntax highlighting, code folding, more modes and features than you can shake a stick at and it works everywhere. It even has a ..wait for it...GUI!

For anyone seriously interested in trying vi/ex or Vim, I'd recommend reading the following tutorial on vi/ex:
https://www.ele.uri.edu/faculty/vetter/ ... -intro.pdf
And also check out this brief article to see why vi/ex is so cool and powerful:
https://why-vi.rocks/
(don't forget to read the vi/ex man page on your system or online too)

If you want more *cough* "features" than what you read there, then just use Vim.

[Z-Man]

I personally can't be bothered any more to work without some form of code completion, go-to-definition, jumping to error sites on compilation and an integrated debugger. My current choice is neovim with a bunch of plugins, I mostly followed this video and worked from there:
https://www.youtube.com/watch?v=lsFoZIg-oDs
Yeah, compared to pure vi, it's bloat, but what isn't? Bloat only bothers me if it slows me down, which this does not. The code completion is using the language server model, where the actual work of understanding the code happens in a background process; if you don't currently need it, even if it should take a second or two to find your completions, it does not block you from just typing away.
It all works the same way on Linux and macOS, so I can just share the entire configuration between the two. The only problem on the mac side is that the default terminal does not work well with neovim's colors and fonts, so I use an alternative there (iTerm2). The only alternative I know of that does that equally well would be visual studio code... and yeah, that is bloat, plus I find it hard to configure properly. It's invasive: often configuration boils down to dropping some poorly explained json file into your project folder (JSON DOES NOT KNOW COMMENTS), sometimes with paths to the required external tools baked in.

[Monkey]

My current choice is neovim with a bunch of plugins

I thought you used Emacs, which, by the way, is vomit-inducing bloat of the highest order?!
Vim/Neovim are respectable editors. For learning Vim/Neovim, there is also "vimtutor" which, IIRC, comes as standard with the main program. I used vimtutor pretty much exclusively, to learn Vim. After that, there is an inbuilt help system too, IIRC.

The only alternative I know of that does that equally well would be visual studio code...

Yeah OK, I'd stick with Vim.

[sinewav]

Ok so Geany doesn't look too bad as editors/IDEs go ...

Geany is my go-to editor on GTK based systems. I don't do anything fancy and I use VI for editing config files and simple edits, but when I'm obsessively working on something I like that I can hit F5 (I think) and Geany will compile and execute what I'm working on, plus it has a built-in terminal so I can read stdin, stdout, and stderr right in the same window. Also, bracket and tag completion is nice when I want it. I'm sure VI can do a lot of great stuff but I'm already used to the convenience and getting stuff done more important to me than the tools I use.

[Monkey]

Geany will compile and execute what I'm working on, plus it has a built-in terminal so I can read stdin, stdout, and stderr right in the same window. Also, bracket and tag completion is nice when I want it. I'm sure VI can do a lot of great stuff but I'm already used to the convenience and getting stuff done more important to me than the tools I use.

You can use whatever editor/IDE you want of course.
I wouldn't say that Vim is less good at getting things done though, It has all what you just mentioned IIRC, plus more.
As for ex/vi, that is an editor that is not to everyone's taste. It is designed to be used in unison with other UNIX tools. That and its modal editing are what *I* like about it...it lets you really unleash the power of UNIX. However, you have to know the UNIX tools well in order for it to be of any real use (such as the shells, sed, AWK, tmux, filters, etc, etc...). I'm still learning how to use it properly myself.

[Z-Man]

Yeah, I was using Emacs for a loooong time, because the best pure editor back on the Amiga was MicroEmacs, which was Emacs without all the customization, I guess, because how else are you going to fit it into 512 kB of RAM? Emacs iself under Unix pretty much nailed two of my IDE needs: Compilation with jump-to-error and comfortable debugging. But I drifted to more fully featured IDEs, first Eclipse and later VS Code, Code::Blocks and QTCreator. QTCreator was what I used the most, because that one has the best out-of-the-box code completion without need for much configuration and detailed project knowledge, it just has pretty good heuristics. I think I ditched it because the debugger is a bit unweildy.

I will give Geany a closer look should I get annoyed with neovim. I liked what I saw so far.

[Lucifer]

Still using Kate. I just want a decent syntax highlighter and a treeview that starts at the root of the directory in which I'm working.

Also, the syntax highlighter is so good at guessing what to highlight that I can make custom file formats and does a decent job with them. I've quit using .ini files for everything because it turns out I can write a parser for a more descriptive format in like five minutes.

When I work with something like C++, which isn't often, there's decent debug integration with the embedded Konsole widget. It has multiple file search and replace. I haven't needed more than what Kate has for years, and I still don't.

[kyle]

Well since this topic has diverged I guess I will chime in too. I've been using Geany since I switched to Linux, That was the hardest thing for me to find a replacement for with Linux, as on windows I would use PSPad, yes that's freeware, but keep in mind this was way back in 2006.

But it really depends on the project I'm working on, at work I used Brackets for a while as I was working on a very large JavaScript application and it just made tracking down things a lot easier at the time. If I'm making a quick edit or looking at a file on a server it's usually vim. If I'm stuck on .net stuff it's Visual studio in a windows VM, yep very bloated, but not an easy way around that. I've tried VS code, but it does not handle the MS solution/project files very well, maybe it does now. For a Large Java project I use netbeans, but prefer eclipse, but would have been a pain to set-up that was since it was already setup with netbeans.

I believe all of the code changes I made to armagetronad were all done with geany

I do want to try neovim sometime, I've heard a lot of good things about it.

[delinquent]

I've tried VS code, but it does not handle the MS solution/project files very well, maybe it does now.

It does not. There are some Roslyn plugins for VSCode, but frankly there's nothing that really matches the "everything and the kitchen sink" featureset of VS. Although I will say, VS2022 is an awful experience. It's a laggy mess in a VM, even with all the nice hypervisor config, and it flat out doesn't work in remoteapps meaning I have to launch the entire RDP window to use it. VS2017 is a far better experience, but it lacks compatibility with dotnet6/7/8, which is what I'm rebuilding Rinzler in for the moment.

I've actually started a kitchen sink project of my own, that I call CoffeePot. The idea is to build it for a slightly modified fork of DLang, but to include templating, compiling, code completion, linting etcetera for other languages too. It's intended to be linux based, but in theory should be buildable for any system that supports GTK (although I may move to another design library, since GTK is a bit hit and miss with documentation). That's going to be quit some time though.

I really rather miss MonoDevelop. It was fairly light considering its capabilities, and had the potential to be a kitchen-sink IDE in its own rite. There is some movement behind a modernised fork called DotDevelop, but thats a long way away from being usable.

[kyle]

I've tried VS code, but it does not handle the MS solution/project files very well, maybe it does now.

It does not.

Yikes, that's actually kinda funny, given Microsoft is also ditching visual studio for mac, that makes development with Xamarin/MAUI even more painful for iOS, as they say to use VS code, and you can only compile on a mac for iOS. Also the project files for iOS don't even get updated correctly on windows visual studio.

Looks like I'll be having a fun conversation with the client with MS kills Xamarin/MAUI. MAUI is supposed to replace Xamarin, but it much worse than Xamarin, and Xamarin is pretty bad.

[delinquent]

Xamarin

I'm lead to believe that dotnet, as in the modern iteration of .NET Core/.NET/.NET Web, is intended to be truly cross-platform, including mobile devices. I'm unconvinced that there will be a decent mobile design framework, but it's also not impossible to use a frontend design language like JS or HTML5 alongside a Dotnet backend. As for how that would be properly packaged, I have no idea - currently, the dotnet libs for 'nix, both x86 and arm64, are straight up monolithic runtimes that are required to be dumped in to a separate library. Packaging that up as a single runtime for a mobile app would be a huge waste of space, so I'm assuming the ostensible objective is to either include a framework for android as a whole, or use a partial export process that compiles with just the aspects of dotnet that are used in the application. The former sounds like a more attainable objective, so I'd presume that would be the route forward.

Still, it raises questions about how FOSS spinoffs, like LineageOS, would manage. Presumably they'd want a truly open source runtime like Mono was, but getting there is a long and rather arduous task.

There is, of course, the concept of implementing a dependency system, whereby teh dotnet runtime is a separate downloadable item, but I have a feeling that this would end up going the same way as Windows Phone and Zune.