#모음: #이블 #편집

:collection:emacs:evil:notes:

[2023-10-04 Wed 15:12] 코딩을 하다 보니 필요한 키를 알게 된다. 그래서 자연스럽게 여기게 집중하게 된다. 놀라운 일이다.

[2023-09-09 Sat 12:35] 간단하게 정리할 수 없는 내용이다. 근데 해야 한다. 그래서 일단 씨앗을 심었다. 거둘 수는 없다. 가야 한다. 텍스트 마스터로서 자유를 얻으려면 일단 편집 모드를 이해해야 한다. 이맥스에서 제공하는 편집 모드를 섞어 쓰는 것도 좋지만 EVIL 은 경험을 해야 한다.

* # :: #심볼 Symbol Transient State

[2023-05-13 Sat 16:40]

EVIl 관련 훈련을 좀 했어야 되는데 이제 알았네. 된장.

그리고 Spacemacs 에서 제공하는 Transient State 는 다 이유가 있다. 필요해서 있는 것이다. compleseus 레이어에 가면 수정하면 된다. 여기서 project 가 projectile 에 연결되어 있다. 수정 바람.

히스토리

Corgi Manual

Principles

Minimal

Minimal is relative, one person's essential is an other person's bloat. What do we mean for Corgi to be minimal?

최소한의 것은 상대적이고 한 사람의 필수품은 다른 사람의 팽만감입니다. Corgi 가 최소라는 것은 무엇을 의미합니까?

First off we limit the amount of packages that Corgi pulls in, even though some of the packages we do pull in are fairly large. Beyond that we limit the amount of customization we do beyond what these packages provide. When in doubt, do less. When there are multiple competing options for how to handle something, do the one that is closer to the default.

먼저 우리가 가져오는 패키지 중 일부가 상당히 크더라도 Corgi 가 가져오는 패키지의 양을 제한합니다. 그 이상으로 우리는 이러한 패키지가 제공하는 것 이상으로 사용자 정의의 양을 제한합니다. 의심스러울 때는 적게 하십시오. 어떤 것을 처리하는 방법에 대해 여러 경쟁 옵션이 있는 경우 기본값에 더 가까운 옵션을 선택하십시오.

Combined this brings several benefits. It keeps Emacs running smoothly. It limits the number of moving parts, so there is less that can go wrong. And it makes it possible for people to keep an overview of what is it they are installing.

이를 결합하면 몇 가지 이점이 있습니다. Emacs 가 원활하게 실행되도록 합니다. 움직이는 부품의 수를 제한하므로 잘못될 수 있는 부분이 적습니다. 또한 사람들이 설치 중인 항목에 대한 개요를 유지할 수 있습니다.

Reproducible installs

The modern Emacs ecosystem has gone far beyond what it is was originally intended for. People are doing increasingly impressive and complex things on top of this humble LISP runtime, with packages recursively depending on dozens if not hundreds of other packages.

현대 Emacs 생태계는 원래 의도한 것 이상으로 발전했습니다. 사람들은 수백 개의 다른 패키지는 아니더라도 수십 개의 패키지에 재귀적으로 의존하는 이 겸손한 LISP 런타임 위에서 점점 더 인상적이고 복잡한 작업을 수행하고 있습니다.

Sadly our practices have not kept up with this reality. Two people can install the same Emacs config minutes apart, but still get different versions of packages, so no one is actually running the same code as anyone else. You are almost certainly getting a combination of package versions that was never tested before. Predictably this leads to breakage.

슬프게도 우리의 관행은 이러한 현실을 따라가지 못했습니다. 두 사람이 몇 분 간격으로 동일한 Emacs 구성을 설치할 수 있지만 여전히 다른 버전의 패키지를 얻을 수 있으므로 실제로 다른 사람과 동일한 코드를 실행하는 사람은 없습니다. 이전에 테스트한 적이 없는 패키지 버전의 조합이 거의 확실하게 나타납니다. 예상대로 이것은 파손으로 이어집니다.

This is partly technical and partly cultural, it seems the diligence to not introduce breaking API changes is not pervasive yet, and frankly the language and package system provide little affordances to limit the blast radius.

이것은 부분적으로는 기술적이고 부분적으로는 문화적인 것이며, API 변경 사항을 도입하지 않으려는 노력이 아직 널리 퍼져 있지 않은 것 같습니다. 솔직히 말해서 언어 및 패키지 시스템은 폭발 반경을 제한하기 위한 어포던스를 거의 제공하지 않습니다.

straight.el seeks to rectify this by providing reproducible installs. All packages are installed via Git, using specific commit hashes, which are "frozen" in a version file. When first using Corgi it will install its own version file, so you get the exact same code that Corgi was developed and tested with.

straight.el은 재현 가능한 설치를 제공하여 이 문제를 해결하려고 합니다. 모든 패키지는 버전 파일에서 "고정"된 특정 커밋 해시를 사용하여 Git 을 통해 설치됩니다. Corgi 를 처음 사용할 때 자체 버전 파일을 설치하므로 Corgi 가 개발 및 테스트된 것과 똑같은 코드를 얻을 수 있습니다.

Packages all the way down

When installing Corgi we don't give you a huge .emacs.d directory to copy, instead you create your own, and simply pull in the corgi package. Beyond that it's a standard Emacs config, and it's your config. Add customizations to .emacs.d/init.el to your heart's content.

Corgi 를 설치할 때 복사할 거대한 .emacs.d 디렉토리를 제공하지 않고 대신 직접 생성하고 corgi 패키지를 가져오기만 하면 됩니다. 그 외에는 표준 Emacs 구성이며 *귀하의 구성*입니다. ~.emacs.d/init.el~에 사용자 정의를 원하는 대로 추가하십시오.

Corgi itself is a collection of packages like corgi-editor, corgi-defaults, or corgi-emacs, and most of what these do is pulling in and configuring other packages. If you don't like what any of them is doing, then copy the relevant package over to your personal config and customize it from there.

Corgi 자체는 corgi-editor, corgi-defaults 또는 ~corgi-emacs~와 같은 패키지의 모음이며, 이들의 대부분은 다른 패키지를 가져와서 구성하는 것입니다. 그들 중 하나가 하는 일이 마음에 들지 않으면 관련 패키지를 개인 구성으로 복사하고 거기에서 사용자 정의하십시오.

Vim-style modal editing

There are two schools of thought for how to do editor key bindings, modal and key-chord. Emacs traditionally is a key-chord style editor, you combine keys with one or more modifiers in elaborate "chords". The vi/vim family of editors instead uses different editor "modes", like "normal mode", "insert mode", or "visual mode". What each key does depends on the current mode, in insert mode pressing `D` will insert the letter "D", but in normal mode it will delete up to the end of the line.

편집기 키 바인딩을 수행하는 방법에는 modal 및 /key-chord/라는 두 가지 학파가 있습니다. Emacs 는 전통적으로 키-코드 스타일 편집기이며, 정교한 "코드"에서 키를 하나 이상의 수정자와 결합합니다. vi/vim 편집기 제품군은 대신 "일반 모드", "삽입 모드" 또는 "비주얼 모드"와 같은 다른 편집기 "모드"를 사용합니다. 각 키가 하는 일은 현재 모드에 따라 다릅니다. 삽입 모드에서 `D`를 누르면 문자 "D"가 삽입되지만 일반 모드에서는 줄 끝까지 삭제됩니다.

Not all commands can be bound to a single key like that, others are bound to key sequences. `gg` goes to the beginning of the buffer. `,ep` evaluates and expression and pretty prints the result.

모든 명령이 이와 같이 단일 키에 바인딩될 수 있는 것은 아니며 다른 명령은 키 시퀀스에 바인딩됩니다. `gg`는 버퍼의 시작 부분으로 이동합니다. `,ep`는 결과를 평가하고 표현하고 예쁘게 인쇄합니다.

(Note that Emacs has a separate, unrelated concept of modes. To differentiate them these vim-style modes are also referred to as states.)

(Emacs 에는 관련이 없는 별도의 모드 개념이 있습니다. 이를 구별하기 위해 이러한 vim 스타일 모드를 상태라고도 합니다.)

There are two reasons why we have made a strong decision to promote the modal style: RSI, and command composition.

모달 스타일을 장려하기로 결정한 데에는 RSI 와 명령 구성이라는 두 가지 이유가 있습니다.

RSI or repetitive strain injury, also known as a "mouse arm" or "emacs pinky" is an inflammation of the neural pathways in the arm and wrist. It's a painful affliction that many programmers suffer from, and recovering can be a long and frustrating process, sometimes forcing people to put their programming career on hold for extended periods of time.

