nous

What I would love to see is a terminal that builds it’s own shell from scratch too rejecting the ancient ideas we have with bash. I still love bash but I’m curious what could come of it.

Thinking about it some more I am not sure that we would have to go that far. Well not in the longer term - short term we might for experimenting with ideas. I think one of the bigger problems ATM is the terminal does not understand what a shell is or its component parts. Terminals just display characters and move the cursor around the screen and send keyboard and now mouse input back to the command they run. They are also aware of alternative buffers and raw input mode and know about echoing characters back the the screen.

If we extended the terminals to also understand some shell concepts like the prompt, commands being typed and output from the commands and gave the shell some markers it could send along with these (like we do with color information ATM) the terminal would be able to use these to change how it displays each part and would open up a lot of new an interesting features. Could even add things like tooltip support or actions on clicking some bits of the text.

I am starting to see these terminals as experimenting on what we features could be enabled if we were not stuck on the current VT100 protocals. Though if we ever get wider adoption and generalisation of these ideas backed back into the protocals will be another question to consider.

Thinking about it some more I don't think we would need to abandon the whole TTY to get a good set of the features. What is basically required for a lot of the features is more communication between the shell and the terminal. There is already some communication for basic things - like raw mode and alternative buffers, colors and even images. These are how TUI programs like vim or screen/tmux function and how you can exit them without losing what was previously in the buffer.

I wonder if markers for the prompt and start/end of command output would probably enable a lot smarter virtual terminals with only some minor additions to the VT100 protocols. Possibly some extra data could be sent as well - like optional tooltip data maybe or even supporting actions that when the user clicks something it can send a response back to the shell. Maybe like a retry button on previous commands for example.

There is quite a lot that could be done if the terminal and shells had better protocals to communicate between each other. I dont think these will change overnight though so seeing terminal emulators try out these features to find what people like/want to use IMO is a good thing to see where we can take things in the longer term.

Would we have to abandon SSH or always X forward

No we would not. At the end of the day a TTY is just a input and output pipe between the terminal and the program running on the shell with a specific protocal VT100 (or some bastardized version of that - looking at you xterm). This is what network protocals are as well - just with different protocals in play. So you can do a lot over that connection with changes to the protocals. No need for xforwarding at all.

Might I add the idea that your terminal emulator must support your shell is utterly ridiculous?

TBH I am starting to come around to the idea of a tightly integrated shell and terminal emulator support. There are just things you cannot do with these being separate things. I am very tempted to explore the idea from the other end though - writing a shell that has a emulator built into it (like screen/tmux basically are). But I do think that this integration is needed for any per command features that is not just printing out a prompt.

It would be interesting to see what could be done with this type of integration but will likely break support for existing shells. Unless you maybe launch a shell for each command you run or something 🤔. Would like to seem more people experimenting with stuff like this and see what new things we could drive forward. We have been stuck with the current tty system since like the 80s to support devices that just dont exist anymore.

I think the issue fundamentally is that this isn’t what terminal emulators are. The terminal emulator initializes a TTY session and enters a shell environment (sh, zsh, fish, etc). The medium is text and cannot be anything else.

This is 90s thinking. Why must terminal emulators only be text and only do things that a physical terminal could? What makes teminals so nice is not that they work on 90s technology. Some terminal emualtors can already display images. Which is great. And the ideas they are introducing are still fundamentally text based, but are geared towards structuring that texts a bit more than a constant stream of characters on the screen.

Skill issue. Pipe your output to something (like a file or the “less” command)

This is a convenience issue not a skill issue. Yes you can pipe output to things but you need to know before hand that you want to do that. And with less you lose that output once you close less. And with files you have to clean them up after the fact. Both of these are inconvenient and need to be thought of before you run a command. IMO it would be nice to just run a command and then be able to collapse or expand or search its output after the fact and not have to preempt everything beforehand.

The argument that you can already do that in a much less convenient way is not a very good argument.

Konsole can display images, as can kitty alacritty, western, iterm2, etc.

They can now? I know it was possible in some niche terminals but never knew it was as wide spread as that.

but it’s not exactly game changing

None of these features on their own are game changing I agree. But lots of small nice to haves can end up being game changing overall. Again - I don't think these terminals offer anywhere near enough to warrant their IMO massive downsides though. But I would love to see more innovation in the terminal emulator space.

