What do you really need in a text editor?

(Derek only cares about a very small set of things, but he cares about them a lot) (going to just collect them here)

Make a new file

It’s crazy that I have to ask for command + N to make a new text file — in a text editor… but here I am. I like this. Can we have this? And if you want a more special “new” – how about command + shift + N for I don’t know… a Vue file or a special window to deal with where you want it.

A simple sidebar

I prefer to not use the side bar most of the time — but – I still want it to be there as an option — and i don’t want to have it dissapear / and then spend a long time trying to find it … and not be able to find it – because it has some confusing name…

Minimal UI

When VSCode first came out – it was like Nascar for texteditors. We don’t need a bunch of icons — (it just makes everything worse).

Find a file by name

You should be able to think of what you want and get to it immediately without looking through a file directory/sidebar. Ideally very
loose just mashing of letters: lec = **l**isting **e**ditor **c**ontroller etc.)

command + P is how they do it in Sublime (for example) and it’s very good. You can mash out crazy letters and it somehow
still finds what you want. Some look for the first letters of words only.

In PHPStorm there’s `shift + shift` – and it has a really in-depth search area / but it’s way too complex when you’re
just looking for files. So, you can map a form of that that defaults to by file. Furthermore, you can create a sub-scope
of files for it to search and leave out vendor etc.  (but after setting this up and losing it / and resetting and so many different attempts to make the most of it — instead / we just basically memorized ways to get around it)

Zoom in and out

You should be able to zoom in and out  (change font sizes) / so that when sharing your screen people can read what you’re showing them. But
you should be able to only zoom in the pane you are in. If all the UI also gets bigger and not just the actual code –
it’s not nearly as useful. Using the classic command w/  + and - (like every program does) is ideal. If you need a unique shortcut – and all the UI zooms — fuck off. srsly bro…

Find words

command + F and command shift F for across all files (and we don’t need a whole specialized app that pops up and blocks everything / and ensures you can click and copy from your text anymore)

Select a string of text and then incrementally select each subsequent occurrence

command + D is how Sublime does it (duplicating selection) —  and command + U will back up – if you went one too far. Command + shift + G will get all of them.

Just do it

In Sublime there’s the “command pallete” (like Alfred or terminal) where (with very little keyword memorization) – you can pretty much just do anything. Need to install something? command + shift + P – then thing of what you want. What to “install” something. Create. You don’t need some super ugly app store built-in to the editor.

Basic tab complete

section.name + tab === <section class='name'> – Emmet – or however that needs to happen. Just looking for the basics – and that goes for MyComponent too

Language and framework syntax highlighting

This is really helpful. But for the record, life still went on when it was just 2 colors ; )

This either has to be 100% right / or having none would be better. But as long as the editor makes these things possible, the community will create them.

Placing multiple cursors

Sublime uses command + click but VSCode and PHPStorm use that for drilling down to a class or function (which is very helpful) — but maybe that’s command/shift/click?

Intuitive quick pane splitting

This isn’t a HUGE issue… but Sublime Text does it well with command + option + 1, 2, 3 4, 5 etc – with no strange side effects.

Auto formatting

On a team, it’s important that we’re not looking at syntax changes in PRs. So, I’d like to have a set of formatting rules that are ideally shared with the team – and work in all the different editors the same. I’d like to choose whether I want to to explicitly format – or auto format.

other notes… still listing these out as I note how I’m navigating things

• auto imports… as in / if you’re not using Nuxt…  – automatically figuring them out and pasting them in there
• highlighting things that are incorrect / or unused. (very helpful!! But not worth a ton of other bullshit that counters that) — but not incorrectly — like seems to be the case — so often… 
• browser refreshing  (browser refresh package for basic PHP stuff / but usually – we’re using Vite anyway)
• a way to create extensions/plugins/packages to extend the editor

Also useful, but needed much less would be to click and drag down a vertical line of cursors. That’s holding option and
dragging. But maybe we just skip that and use `option + click` for drilling — or `command + shift + click` for
drilling.

Let’s try and order these for the video….