"마우스 팔" 또는 "이맥스 핑키"라고도 알려진 RSI 또는 /반복적 긴장 부상/은 팔과 손목의 신경 경로 염증입니다. 이는 많은 프로그래머가 겪는 고통스러운 고통이며, 복구는 길고 좌절스러운 과정이 될 수 있으며, 때로는 사람들이 프로그래밍 경력을 장기간 보류해야 하는 경우도 있습니다.

The Emacs key chords can be a contributing factor to RSI. It is telling that a common form of RSI among Emacs users shows up in the left pinky, used to press Ctrl over and over. It seems in contrast that pressing single keys in sequence, so the hands do less moving around and less stretching out, is easier on the body.

Emacs 키 코드는 RSI 에 기여하는 요소가 될 수 있습니다. 그것은 Emacs 사용자들 사이에서 일반적인 형태의 RSI 가 Ctrl 을 계속해서 누를 때 사용되는 왼쪽 새끼손가락에 나타난다는 것을 말하고 있습니다. 반대로 손이 덜 움직이고 덜 펴지도록 키를 하나씩 차례로 누르는 것이 몸에 더 쉬운 것 같습니다.

This alone should be a fairly compelling argument, but modal editing isn't only good for your health, it will also make you a more productive programmer. See, these single keypress commands don't just exist in isolation, they can be combined into "sentences" to very concisely express complex operations.

이것만으로도 상당히 설득력 있는 주장이 될 것이지만, 모달 편집은 건강에 좋을 뿐만 아니라 더 생산적인 프로그래머가 될 것입니다. 이러한 단일 키 누르기 명령은 단독으로 존재하는 것이 아니라 "문장"으로 결합되어 복잡한 작업을 매우 간결하게 표현할 수 있습니다.

<number><command><text object or motion>
 
<숫자><명령><텍스트 개체 또는 모션>
 
In normal mode `w` moves forward by one word. `3w` moves forward by 3 words. `dw` deletes the next word. `3dw` deletes the next 3 words. Combining these commands and text objects allows you to do in two or three key strokes what might be a lot of bouncing the cursor around and pressing several key chords otherwise.
 
일반 모드에서 `w`는 한 단어 앞으로 이동합니다. '3w'는 3단어 앞으로 이동합니다. `dw`는 다음 단어를 삭제합니다. `3dw`는 다음 세 단어를 삭제합니다. 이러한 명령과 텍스트 개체를 결합하면 두세 번의 키 입력으로 커서를 이리저리 튕기고 그렇지 않으면 여러 키 코드를 누르는 작업을 수행할 수 있습니다.
 
Some more examples:
몇 가지 더 많은 예:
 
- `2yL` copy ("yank") the next 2 s-expressions
- `c$` "change" from cursor position to the end of the line, this deletes the
  relevant section and changes to insert mode
- `cs(]` change surrounding parenthesis to brackets
- `di"` delete inner string, i.e. delete everything inside the surrounding
  double quotes

Focused on Clojure and LISP

This setup is mainly intended for Clojure programmers. That isn't to say that you can't or shouldn't use Corgi with other languages, but when making choices of what to include a big factor is how much it matters to Clojure and LISP developers.

이 설정은 주로 Clojure 프로그래머를 위한 것입니다. Corgi 를 다른 언어와 함께 사용할 수 없거나 사용하지 않아야 한다는 말은 아니지만 포함할 항목을 선택할 때 Clojure 및 LISP 개발자에게 얼마나 중요한지 결정하는 것이 중요합니다.

So we care a lot about interactive development, and structural editing, and make sure we have short convenient bindings for these things.

그래서 우리는 대화형 개발과 구조적 편집에 많은 관심을 가지고 있으며, 이러한 것들에 대한 짧은 편리한 바인딩을 가지고 있는지 확인합니다.

Consistent keybindings

When a command is specific to a major mode, its binding should do the closest equivalent in other major modes, or do nothing. So no bindings that do radically different things depending on the mode. (this is mostly for `,` leader keys)

명령이 주 모드에 특정한 경우 해당 바인딩은 다른 주 모드에서 가장 유사한 작업을 수행하거나 아무 작업도 수행하지 않아야 합니다. 따라서 모드에 따라 근본적으로 다른 작업을 수행하는 바인딩이 없습니다. (대부분 `,` 리더 키용)

Keybindings all live in one place

The common practice in the Emacs world is for packages to come with a bunch of keybindings out of the box, and for the Emacs config to then add a bunch more. These are all set up in their own library (.el) files imperatively with calls to define-key and friends.

Emacs 세계의 일반적인 관행은 패키지가 기본적으로 많은 키 바인딩과 함께 제공되고 Emacs 구성이 더 많은 키 바인딩을 추가하는 것입니다. 이것들은 모두 define-key 및 친구들에 대한 호출과 함께 자체 라이브러리(.el) 파일에 설정됩니다.

In Corgi we load key bindings from key and signal files. These are pure-data specifications. Corgi comes with corgi-keys.el and corgi-signals.el, these contain all the bindings that Corgi provides, you can see them all in a single place.

Corgi 에서는 키 및 신호 파일에서 키 바인딩을 로드합니다. 순수 데이터 사양입니다. Corgi 는 corgi-keys.el 및 ~corgi-signals.el~과 함께 제공되며, 여기에는 Corgi 가 제공하는 모든 바인딩이 포함되어 있으며 모두 한 곳에서 볼 수 있습니다.

For custom bindings you can put a user-keys.el and user-signals.el in your Emacs user directory, and they will get merged in (and get precedence, so you can override built-ins). For more extensive changes you can place a custom corgi-keys.el and/or corgi-signals.el in your Emacs user directory, and it will be used instead of the built-in ones.

사용자 정의 바인딩의 경우 Emacs 사용자 디렉토리에 user-keys.el 및 user-signals.el~을 넣을 수 있습니다. 보다 광범위한 변경을 위해 사용자 정의 ~corgi-keys.el 및/또는 ~corgi-signals.el~을 Emacs 사용자 디렉토리에 배치할 수 있으며, 내장 디렉토리 대신 사용됩니다.

Signals provide a level of indirection, they are keywords, like :eval/buffer, or :file/open. In the key binding file you configure how the signal is triggered (e.g. with , e b or SPC f f), in the signals file you bind it to a specific command, based on the mode, like eval-buffer in Emacs LISP, or cider-eval-buffer in Clojure.

신호는 간접적인 수준을 제공하며 :eval/buffer 또는 :file/open~과 같은 키워드입니다. 키 바인딩 파일에서 신호가 트리거되는 방식을 구성하고(예: ~, e b 또는 SPC f f 사용) 신호 파일에서 eval-buffer~와 같은 모드를 기반으로 특정 명령에 바인딩합니다. Emacs LISP, 또는 Clojure의 ~cider-eval-buffer.

This way we get great consistency, you can rebind how you want to "evaluate the current buffer", and this key binding will work everywhere, even if the concrete commands are language-dependent.

이렇게 하면 일관성이 크게 향상되고 "현재 버퍼 평가" 방법을 다시 바인딩할 수 있으며 구체적인 명령이 언어에 따라 달라지더라도 이 키 바인딩은 모든 곳에서 작동합니다.

It also means you can change the concrete command, like using counsel-find-file instead of the vanilla find-file, and this change will work regardless of how you are invoking that.

이는 또한 바닐라 find-file 대신 ~counsel-find-file~을 사용하는 것과 같은 구체적인 명령을 변경할 수 있음을 의미하며 이 변경은 호출 방법에 관계없이 작동합니다.

First class terminal and GUI support

While using GUI Emacs generally provides the better experience, there is value in continuing to support usage from a simple dumb terminal emulator. It's especially valuable for use on servers, and combined with Tmux it provides a great low-latency mechanism for pairing in the cloud. (See our blog post on the matter).

일반적으로 GUI 에맥을 사용하는 것이 더 나은 경험을 제공하지만, 간단한 덤 터미널 에뮬레이터의 사용을 계속 지원하는 것도 가치가 있습니다. 특히 서버에서 사용할 때 유용하며, Tmux 와 함께 사용하면 클라우드에서 페어링할 때 지연 시간이 짧은 훌륭한 메커니즘을 제공합니다. (관련 블로그 게시물 참조).

So we mainly try to not do anything funky that terminals can't handle, we pick bindings that can be communicated over a TTY, and include a few tweaks to make the emacs-in-a-terminal experience a little more smooth.

그래서 우리는 주로 터미널에서 처리할 수 없는 펑키한 작업을 하지 않으려고 노력하며, TTY 를 통해 통신할 수 있는 바인딩을 선택하고, 단말기 내 이맥스의 경험을 조금 더 부드럽게 만들기 위해 몇 가지 조정을 추가합니다.

It's your config

