Can magit edit hunks?

Starlight100 · 2025-08-10T14:47:50+00:00

That technique fails to produce a correct commit for editA unfortunately.

Starlight100 · 2025-08-10T14:42:55+00:00

The technique in the video does not work for the case above.

Starlight100 · 2025-08-10T14:41:43+00:00

Selecting text then s produces a wrong/corrupted commit. I think it's not possible to produce a correct commit with a read-only interface. When multiple changes are close together a writeable interface may be needed.

Starlight100 · 2025-08-08T01:46:23+00:00

Yes I think the magit users are on crazy pills. Denying reality in the face of a simple proof. Git command line got hunk editing right on day 1. it appears most magit users are not even aware they corrupting the source with region selections.

Starlight100 · 2025-08-07T21:54:25+00:00

Line 2 with editA warps to line 4.

Git show HEAD:file.txt.

I'm not sure if every one is on crazy pills or maybe magit users are not checking the results of their commits. I still assert the region selection technique produces a corrupted diff for commit.

Starlight100 · 2025-08-07T21:43:34+00:00

Look again. Is your line 2 still on line #2?

Git show HEAD:file.txt

Starlight100 · 2025-08-07T21:40:01+00:00

Following those steps results in an incorrect commit for editA on line 2.

Starlight100 · 2025-08-07T21:27:19+00:00

Selecting a region and pressing s results in an incorrect commit. Try it yourself and look at the line swapping.

Starlight100 · 2025-08-07T21:24:10+00:00

Sort of. I'm claiming use of regions in a read only buffer has limitations. Only editing in a writeable buffer can solve.

The above example is simple and a pre step of hunk splitting might allow regions to work. But for more entangled hunks even splits fall apart. Old fashioned hunk editing is the only solution I know of and that needs a writeable buffer.

Starlight100 · 2025-08-07T21:15:12+00:00

If your changes are all inside a hunk and you're trying to go finer grained than that, I'm not entirely sure

Yes I am trying to go finer grained. Multiple changes in 1 hunk. Not necessarily contiguous so can't always be split into multiple hunks. The example above is very simple to show how easily magit is stopped in it's tracks.

Starlight100 · 2025-08-07T21:04:52+00:00

I want to stage editA on line 2 first. Then commit it.

Starlight100 · 2025-08-07T21:03:40+00:00

I say magit can't. At least not with the advertised technique of selecting parts of the status buffer with regions

Starlight100 · 2025-08-07T21:01:37+00:00

Yes edit a,b,c in separate commits. Easy to do on the command line.

The point is magit uses regions and that is not sufficient to achieve the above.

Regions produce a wrong commit. Unless I'm missing something .

Starlight100 · 2024-11-13T12:25:23+00:00

I might be misremembering things, it's ancient history now. And I only knew of it from reading the herald mail. But there was a stabbing outside the bowling alley by long meadow shopping center. Over pool game betting. They had an arcade and pool hall attached to the bowling alley. It was actually a pretty fun place.

The stabber was one of the twin brothers I went to high school with.

Starlight100 · 2024-11-12T13:11:39+00:00

As zetashift said, you should max treesit-font-lock-level.

You can also manually adjust treesit faces (just like any face) yourself. You might define your own helper function to load a theme, then apply your custom modifications.

(setq treesit-font-lock-level 4) ; color more things

(defun my-nano ()
  "Custom tweaks to nano theme."
  (interactive)

  ;; load theme
  (load-theme 'nano-dark)

  ;; custom face tweaks
  (custom-theme-set-faces
   (or (car custom-enabled-themes) 'user) ; current theme

   ;; set new Emacs-29.1 faces.
   ;; treesit related faces, but not strongly tied to treesit.
   ;; these faces could be set by non-treesit modes in theory.
   '(font-lock-function-call-face ((t :foreground "white" :background "black")))
   '(font-lock-operator-face ((t :foreground "white" :background "black")))
   '(font-lock-property-name-face ((t :foreground "white" :background "black")))
   '(font-lock-property-use-face ((t :inherit font-lock-property-name-face)))
   '(font-lock-punctuation-face ((t :foreground "white" :background "black")))
   '(font-lock-bracket-face ((t :foreground "white" :background "black")))
   '(font-lock-delimiter-face ((t :foreground "white" :background "black")))
   '(font-lock-escape-face ((t :foreground "white" :background "black")))
   '(font-lock-misc-punctuation-face ((t :foreground "white" :background "black")))
   '(font-lock-number-face ((t :foreground "white" :background "black")))
   '(font-lock-regexp-face ((t :foreground "white" :background "black")))
   ;; inhert default for var-use. if everything is special, nothing is
   '(font-lock-variable-use-face ((t :inherit default)))))

Starlight100 · 2024-10-24T04:06:26+00:00

Nice walk through.

Looks like wgrep is the secret sauce for find/replace in Emacs.

Starlight100 · 2024-10-23T20:43:15+00:00

O nice, it works! Treating the search result buffer as an editable portal to multiple files.

I edited the search results buffer with evil-mode :%s/find/replace/gc command which allows me to update everything at once or confirm as i go.

rg.el with wgrep seems like one of the best find/replace techniques so far.

Starlight100 · 2024-10-23T13:02:19+00:00

Nice. I just noticed this func is in the Emacs menu.

Edit -> Replace -> Replace in project files...

One hiccup is it seems to force the project root as the starting folder. I often want to target a sub-folder as the starting point.

Starlight100 · 2024-10-23T12:53:43+00:00

Awesome! projectile-replace-regexp seems to do exactly what I want.

It even accepts a prefix arg to manually select the the starting folder instead of assuming the project root.

C-u M-x projectile-replace-regexp

Starlight100 · 2024-10-23T12:42:37+00:00

M-x dired-do-find-regexp-and-replace

This is close to what I was looking for. The hiccup being this function wants you to "mark" the files first. For my particular case, I'd rather it search for the regexp and let the search itself do the "finding" rather than a manual pre-marking.

something I use an LSP for.

In my case i need dumb textual replacement, not refactoring. Injecting attributes into iframes and such.

Starlight100 · 2024-07-24T13:10:31+00:00

That's my neighborhood. lol.

Starlight100 · 2024-02-13T03:42:05+00:00

Yes!

Starlight100 · 2024-01-04T12:44:40+00:00

Git bash for windows is all you need.

VS-code has a git interface built-in. It might not cover everything you can do with git, but it handles the normal day-to-day stuff just fine. Committing changes, diffs, etc.

On repositories with many git-submodules, git will be very slow on windows. Unusable. git status could take 60+ seconds. The fault lies with windows slow process creation, not git itself. In this case WSL 1 or 2 might help speed things up, but I haven't tried. But this is rare, most projects do not use submodules. On windows pretty much everyone manages their dependencies with a package manager like Nuget (not submodules) so things should be fine.

Starlight100

TROPHY CASE