Windows 10, Emacs 25.1, Magit

Execute command magit-status and press "TAB". Here result:


If I want to change this text I go to my editor (e.g. Notepad++) and edit text.

The question is:

Can I directy edit text in magit buffer when files are in Unstaged changes?

  • 3
    You can not edit text directly in the Magit buffer, but when your cursor is on the changes you want to edit you can press RET to jump to a buffer within Emacs in which you can edit the file.
    – Arnot
    Oct 6, 2017 at 8:35
  • 2
    – bertfred
    Oct 6, 2017 at 8:49
  • 4
    "go to my editor (e.g. Notepad++)" ??!?
    – phils
    Oct 6, 2017 at 11:48
  • 1
    @phils I hear it's not uncommon to use emacs just for magit; in fact, magit promotes the idea. Oct 8, 2017 at 17:37
  • 1
    @SeanAllred Indeed, but there's no denying at least a bit of irony. :)
    – Basil
    Oct 8, 2017 at 18:52

2 Answers 2


The status buffer is just an interface to git; it's not an editor in itself, so you can't edit right from there. In Emacs, this isn't a problem, since you just RET and it takes you to the file/line/column you were at. There is still a feature request for this enhancement, but such functionality would be weird IMO since you'd have to enter some other mode within magit-status-mode since most keys already mean something special.

You mention though that you want to use a different editor to edit this text. If that is your real question, read below.

If your editor supports command-line arguments, you can do this rather easily at a file-level by advising magit-diff-visit-file:

(defun open-in-vscode (orig-fun &rest args)
  (let ((file (car args)))
    ;; If you don't want this behavior for every file/project,
    ;; you can still keep the old behavior using `orig-fun`.
    (if (or t (should-open-in-vs-code file))
         ;; This is VS Code, the only other editor I have installed
         ;; Look up Notepadd++'s arguments as appropriate.
         "/Applications/Visual Studio Code.app/Contents/Resources/app/bin/code"
         nil nil nil
      (apply orig-fun args))))

(advice-add #'magit-diff-visit-file :around #'open-in-vscode)

If you want to jump to the file:line:column, you'll have to dig deeper into magit-diff-visit-file and possibly provide a reimplementation (then advising using :override) that will do the right thing for you. The line/column information is already available in magit-diff-visit-file, so it would just be a matter of putting that information to other use.


If you make the status buffer editable (M-x read-only-mode), you actually can edit it. Note, though, that this edits only the magit status buffer, and not the underlying file, and this is generally very hacky and it's easy to break the status buffer this way.

However, this can still be useful because you can then perform git operations on the edited diffs - e.g. you can edit a part of a diff, then select and stage the edited variant.

One particularly useful operation which can be done this way is to reorder lines to allow staging only some edits in consecutive edited lines. For example, if the old file is:


and it was changed to:


then the diff will be:


If you wish to stage only changes in the first line, staging only the -fun(apple); and +fun(apple2); lines will not do what you want - it will reorder the calls. However, by making the magit status buffer writable, you can reorder lines to make it look like this:


Then, you can select the first two lines and stage them, achieving the desired result.

  • Amazing. I'd never have guessed that this would work. You do need to ensure that your edits still produce a valid patch though, so I can't see myself considering this for more than the most trivial changes.
    – phils
    Jun 1, 2021 at 6:04
  • Alternatively, assuming that you're familiar with ediff, you can type e on the file in question to open up a 3-way ediff session including an ~index~ buffer for the staged version -- and if you edit that buffer directly and then quit ediff (no need to save), Magit will prompt you to update the index accordingly. So you can stage the 'bad' changes and then just edit them to be 'good'. Somewhat similar to your trick, but using a supported technique which doesn't require you to use diff formatting.
    – phils
    Jun 1, 2021 at 6:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.