• Stable, minimal UI – no flashing widgets or clutter; everything should be easy to find. — nothing distracting or opinionated and stylized — just a place to author clean readable code (if you can only have one thing — well, this would be it)
• Basic settings for tab/spaces and indentation. We set our tabs to 3 spaces deep so that it’s clearer on video. But ideally – we’d be able to change what a tab means at any time. Sometimes – you want to se them to 2 or 6. Some editors have crazy huge/deep panels for turning everything on and off and setting settings. Sublime Text has a simple JSON-like file where you just write the key and value.
• Create new documents
• Pane splitting – view multiple files side by side without fuss. (as soon as you have an HTML page – and it’s CSS – it’s really helpful to see both at the same time / especially while learning.
• Set their type –
• Syntax highlighting – you really can live without it… and in the early stages of learning — it’s nice to do that — and really learn to see the characters. But it’s not a niche thing – so, you may as well make the code easy to read – right? But if we could only have plain text and pane splitting – that would be more important (as far as the ‘order of practical need’ go)
• Find in file search –
• Fast file search (fuzzy find) – open files by typing a few letters, not hunting through folders. (at the beginning – there are very few files — so, you can use the sidebar to see the directory structure — but the sooner you can start just thinking “I want this file” and having it appear the better — and also because it will help you ensure you’re naming things in an intuitive way — which is a career-long challenge
• Project-wide text search – find code across the whole repo, excluding irrelevant folders like node_modules or vendor. (maybe this is more important than file search? But in some of these cases – you’ll have both or none anyway).
• Multi-cursor / batch edits – change multiple occurrences in seconds. This is nice. But you can
• What do we call this — In the beginning — it’s nice to write out all the characters <header class=’site-header’>…  – but once you’ve 100% got all that down, to get your thoughts out on the screen faster, there are tools like Emmet to autocomplete your thought  so, you’d type header.site-header and hit tab and it would complete it as <header class=’site-header’> and it would place the cursor at the next appropriate spot. It’s not guessing and suggesting, it’s from a preset rule system. It’s not all about being ‘faster’ (speed is never really the bottleneck) — but what it really does is keep your mind in gear / and it leads to less typing errors too.

CodePen

OK, so – before we get into the super boring and annoying configurations and things… you know what’s really great for working out ideas? Yes you do: CodePen.

CodePen is an online sandbox, and it has a lot of powerful features, but the core ones are: three little code panes for HTML, CSS, and JavaScript, and an output window. There’s a lot of stuff going on behind the scenes, but for the user, they just type in their code and it updates live like magic.

Since you can create a Pen with no extra apps, even on a computer at the library or something, maybe that’s the lowest barrier to entry. And to be fair, there are many many different sandbox-based online editors like this, so – whichever ones work for you.

Too many mysteries

The problem with VSCode‑centric tutorials is that you load up all this “stuff” you don’t really understand. You follow what the tutorial guy says during that long “just type what I type” section at the start of the course. The problem is that most people have no idea how any of it works, and then they move on taking it all for granted. CodePen is allowed to be a little magic. But once you get serious and start working locally on your computer, we don’t want any mysteries. And as of 2025, there’s all sorts of “AI” and autocomplete and coding assistants built in — which we highly recommend you stay away from until much later in your learning journey.

The minimum

The most basic text editors are the best place to start. You can put your editor on the left and your browser on the right. Your editor might be split into a pane for HTML and a pane for CSS. You’ll be able to use as much of your screen as possible and see the whole story. But your browser isn’t going to refresh automatically — because why would it? How would your text editor know to send a message to the browser telling it to reload after every change?

If you’re used to that kind of thing, it might feel annoying at first. But we’ve found that, in the beginning, it’s important to take it slow. You make a change. Maybe a few more. Then you go over, click refresh, and re-request the page (right? because… HTTP). And then you see the update, for better or worse. This is good.

When you’re starting out, it can be too distracting to see the changes happen instantly. You don’t want that. Trust us – we’ve tested this with hundreds of students. The people who get anxious and are really tied to VSCode do the worst 😬.

PHP + Sublime (partials and first server)

• First server step without a framework
• Use PHP includes for reusable HTML chunks
• Explain MAMP/LAMP and why they exist
• Project lives in server root (htdocs or similar)
• Browser request now goes through the server
• Keep Sublime setup minimal, just use .php files
• Refresh still works, now you see server output

Sublime auto refresh plugin

• Add only after manual refresh habits are solid
• Map to Command+Shift+R
• Speeds CSS and markup loops
• Does not replace understanding caching and requests
• Keep it toggleable for debugging

Vite for prototyping

• First Node based tooling
• Dev server with hot reload
• Use ES module imports and simple assets
• Keep config tiny, run with defaults
• Optional: add Prettier once you are here
• Avoid piling on plugins just because you can

Shared project basics

• Only when a second person touches the code
• Add .editorconfig for indent and newlines
• Add Prettier for formatting, one script to run it
• Document the one fix command in README
• Keep rules minimal and agreed upon

Future phases placeholder

• Frontend heavy path: components, design system, Storybook
• Backend heavy path: database, APIs, auth
• Deployment path: build, envs, simple CI
• Laravel comes after these, ties it all together

More thinking on this:

General Editor Core Needs (applies to every stack)

• Stable, minimal UI. No clutter. Calm space to write.
• The ability to turn off anything that’s on by default (like autocomplete etc / which is often wrong and surely visually distracting) –
• Tabs, spaces, indentation. Change tab width easily. Simple settings file.
• Create new documents fast. Cmd+N should just work.
• Pane splitting. See HTML and CSS side by side.
• Set file type manually when needed.
• Syntax highlighting. Optional at first, enable once comfy.
• Find in file search.
• Project-wide search that ignores vendor folders.
• Fast file search (fuzzy find) for larger projects.
• Multi-cursor and batch edits.
• Structured shorthand (Emmet) once markup is second nature.

Section 1: Solo learning, no build tools

• Editor on left, browser on right. Manual refresh on purpose.
• Use plain files first. Learn cause and effect of saves and reloads.
• Practice with and without syntax highlighting.
• Start naming files clearly, then use fuzzy find to reinforce naming.
• Skip AI, autocomplete helpers, and integrated terminals for now.

Section 2: Simple projects on a team (still no build tools)

• Goal: same look on every machine, zero style debates.
• .editorconfig for indent, newline, charset.
• One formatter. Prefer Prettier for web files. One script: npm run format.  (that introduces node so early though… so — I’m not sure I’m excited about that… ) (if they aren’t all using different formatters – this isn’t going to matter quite yet, right?)
• Keep rules minimal. Document the one fix command in README.
• Basic Git awareness in editor. Commit however you like (CLI or Tower). (I think the git awareness is confusing and the colors just distract people / so, I’d want to turn that off)
• No linters yet unless they solve a real problem.

Section 3: Basic PHP stage (first server, still lightweight)

• Why PHP here: teaches what a server does without a framework.
• Includes and partials to avoid copy-paste HTML.
• Use MAMP or Herd. Project lives under the web root. Hit http://localhost.
• Sublime auto-refresh plugin only now, after manual refresh is understood.
• Create .env for secrets. Commit .env.example, never commit .env.
• Editor needs for this stage:
  • PHP syntax highlighting and basic IntelliSense.
  • Project-wide search that ignores vendor/.
  • Multi-cursor for routes, includes, repeated markup.
• Keep editor minimal. Terminal, server controls, and Git in dedicated apps (iTerm, MAMP/Herd, Tower).

Section 3.2: PHP + CMS

• anything unique here?
  • We could talk about CodeKit and how it’s used to abstract away the need to understand package managers and build tools

Section 3.5: Vanilla JS stage

• we have students build out things with ESM and build their own apps without any build tools or frameworks first —

Section 4: Vite stage (modern front end, shared configs allowed)

• Why now: modules, imports, HMR. Still small, still fast.
  • At this point — we can’t avoid build tools
• Editor needs do not change. Same core features as above.
• Add shared config only if it removes friction:
  • .prettierrc and .prettierignore. One format script.
  • Optional ESLint with the smallest sane ruleset. Only if it prevents real bugs.
  • Optional jsconfig.json/tsconfig.json for path aliases so editor “go to file” works with @/....
• Keep Vite config tiny. Defaults first. No plugin pile-on “just because.”
• Document the one or two commands teammates run in the README.

Section

Section 5: Laravel (coming later)

• You still need all the general editor needs above.
• Laravel-specific extras will be additive: Blade highlighting, route/controller/view jumps, PHP formatter, etc.
• We will keep terminals, servers, and Git as dedicated tools.

Integrated stuff (optional, noted but discouraged early)

• Integrated terminal, Git panels, and server controls exist, but are distracting for learners.
• Prefer dedicated apps: iTerm, Tower, MAMP or Herd.
• Revisit integration only if it clearly reduces context switching later.