what is basic alghoritm/logic of installation packages to emacs?

when should ı use write codes to .emacs file for installation and when should ı use M-x shortcut?

You can install packages in emacs declaratively or imperatively, that is you can either call `M-x package*` and use `package.el` to manage packages, or use something like straight.el to list packages out in your dotfiles. I personally prefer using straight + use-package to manage packages, but some people prefer using package.el + m-x customize ref: https://github.com/radian-software/straight.el https://github.com/jwiegley/use-package There are many other ways to manage packages, but those are the two big ones

>There are many other ways to manage packages, but those are the two big ones Yes, and it's super confusing imo. It's nearly as bad as Python's package management. After ELPA/MELPA were introduced I found that getting these mechanisms to work seamlessly was often more trouble than manual installation. I've never heard of straight.el but I do remember when "packages" were simply conceptual descriptions of related functionalities but they were an obscure Emacs feature and rarely used. They seemed like more of a documentation feature. I'm pretty sure use-package built on top of this, but idk. I always just downloaded raw .el files and just dropped them into my load-path.

IMO you should ONLY use declarative way, for instance use-package/package.el in config BUT in practice just to test a package a quick manual install might be ok. All you need is remember to periodically rebuild you Emacs when you have spare time BEFORE the deploy goes TFU. I mean: - write an initial config/choose one made by someone else - tweak it until you are satisfied - keep it for a little while, than move ~/.emacs.d, create a new empty one, put the old config ALONE (with snippets etc, but ONLY the code you have written) and restart Emacs. Anything should be auto-reinstalled issueless - since probably it will not, tweak/fix and repeat until it work - keep the new, drop the old, use for a little while and repeat when you have spare time such fresh-install cycle ensure to never reach an Emacs bankruptcy in a bad moment, it's not different for any OS deploy, except eventually those based on a declarative config like NixOS/Guix system... If you do so, you only need to remember properly adding packages declarative and forgetting it is a good natural selection way: you install something, you use it then forgot about it, next rebuild will vanish keeping your install clean. If you need it you'll find it missing and then properly add it.

Yeah I find dependency management for most languages is *super* annoying. I think rust has gotten it the most right, providing options for cloning from git as well as a centralized repo (crates), proper versioning, lock files, etc. Though I'm not sure if I prefer emacs' method of multiple "central" repositories elpa/melpa/nongnuelpa/etc. or neovim's method of just hosting all plugins on git forges. Knowing that a plugin has been reviewed for quality if it's in melpa or elpa is nice reassurance.

> write codes to .emacs file for installation What sort of code did you have in mind? > when should ı use M-x shortcut? Which command?

generally ı want install useful plugin/packages like emmet-mode or jedi into emacs and when ı searched how can ı install emmet-mode into emacs ı see write codes to .emacs file or sometimes M-x shortcut like packages-install RET jedi

ı am new in using emacs and ı dont have any idea about how does emacs work, ı know just useful keys combination like M-f or M-w etc.. but ı still dont know install plugins and how can ı use them for example ı installed jedi with 'M-x packages-install RET jedi' but ı dont know how can ı use this also ı saw codes in init.file about installation jedi so ı wonder difference between M-x and init.file configuring

Ok, well `M-x package-install` is the simplest option, so I recommend using that generally. Make sure you read `C-h i g (emacs)Packages` which will tell you everything you need to know about installing packages this way. (And type `h` from there if you're not very familiar with the info reader, as the resulting intro/tutorial will teach you lots of extremely helpful things.) There *are* many other options available, but you can pick just one approach and stick with that. You can always change it later if you decide you want to, once you've learned more. You may also need to add things to your init file to *configure* the installed package. This varies from package to package, so make sure you always check the documentation for each package you use.