We don't take over init.el, at the end of the day you decide how your config works. You decide which Corgi packages to pull in, and if you don't like some of our choices, you can simply copy over the relevant code and tweak it from there.

저희는 ~init.el~을 인수하지 않으며, 결국 구성 방식은 사용자가 결정합니다. 어떤 Corgi 패키지를 가져올지 결정하고, 일부 선택 사항이 마음에 들지 않으면 관련 코드를 복사하여 거기에서 조정하면 됩니다.

We call this an unbundled Emacs config.

우리는 이것을 unbundled Emacs 설정이라고 부릅니다.

Key bindings

Corgi's key system is provided by one of a Corgi package called Corkey. It contains the key binding functionality based on simple configuration files, as well as Corgi's default bindings.

Corgi 의 키 시스템은 Corkey라는 Corgi 패키지 중 하나에서 제공됩니다. 여기에는 간단한 구성 파일을 기반으로 하는 키 바인딩 기능과 Corgi 의 기본 바인딩이 포함되어 있습니다.

You can find all binding definitions in corgi-keys.el and corgi-signals.el. The keys file contains the actual bindings as a nested datastructure, bound to symbolic signals (keywords). E.g.

모든 바인딩 정의는 corgi-keys.el 및 corgi-signals.el. keys 파일에는 기호 signals (키워드)에 바인딩된 중첩 데이터 구조로 실제 바인딩이 포함되어 있습니다. 예를 들어

  (("SPC" "Global leader key" ("f" "File commands" ("f" "Find file" :file/open))))

The signals file provides the mapping from this keyword to an actual Emacs command, based on the current major mode or minor modes.

signals 파일은 현재 메이저 모드 또는 마이너 모드를 기반으로 이 키워드에서 실제 Emacs 명령으로의 매핑을 제공합니다.

  ((corkey-local-mode (:file/open counsel-find-file)))

This indirection serves two purposes. It allows you to change the command you want to use for a certain action like opening a file, indepently of its keybinding. So you can configure the command you want to use, and have it work consistently even when switching between different sets of bindings.

이 간접 참조는 두 가지 용도로 사용됩니다. 키 바인딩과 무관하게 파일 열기와 같은 특정 작업에 사용하려는 명령을 변경할 수 있습니다. 따라서 사용하려는 명령을 구성하고 서로 다른 바인딩 세트 간에 전환할 때에도 일관되게 작동하도록 할 수 있습니다.

The other purpose is to provide mnemonic bindings that work in a mode-specific way. E.g. SPC s s invokes the signal :repl/toggle. In Clojure mode this will be bound to cider-switch-to-repl-buffer, whereas in Emacs LISP mode it will call ielm, and in SQL mode it does a sql-show-sqli-buffer. Each brings you to the REPL associated with the file you are working on.

다른 목적은 모드별 방식으로 작동하는 니모닉 바인딩을 제공하는 것입니다. 예를 들어 SPC s s~는 ~:repl/toggle 신호를 호출합니다. Clojure 모드에서는 ~cider-switch-to-repl-buffer~에 바인딩되지만 Emacs LISP 모드에서는 ~ielm~을 호출하고 SQL 모드에서는 ~sql-show-sqli-buffer~를 수행합니다. 각각은 작업 중인 파일과 관련된 REPL 로 이동합니다.

If you decide you don't like SPC s s for this functionality then you can rebind that, and it will work accordingly in all these modes.

이 기능에 대해 ~SPC s~가 마음에 들지 않는다고 결정한 경우 해당 기능을 다시 바인딩하면 이 모든 모드에서 적절하게 작동합니다.

Keys to get you started

Corgi relies on evil-mode, which Emulates Vim. For basic editing (insert, delete, copy, paste, etc.) we recommend going through a Vim tutorial.

Corgi 는 Vim 을 에뮬레이트하는 ~evil-mode~에 의존합니다. 기본적인 편집(삽입, 삭제, 복사, 붙여넣기 등)의 경우 Vim 튜토리얼을 진행하는 것이 좋습니다.

For other commands like opening files or jumping around windows (panes/splits) we follow the conventions set out by Spacemacs, where all commands start with hitting the space bar (SPC), typically followed by a prefix key denoting a category (e.g. f for "file") and a final key for the specific command. So e.g. SPC f f to open a file.

파일 열기 또는 창 이동(창/분할)과 같은 다른 명령의 경우 모든 명령이 스페이스바(SPC)를 누르는 것으로 시작하고 일반적으로 범주(예: f "파일") 및 특정 명령의 마지막 키. 그래서 예를 들어 SPC f f 파일을 엽니다.

Press SPC or SPC f and wait a moment to get a list of options.

SPC 또는 ~SPC f~를 누르고 옵션 목록이 표시될 때까지 잠시 기다리십시오.

Besides this SPC "leader key" we also use , for mode-specific commands, e.g. in a Clojure buffer , j j will "Jack-in" a REPL.

이 SPC "리더 키" 외에도 모드별 명령에 ~,~를 사용합니다. Clojure 버퍼에서 ~, j j~는 REPL 을 "Jack-in"합니다.

General

SPC SPC : execute command (Emacs M-x)

Window `SPC w`

SPC [0...9] - go to window number [0..9]
SPC w /- split window vertically
SPC w -- split window horizontally
SPC w d- delete window
SPC w 1- extend current window to whole screen

buffers `SPC b`

SPC b b- list of all buffers
SPC b d- kill current buffer (not delete)

file `SPC f`

SPC f s - save a file
SPC p p- open a project
SPC f f- find a file
SPC p f- find a file in current project

Getting help `SPC h`

SPC h - help system
SPC h d f - description of selected function
SPC h d k - description of selected key binding

Working with REPLs

, s c connect to a REPL / process
, s s toggle between REPL and code buffer
, s q quit current REPL
, s Q quit all REPLs for the current project/session
, j j connect to a regular REPL (Clojure)
, j o connect to "other" REPL (ClojureScript)
, j a connect to "all" (Clojure + ClojureScript)
, l l link current project/buffer to an open REPL session

Structural editing

문서 옮김

> slurp forward
< barf forward
SPC x s splice backward
SPC x t transpose sexp
L forward sexp
H backward sexp

The latter two are "text objects" that can be combined with other vim-style operations

후자의 두 가지는 다른 vim 스타일 작업과 결합할 수 있는 "텍스트 개체"입니다.

