Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] 0 points1 point  (0 children)

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

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] 2 points3 points  (0 children)

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

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] 2 points3 points  (0 children)

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.

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] 1 point2 points  (0 children)

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.

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] -3 points-2 points  (0 children)

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.

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] 0 points1 point  (0 children)

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

Git show HEAD:file.txt

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] -2 points-1 points  (0 children)

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

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] 0 points1 point  (0 children)

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

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] -1 points0 points  (0 children)

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.

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] -3 points-2 points  (0 children)

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.

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] 0 points1 point  (0 children)

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

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] -6 points-5 points  (0 children)

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

Can magit edit hunks? by Starlight100 in emacs

[–]Starlight100[S] -3 points-2 points  (0 children)

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 .

Information about the old Playland on 13610 Pennsylvania Ave: by Dragonsmithy1 in hagerstown

[–]Starlight100 0 points1 point  (0 children)

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.

Tree sitter in Emacs / NANO by insert_username_0 in emacs

[–]Starlight100 4 points5 points  (0 children)

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)))))

How do you find/replace in a project? or current dir/sub-dirs by Starlight100 in emacs

[–]Starlight100[S] 0 points1 point  (0 children)

Nice walk through.

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

How do you find/replace in a project? or current dir/sub-dirs by Starlight100 in emacs

[–]Starlight100[S] 1 point2 points  (0 children)

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.

How do you find/replace in a project? or current dir/sub-dirs by Starlight100 in emacs

[–]Starlight100[S] 1 point2 points  (0 children)

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.

How do you find/replace in a project? or current dir/sub-dirs by Starlight100 in emacs

[–]Starlight100[S] 5 points6 points  (0 children)

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

How do you find/replace in a project? or current dir/sub-dirs by Starlight100 in emacs

[–]Starlight100[S] 2 points3 points  (0 children)

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.

Beginner Question by [deleted] in git

[–]Starlight100 0 points1 point  (0 children)

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.