In D12018#202291, @DataDrake wrote:

2. Duplicate nanorc files in scopatz be removed entirely from the install when they are present in nano itself
3. A note in this repo to always make sure scopatz is modified when new nanorc files are added or removed from nano

Change name.

This prevents the duplication, but we do get a very long list of includes. What do y'all think?

Remove useless line in package.yml.

Prevent having to include duplicate definitions.

Yes they do, with the --lite option all that happens is the script includes the scopatz definitions higher up than the upstream ones. All of the scopatz definitions are still included.

Should it? Perhaps something like scopatz-nanorc since nanorc by itself is generic. I understand sticking to the upstream name is important but in this case the upstream name isn't really a name.

The current state of the patch does just that, complimenting the upstream nanorc files, by including the scopatz files higher up than the upstream files.

Give scopatz definitions lower precedence.

On further thought, I'm not sure if including scopatz's as default is a good idea. There hasn't been any activity for nearly a year, and after numerous nano updates, some of the files are buggy (even nanorc.nanorc).
Seems it's best to include the scopatz files with lower precedence, so we have up-to-date definitions from nano and scopatz fills in definitions missing upstream (as hinted to in their readme).

Fix directory permissions.

There are a few that nano-syntax-highlighting doesn't cover, and also, scopatz's files haven't seen a release in a while, so some of nano's files are better ATM. Constantly choosing which ones would be better OOTB is a nightmare so we could just go with scopatz as default and let users choose if they want.

Replace mkdir with install.

Fix rundep.

Verified, no breakage.

I used to use that card and I remember it being butchered by multiple Linux releases.

Fix pspec and link.

Has seen stable release.

There's been a few dozen releases since then, and I think marp-cli is what should be considered for inclusion at this point: https://github.com/marp-team/marp-cli

I'm abandoning, doesn't seem worth the effort as it's poorly documented and getting it to work in its entirety looks to be a pain.

Oops, seems my local zsh-autosuggestions repo was out of date, abandoning. :p

Replace %make with make.

Like this? :)

Hopefully add the files this time.

Add zsh completions.

Add fish completion and change descriptions.

I've just tested the software in a clean Budgie installation and cannot replicate your issue, could you provide more details about your setup? The output of inxi -Fz would be great.

Thanks @kyrios123. :-)

@kyrios123 Windows 10, although the issue is also present on a fresh Ubuntu 18.04 guest machine.
You don't need a license, Microsoft provides free VMs for developers.

The issue is still present in the current Virtualbox package, the first time I tried inserting the quest additions image it failed to download, and the second time it outright crashed and aborted the VM. :/

Sorry 'bout that, copy. :-) I can provide a patch for the Python client when I have the time but before then perhaps @Jacek would like to take it up.

The machine which needed removal of xorg-driver-video-intel in order to work properly was a ThinkPad X220. I am currently on an XPS 13 9360 and the issue is not present, the Intel driver works fine.

It's actually one of the clients for tldr, the original one is I believe a node package, do we really want to package that? The initial proposal suggested the Python client tldr-python-client but an argument was made above for the Rust client tealdeer.

Oh I'm all for Tealdeer too then. :-)

I'd like to package the Python client of TLDR, as Python is included in the base Solus system. Not familiar with Rust, does Tealdeer have Rust as a dependency? Not sure I would be willing to install an entire language for one utility.

This has been addressed before: https://dev.getsol.us/T649