Lastly, searching explicitly your last command for a term with context would be much better suited to the shell to solve as it’d be terminal independent.

I had a similar thought TBH. But the more I thought about it the more I came to see that in order to do this nicely - ie with inline scroll back or being able to collapse command output like these terminals do then you would basically need to implement a terminal emulator into the shell. Either way you are breaking down the wall between what a shell and a terminal emulator are doing. I would be interesting in exploring this from the shell side, though I cannot fault them from doing it from the emulator side either.

couldn’t be solved at the shells level or with supplementary applications

I think the key benefit here is integration rather than technical ability to do something. Making it easy and convenient to do goes a long way. There is a lot that can be made much nicer with things more tightly integrated together than trying to string up a bunch of disparate applications together - even if you can do it the integrated approach will give you a much more refined experience.

I doubt they’re outright rejecting any idea of progress

It sounds like an outright dismissal of new features to me.

That is the Luddites argument against progressing anything. There are many problems with current terminal emulators that these newer ones are trying to fix and make the terminal experience better overall. Terminals as they currently work were designed the way they are to talk to dumb typewriters with a screen (that's right, not keyboards, digital typewriters). And they have barely changed at all since then.

Personally looking at these terminals they have a lot of niceties that I would love to use. But IMO these benefits are not worth the costs these particular terminals also have. One being closed source and requiring an account and the other being electron - no benefit is worth that. But to bury your head in the sand and claim they have no benefits at all is wrong.

Begin able to view images in the terminal would be amazing alone - just like you can cat a text file. I would hate to need to launch a GUI program every time I wanted to see what was inside a text file but that is exactly what I need to do for images or PDFs.

Being able to collapse the output of a command would be nice as well. The number of times I have had to scroll for days to get to the output of a previous command because I happen to run a noisy one but still want to check what something previously had done would save me quite a bit of annoyance. And being able to search just the last commands output would be great - like an after the fact, interactive grep with context. And being able to quickly copy the output of the last command would also be great.

Just factor it into your estimates and make it a requirement to the work. Don't talk to managers as though it is some optional bit of work that can be done in isolation. If you do frequent refactoring before you start a feature then it does not add a load of time as it saves a bunch of time when adding the feature. And helps keep your code base cleaner over the longer term leading to fewer times you need to do larger refactors.

Big refactorings are a bad idea.

IMO what is worst then big refactors are when people refactor and change behavior at the same time. A refactor means you change the code without changing its behavior. When you end up mixing these up it becomes very hard to tell if a behavioral change is intended or a new bug. When you keep the behavior the same then it is easier to spot an accidental change in behavior in what otherwise should be a no-op change.

And if you can, try to keep your refactors to one type of change. I have done and seen many 100 or even 1000s of lines changed in a refactor - but was kept manageable because it was the same basic pattern changing across a whole code base. For instance. Say you want to change logging libraries, or introduce one from simple print statements. It is best to add the new library first, maybe with a few example uses in one PR. Then do a bulk edit of all the instances (maybe per module or section of code for very large code bases) for simply switching log instances to the new library.

If you don't know what an API should look like, write the tests first as it'll force you to think of the "customer" which in this case is you.

I think there is some nuance here that is rarely ever talked about. When I see people trying this for the first time they often think you need to write a full test up front, then get frustrated as that is hard or they are not quite yet sure what they want to do yet. And quite often fall back to just writing the code first as they feel trying to write a test before they have a solid understanding of what they want is a waste.

But - you don't need to start with a complete test. Start as simple as you can. I quite often start with the hello world of tests - create a new test and assert false. Then see if the test fails as expected. That tells me I have my environment setup correctly and is a great place to start. Then if I am unsure exactly what I want to write, I start inside the test and call a function with a name that I think I want. No need for parameters or return types yet, just give the function a name. That will cause the code to fail to compile, so write a stub method/class to get things working again. Then start thinking about how the user will want to call it and refactor the test to add parameters or expect return types, flipping back to the implementation to get the code compiling again.

You can use this to explore how you want the API to look as you are writing the client side and library side at the same time. You can just use the test as a way to see how the caller will call the code. No need to start with asserting behavior yet at all. I will even sometimes just debug print values in the test or implementation or even just write code in the test that calls into a third party library that I am new to to see how it works. With no intention that that test will even be included in the final PR - I just use tests as a staging ground to test ideas. Don't feel like every test you write you need to keep.

Sometimes I skip the testing framework altogether and just test the main binary in a simple situation. I especially do this for simpler binaries that are meant to mostly do one thing and dont really need a full testing framework. But I still do the red/green/refactor loop of TDD. I am just very loose on what I consider a valid "test".

The second time you're introducing duplication (i.e., three copies), don't. You should have enough data points to create a good enough abstraction.

This missed one big caviat. The size of the code being duplicated. If it is only a few lines then don't worry so much. 5 or even 10 copies of a 2 line change is not a big issue and quite often far harder to read and maintain then any attempt at de-duping it. As the amount of code you need to copy/paste grows though then it becomes more advantageous to abstract it with fewer copies.

if you find yourself finding it difficult to mock

I hate mocks. IMO they should be the last resort for testing things. They bake far too many assumptions about the code being mocked out and they do it for every test you write. IMO just test as much real behavior as you can. As long as your tests are fast and repeatable then you dont need to be mocking things out - especially internal behaviors. And when you do need to talk to an external service of some kind then I would start with a fake implementation of the service before a mock. A fake implementation is just a simple, likely in memory, implementation of the given API/interface/endpoints or whatever.

With a mock you bake assumptions about the behavior into every mock you write - which is generally every test you write. If your assumptions are off then you need to find and refactor every test you have that has that assumption. With a fake implementation you just update the fake and you should not need to touch your tests. And you can write a fake once and use it on all your tests (or better yet use a third party one if one is available (for instance I quite often use goflakes3 - a golang in memory implementation for aws s3 service).

Almost. But with one key difference. PPAs are precompiled binaries where you cannot inspect the source - you have to trust the maintainer of the PPA. AUR is a repository of source packages which you can download and inspect yourself (or hope others have done this). This makes AUR more community focused than PPAs I feel. AUR is also a central repo managed by people that dont own the vast majority of the packages hosted on it and where packages can be taken down if found malicious. PPAs are lots of separate repositories all managed by different people that generally maintain all the packages for their PPA.

Though in both cases anyone can upload anything to them, so they are not 100% trustworthy. But I do think the way AUR works puts them ahead of PPAs.

Or just thing.age() which is fine and is fairly obvious it will return the age of the thing. And that is what is done in most languages that dont have computed properties. get_ on a method really adds no value nor clarity to things. The only reason foo() is ambiguous is because it is a bad name - really just a place holder. Missing out the brackets here adds no value either, just makes it hard to tell that you are calling a function instead of just accessing a property.

Make its usage cleaner? I don't see how a property does that at all. We are talking about x.foo vs x.foo() really. And IMO the latter tells you this is a function that needs to do some work even if that work is very cheap. x.foo implies that you might be able to set the value as well. But with computed properties maybe not. Which IMO makes the program a bit harder to read and understand as you cannot simply assume it is a simple assignment or field access. It could be a full function call that does different things depending on other values or even if you are setting vs getting the value. I prefer things being more explicit.

It is such a weak smell though you might as well look at any bit of code you have and ask yourself if it is bad code. Lambdas are fine in a lot of places and the existence of them is not an indication of good or bad code. It is just a tool that can be used in lots of situations.

A better smell here is excessive inlineing causing a loss of context. Does not matter if it is a lambda, or a parameter to a function call, or a field in a object creation. None of those are signs of bad code, but if you cannot understand what something anonymous is doing you might want to give it a name. This does not mean creating a named function, but might just be assigning the lambda or parameter to a variable so it is named.

But on the flip side I find it you are struggling to name something then that can also be a smell that maybe it should just be inlined. Giving everything a name can create just as bad code as trying to inline everything. There is a balance in the middle somewhere. And the presence of a lambda does not really hint as to which way you want to go. So its existence is a very poor marker for code quality.

it’s probably worth taking a second to ask yourself

You can extend this to all code, not just lambdas. Any code you can take a second to ask yourself if you could write it better or more readable. If that is the bar then all code has a very weak code smell and singling out lambdas here seems arbitrary.