Partial fix for strange airline behaviour

unknowledgeable commented 4 years ago

I started rewriting the airline theme based on the default dark theme and came across the same strange behaviour when I tried to make airline_a and airline_b have the same background colour.

This small change fixes the majority of the problems I was having but there are still some to iron out.

I think this file is over-engineered and it's confusing airline, I'm going to finish my re-write of the theme and although it's less elegant, I think it'll be more likely to work as expected. I'll make another PR when it's working and stable.

skbolton commented 4 years ago

I was going to take the plunge in this week to fix this! Thanks for jumping in. It's probably much easier for someone who uses airline to be able to fix and diagnose this.

skbolton commented 4 years ago

So does this solve #5 ?

unknowledgeable commented 4 years ago

So does this solve #5 ?

Only partially, it looks better but still behaves erratically when the same colour appears in two touching cells, this just prevents that from happening in the most common occurence of the problem I was having. It also looked like that's what it should have been to be consistend with the other modes.

BTW for the rewrite, I've found a few cool features that I could implement but would mean not keeping the color scheme strictly the same, namely:

Change the fg and bg colours of bufferline/tabline cells where a buffer has been edited but not focussed
Change the colour of the statusline text when a buffer has been edited
Change the colour of the filetype/language depending on mode

Do you have any objection to me changing some of the mode colours to help distinguish modes more easily? I'm thinking

Normal = cyan
Visual = yellow
Replace = green
Insert = Red
Terminal = blue
Command = purple
Unfocussed = dark (space/deepspace/eclipse)

skbolton commented 4 years ago

The current theme really is a rough port of challenger deep. I am not partial to it. That said if you can supply screenshots in your PR it would help give context and make the decision a lot easier.

unknowledgeable commented 4 years ago

Apologies, I realise I should have just put the screenshot and explanation of the rewrite here.

I have another newbie GitHub workflow question for you if you wouldn't mind helping me out? How should I go about making a PR for the rewrite?

I'm using vim-plug to keep embark up to date within vim so I don't need to manually clone the repo to update it. For the last commit I forked the embark-theme/vim repo and cloned my fork to an irrelevant folder and just made the same changes that I tested on a separate file. The changes were so small in this case that I wasn't too worried about it causing problems. My new embark_V2 airline theme file is currently in the airline-themes folder and not in the embark folder.

Here's what I know I could do:

replace the file in the irrelevant cloned directory with the new embark_V2 file and rename every mention of embark_V2 with embark in that file
git commit and push
make a PR

But that would mean I'm not absolutely sure the theme works because the file I'm pushing isn't the one I see in my vim setup. Also, my fork may not be up to date with your repo.

Should I instead:

a. delete my fork, make a new fork of the embark-theme/vim repo and then clone it again and do steps 1, 2 and 3?

b. remove embark in vim-plug, delete my fork, make a new one and clone it manually to somewhere that would work in my vim setup then do 1, 2 and 3?

c. something else entirely?

Once I've got my fork cloned to my computer, is this what I need to do to make sure I'm up to date?

git remote add upstream git://github.com/embark-theme/vim.git
git fetch upstream
git pull upstream master

Or should the first step be this?

git remote add upstream https://github.com/embark-theme/vim.git

Many thanks!

skbolton commented 4 years ago

I would clone down your fork of the library and then point your vim plug installation to that folder.

Plug '~/path/to/your/clone', { 'as': 'embark'}

This way you can make changes locally and see them immediately in your vim. When ready just push the new code to your fork and make a PR. After wards you can either keep your fork up to date on your machine by catching up with master or change your plug installation to point back to the main repo.

If you decided to keep your fork locally and want to keep it up to date with the main master I would create a new remote.

git remote add embark git@github.com:embark-theme/vim.git

You can make the embark name be whatever you want. With that you can push to origin (your fork), or pull from embark (original repo).

On your fork I would suggest not making commits directly to master that way when on master you can do this to get caught up with the main repo.

git pull embark master

No matter what way you choose I would just keep your fork on your machine as long as you think you are going to make contributions.

The way I do contributions to embark is by temporarily changing my plugin managers path to point to the local copy. After whatever I am working on gets merged in I change the path back to the main repo.

embark-theme / vim

Partial fix for strange airline behaviour #15