yL copy next sexp (paste with p
dL delete next sexp
cL "change" sexp (delete and switch to insert mode)

Packages

corgi-packages

The corgi-packages repo acts itself as a straight package, but a special kind of package called a "recipe repository", it contains the descriptions of all Corgi packages so Straight knows where to find them.

corgi-packages repo 는 스트레이트 패키지처럼 작동하지만 "레시피 저장소"라고 하는 특별한 종류의 패키지에는 모든 Corgi 패키지에 대한 설명이 포함되어 있으므로 Straight 는 패키지를 찾을 수 있습니다.

It also contains the corgi/upgrade-self command, which you can use to upgrade Corgi itself. This will upgrade corgi-packages to the latest git commit, and overwrite the corgi versions file, before relying on Straight to get all other packages to the correct version.

여기에는 Corgi 자체를 업그레이드하는 데 사용할 수 있는 corgi/upgrade-self 명령도 포함되어 있습니다. 이것은 ~corgi-packages~를 최신 git 커밋으로 업그레이드하고, 다른 모든 패키지를 올바른 버전으로 가져오기 위해 Straight 에 의존하기 전에 corgi 버전 파일을 덮어씁니다.

  (defun corgi/upgrade-self ()
    "Upgrade Corgi
     Fetch the latest corgi-packages, and make straight use the versions specified therein. Will overwrite any local changes to straight/versions/corgi.el"
    (interactive) (straight-pull-package "corgi-packages") (corgi-copy-versions-file) (straight-thaw-versions))

corgi-defaults

This simply sets a slew of of Emacs variables to more sensible values, from disabling the menubar and toolbar, to fixing modifier keys on Mac and disabling the system bell.

이것은 단순히 메뉴 표시줄과 도구 모음 비활성화부터 Mac 의 수정자 키 수정 및 시스템 벨 비활성화에 이르기까지 많은 Emacs 변수를 보다 합리적인 값으로 설정합니다.

There are many versions of this kind of thing around, this one is ours. We've tried to include mostly non-controversial things, but if there is anything you don't like then just copy this file over to your own config, load your own version instead of ours, and take it from there.

주변에 이런 종류의 버전이 많이 있습니다. 이 버전은 우리 것입니다. 우리는 대부분 논쟁의 여지가 없는 것들을 포함하려고 노력했지만, 마음에 들지 않는 것이 있으면 이 파일을 자신의 구성에 복사하고 우리 대신 자신의 버전을 로드한 다음 거기에서 가져옵니다.

corgi-editor

This is the meat-and-potatoes of the Corgi experience, how the editor feels and behaves. This sets up and configures a bunch of packages like Evil, Smartparens, Ivy (minibuffer completion), Swiper (fuzzy search), Projectile (project-aware commands), Aggressive indent, Company (completion).

이것은 편집자가 느끼고 행동하는 Corgi 경험의 고기와 감자입니다. 이것은 Evil, Smartparens, Ivy(미니버퍼 완성), Swiper(퍼지 검색), Projectile(프로젝트 인식 명령), Aggressive indent, Company(완료)와 같은 많은 패키지를 설정하고 구성합니다.

Full list at time of writing:

작성 당시 전체 목록:

aggressive-indent: auto-indent code as you type
avy: jump to specific character
company: completion framework
counsel: Improves some of the built-in UI using the Ivy completion features
diminish: Clean up the modeline by hiding certain minor modes
dumb-jump: Simple jump to identifier, mainly a fallback
- 이건 없네? 패키지 리스트에서도 검색 안됨
evil: Vim-style editing
evil-cleverparens: Evil-based structural editing
evil-collection: Make many more areas of Emacs play nice with Evil
evil-surround: Port of Vim-surround, especially handy in LISP
expand-region: Edit by semantically shrinking/expanding the selection
goto-last-change: Jump to the last change in the file
- 2015 이후 업데이트 된 적도 없는 패키지 인데?! 같은 역할 하는게 스페이스맥스에 있을 것 같은데. 괜찮아 보인다.
ivy: Minibuffer completion framework
projectile: Project-specific functionality
rainbow-delimiters: Color matching parenthesis, brackets, etc.
smartparens: Structural editing
smex: Interactive fuzzy-searching alternative to M-x
- 2015 이후 업데이트 안된 거다. 필요 없다. compleseus 레이어가 있다
string-edit: Edit string contents in a separate buffer (great when you have a lot of escaping)
swiper: Fuzzy search inside the buffer
undo-fu: Better undo
which-key: Make keys discoverable
winum: Number buffers and jump to them easily
xclip: Only on terminal, integrate with the system clipboard

corgi-emacs-lisp

Emacs Lisp config, mainly to have a development experience that feels similar to using CIDER and Clojure. (show results in overlay, threading refactorings)

Emacs Lisp 구성, 주로 CIDER 및 Clojure 사용과 유사한 느낌의 개발 경험을 갖습니다. (오버레이, 스레딩 리팩토링에 결과 표시)

corgi-commands

The few custom commands that we ship with. This includes a few things we emulate from Spacemacs, and commands for jumping to the user's init.el (this file, with `SPC f e i'), or opening the user's key binding or signals file.

우리가 함께 제공하는 몇 가지 사용자 정의 명령. 여기에는 Spacemacs 에서 에뮬레이트한 몇 가지와 사용자의 init.el(이 파일, `SPC f e i' 포함)로 이동하거나 사용자의 키 바인딩 또는 신호 파일을 여는 명령이 포함됩니다.

corgi-clojure

Extensive setup for a good Clojure experience, including clojure-mode, CIDER, and a modeline indicator that shows which REPLs your evaluations go to. Also contains `corgi/cider-pprint-eval-register', bound to `,,'.

클로저 모드, CIDER, 평가 대상 REPL 을 보여주는 모델린 표시기를 포함하여 우수한 클로저 경험을 위한 광범위한 설정. 또한 `,null,'에 바인딩된 `corgi/cider-pprint-eval-register'를 포함합니다.

We also include clj-ns-name, which changes Clojure buffer names to their namespace name.

또한 Clojure 버퍼 이름을 네임스페이스 이름으로 변경하는 ~clj-ns-name~을 포함합니다.

Babashka utility REPL

corgi/cider-jack-in-babashka starts a new bb process and connects to it, creating a REPL buffer called *babashka-repl*. This is meant as a project-independent long running utility REPL, so that you can always eval basic Clojure expressions. Whenever you are in a Clojure file and there is no project-specific connected REPL then evaluations will go to this Babashka REPL instead.

corgi/cider-jack-in-babashka~는 새로운 ~bb 프로세스를 시작하고 여기에 연결하여 ~*babashka-repl*~라는 REPL 버퍼를 생성합니다. 이것은 프로젝트 독립적인 장기 실행 유틸리티 REPL 을 의미하므로 항상 기본 Clojure 표현식을 평가할 수 있습니다. Clojure 파일에 있고 프로젝트별 연결된 REPL 이 없을 때마다 평가는 대신 이 Babashka REPL 로 이동합니다.

Modeline indicator

corgi/enable-cider-connection-indicator will add an indicator in the modeline showing you which Clojure REPL(s) if any evaluations will go to. It's either a clj on a blue background, a cljs on a yellow background, or a bb on a green background. If you are linked to a REPL from another project then the project directory will be included.

corgi/enable-cider-connection-indicator~는 평가가 진행되는 경우 어떤 Clojure REPL(들)을 표시하는지 모델라인에 표시기를 추가합니다. 파란색 배경의 ~clj, 노란색 배경의 cljs 또는 녹색 배경의 ~bb~입니다. 다른 프로젝트의 REPL 에 링크된 경우 프로젝트 디렉토리가 포함됩니다.

Eval from register

Emacs has registers, named slots where you can put snippets of text. corgi/cider-pprint-eval-register leverages this, it lets you send code from a register to your REPL, and get the result pretty printed in a separate buffer.

Emacs 에는 텍스트 조각을 넣을 수 있는 슬롯이라는 레지스터가 있습니다. ~corgi/cider-pprint-eval-register~는 이것을 활용하여 레지스터에서 REPL 로 코드를 보내고 결과를 별도의 버퍼에 예쁘게 인쇄할 수 있습니다.

This is bound to ,,, so e.g. if you have (kaocha.repl/run) in the k register, then ,,k in a Clojure buffer will run Kaocha on the current file.

이것은 ,null,~에 바인딩됩니다. ~k 레지스터에 ~(kaocha.repl/run)~이 있는 경우 Clojure 버퍼의 ~,null,k~는 현재 파일에서 Kaocha 를 실행합니다.

There are two ways to leverage this, you can pre-set some registers in your init.el, like the Kaocha example, so you basically get your own shortcut commands. It's also really useful to use Emacs's copy-to-register in a more ad-hoc way. Say you are working on a function, and then you have a snippet that calls that function that you use to test it out. Copy the snippet to a register and you no longer need to jump back and forth.

이것을 활용하는 두 가지 방법이 있습니다. Kaocha 예제와 같이 ~init.el~에 일부 레지스터를 미리 설정할 수 있으므로 기본적으로 고유한 바로 가기 명령을 얻을 수 있습니다. Emacs 의 ~copy-to-register~를 좀 더 임시적인 방식으로 사용하는 것도 정말 유용합니다. 함수에 대해 작업 중이고 테스트하는 데 사용하는 해당 함수를 호출하는 스니펫이 있다고 가정합니다. 스니펫을 레지스터에 복사하면 더 이상 앞뒤로 이동할 필요가 없습니다.

corgi-stateline

Change the color of the modeline based on the Evil state (e.g. green when in insert state)

Evil 상태에 따라 모델린의 색상을 변경합니다(예: 삽입 상태일 때 녹색).

Corkey

Corkey is Corgi's key binding system. It's powerful and flexible, but does things quite differently from other Emacs configs, and we encourage you to familiarize yourself with its concepts.

Corkey 는 Corgi 의 키 바인딩 시스템입니다. 강력하고 유연하지만 다른 Emacs 구성과 상당히 다른 작업을 수행하므로 해당 개념에 익숙해지는 것이 좋습니다.

Some of the goals of Corkey: Corkey 의 목표 중 일부:

Have all bindings centralized in simple data files
Make it easy to add or override bindings in your config
Provide consistent bindings across modes (e.g. have the same key combination to "eval" something, regardless of the language)
Make it easy to customize these consistently, e.g. change the "eval" keybinding in one place and have it apply to all modes
Make it easy to share complete sets of bindings with others
Provide both vim-style state-specific bindings and "global" (any state) bindings
Have great which-key hints/descriptions for everything
Allow toggling all Corkey bindings on or off globally

Initializing Corkey

In the example config we've shown how to initialize Corkey:

예제 구성에서 Corkey 를 초기화하는 방법을 보여주었습니다.

  (use-package corkey :config (corkey-mode 1) (corkey/load-and-watch))

This makes sure the corkey package is installed and loaded, it then enables the global corkey-mode, and sets up the built-in bindings by loading the default binding files.

이것은 corkey 패키지가 설치 및 로드되었는지 확인한 다음 전역 ~corkey-mode~를 활성화하고 기본 바인딩 파일을 로드하여 내장 바인딩을 설정합니다.

Installing bindings

Before you use Corkey you need to load the set of key bindings it will use, it will then apply the right set of bindings depending on the major and minor modes active in a given buffer. This is done with corkey/load-and-watch, which sets up file watchers for the key binding and signal mapping files, so any changes in them are reflected immediately.

Corkey 를 사용하기 전에 사용할 키 바인딩 세트를 로드해야 합니다. 그러면 지정된 버퍼에서 활성화된 메이저 및 마이너 모드에 따라 올바른 바인딩 세트가 적용됩니다. 이것은 ~corkey/load-and-watch~를 사용하여 수행되며, 키 바인딩 및 신호 매핑 파일에 대한 파일 감시자를 설정하므로 변경 사항이 즉시 반영됩니다.

corkey/load-and-watch takes two optional arguments, a list of binding files, and a list of signal files, so (corgi/load-and-watch) is really just a shorthand for

~corkey/load-and-watch~는 두 개의 선택적 인수, 바인딩 파일 목록 및 신호 파일 목록을 취하므로 ~(corgi/load-and-watch)~는 실제로는

(corgi/load-and-watch '(corgi-keys user-keys) '(corgi-signals user-signals))

These are references to EDN-like files. Corkey will try to look this up in your emacs-user-directory, and if not found there falls back to scanning the Emacs library path.

이것은 EDN 과 유사한 파일에 대한 참조입니다. Corkey 는 ~emacs-user-directory~에서 이것을 찾으려고 시도하고, 찾을 수 없으면 Emacs 라이브러리 경로를 스캔하는 것으로 폴백합니다.

In other words: Corkey will look for corgi-keys.el in your Emacs config directory, and if it doesn't find it there it will use the one provided by corgi-packages/corkey. The same goes for corgi-signals. This means that you can copy these files to your Emacs config directory and customize them there.

즉, Corkey 는 Emacs 구성 디렉토리에서 ~corgi-keys.el~을 찾고, 찾지 못하면 ~corgi-packages/corkey~에서 제공하는 것을 사용합니다. ~corgi-signals~도 마찬가지입니다. 이것은 이 파일을 Emacs config 디렉토리에 복사하고 거기에서 사용자 정의할 수 있음을 의미합니다.

user-keys.el and user-signals.el are what goes into your own config, here you can add whatever extra bindings you like to have. The sample config has an example.

user-keys.el 및 ~user-signals.el~은 자신의 구성에 들어가는 것입니다. 여기에 원하는 추가 바인딩을 추가할 수 있습니다. 샘플 구성에 예가 있습니다.

You can jump to all of these files with built-in commands

내장 명령을 사용하여 이 모든 파일로 이동할 수 있습니다.

SPC f e k - Open user-keys, create it if it doesn't exist
SPC f e s - Open user-signals, create it if it doesn't exist
SPC f e K - Open corgi-keys (all built-in bindings)
SPC f e S - Open user-signals (all built-in signal mappings)

See the comments in those files for more info on how to set things up. 설정 방법에 대한 자세한 내용은 해당 파일의 주석을 참조하십시오.

Differences from Vim

Generally we don't override Evil's keybindings, and Evil in turns emulates vim closely. Some differences

일반적으로 우리는 Evil 의 키 바인딩을 무시하지 않으며 Evil 은 차례로 vim 을 밀접하게 에뮬레이트합니다. 몇 가지 차이점

L and H move forward/backward by one s-expression, instead of moving to the beginning/end of the buffer
SPC and , are both used as leader/prefix keys. Press either and wait a bit to see what they can do.

Walkthrough of a Clojure session

When working on a Clojure project I will typically start by opening a .clj, .cljs, or .edn file, and "jacking-in" CIDER. I'll either use SPC j j if it's a plain Clojure project (just start a Clojure REPL), or SPC j a for both CLJ and CLJS (most CLJS projects I still like to have a CLJ REPL around).

Clojure 프로젝트에서 작업할 때 저는 일반적으로 .clj, .cljs 또는 .edn 파일을 열고 CIDER 를 "재킹-인(jacking-in)"하는 것으로 시작합니다. 일반 Clojure 프로젝트(Clojure REPL 시작)인 경우 ~SPC j j~를 사용하거나 CLJ 와 CLJS 모두에 대해 ~SPC j a~(대부분의 CLJS 프로젝트는 여전히 CLJ REPL 을 사용하고 싶습니다)를 사용합니다.

Once that's started you can jump back and forth to the REPL buffer with , s s. When you're done you can close a single REPL with , s q, or all connected REPLs for this project with , s Q.

일단 시작되면 ~, s s~를 사용하여 REPL 버퍼로 앞뒤로 이동할 수 있습니다. 완료되면 ~, s q~로 단일 REPL 을 닫거나 ~, s Q~로 이 프로젝트에 대해 연결된 모든 REPL 을 닫을 수 있습니다.

If you are running your nREPL sever outside of Emacs, then use , s c to connect to it.

Emacs 외부에서 nREPL 서버를 실행하는 경우 ~, s c~를 사용하여 연결하십시오.

To evaluate forms I mainly use , RET (evaluate outer form), and , e p (evaluate the form before the cursor, and pretty print the result to a separate buffer), but there are a slew of "eval" commands available.

양식을 평가하기 위해 주로 , RET (외부 양식 평가) 및 , e p (커서 전에 양식을 평가하고 결과를 별도의 버퍼에 예쁘게 인쇄)를 사용하지만 "평가" 명령이 많이 있습니다. 사용 가능.

Inside LISP buffers the L and H text objects come in handy, these jump back and forth across s-expressions, and can be combined with Vim commands, like dL (delete sexp) or 3yL (copy next 3 sexps).

LISP 버퍼 내부에서 L 및 H 텍스트 객체가 유용하며, 이들은 s-표현식을 앞뒤로 이동하며 ~dL~(sexp 삭제) 또는 ~3yL~(다음 복사)와 같은 Vim 명령과 결합할 수 있습니다. 3 섹스).

