Everywhere: Fix typos

Base/res/html/misc/contenteditable.html

@@ -3,6 +3,6 @@
         <h1>Everything on this page should be editable.</h1>
 
         <p>Here is a paragraph to play with.</p>
-        <p>Another paragraph with a <b>bold</b> element embeded in it.</p>
+        <p>Another paragraph with a <b>bold</b> element embedded in it.</p>
     </body>
 </html>

Base/usr/share/man/man1/expr.md

@@ -59,7 +59,7 @@ Note that many operators will need to be escaped or quoted if used from within a
 
 ## Options
 
-* `--help`: Prints usage informations and exits.
+* `--help`: Prints usage information and exits.
 
 ## Examples
 

Documentation/HighDPI.md

@@ -34,7 +34,7 @@ A 2x resource should look like a 1x resource, just with less jagged edges. A hor
 
 A good guideline for black-and-white images: start with a 1x bitmap, resize it to 200% using nearest-neighbor filtering, and then move black pixels around to smooth diagonal edges -- but the number of black pixels shouldn't change relative to the 200% nearest-neighbor-resampled image. If that's not possible, err towards making the icon smaller instead of larger. A good technique is to use the Ctrl-Shift-Super-I shortcut in HighDPI mode to toggle between low-res and high-res icons in HighDPI mode.
 
-While a 1x 32x32 bitmap and a 2x 16x16 bitmap both have 32x32 pixels, they don't have to look the same: The 2x 16x16 should look exactly like the corresonding 1x 16x16, just with smoother edges. The 1x 32x32 pixel resource could instead pick a different crop. As a concrete example, the 1x 7x10 ladybug emoji image currently just has the ladybug's shell (for space reasons), and so should the 2x version of that emoji. On the other hand, if we add a higher-res 1x 14x20 ladybug emoji at some point, we might want show the ladybug's legs on it, instead of just a smoother rendition of just the shell. (The 2x version of that 14x20 emoji would then have legs and shell in less jagged.)
+While a 1x 32x32 bitmap and a 2x 16x16 bitmap both have 32x32 pixels, they don't have to look the same: The 2x 16x16 should look exactly like the corresponding 1x 16x16, just with smoother edges. The 1x 32x32 pixel resource could instead pick a different crop. As a concrete example, the 1x 7x10 ladybug emoji image currently just has the ladybug's shell (for space reasons), and so should the 2x version of that emoji. On the other hand, if we add a higher-res 1x 14x20 ladybug emoji at some point, we might want show the ladybug's legs on it, instead of just a smoother rendition of just the shell. (The 2x version of that 14x20 emoji would then have legs and shell in less jagged.)
 
 ### Directory structure
 
@@ -131,7 +131,7 @@ Root-level split makes it easy to see which scale factors exist and is subjectiv
 
 Filename suffixes make it easy to see which icons don't have high-res versions (but in return clutter up an icon directory), and it makes it easy to get the intrinsic scale factor of a bitmap (just need to look at the image's basename, not at any directory).
 
-Android has additional modifiers in additon to scale factors in its resource system (UI language, light/dark mode, screen size in addition to resolution, etc). If we ever add more factors to the resource system, a suffix-based system would probably extend more nicely than a nesting-based one.
+Android has additional modifiers in addition to scale factors in its resource system (UI language, light/dark mode, screen size in addition to resolution, etc). If we ever add more factors to the resource system, a suffix-based system would probably extend more nicely than a nesting-based one.
 
 In the end probably doesn't matter all that much which version to pick.
 
@@ -176,7 +176,7 @@ or
 
 Going forward:
 
-    FIXME (depends on loading strategy decison a bit?)
+    FIXME (depends on loading strategy decision a bit?)
 
 Implementation plan
 -------------------

Kernel/FutexQueue.cpp

