Forem: Mikhail Konkov

Emacs-команды в Claude Code CLI на русской раскладке для iTerm2

Mikhail Konkov — Sat, 02 May 2026 13:10:17 +0000

Проблема

Я уже несколько месяцев работаю с Claude Code CLI в терминале и столкнулся с неприятной мелочью: команды Emacs для редактирования текста (Ctrl+A, Ctrl+E, Ctrl+W и т.д.) не работают на русской раскладке.

Раньше всё было нормально, так как я работал в терминале только на английском. Но сейчас, когда удобнее вводить промты на родном языке, эта проблема мешает.

Ctrl+A не прыгает в начало строки
Ctrl+W не удаляет слово назад
Ctrl+V для вставки скриншотов тоже мимо
Переключать раскладку каждый раз ради одной команды — боль

Решение

Это лечится одним key mapping файлом для iTerm2. Он:

маппит кириллические позиции клавиш на правильные управляющие коды (Emacs-команды работают и на RU, и на EN);
добавляет Option+а / Option+и как прыжки по словам;

Как применить

Откройте iTerm2 → Settings → Profiles → Keys → Key Mappings.
Нажмите кнопку Presets... → Import... и выберите файл с конфигом ниже (сохраните его как ru-emacs.itermkeymap или вставьте через JSON-редактор).

Конфиг

{
  "Key Mappings": {
    "0x430-0x40000": {"Action": 11, "Text": "0x06"},
    "0x438-0x40000": {"Action": 11, "Text": "0x02"},
    "0x430-0x80000": {"Action": 11, "Text": "0x1b 0x66"},
    "0x438-0x80000": {"Action": 11, "Text": "0x1b 0x62"},
    "0x444-0x40000": {"Action": 11, "Text": "0x01"},
    "0x443-0x40000": {"Action": 11, "Text": "0x05"},
    "0x43b-0x40000": {"Action": 11, "Text": "0x0b"},
    "0x433-0x40000": {"Action": 11, "Text": "0x15"},
    "0x446-0x40000": {"Action": 11, "Text": "0x17"},
    "0x43c-0x40000": {"Action": 11, "Text": "0x16"},
    "0x43d-0x40000": {"Action": 11, "Text": "0x19"},
    "0x449-0x40000": {"Action": 11, "Text": "0x0f"}
  },
  "Touch Bar Items": []
}

Шпаргалка по маппингам

Emacs-навигация на русской раскладке

Клавиша (RU)	Что делает	Эквивалент EN
`Ctrl+ф`	в начало строки	`Ctrl+A`
`Ctrl+у`	в конец строки	`Ctrl+E`
`Ctrl+а`	символ вправо	`Ctrl+F`
`Ctrl+и`	символ влево	`Ctrl+B`
`Ctrl+л`	удалить до конца строки	`Ctrl+K`
`Ctrl+г`	удалить всю строку	`Ctrl+U`
`Ctrl+ц`	удалить слово назад	`Ctrl+W`
`Ctrl+н`	Yank (вставить из kill-буфера)	`Ctrl+Y`
`Option+а` / `Option+и`	прыжок по словам вправо/влево	`Option+F` / `Option+B`
`Ctrl+м`	вставить скриншот в claude code cli	`Ctrl+V`
`Ctrl+щ`	развернуть вывод команд в claude code cli	`Ctrl+O`

Почему это работает

iTerm2 ловит события клавиатуры до того, как macOS успевает решить «эта раскладка не знает Ctrl+a». Мы матчимся на конкретные кодпоинты Unicode (0x444 это ф, 0x443 — у, и т.д.) с модификатором 0x40000 (Control) и руками отправляем в TTY правильный байт (0x01 для Ctrl+A).

Итог

Один импорт пресета — и Claude Code CLI перестаёт быть пыткой при работе на русском. Промт теперь можно набирать, не дёргая Cmd+Space каждые пять секунд.