, g g is a general binding to jump to an identifier's definition, get used to using this a lot. This will also help you explore libraries you're using. , g b will pop you back to where you came from.

~, g g~는 식별자의 정의로 점프하는 일반적인 바인딩입니다. 이 많은 사용에 익숙해지세요. 또한 사용 중인 라이브러리를 탐색하는 데 도움이 됩니다. ~, g b~는 원래 있던 곳으로 다시 팝업합니다.

목표

태생이 클로저 개발 전용으로 커스터마이즈 된 이맥스가 코지다. 모달 에디팅이 기본이다. 궁금하다. 모달 + 클로저 개발용 커스텀 이맥스는 뭐가 다른가? 내가 바라는 스페이스맥스는 이맥스 전체 패키지를 아우른다. 클로저 개발도 좋고, 오그 모드 글도 좋고, 파이썬 개발도 좋다. 범용이다. 클로저 개발에 포커스한 심플한 이맥스도 필요하다.

lsp-mode, clj-kondo

Tim 님이 작업해놓음. 콘도는 단계 별로 해봐야 한다.

- GitHub - theophilusx/corgi-lsp-mode: Corgi extension package to add lsp-mode ...

GitHub - theophilusx/corgi-clojure-kondo: Simple extension for Corgi to add k...

corgi 패키지에 대해서

편집 관련된 패키지 목록. 아마 나의 스페이스맥스에 이미 다 있을 것 같다. 잠시 확인해보자.

확인해보니, dumb-jump, goto-last-change 패키지가 내 스페이스맥스에 없다. 나머지는 대체 가능한 수준으로 다 들어가 있다.

string-edit, avy, undo-fu, expand-region, smartparens, agressive-indent 가 특히 눈에 띈다. 모두 spacemacs-editing layer 에 있다 (spacemacs-editing layer). 여기에는 물론 기본은 undo-tree 이지만 나 역시도 속도 문제로 undo-fu 로 바꿔 쓴다.

이미 있는데 내가 뭘 알고 쓰는가? nothing! 몰랐다. agressive-indent 는 코지 보고 써야겠다 생각이 들었다. 이게 스페이스맥스를 쓰는 초보자들의 문제다. 이 친구도 그 점을 이야기하고 있다. 필요한 것 이상으로 설치해 놓고 사용하지도 않는다. 더 간단하게 사용하면 되는 것을 기능 많다고 좋은 거라고 생각하고 설치하고는 배우기가 어려워서 오히려 시작도 못한다. 이런게 lsp-mode 에 대한 만든 이의 생각이다. 이미 충분하다는 것이다. 불필요한 복잡성은 시스템과 워크플로우 전반을 해친다는 것이다.