@@ -107,7 +107,7 @@ u32 FutexQueue::wake_n_requeue(u32 wake_count, const Function<FutexQueue*()>& ge
 u32 FutexQueue::wake_n(u32 wake_count, const Optional<u32>& bitset, bool& is_empty)
 {
     if (wake_count == 0)
-        return 0; // should we assert instaed?
+        return 0; // should we assert instead?
     ScopedSpinLock lock(m_lock);
 #ifdef FUTEXQUEUE_DEBUG
     dbg() << "FutexQueue @ " << this << ": wake_n(" << wake_count << ")";

Kernel/ThreadBlockers.cpp

@@ -163,7 +163,7 @@ void Thread::FutexBlocker::finish_requeue(FutexQueue& futex_queue)
 {
     ASSERT(m_lock.own_lock());
     set_block_condition_raw_locked(&futex_queue);
-    // We can now releas the lock
+    // We can now release the lock
     m_lock.unlock(m_relock_flags);
 }
 

Kernel/VM/AnonymousVMObject.cpp

@@ -145,7 +145,7 @@ AnonymousVMObject::AnonymousVMObject(const AnonymousVMObject& other)
     ensure_or_reset_cow_map();
 
     if (m_unused_committed_pages > 0) {
-        // The original vmobject didn't use up all commited pages. When
+        // The original vmobject didn't use up all committed pages. When
         // cloning (fork) we will overcommit. For this purpose we drop all
         // lazy-commit references and replace them with shared zero pages.
         for (size_t i = 0; i < page_count(); i++) {
@@ -380,7 +380,7 @@ RefPtr<PhysicalPage> AnonymousVMObject::allocate_committed_page(size_t page_inde
 
         ASSERT(m_unused_committed_pages > 0);
 
-        // We should't have any committed page tags in volatile regions
+        // We shouldn't have any committed page tags in volatile regions
         ASSERT([&]() {
             for (auto* purgeable_ranges : m_purgeable_ranges) {
                 if (purgeable_ranges->is_volatile(page_index))

Kernel/WaitQueue.cpp

@@ -74,7 +74,7 @@ void WaitQueue::wake_one()
 u32 WaitQueue::wake_n(u32 wake_count)
 {
     if (wake_count == 0)
-        return 0; // should we assert instaed?
+        return 0; // should we assert instead?
     ScopedSpinLock lock(m_lock);
 #ifdef WAITQUEUE_DEBUG
     dbg() << "WaitQueue @ " << this << ": wake_n(" << wake_count << ")";

Userland/Libraries/LibCompress/Deflate.cpp

@@ -111,7 +111,7 @@ u32 CanonicalCode::read_symbol(InputBitStream& stream) const
         code_bits = code_bits << 1 | stream.read_bits(1);
         ASSERT(code_bits < (1 << 16));
 
-        // FIXME: This is very inefficent and could greatly be improved by implementing this
+        // FIXME: This is very inefficient and could greatly be improved by implementing this
         //        algorithm: https://www.hanshq.net/zip.html#huffdec
         size_t index;
         if (AK::binary_search(m_symbol_codes.span(), code_bits, &index))

Userland/Libraries/LibDebug/DebugInfo.cpp

@@ -249,7 +249,7 @@ static void parse_variable_location(const Dwarf::DIE& variable_die, DebugInfo::V
         break;
     }
     default:
-        dbgln("Warninig: unhandled Dwarf location type: {}", (int)location_info.value().type);
+        dbgln("Warning: unhandled Dwarf location type: {}", (int)location_info.value().type);
     }
 }
 

Userland/Libraries/LibRegex/RegexByteCode.h

@@ -286,7 +286,7 @@ public:
             empend((ByteCodeValueType)2); // Fail two forks
             empend((ByteCodeValueType)OpCodeId::Save);
             empend((ByteCodeValueType)OpCodeId::ForkJump);
-            empend((ByteCodeValueType) - (body_length + 5)); // JUMP to lavel _L
+            empend((ByteCodeValueType) - (body_length + 5)); // JUMP to label _L
             empend((ByteCodeValueType)OpCodeId::Restore);
             return;
         }
@@ -321,7 +321,7 @@ public:
             empend((ByteCodeValueType)2); // Fail two forks
             empend((ByteCodeValueType)OpCodeId::Save);
             empend((ByteCodeValueType)OpCodeId::ForkJump);
-            empend((ByteCodeValueType) - (body_length + 7)); // JUMP to lavel _L
+            empend((ByteCodeValueType) - (body_length + 7)); // JUMP to label _L
             empend((ByteCodeValueType)OpCodeId::Restore);
             return;
         }

Userland/Services/WindowServer/Compositor.cpp

@@ -527,7 +527,7 @@ void Compositor::flush(const Gfx::IntRect& a_rect)
 {
     auto rect = Gfx::IntRect::intersection(a_rect, Screen::the().rect());
 
-    // Almost everything in Compositor is in logical coordintes, with the painters having
+    // Almost everything in Compositor is in logical coordinates, with the painters having
     // a scale applied. But this routine accesses the backbuffer pixels directly, so it
     // must work in physical coordinates.
     rect = rect * Screen::the().scale_factor();

Userland/Shell/main.cpp

@@ -114,7 +114,7 @@ int main(int argc, char** argv)
     parser.add_option(format, "Format the given file into stdout and exit", "format", 0, "file");
     parser.add_option(should_format_live, "Enable live formatting", "live-formatting", 'f');
     parser.add_positional_argument(file_to_read_from, "File to read commands from", "file", Core::ArgsParser::Required::No);
-    parser.add_positional_argument(script_args, "Extra argumets to pass to the script (via $* and co)", "argument", Core::ArgsParser::Required::No);
+    parser.add_positional_argument(script_args, "Extra arguments to pass to the script (via $* and co)", "argument", Core::ArgsParser::Required::No);
 
     parser.parse(argc, argv);