Если у вас другой терминал — подход тот же: ищите в их конфигах секцию key bindings и маппите кириллические кодпоинты на управляющие байты.

Удачи в промтах.

Claude Code CLI: Best Practices

Mikhail Konkov — Wed, 29 Apr 2026 22:55:19 +0000

A handful of observations from working with Claude Code day to day — about memory, context, modes, and a couple of useful skills. Nothing groundbreaking, just the things I wish someone had told me earlier.

Setup once

These are the things you do at the start of a project (or once per machine) and forget about — but they pay back on every single session.

CLAUDE.md. Put commands for running tests and linters here, along with an architecture overview, what NOT to touch, and code style conventions. The agent reads this file automatically, so you don't have to repeat the same things in every prompt.

If your project has multiple areas, you can drop a separate CLAUDE.md into each one: the agent will pick up both the root file and the one closest to the files it's working on.
Cultivate auto memory deliberately. Auto memory is Claude Code's built-in notebook where the agent stores notes between sessions on its own: build commands, debugging insights, your style preferences. It lives in ~/.claude/projects/<project>/memory/ as an index file (MEMORY.md) plus topic files. The index loads at the start of each session (first 200 lines or 25 KB); deeper notes are pulled in on demand when relevant. Requires Claude Code v2.1.59+, on by default; view and prune via /memory. Important caveat: this is not model fine-tuning — it's just markdown that gets pulled into context. So the agent gets "better" only as far as its notebook is good, and the notebook needs to be managed.

What works:

Correct with words, not silent edits. "Don't use var, we use const/let everywhere" is a signal worth remembering. A silent fix in the IDE isn't.
At the end of a hard task, ask explicitly: "remember how we fixed this" or "save to memory: this repo uses Arel, not raw SQL." Claude will ask whether to save it to project memory or global (~/.claude/).
Every couple of weeks, open /memory and clean out anything stale (architecture changed — old notes now lie). Move team-wide findings into CLAUDE.md so they reach the whole team, not just you.

A useful end-of-session prompt:

Sum up what we did, where we got stuck, and what worked. From that, pick 1–3 notes worth saving for future sessions and suggest where each should go — project or global memory. Don't save them yet; I'll confirm.

  Sum up what we did, where we got stuck, and what worked. From that, pick 1–3 notes worth saving for future sessions and suggest where each should go — project or global memory. Don't save them yet; I'll confirm.

Working on a task

Habits for the actual work — how to brief the agent, how to keep yourself out of trouble.

Use git as a safety net. Commit often and start agent sessions with a clean working tree — it's much easier to see exactly what the agent changed and to roll back if needed.
Use plan mode for complex tasks. Ask for a plan first — either explicitly ("draft a plan, don't write code yet") or by switching into plan mode (Shift+Tab cycles through modes: normal → auto-accept → plan). Read it, adjust it, and only then let the agent execute. This dramatically reduces the chance of the agent spending half an hour doing the wrong thing.

Don't default to auto-accept mode. Auto-accept — where the agent confirms all its own actions (file edits, shell commands) — is fine for short, contained tasks: rename a variable, run the linter, fix a flaky test. For anything else it's a way to rack up a dozen unreviewed changes in five minutes. Keep the default mode (manual confirmation) and turn on auto-accept consciously, for a specific stretch of work, ideally on top of a clean git state so rolling back is cheap.

Break tasks down. Instead of "implement the whole feature," go step by step: schema first, then migration, then the endpoint, then tests. It's cheaper in tokens, easier to review intermediate results, and easier to roll back if the agent went off course.

Managing context

Context is the resource you're actually paying for — both in money and in answer quality. These three pull in the same direction.

Watch your context size. The larger it gets, the more expensive each step becomes (the entire context is re-sent every turn) and the worse the agent holds focus. For a separate task, start a new session — or use /compact to compress the history.
The downside of a new session is that the agent loses context and burns tokens getting back up to speed. So move the essentials (project architecture, conventions, frequently used commands) into CLAUDE.md or package them as a skill — that way they load automatically and don't eat into your context window on every start.
Don't let the agent fix what it just broke in the same session. If it's stuck in a hole, it's better to roll back, reformulate the task, and start fresh than to pile more on top. Otherwise mistakes compound and chew through context.