그래서 코지는 패키지가 정말 없다. 핵심 패키지만 넣어 놨다. 나머지는 알아서 쓰라는 것이다. 키 바인딩도 마찬가지다. 이거 밖에 안쓰나? 싶을 정도다. 여기에 대해서도 말을 남겼다. 스페이스맥스를 보면 모든 기능을 적절하게 키 바인딩해서 다 넣어놨다. 다 쓰는가? 압도 당한다. which-key 리스트만 보면 정신이 아찔하지 않는가?

내가 느낀 바, 이맥서는 주체적인 철학을 가져야 한다. 내가 배워야 하는 것이 철학의 마인드셋이다.

깃헙에서 이야기가 나온대로 ivy 는 vertico 패키지류로 바꿔야 한다. 개발 측면에서는 clj-kondo 는 CIDER 백엔드로 붙여야 한다. 위에 Tim 님이 작업을 해놓았다. lsp-mode 는 당장은 아니다. eglot 이 더 적합할 수도 있다.

Walkthrough of a Clojure session

이 부분은 워크 플로우를 이야기 한다. >> 나의 관심은 무엇인가? 어떤식으로 이맥스를 켜서 클로져 코딩하는가?! 그냥하는거 아닌가? 워크플로우 관점? 유튜브 뭐 있더만. 그것도

정리하자면, 일단 레플을 열기 위해서 젝인한다. 그리고 평가한다. L, H 를 이용해서 sexp 를 이동한다. dL, 3yL 이런식으로 앞서 말한 컴바인드 커맨드를 사용한다. 예를 들어 3yL 은 copy next 3 sexps 이다. 정의로 점프하고 돌아오는 명령어는 , g g, , g b 이다.

이게 끝이다. 사실 그렇다. 뭐 대단하게 하는게 있던가!

SpaceVim VSpaceCode and Spacemacs

SpaceVim 설치하며 -- VSpaceCode and Spacemacs 비교

재미있는 주제이다. 굉장히 비슷한 느낌의 첫인상이다. 키 바인딩도 유사하다. 그러나 태생이 다르기 때문에 텍스트 편집에 관련한 Emacs 생태계에 범접할 수가 없을 것이다. 나도 여기에 있어서 단편만 보았기 때문에 그러리 라고 보는 것일 분이다. 그리고 VIM 생태계에서는 이러한 메뉴 시스템이 필요한가? 열고 닫는 짧은 사이클의 툴에서는 굳이 필요가 없으리라 본다. Emacs 에서는 한번 실행하고 얼마나 오래 쓰는가? 관련해서 종종 글을 본다. 이 말은 이 하나에서 다 커버가 가능하기 때문이다. 터미널, 런처 등 별도로 필요한 것이 없다. 그러기에 Org-mode 가 의미가 있는 것이다. 어젠다 역시 마찬가지다. Workflow 와 Writing 전부가 이 하나로 다 담겨지기 때문이다. SpaceVim 은 VSpaceCode 와는 분명히 다른 포지션이다. 전자는 터미널에서 짧게 처리 할 텍스트 작업을 Spacemacs 와 별개로 처리 할 때 사용하면 된다. 궁극적으로는 Emacs 터미널을 사용하면 필요가 없게 된다. (내가 아직 미진해서 생기는 문제) 후자는 개발에 집중한 툴 이다. 일단 LSP 등 최신 Feature 들을 추가 설정 거의 없이 성능 걱정 덜하고 다 쓸 수 있다. 키 바인딩은 Spacemacs 와 거의 유사하게 잡혀 있기 때문에 작업의 불편함도 덜하다. 물론, 스니펫을 공유하도록 구성할 경우이다. 글쓰기도 마찬가지고 개발도 나의 경험을 누적하는 게 중요하다. 그럼에도 VSpaceCode 또한 테스트 용도 또는 Emacs 입문자 용도를 벗어나기 어렵다고 생각한다. Emacs 가 이미 충분히 좋아졌고 어느 정도 나의 구성이 안정화 되면 툴을 벗어나는 게 그 자체로 불편함을 줄 것이다. Eglot 을 도입하면서 LSP 이슈도 없어진 것과도 마찬가지다. 나의 모든 툴 은 Emacs 에 집중하기 위한 보조 도구로써 만족한다. 오늘 SpaceVim 도입은 아주 큰 의미가 있다. 비교의 기준점으로서 가져갈 수 있기 때문이다. 나는 그러니까 텍스트 에디터로써 이맥스를 쉽게 받아들이기 위해서 SpaceVim (TUI), VSpaceCode (GUI)를 적극 권장할 것이다. 여기에 익숙하게 되면 Spacemacs 는 가볍게 사용할 수 있게 된다. 여기에 Meta 키 바인딩의 노하우를 익혀가면 된다. 학생 뿐만 아니라 현업에 있는 누구나 큰 부담이 없이 나의 텍스트 에디터 환경을 구축함으로서 텍스트 지식인이 되기를 바란다. -끝- [2023-01-28 Sat 08:23]

Emacs and SpaceVim on Markdown on Kitty

[2023-08-31 Thu 05:22]

지금 나의 설정에서 비교할 겸. 스크린샷. 둘다 Kitty 사용. 빔과 비슷. 어색하지 않다. 그 뒤의 풍부함이라. 테마는 다양하니 골라쓰라.

width="100%" >

Evil Tips Examples

| Key | For | Used | |------|---------------------------------------|------------| | vip | evil-inner-passage | Very Often | | vis | evil-inner-sentence | Very Often | | gqap | format passage | Very Often | | gqas | format sentence | Often | | ci | replace everything within parens | Sometimes | | dt; | deleting everything until a semicolon | Rare | | cif | evil-cp-inner-form | Rare |

cif

cif 이게 뭔가? :: evil-cp-inner-form 함수를 호출한다. 즉 괄호 안에 폼을 잘라내기 한다. 아래 리스트가 있다. 아! 이 함수는 evil-cleverparens-text-objects 기능의 일부이다. 이게 될까?

References

Review of evil-mode for emacs. Evil-mode, the extensible vi layer for-
- [2023-12-14 Thu 09:32] vip vis 등 모르는 세계가 있음을 알다.
My emacs clojure journey Ep 1 - Corgi & evil-mode - YouTube

evil-surround

[2023-10-04 Wed 12:35] 이걸 드디어 사용한다. 왜?!

evil-textobj-line 텍스트 오브젝트

[2023-12-14 Thu 15:59]

VIM https://nolboo.kim/blog/2016/10/13/vim-text-objects-definitive-guide/
- VIM 에서 편집을 효과적으로 하려면, 단순히 문자를 넘어서 단어, 문장, 문단을 편집해야 한다.VIM 에서 이런 하이레벨의 컨텍스트를 텍스트 개체라고 한다.
- VIM 에는 일반 텍스트 개체와 프로그래밍 언어를 위한 텍스트 개체가 있다. 텍스트 개체를 배우면 VIM 편집이 완전히 새로운 단계의 정확도와 속도를 가지게 된다.

Spacemacs Focus Document

[2023-02-25 Sat 17:16]

여기 문서도 좋다.

/home/junghan/sync/man/dotsamples/spacemacs/ghasak-dot-spacemacs/docs/emacs_tips_tricks/multi_cursor.md:

Evil for Viim Style Editing

Evil for Vim Style Editing - Practicalli Spacemacs

2022-10-04 evil-emacs forward backward keybinding

[2023-06-17 Sat 13:43]

알아야 할 키 바인딩

M-x 영원하라 메타엑스! M-m SPC 와 같음. 스페이스맥스 root 라고 함. M-RET 마이너모드 명령셋 노멀 모드에서 , 과 같음. C-g keyboard-quit :: 이걸 몰랐었다. 실행 취소!!

evil emacs 를 잘 사용하기 위한 핵심은?

내 생각에는 evil mode 와 상관 없이 원하는 작업을 실행할 수 있는 이맥스 고유의 키 바인딩이라고 생각한다.

vim 에서 편집 모드로 진입하면 메타 키 조합이 아니라면 할 수 있는 일은 텍스트 입력이다. vim 도 제대로 써보지 않은 이유는 모드 전환이 귀찮아서다.

이맥스를 제대로 써보려고 하는데... 그렇다고 이맥스 입력 방식을 공부하기는 싫고... 선택 옵션은 EVIL 이다. 스페이스맥스는 여기에 충실한 이맥스이고 만족스럽다.

이동/삭제/추가 : 캐릭터, 워드, 라인 검색 undo/redo

등. 일관성 있는 방식이 필요하다.

C-r undo-fu only redo $ end 0 home

insert 모드 방향키 대신 사용하도록 세팅

C-h j k l C-S backspace kill line C-w evil-delete-backward-word C-_ undo-region C-u undo-fu undo C-r undo-fu redo C-$ end C-0 home M-h delete-backward-char M-l delete-forward-char

