Load stdin regardless if files are passed in arguments

[niten94]

Data in standard input is not read to an empty buffer if there are files specified in command-line arguments like env | sort | micro .profile. With this pull request, data is read to match the case with no file arguments.

[niten94]

I realized that CLI programs like cat and less read standard input in the conditions below, which are different with what this pull request implements:

• No arguments specified (and input isn't terminal if using less)
• - is specified and handled as file argument

I think standard input should be read in the same conditions to be consistent. I'll just mention that they aren't documented in the man page of the more implementation of util-linux and less.

The changes would be easy but I'll mark this as a draft. I don't mind if someone else implements it.

[dmaluka]

Data in standard input is not read to an empty buffer if there are files specified in command-line arguments like env | sort | micro .profile. With this pull request, data is read to match the case with no file arguments.

So micro will open both .profile and a buffer with the data from stdin? As I guess from the code, it will open them in separate tabs, and the stdin tab will be after the .profile tab (just because it happens to be after it in the code)?

Maybe not a bad idea...

[dmaluka]

I realized that CLI programs like cat and less read standard input in the conditions below, which are different with what this pull request implements:

* No arguments specified (and input isn't terminal if using less)

* `-` is specified and handled as file argument

I think standard input should be read in the same conditions to be consistent.

Regarding p.1, so you mean that we shouldn't implement what your PR implements, since it would be inconsistent with cat and less? But I guess you implemented it for a reason, i.e. you find it useful? :) So if we think it is useful, I guess we shouldn't give it up just to be consistent with cat and less (which are not text editors after all).

Regarding p.2., yes, interpreting - as stdin is pretty common. We might implement that, if really needed.

[niten94]

Regarding p.1, so you mean that we shouldn't implement what your PR implements, since it would be inconsistent with cat and less? But I guess you implemented it for a reason, i.e. you find it useful? :) So if we think it is useful, I guess we shouldn't give it up just to be consistent with cat and less (which are not text editors after all).

Yes, I meant that standard input shouldn't be read as implemented in this PR if - is not specified. I'll retain this behavior now, since I think you are right that we don't have to be exactly consistent. And yes, I still find it useful.

Regarding p.2., yes, interpreting - as stdin is pretty common. We might implement that, if really needed.

I'll try to implement it to avoid surprising other users.

[niten94]

Regarding p.2., yes, interpreting - as stdin is pretty common. We might implement that, if really needed.

I'll try to implement it to avoid surprising other users.

I have implemented it, but I also rebased on master, slightly adjusted the comments and code structure.