Tuning and extras

The fine-tuning knobs and a couple of optional add-ons.

Pick the model and /effort to match the task. Sonnet is cheaper and faster — usually enough for routine work (edits, refactoring, tests). Opus is for complex design, gnarly bugs, and architectural decisions. /effort controls reasoning depth (low | medium | high | xhigh | max): use low for mechanical tasks and high/max for architecture and heavy debugging.

Attach screenshots and logs directly. For UI bugs, a screenshot saves a ton of back-and-forth; for errors, paste the full stack trace, not a paraphrase. The agent works noticeably better with raw input. (Use Ctrl+V to paste a screenshot in Claude Code CLI.)
Install Caveman — a skill that makes Claude respond in a telegraphic style, without filler phrases or hedging. It cuts up to 75% of output tokens while keeping technical accuracy intact; code, error messages, and commit messages stay normal. Toggle on with /caveman or "caveman mode," off with "normal mode."

That's the set. None of it is rocket science — most of the wins come from setting up CLAUDE.md properly, leaning on plan mode, and keeping the context window honest. If you've got your own practices, drop them in the comments — I'm always looking to steal good ones.

English Writing Tips for Non-Native Speakers: How to Sound More Natural

Mikhail Konkov — Mon, 27 Apr 2026 10:00:00 +0000

You speak English well. You understand meetings, read articles, follow conversations. But when you write — Slack messages, emails, LinkedIn posts — something feels off. Not wrong, exactly. Just not
quite native.

Here are the patterns that give away non-native writers, and how to fix them.

1. Cut the formal opener

Starting with "I hope this email finds you well" or "As per my previous email" — technically correct, but native speakers almost never write this. It reads as bureaucratic.

Instead:

❌ "I am writing to inquire about the status of my application."
✅ "Just checking in on my application — any updates?"

2. Use contractions in casual contexts

Non-native writers avoid contractions because they learned formal grammar first. "I am," "it is," "do not" — stiff when the context is casual.

In Slack, casual emails, LinkedIn comments — use contractions. Save full forms for legal documents.

3. Stop hedging everything

"I was wondering if perhaps it might be possible to..." reads as uncertain, not polite.

❌ "I was thinking that maybe we could perhaps consider moving the deadline if that would be okay."
✅ "Could we push the deadline by a day? I want to make sure the output is solid."

Direct requests with a brief reason are more respected — not less polite.

4. Watch for literal translations

Phrases that make sense in your native language produce awkward English word-for-word:

"Make a question" → Ask a question
"It depends of" → It depends on
"In the other hand" → On the other hand

5. Vary your sentence length

Non-native writers often write in uniform, medium-length sentences. Each one correct. Each one the same rhythm. Native writing mixes it up — short punches followed by longer sentences that build on the
idea.

Read your draft out loud. If it sounds like a metronome, break it up.

6. Articles: the invisible enemy

If your native language has no articles (Russian, Chinese, Japanese, Turkish...), "a," "an," "the" will trip you up for years.

Highest-impact fix: use the for specific/established things, a/an for introducing something new.

❌ "We need to make decision. Decision will affect entire team."
✅ "We need to make a decision. The decision will affect the entire team."

7. End emails with action, not formality

❌ "Please do not hesitate to contact me should you require any further information."
✅ "Let me know if you have questions." / "Happy to jump on a call if easier."

8. Read out loud

If you stumble reading it aloud, your reader stumbles mentally. Rewrite until it flows.

The shortcut

All of this takes years to internalize. If you need to write professionally in English right now — in a job interview, a client email, a LinkedIn post — I built Limato: a Chrome
extension that rewrites your text in a native tone, inline, wherever you type.

Originally published on limato.app