@ldeck Emacs has a profiler to identify cpu and memory usage which can help.
For example:
https://practicalli.github.io/spacemacs/install-spacemacs/troubleshooting.html#profiling-emacs
M-x profiler-start, run some commands, M-x profiler-reportFor example:
https://practicalli.github.io/spacemacs/install-spacemacs/troubleshooting.html#profiling-emacs
Looking for help with magit/forge against github. Everything seems to work except any pull/push request asks for username/password. I enter username and github personal token and the push/pull works fine. I've fixed .authinfo and added .authinfo to auth-sources. What am I missing?
@DSMasterson your remote URLs are
https://github.com/<repo>/<user> I assume? You can set up git credential caching, or switch to ssh URLs (git@github.com:<repo>/<user>) and rely on ssh-agent for password caching
@npostavs oh, but shouldn't magit/forge be getting the username/password out of ~/.authinfo (which I think I've set up)?
I set up the GitHub access token in .gitconfig https://practicalli.github.io/spacemacs/source-control/github-configuration.html#add-github-access-to-git-configuration
Am I right in thinking that there's no native UI in magit for editing git config variables? From reading magit/magit#2744 I'm not sure whether this is a "we'll never add that" or "we might add that at some point" kind of situation, or maybe that issue is about something else entirely.
IMHO it would be really helpful to have a native interface for it
@aspiers I think that issue is more about the non-interactive functions that magit uses for git config variables. Some transients allow editing certain git config variables, but there isn't a totally general UI for it. IMO, that sort of thing doesn't really belong in magit, but having a mode more specialized than
conf-mode for gitconfig files could be nice.
@npostavs Thanks! Curious why you don't feel it belongs in magit? The first paragraph of the manual says
Magit aspires to be a complete Git porcelain. While we cannot (yet) claim that Magit wraps and improves upon each and every Git command, it is complete enough to allow even experienced Git users
to perform almost all of their daily version control tasks directly from within Emacs. While many fine Git clients exist, only Magit and Git itself deserve to be called porcelains.
IMHO
git config is one of the more commonly used tasks
There would be significant advantages over editing config files directly, e.g.:
- Significantly fewer keystrokes, since just opening up the right file involves several keystrokes, and then you have to navigate to the right section
- Completion of already set (and maybe even known) config variable names
- No risk of adding duplicate values to the same file
All very similar to the reasons justifying why it is worth magit allowing configuration of remotes via Transient menus
(magit-insert-ignored-files) is closest but it only applies a filter. The file under point is not added to .gitignore
@magthe In addition to what @gcentauri said:
text-mode and magit-status-mode are both MAJOR modes. You cannot just turn on some random major mode in a buffer and expect things to go back to normal when you switch back to the expected major mode. It might mostly work but other things might also end up broken.
(something like interpreting those control characters I guess)
@juboba Is there any option in your hook scripts to disable ANSI colors? For example, I see Eslint supports a
--no-color argument flag: https://eslint.org/docs/user-guide/command-line-interface
good idea, thanks
@juboba https://github.com/magit/magit/issues/1878#issuecomment-105963850 "If you really want the colors, or prefer editing Magit instead of the Git hooks, then you'll need to advise magit-process-sentinel, magit-process-filter, or some other related function"
Using https://github.com/alphapapa/org-rifle on Windows 10 and Emacs compiled with MSYS2 MinGW I get this traceback with errors from magit: https://pastebin.com/F6t8thX6.
I found https://magit.vc/manual/magit/Microsoft-Windows-Performance.html#Microsoft-Windows-Performance which mentions subprocesses, but only regarding speed, not the limit of maximum number of processes. Any ideas?
I guess it is ultimately related to the official Git release for Windows which presumably runs on a fork of MSYS2 where I could not set the max user processes> This SO question without answer is related, but about lowering and not increasing the number - getting the same error message though: https://unix.stackexchange.com/questions/320494/msys2-ulimit-max-user-processes-cannot-modify-limit-invalid-arguments.