It would be very useful if mousepad was able to place the contents of stdin into an unsaved document in a similar way to gedit. For example, 'echo hi|gedit' produces a gedit window with a new document containing 'hi', however, 'echo hi|mousepad' produces a new empty document.
+1 This feature seems very useful, but I can't gEdit(3.10.1) to read from stdin, it just opens a blank file.
Created attachment 6250 Create files from stdin
What would happen if you did this? cat /dev/random | mousepad Does it block the UI until `cat` gets killed? Other than the blocking read (which IIRC Mousepad already uses anyway), and that locale encoding is assumed (which may or may not be a decent assumption, depending on the usage ... echo vs files vs OSes like windows with non-locale console encodings, etc), it looks pretty good to me. I will review, test and try and get it merged next time I can dedicate some time to go through the patches in tracker. Thanks
(In reply to Matthew Brush from comment #3) > What would happen if you did this? > > cat /dev/random | mousepad > > Does it block the UI until `cat` gets killed? Yes, it will do - I'm not sure of how this could be prevented. Perhaps a maximum read size, but that could cause more problems. > Other than the blocking read (which IIRC Mousepad already uses anyway), and > that locale encoding is assumed (which may or may not be a decent > assumption, depending on the usage ... echo vs files vs OSes like windows > with non-locale console encodings, etc), it looks pretty good to me. I think the majority of uses will be echoes and command outputs, so locale encoding makes the most sense. But it could be changed to guess the encoding based on the contents. > I will review, test and try and get it merged next time I can dedicate some > time to go through the patches in tracker. Thanks - if anything needs changing, just shout (this is my first patch).
Nicely done Ian, I have just applied the patch and it works (almost) smoothly here. Besides the problems mentioned by Matt, I noticed that if you run "echo test | mousepad" and run it again in another terminal, second mousepad window is blank. Right now I'm a bit busy, but I guess this is something related to how mousepad handles(or it was supposed to handle) instances.
I am guessing that is due to only the file name being passed through dbus. With the second process exiting after sending the dbus command, so that its stdin is lost. I'm not sure of a simple way of getting round this - sending the contents of stdin across dbus might be difficult (as it isn't a fixed size and can range massively). I've had a look at gedit, it seems they now require a file name of '-' to read from stdin (i.e. "echo hi|gedit -"). They have an interesting solution to the problem pointed out by Matt - they essentially launch another process to read from stdin, with the data being added to the bottom of the window. This allows it to follow the input, for example "tail -f /var/log/syslog|gedit -" will update the window with new content from syslog, which is quite nice. I'm thinking that a similar approach might fix both problems, although I'm not sure how this could be done with dbus in the middle. Perhaps switching to background process file loading might also help with large files.
Maybe `-` could imply `--disable-server` (and put a note to that effect in the `--help` output).
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/mousepad/-/issues/7. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev