ECFG: put ~ / .emacs on a diet
Friends, today I want to share with you the realization of the idea of creating a modular, portable and scalable configuration for your favorite text editor, tested in practice for many months on various combinations of hardware and software: Emacs Config .
Without panic, if everything is already working fine for you, you do not need to change anything. If something from the list below has long languished in the dusty tudu-list, but there is not enough time to roll up your sleeves as usual, then it will be interesting to see. So what ECFG offers you:
The source code is publicly available on the github: github.com/maslennikov/emacs-config .
')
I started using the Emacs text editor about seven years ago. In the beginningthere was a word that all configuration recipes found on the network were heaped up in ~ / .emacs .
As they accumulate experience and various applications, more and more voluminous plugins began to move to ~ / .emacs.d / . All this, however, required more and more gluing logic and dependency management, and one ~ / .emacs was obviously not enough.
Over time, the initialization code was divided into separate modules, and for quite a long time ~ / .emacs.d / with these modules and manually assembled from the Internet spaces the plugins were synchronized via Dropbox with all my workstations.
During this period, I began to feel acutely the problem of controlling the plug-in versions. Around the same time, package.el began to gain popularity, and the idea of automatically controlling the installation of packages no longer seemed utopian. Another reason for automating the installation of plug-ins was the desire to move from simple synchronization via Dropbox to a full-fledged repository on the githaba: there was already too much configuration code to allow yourself not to use the version control system, and the firewall at the new workplace also blocked my dropbox To keep the downloaded and unmanaged source files and binary files of plug-ins on the github did not want to be stored.
The turning point came when I discovered the Oh My Emacs configuration framework, which was almost an ideal solution for all my needs. Except for one thing: it was slow. Highly. This was the impetus for the creation of the ECFG project.
ECFG does not currently use ~ / .emacs nor ~ / .emacs.d / . This is done intentionally in order to exclude the possibility of automatic modification of the library by the editor or the connected plug-ins. On the other hand, all artifacts of various modules (for example, recentf history files) will find their originally intended place in ~ / .emacs.d , and settings that are unique to each user (for example, custom-set-variables, etc.) can be freely placed in ~ / .emacs .
Information for more subtle control over this process can be found in the help for the user-emacs-directory and custom-file variables.
To install ECFG, save a copy of the repository to your workstation in any directory:
To teach Emacs to download ECFG , just place the following lines in your ~ / .emacs
And it's all. During the first launch, it may take some time to download from the network and configure all the plug-ins used in the configuration.
As stated in your ~ / .emacs , the entry point for ECFG is the init.el file, which controls the boot sequence of all other modules.
Configuration files (just for the sake of what it was all started) are grouped in two directories:
The basic configuration from the init.d / directory is loaded synchronously during the launch of the editor, which is why special attention was paid to optimizing the speed of execution of this code (for more information on optimizing plug-ins, you can get here ).
The configuration of the main modes from the modules directory prepares the lazy loading of modules using the autoloads mechanism. To do this, it is enough to define an initialization function in the module file with the name ecfg-NAME-module-init and register it with the ecfg-auto-module macro. For example, the connection of a new module for cmake mode configuration is as follows:
In this case, the module will be loaded and initialized only during the opening of a file with the name CMakeLists , in other cases the code of this file will not be loaded.
You will find more detailed and always up-to-date information on the project repository page, and I will gladly provide answers to your questions in the comments.
Again something to configure?
Without panic, if everything is already working fine for you, you do not need to change anything. If something from the list below has long languished in the dusty tudu-list, but there is not enough time to roll up your sleeves as usual, then it will be interesting to see. So what ECFG offers you:
- Storage of the entire configuration in the git repository.
- Automatic download of fresh versions of all third-party packages on the network during the first run.
- Optimized download speed editor: connected modules are automatically loaded only at the time of use.
- The lightweight framework practically does not interfere with the configuration code, allowing you to include snippets found on the network and still taking advantage of all the advantages listed above.
- It is easy and intuitive to add or change the configuration - even when you managed to forget all elisp-kung-fu (the author was convinced several times)
The source code is publicly available on the github: github.com/maslennikov/emacs-config .
')
Emacs Config. Start
I started using the Emacs text editor about seven years ago. In the beginning
As they accumulate experience and various applications, more and more voluminous plugins began to move to ~ / .emacs.d / . All this, however, required more and more gluing logic and dependency management, and one ~ / .emacs was obviously not enough.
Over time, the initialization code was divided into separate modules, and for quite a long time ~ / .emacs.d / with these modules and manually assembled from the Internet spaces the plugins were synchronized via Dropbox with all my workstations.
During this period, I began to feel acutely the problem of controlling the plug-in versions. Around the same time, package.el began to gain popularity, and the idea of automatically controlling the installation of packages no longer seemed utopian. Another reason for automating the installation of plug-ins was the desire to move from simple synchronization via Dropbox to a full-fledged repository on the githaba: there was already too much configuration code to allow yourself not to use the version control system, and the firewall at the new workplace also blocked my dropbox To keep the downloaded and unmanaged source files and binary files of plug-ins on the github did not want to be stored.
The turning point came when I discovered the Oh My Emacs configuration framework, which was almost an ideal solution for all my needs. Except for one thing: it was slow. Highly. This was the impetus for the creation of the ECFG project.
Installation
ECFG does not currently use ~ / .emacs nor ~ / .emacs.d / . This is done intentionally in order to exclude the possibility of automatic modification of the library by the editor or the connected plug-ins. On the other hand, all artifacts of various modules (for example, recentf history files) will find their originally intended place in ~ / .emacs.d , and settings that are unique to each user (for example, custom-set-variables, etc.) can be freely placed in ~ / .emacs .
Information for more subtle control over this process can be found in the help for the user-emacs-directory and custom-file variables.
To install ECFG, save a copy of the repository to your workstation in any directory:
git clone https://github.com/maslennikov/emacs-config.git ~/.emacs.config To teach Emacs to download ECFG , just place the following lines in your ~ / .emacs
;; in case you use windows, teach it the utf8 (prefer-coding-system 'utf-8) (load-file "~/.emacs.config/init.el") And it's all. During the first launch, it may take some time to download from the network and configure all the plug-ins used in the configuration.
How it works
As stated in your ~ / .emacs , the entry point for ECFG is the init.el file, which controls the boot sequence of all other modules.
Configuration files (just for the sake of what it was all started) are grouped in two directories:
- init.d: contains the basic configuration of the editor, independent of the file type or mode in the current buffer;
- modules: contains the configuration applicable to files or modes of a particular type.
The basic configuration from the init.d / directory is loaded synchronously during the launch of the editor, which is why special attention was paid to optimizing the speed of execution of this code (for more information on optimizing plug-ins, you can get here ).
The configuration of the main modes from the modules directory prepares the lazy loading of modules using the autoloads mechanism. To do this, it is enough to define an initialization function in the module file with the name ecfg-NAME-module-init and register it with the ecfg-auto-module macro. For example, the connection of a new module for cmake mode configuration is as follows:
;;;###autoload (ecfg-auto-module "CMakeLists\\.txt$" cmake) In this case, the module will be loaded and initialized only during the opening of a file with the name CMakeLists , in other cases the code of this file will not be loaded.
You will find more detailed and always up-to-date information on the project repository page, and I will gladly provide answers to your questions in the comments.
Source: https://habr.com/ru/post/268271/
All Articles