adslfjaldksjflk ds asdlkk

;; 편집 모드 시, 단어 단위로 지우려면 C-w 를 쓰면 된다 ;; char 를 지우려면 backspace 를 누르면 된다. 이게 불편하다. 추가하자.

alsdkfjlkdsf

w evil forward word : 이동|단어 b evil backward word 이동|단어

all mode

M-DEL backword-kill-word 커서 이전 워드 단위로 삭제 M-d kill-word M-f forward word M-b backward word

내가 추가한 키 바인딩의 일부이다. 목적은 방향키를 최소한으로 줄이고 일관성 있게 모드 변환을 최소화 하면서 글을 쓸 수 있게 만드는 것이다. 예를 들어 편집 모드에서 쓰다가 노멀 모드로 바꾸고... 이 작업이 매우 번거롭다. 최소한의 기능은 편집 모드에서도 가능해야 한다. 특히 일반적인 편집 기능의 경우.

다행인 것은 이맥스는 에빌 모드만 지원하는게 아니라는 것이다. 물론 스페이스맥스 에빌 모드 환경에서는 기존 이맥스 키 바인딩과 다른 부분이 많아서 막 넣을 수가 없다.

그럼에도 함수는 여전히 있기에 적당히 맞춰 넣어주면 편집, 이동이 무난하게 가능하다.

evil-escape 도 ,. 으로 매핑해 놓았는데 괜찮다. ESC 를 누르는 것 보다 따닥 누르는게 편할 때가 있다. 예를 들어!! 편집 모드에서 마이너모드 명령을 입력하고 싶을 때 , . , 을 따다닥 눌르면 가능했다.

