I'm not sure I fully understand which issues you wish to solve, as the images only compare the mode line with the full screen of the other editors. It seems like there are two potential issue: 1. Modeline has too much information 2. You want more feedback during the diff (no screenshot of what you are doing in Emacs here)

Im currently under the impression that mode line, isnt showing the most useful information. But maybe i don't understand what I'm seeing

In the practicalli/spacemacs.d config I have switched off much of the information on the modeline by adding spacemacs-modeline as a layer and adding variables to customise the modeline

;; Configuration: 
     (spacemacs-modeline :variables
                         doom-modeline-height 12
                         doom-modeline-major-mode-color-icon t
                         doom-modeline-buffer-file-name-style 'relative-to-project
                         doom-modeline-display-default-persp-name t
                         doom-modeline-minor-modes nil
                         doom-modeline-modal-icon nil)

And am using the Doom modeline theme (which these variables act upon, which I found easier to decultter than the spaceline theme

dotspacemacs-mode-line-theme '(doom)

However, I dont really look at the modeline when using diff or ediff in Emacs, so not sure how this really helps issue 2.

I assume that ediff is launched by pressing e key on the file that is causing a merge conflict. This should open 3 windows, two large windows showing the committed file and the file to merge respectively. The third window along the bottom is the control window and ? shows the key bindings to control ediff In Evil state, j and k keys move the highlight between the conflicting changes. a uses the change from window one to resolve the conflict, b uses the change from window 2 to resolve the conflict

Huh. Nothing obvious on my screen displays the necessary git branch info, it seems to be in the modline

But truncated

So this issue is you do not know which window is which in ediff ? I dont have anything with a merge conflict at the moment, so not easy for me to check...

Not sure if this helps or makes things more confusing, but if you add diff3 as the conflict style in your Git config (`~/.gitconfig`) then you get 4 large windows, which shows the parent and resulting window as well

[merge]
	# Include common parent when merge conflicts arise
	conflictstyle = diff3

The issue is that there are times when it's not obvious which window contains which branches changes. Here is an example here it does contain that information HEAD and a-branch. In the other one, it looks like the long file name somehow pushed that info off.

or like, it has the file path where the branch name should be?

^ that at least has the branch info displayed. the one below doesnt https://files.slack.com/files-pri/T03RZGPFR-F04FWD50L4S/image.png

I think i tried diff3 and didn't like it because it messed up magit-ediff because it inserted characters that it didn't expect so it didn't register it as a diff in need of resolution.

thanks for the help john. Its enough to bounch the ideas off someone. Ill just put this in my todo list of minor improvements i need to make. Maybe ill give doom modeline another try. I felt like it was missing some things i was used to.

I'd suggest trying out the doom modeline theme again. It should just need the two pieces of code I pasted towards the start of this thread and then restart Emacs. I havent noticed the issue myself, but will take some screenshots next time. I also need to do some screenshots of using diff3 with ediff as it seems to work well for me. As I can see the parent it makes it more obvious as to the change. I think a fairly recent version of the Git client is required (it was working from May this year)

Did you resolve this issue with Spacemacs @U0DJ4T5U1 Using Doom Emacs I find it fairly clear which buffer is which, I assume Spacemacs is the same if using Doom modeline If not then there must be an option to tweak what is shown

the situation hasn't improved. I'm going to make a list of things i want to improve and rank them. i'm not using the modeline that came with spacemacs because it seemed to have what i expected more often.

it was other issues but the number of problems I had with spacemacs is what drove me to doom, too

Likewise. If you need help porting over some of the Spacemacs features like SPC k we can definitely help you out over in #C01GE5PD249. 🙂

I've been trying to use doom for several years (usually trying winter and summer), but just too many different key bindings, it really slowed me down each time. If someone has replicated all the Spacemacs keybindings in Doom (I use tonnes of Spacemacs ones) then it might be worth trying, otherwise I'd be very slow. I've experienced this slowness with Neovim recently, very much slower for several months and still not replicated enough functionality for it to be worth switching fully). Havent seen anything as consistent as Spacemacs as yet unfortunately.

I'm in that boat to, i keep trying to switch stuff over that i know how to do in space but it's time consuming and push comes to shove i use what i can work with.