근데.... =M-RET=을 누르면 모드에 상관 없이 마이너모드 명령어를 쓸 수 있다. 그럼에도 evil-escape 는 쓸만하다. 괜히 있는게 아니다. 아! 원래 매핑은 fd 에 되어 있다. 한글 입력 중에는 ㄹㅇ이 입력되니까... 영문으로 바꾸고 해야 한다는 말이다. 그러기에 , . 을 사용하는 것이다. 물론 더 좋은 키 매핑이 있을 수도 있다. 큰 고민한 것은 아니니까.

  (evil-define-key '(normal insert visual) org-mode-map (kbd "C-c h") 'org-insert-heading)
  (evil-define-key '(normal insert visual) org-mode-map (kbd "C-c s") 'org-insert-subheading)
 
  ;; 헤딩 이동을 편하게 하자
  (define-key org-mode-map (kbd "C-n") 'org-next-visible-heading)
  (define-key org-mode-map (kbd "C-p") 'org-previous-visible-heading)
 
  ;; 편집 모드에서 방향키를 커버하는 방법
  ;; evil-mode 에서 기존 키 바인딩 C-k를 제거한다.
  ;; 나머지 키는 큰 문제 없어서 그냥 둔다.
  (keymap-unset-key [C-k] "evil-mode")
 
  ;; insert 모드에서 방향키로 쓰도록 세팅한다. evil-xxx-line 대신
  ;; 이맥스 기본 이동으로 세팅 했다.
  (evil-define-key '(insert) org-mode-map (kbd "C-h") 'left-char)
  (evil-define-key '(insert) org-mode-map (kbd "C-l") 'right-char)
  (evil-define-key '(insert) org-mode-map (kbd "C-j") 'next-line)
  (evil-define-key '(insert) org-mode-map (kbd "C-k") 'previous-line)
 
  ;; 이상하게 기존 키 바인딩이 안지워진다. 이건 나중에 다시 하자.
  ;; (define-key org-mode-map (kbd "M-h") nil)
  ;; (define-key org-mode-map (kbd "M-l>") nil)
  ;; (keymap-unset-key [M-h] "evil-mode")
  ;; (keymap-unset-key [M-l] "evil-mode")
  ;; (evil-define-key '(insert) org-mode-map (kbd "M-h") 'delete-backward-char)
  ;; (evil-define-key '(insert) org-mode-map (kbd "M-l") 'delete-forward-char)
 
  (evil-define-key '(insert) org-mode-map (kbd "C-u") 'undo-fu-only-undo)
  (evil-define-key '(insert) org-mode-map (kbd "C-r") 'undo-fu-only-redo)
 
  (evil-define-key '(insert) org-mode-map (kbd "C-0") 'org-begginng-of-line)
  (evil-define-key '(insert) org-mode-map (kbd "C-4") 'org-end-of-line)

이미지 없이 embark 로 복사하는 방법을 찾자.

이 방법이 있으면 정말 이맥스를 거의 문서화 하고 설명하는데 유리해진다.

which-key toggle

도대체 키 바인딩이 뭐야? 뭘 입력해야 이걸 할 수 있는거야? M-x 에서 호출 할 수 있는 함수들도 있지만... evil 입력이라던가 모르는 세상이 있다. 그러기에 가장 중요한 것은 찾는 방법 그 자체이다.

which-key 를 토글을 이용해서 각 레벨 별로 현재 입력 할 수 있는 키맵을 확인할 수 있다. 예를 들어 지금 org 문서를 편집 중인데 뭘 입력해야 뭐가 되는지 모르겠다면 토글로 메뉴를 띄워 놓고 선택하면 된다. 한두번 하다보면 익숙해지고 기억이 나고, 나중에는 더 편한 키로 바꿔서 쓰게 된다.

이미지를 본다.

vim keybindings

translate:: VIM 핵심 키맵 alias:: project:: url:: person:: progress:: , create-at:: week-at:: #2022-W27 editcount:: 2

입력모드 i 를 넘어서자.

i : 커서 앞
a : 커서 뒤
I : 줄 앞 -- i + Home
A : 줄 끝
o : 빈줄 넣고 입력
r : 한글자 수정
R : 수정 모드

** 명령모드에서 방향키를 넘어서자.

:CUSTOM_ID: 명령모드에서-방향키를-넘어서자.
- * 단어 단위 이동
  
  :CUSTOM_ID: 단어-단위-이동
  - w : Next word
  - b : previous word
- * 문자 단위 이동
  
  :CUSTOM_ID: 문자-단위-이동
  - h j k l : arrow keys
- * 문단 단위 이동
  
  :CUSTOM_ID: 문단-단위-이동
  - { : 문단 시작으로
  - } : 문단 끝으로
- * 화면 내에서 이동
  
  :CUSTOM_ID: 화면-내에서-이동
  - H : 화면 맨 위로
  - L : 화면 맨 아래로
  - M : 화면 가운대로
- * 페이지 단위 이동
  
  :CUSTOM_ID: 페이지-단위-이동
  - ctrl u : 반 페이지 위로
  - ctrl d : 반 페이지 아래로
** 복붙은 v 보다 V 를 쓰자

:CUSTOM_ID: 복붙은-v 보다-v 를-쓰자
- v : 선택 모드
- V : 줄 단위 선택 모드
- x : 오려두기
- d : 삭제
- p : 붙여넣기

Move and Kill Editing Keybindings in Emacs

Hungry Delete with `S-<backspace> S-<DEL>`

[2023-10-05 Thu 06:50] 이게 완벽한 조합이었다. 반영했다.

spacemacs.org 참고

[2023-09-07 Thu 18:48] home/junghan.spacemacs.d/dot-org/spacemacs.org

jh-editing 참고

[2023-09-07 Thu 18:48] home/junghan.spacemacs.d/dot-org/jh-editing.org

iedit

[2023-10-04 Wed 12:28] 빌트인 아님. 그러나 중요.

iedit - edit multiple regions simultaneously

evil-iedit-state

[2023-09-09 Sat 16:51] 이걸로 못할게 없다.

먼저 rg-menu 로 regex 검색을 한다음에 wgrep 으로 잡고

v 눌러서 visual block 으로 잡고 SPC s e 하면 파란색이 잡힌다. insert 모드로 변경해서 수정하면 된다.

https://github.com/syl20bnr/evil-iedit-state

TEMP auto-highlight-symbol and evil-visualstar

[2023-09-10 Sun 08:25]

스페이스맥스에 설치 되어 있는 두 패키지를 보라. 장단점이 명확하다.

"evil-visualstar" 는 기본은 꺼져 있다. 켜주라.

왜 켜줘야 하는가? 비주얼 모드로 선택한 텍스트만 다룰 수 있으니까. 이게 없다면 그냥 타이핑 하면 된다. 아니면 ripgrep 도 된다. 필요 없다면 지우고. 되도록 타이핑 안하면 편하지 않는가? 지금 이것도 입력하려면 힘들텐데

evil-snipe

[2024-01-30 Tue 05:30]

Description

This layer adds various replacements for vim's default search functions.

Features:

Alternative implementation of vim's default search operations.
Replacement of evil-surround with a two-character search.
Support for alternative scopes for default search operations.
Support for alternative motions based on configurable regexps.

Install

Layer

To use this configuration layer, add it to your ~/.spacemacs. You will need to add evil-snipe to the existing dotspacemacs-configuration-layers list in this file.

Improved f and t search behavior

With evil-snipe you can define your own search scope for f and t searches which means that you won't have to jump to the correct line before searching with f / t / F / T. And after you have found a match, you can just press f or t again afterwards to continue the search. No need to use ; / ~,~.

이블스닙을 사용하면 f 및 t 검색에 대한 검색 범위를 직접 정의할 수 있으므로 f / t / F / T~로 검색하기 전에 올바른 줄로 이동하지 않아도 됩니다. 일치하는 항목을 찾은 후에는 ~에프 또는 티~를 다시 눌러 검색을 계속할 수 있습니다. 를 사용할 필요 없이 ~; / ~,~를 누르면 됩니다.

This alternate behavior is disabled by default, to enable it set the layer variable evil-snipe-enable-alternate-f-and-t-behaviors to t:

  (setq-default dotspacemacs-configuration-layers
    '((evil-snipe :variables evil-snipe-enable-alternate-f-and-t-behaviors t)))

Two-character search with s

With the s~/~S keys you can do a simple search like f~/~t, but instead of searching for one character, you search for two. This makes the search a lot more precise than regular f~/~t searches. While you can search forward or backwards in the buffer with / and ?, s / S are much easier to reach, don't require you to press enter and they are precise enough for many common purposes.

S~/~S~ 키를 사용하면 f~/~t~와 같은 간단한 검색을 수행할 수 있지만, 한 문자를 검색하는 대신 두 문자를 검색합니다. 따라서 일반 ~f~/~t 검색보다 훨씬 더 정확하게 검색할 수 있습니다. 버퍼에서 / 및 ?~로 앞뒤로 검색할 수 있지만, ~s / ~S~는 훨씬 더 쉽게 찾을 수 있고, 엔터키를 누를 필요가 없으며, 많은 일반적인 용도로 충분히 정확합니다.

More scopes

Evil-snipe also adds several scope options for searches (set evil-snipe-scope and evil-snipe-repeat-scope to one of these, the default value is buffer):

| Value | Description | |---------------|--------------------------------------------------------------------------| | buffer | search in the rest of the buffer after the cursor (vim-sneak behavior) | | line | search in the current line after the cursor (vim-seek behavior) | | visible | search in the rest of the visible buffer only | | whole-line | same as line, but highlight matches on either side of cursor | | whole-buffer | same as buffer, but highlight all matches in buffer | | whole-visible | same as visible, but highlight all visible matches in buffer |

If you do not want to replace the regular f / F / t / T behavior, just remove this line from evil-snipe/packages.el: (evil-snipe-replace-evil)

Symbol groups

With symbol groups you can let a character stand for a regex, for example a group of characters. By adding a pair of (CHAR REGEX) to the list evil-snipe-aliases you can search for a regex very simply:

Here we set the [ character to mean all characters [({ in all modes so a search with sa[ would find a[, a{ or a(.

    ;; Alias [ and ] to all types of brackets
    (push '(?\[ "[[{(]") evil-snipe-aliases)
    (push '(?\] "[]})]") evil-snipe-aliases)

Here we set the char : to mean "a regex matching python function definitions" (but only in python-mode), so by searching with f:fff you can quickly cycle through all function definitions in a buffer!

    ;; For python style functions
    (add-hook 'python-mode-hook
              (lambda ()
                (make-variable-buffer-local 'evil-snipe-aliases)
                (push '(?: "def .+:") evil-snipe-aliases)))

Key bindings

| Key binding | Description | |-------------|-----------------------------------------------------------------------------------------| | f | search forward for the next entered character and set the cursor to it's position | | F | search backward for the next entered character and set the cursor to it's position | | t | search forward for the next entered character and set the cursor before it's position | | T | search backward for the next entered character and set the cursor before it's position | | s | search forward for the next entered two characters and set the cursor to it's position | | S | search backward for the next entered two characters and set the cursor to it's position |

CANCELLED 임시

[2024-01-31 Wed 15:24]

TEMP 전반적인 개선 검토 필요 by Injae

[2023-09-10 Sun 08:14] 이렇게 많다. 좋은 것은 써라. 아래 인제님 보니 용법이 있더라.

evil-anzu evil-args evil-collection evil-escape evil-exchange evil-iedit-state evil-indent-plus evil-lion evil-nerd-commenter evil-matchit evil-numbers evil-surround evil-textobj-line evil-unimpaired evil-visual-mark-mode evil-visualstar evil-tutor evil-lisp-state evil-cleverparens

/home/junghan/sync/man/dotsamples/korean/injae-dotfiles/module/+evil.el

전반적으로 에빌 시스템을 검토할 필요가 있다. 안쓰는게 너무 많다. 몰라서 그렇다. 기능을 추가하지 마라! Spacemacs 기본으로 가야 된다.

 
    (evil-want-C-u-scroll t)
    (evil-symbol-word-search t)
    (evil-want-minibuffer t)
    (define-key evil-normal-state-map (kbd "q") 'nil) ; evil macro disable
    (define-key evil-visual-state-map (kbd "R") 'evil-visual-exchange-corners)
    (setq-default evil-kill-on-visual-paste nil)
    ;; visual mode 'p' command update clipboard problem fix
 
;; (global-evil-visualstar-mode t) 없는 것과 있는 것의 차이는?
 
;;;; string-infraction
;; (use-package evil-string-inflection
;; :config (define-key evil-normal-state-map "gR" 'evil-operator-string-inflection)
;; )
 
;;;; indent-plus
 
;;;; evil-surround
; @call-function
; visual mode S- or gS-
; normal mode ys- or yS-
; change surround cs-
; delete surround ds-
; @select area
; call-functionu- - ;현재부터 단어 끝까지
; {call-function}-i- ;현재 단어
; {call-function}-s- ;현재 줄
; @wrap function
; {select-area}-w
; ${target}( 바꾸고싶은거 ), ${change}(바뀔거)
; 감싸기:     => y-s-i-w-${change}( "(", "{", "[")
; 전부 감싸기 => y-s-s-${change}
; 바꾸기: => c-s-${target}( "(", "{", "["), ${change}
; 벗기기: => d-s-${target}( "(", "{", "[")

🧠Junghanacs

Recent Notes

#마음챙김: #텍스트마스터 - 창조적 인간론

#조직모드 #템플릿 #샘플 - latex menuscript

#대시보드 #dashboard

#비둘기 - pigeon

#리처드파인만 #물리학자 #봉고

#모음: #이블 #편집

* # :: #심볼 Symbol Transient State

히스토리

Corgi Manual

Principles

Minimal

Reproducible installs

Packages all the way down

Vim-style modal editing

Focused on Clojure and LISP

Consistent keybindings

Keybindings all live in one place

First class terminal and GUI support

It's your config

Key bindings

Keys to get you started

General

Window SPC w

buffers SPC b

file SPC f

Getting help SPC h

Working with REPLs

Structural editing

Packages

corgi-packages

corgi-defaults

corgi-editor

corgi-emacs-lisp

corgi-commands

corgi-clojure

Babashka utility REPL

Modeline indicator

Eval from register

corgi-stateline

Corkey

Initializing Corkey

Installing bindings

Differences from Vim

Walkthrough of a Clojure session

목표

lsp-mode, clj-kondo

corgi 패키지에 대해서

Walkthrough of a Clojure session

SpaceVim VSpaceCode and Spacemacs

SpaceVim 설치하며 -- VSpaceCode and Spacemacs 비교

Emacs and SpaceVim on Markdown on Kitty

Evil Tips Examples

cif

References

evil-surround

evil-textobj-line 텍스트 오브젝트

Spacemacs Focus Document

Evil for Viim Style Editing

2022-10-04 evil-emacs forward backward keybinding

알아야 할 키 바인딩

evil emacs 를 잘 사용하기 위한 핵심은?

이미지 없이 embark 로 복사하는 방법을 찾자.

which-key toggle

이미지를 본다.

vim keybindings

입력모드 i 를 넘어서자.

Move and Kill Editing Keybindings in Emacs

Hungry Delete with S-<backspace> S-<DEL>

spacemacs.org 참고

jh-editing 참고

iedit

evil-iedit-state

TEMP auto-highlight-symbol and evil-visualstar

evil-snipe

Description

Features:

Install

Layer

Window `SPC w`

buffers `SPC b`

file `SPC f`

Getting help `SPC h`

Hungry Delete with `S-<backspace> S-<DEL>`