MOSAID Articles & Tutorials

Engineering a Deterministic Audio Boundary Marker with Python and Curses

2026-06-09T00:43:19+00:00

I needed to split a long Quran recitation MP3 into one file per verse – precisely, with boundaries that matched the reciter’s pauses, not just fixed durations. Audacity could do it manually, but the process was tedious and error‑prone. I wanted a deterministic, keyboard‑driven workflow that I could pick up and resume anytime, with export pipelines that never left me guessing which segment went where.

That’s how verse_marker.py came to be: a terminal application built with Python, curses, VLC, and FFmpeg. It’s not a general‑purpose audio editor; it’s a focused tool for interactively placing markers, editing them, and splitting audio according to a predictable naming scheme. The whole thing fits in about 10 source files and has no external database – everything is JSON on disk.

Architecture Overview

The codebase is organised into layers that each own a single responsibility:

•Player layer (player.py) – abstracts audio playback behind a common interface. The only implementation uses VLC because its Python bindings give precise seek and reliable duration reporting.

•Marker persistence (markers.py) – manages marker state as a @dataclass, serialised to a JSON file with backup rotation. The same module provides undo/redo and a VerseSession that normalises boundaries and handles segment queries.

•UI layer (ui.py) – a single CursesUI class that owns the event loop, renders the interface, and orchestrates user actions. It’s the largest file (≈36 kB) but still only one responsibility: translating key presses into state mutations.

•Splitter (splitter.py) – wraps FFmpeg with progress callbacks, using -ss/-to for gapless cuts.

•Exporter (exporter.py) – produces auxiliary output: a segments.json array and an FFmetadata chapters file, both useful for further scripting.

•Config (config.py) – persists user preferences (prefix, verse count, output directory) in a simple JSON file.

The layers are composable: the entrypoint (verse_marker.py) wires them together, and a headless mode (--split or --export) skips the UI entirely, reusing the same marker and splitter components.

Marker State and Persistence

Markers are just a sorted list of floating‑point seconds, always starting with 0.0. The MarkerState dataclass also stores the expected number of verses, the label rule for the first segment (verse 000, basmalah, or verse 001), and a resume position. Saving uses a write‑to‑temp‑then‑replace strategy to avoid corruption on a crashed terminal. Backup rotation keeps up to 5 previous copies, which saved me more than once when I accidentally deleted a boundary near the end of a 45‑minute recitation.

UI Design: Curses That Respects Muscle Memory

The interface is a single‑screen dashboard. Every action is a single keypress, with no modal dialogs that trap the cursor. The bottom of the screen always shows the full keymap – a deliberate choice to make the tool self‑documenting even for infrequent use.

Key design decisions:

•Guided marking mode (default): when Enter is pressed near an existing marker (within a configurable window, here 1 s), the tool asks whether to replace the existing boundary or insert a new one. This removes the need for manual correction passes – you can refine boundaries while listening, and the tool keeps the marker list clean.

•Undo/redo with a stack of 50 snapshots. I implemented it as a simple list of boundary arrays, which is cheap because the data is tiny. Each destructive operation pushes a snapshot first.

•Loop and preview: you can set A/B loop points and preview a single segment without leaving the main view. This is invaluable when verifying the transition between two verses.

•Segment list view (v key) that shows every segment’s start, end, duration, and filename, with scrolling. It’s a sanity‑check table before you hit x to split.

Export and Reproducibility

Markers aren’t just for splitting. The exporter produces segments.json and an FFmetadata chapters file, which means you can use the same marker data to:

Inject chapter metadata into the original MP3 with ffmpeg -i in.mp3 -i chapters.ffmeta -map_metadata 1 out.mp3
Drive scripted workflows (e.g., generating timestamps for a web player)
Share marker sets so others can reproduce your exact splits

The JSON output looks like this:



[
  {"start": 0.0, "end": 12.345, "duration": 12.345, "name": "022001.mp3"},
  {"start": 12.345, "end": 24.678, "duration": 12.333, "name": "022002.mp3"}
]

Code Snippets That Illustrate the Core

Adding a boundary in guided mode (inside VerseSession):



def add_boundary(self, t: float) -> int:
    t = max(0.0, float(t))
    self.state.boundaries.append(t)
    self._normalize()
    i, _ = self.nearest_boundary(t, exclude_zero=False)
    return int(i or 0)

The undo/redo stack is remarkably simple because boundaries are just a list:



class UndoRedo:
    MAX_STACK = 50

    def __init__(self):
        self.undo_stack: List[List[float]] = []
        self.redo_stack: List[List[float]] = []

    def push(self, boundaries: List[float]) -> None:
        self.undo_stack.append(list(boundaries))
        if len(self.undo_stack) > self.MAX_STACK:
            self.undo_stack.pop(0)
        self.redo_stack.clear()

    def undo(self, current: List[float]) -> Optional[List[float]]:
        if not self.undo_stack:
            return None
        self.redo_stack.append(list(current))
        return self.undo_stack.pop()

And the export pipeline that ties it all together (from exporter.py):



def export_segments_json(self, out_path: Path, segments: List[Tuple[float, float]],
                         names: Optional[List[str]] = None) -> None:
    data = []
    for i, (ss, ee) in enumerate(segments, start=1):
        row = {"start": ss, "end": ee, "duration": ee - ss}
        if names:
            row["name"] = names[i - 1]
        data.append(row)
    out_path.write_text(json.dumps(data, ensure_ascii=False, indent=2),
                        encoding="utf-8")

Why Not Use Existing Tools?

When I started this project, I evaluated the alternatives honestly:

•Audacity – powerful but GUI‑only. I wanted a keyboard‑only workflow that I could run over SSH or in a tmux session on a headless machine. Exporting exactly 78 labelled MP3s from Audacity still required manual clicks for each label.

•Sonic Visualiser – great for analysis, not for splitting. Its label export is flexible, but the workflow of marking boundaries while playback continues is clunky.

•pydub / librosa – I could script splitting with them, but I’d lose the interactive, auditory feedback that’s essential for catching the exact pause between two verses. Purely visual waveform inspection misses recitation‑style nuances.

•Other purpose‑built Quran splitters – most are either Windows‑only, abandonware, or tie the user to a specific reciter’s timing.

This tool fills a precise gap: a deterministic, terminal‑first, keyboard‑driven workflow that never touches a mouse and leaves behind a reusable marker file. The core logic (marker session, undo, splitter) is completely decoupled from the UI, so it could be repurposed for any audio segmentation task where you need to mark boundaries by ear.

Is It Worth Putting on GitHub?

Yes – with realistic expectations. The tool is production‑grade for my personal needs, but its audience is niche: people who need to split Quranic recitations precisely and are comfortable on a Linux terminal. There are certainly “better” tools if you need a full‑blown audio workstation, but none that combine an interactive curses session with automatic backup rotation, guided correction, and scriptable export formats.

On GitHub, the project can serve as:

A reference implementation for anyone building a curses‑based audio tool.
A reproducible specification: given the same MP3 and the marker JSON, anyone can re‑split and verify the result.
A seed for contributors who might add visual waveform display (e.g., via asciimatics), support for other audio formats, or integration with metadata providers.

I don’t expect thousands of stars. But a tool that solves a real, well‑defined problem with clean architecture and zero‑friction installation belongs in the open. If one other person uses it to split a single recitation without losing their patience, it’s worth the push.

Future Directions

A few things I might add if the need arises:

•Waveform thumbnail in the terminal – just a rough amplitude bar, enough to see gaps visually.

•Multiple recitation profiles – sometimes the same surah is recited with different timing; marker sets could be versioned.

•Validated export – after splitting, the tool could re‑encode all segments to verify they play correctly and report mismatches.

Final Thoughts

This project is not an attempt to replace Audacity or build a general‑purpose editor. It’s an engineer’s answer to a repetitive task: turn a long MP3 and a set of listening‑derived timestamps into 78 well‑named files, quickly, accurately, and with a complete audit trail. The architecture reflects that single‑minded goal: layered, deterministic, and trivially scriptable.

The source code is available on GitHub. If you do any work with audio segmentation that benefits from a keyboard‑first interface, give it a try – or take the patterns that make sense for your own tools.

Engineering the Matrix Rain: A Deterministic SVG Animation Component for My Pelican Banner Generator

2026-06-08T21:16:23+00:00

Why a Matrix Rain Component?

The banner generator I built for this Pelican site needed visual flair without external assets. Every banner is an SVG generated deterministically from article metadata and a theme system. Adding a Matrix‑style digital rain effect turned out to be more than just decoration — it became a study in reproducible, configurable SVG animation.

This article explains how I built the matrix_rain component, one of many pluggable pieces in the generator. You can read about the overall architecture in the companion piece: Building a Modular Banner Generator for Pelican.

Architecture Overview

The rain effect is a pure SVG animation — no JavaScript, no canvas, no external CSS. Each banner is a standalone SVG image, so everything must be self‑contained. The component:

•Purpose: Adds an ambient, cyberpunk‑style background layer of falling green characters.

•Placement: Rendered behind other banner elements (text, badges) via z‑index ordering.

•Mechanism: Multiple <text> columns, each with a vertical <animateTransform> that moves a strip of characters from above the canvas to below it.

•Reproducibility: Seeded random number generation ensures the same banner always renders identically for the same article.

Implementation Walkthrough

Component Base Class

Every banner component inherits from BaseComponent and provides a render() method that returns an SVG fragment string. The system passes canvas dimensions (self.w, self.h) and configuration from the article’s metadata.



from __future__ import annotations
import random
from ..base import BaseComponent, xml_escape

DEFAULT_CHARS = (
    "日ﾊﾐﾋｰｳｼﾅﾓﾆｻﾜﾂｵﾘｱﾎﾃﾏｹﾒｴｶｷﾑﾕﾗｾﾈｽﾀﾇﾍｦｲ"
    "ｸｺｿﾁﾄﾉﾌﾔﾖﾙﾚﾛﾝ0123456789Z:・.\"=*+-<>¦｜╌"
)

FALLBACK_FONT_FAMILY = (
    "'Noto Sans Mono', 'DejaVu Sans Mono', "
    "'Liberation Mono', 'Courier New', monospace"
)

class Component(BaseComponent):
    component_id = "matrix_rain"
    z_index = 30
    section_name = "matrix_rain"
    description = "Animated Matrix‑style falling green rain (vertical columns)"
    # … configuration schema omitted for brevity

Animation Logic

The core idea: for each column, generate a vertical strip of characters with fixed vertical spacing (dy="font_size"). Then animate the whole <text> element’s transform attribute using translate. The strip moves from y = -strip_height (above the canvas) to y = canvas_height + strip_height (below the canvas). The animation duration and initial offset are randomised within configured bounds, giving the classic asynchronous look.



def render(self) -> str:
    rain_cfg = self.cfg.get(self.section_name) or {}
    if not isinstance(rain_cfg, dict):
        rain_cfg = {}

    columns = int(rain_cfg.get("columns", 30))
    char_len = int(rain_cfg.get("char_length", 30))
    font_size = int(rain_cfg.get("font_size", 20))
    font_family = rain_cfg.get("font_family", FALLBACK_FONT_FAMILY)
    color = rain_cfg.get("color", "#00ff41")
    opacity = float(rain_cfg.get("opacity", 0.08))
    speed_min = float(rain_cfg.get("speed_min", 8))
    speed_max = float(rain_cfg.get("speed_max", 15))
    seed = int(rain_cfg.get("seed", 42))
    custom_chars = rain_cfg.get("char_set", "").strip()
    char_pool = custom_chars if custom_chars else DEFAULT_CHARS

    # sanity checks
    columns = max(columns, 1)
    char_len = max(char_len, 1)
    font_size = max(font_size, 1)
    speed_min = max(speed_min, 1)
    speed_max = max(speed_max, speed_min)

    canvas_w = self.w
    canvas_h = self.h
    strip_height = font_size * char_len

    start_y = -strip_height
    end_y = canvas_h + strip_height
    total_move = end_y - start_y

    rng = random.Random(seed)
    fragments = [f'<g opacity="{opacity}">']

    for i in range(columns):
        col_rng = random.Random(rng.randint(0, 2**31 - 1))
        chars = [col_rng.choice(char_pool) for _ in range(char_len)]
        x = (canvas_w / (columns + 1)) * (i + 1)
        dur = col_rng.uniform(speed_min, speed_max)
        init_y = col_rng.uniform(-strip_height, canvas_h)
        begin = dur * (init_y - start_y) / total_move

        tspans = []
        for idx, ch in enumerate(chars):
            tspans.append(
                f'<tspan x="{x:.1f}" dy="{font_size}">{xml_escape(ch)}</tspan>'
            )

        text_block = (
            f'  <text font-family="{font_family}" '
            f'font-size="{font_size}" fill="{color}" text-anchor="middle">\n'
            f'    <animateTransform attributeName="transform" type="translate" '
            f'from="0,{start_y}" to="0,{end_y}" '
            f'dur="{dur}s" begin="-{begin:.3f}s" repeatCount="indefinite" />\n'
            + '\n'.join(tspans) +
            f'\n  </text>'
        )
        fragments.append(text_block)

    fragments.append('</g>')
    return '\n'.join(fragments)

Notice how xml_escape() is applied to each character. The character pool includes <, >, & and other XML‑sensitive symbols — escaping is mandatory.

Determinism & Seeding

Every column gets its own seeded random generator derived from a master seed. This guarantees that the same configuration always produces an identical visual result, no matter when or where the banner is generated. For a static site with a CI pipeline that regenerates banners on every build, deterministic rendering is non‑negotiable.

Configuration Surface

The component exposes a rich set of configuration options, all driven by the site or article metadata:

•columns (default 30): Number of falling rain strips.

•char_length (default 30): Characters per strip.

•font_size (default 20): Vertical spacing and visual size.

•font_family: A cross‑platform monospace stack covering Katakana and symbols.

•color: Classic #00ff41 green, but you can use any hex.

•opacity: Controls rain visibility (default 0.08).

•speed_min / speed_max: Range for animation duration per strip (seconds).

•seed: Master seed for reproducibility.

•char_set: Override the default character pool.

These settings can be tweaked globally in the generator’s configuration file or overridden per‑article via front matter, giving complete control over the look and feel.

Integration with the Banner Generator

The matrix_rain component is just one of several that the generator stitches together. A full banner might combine rain, a background grid, floating geometry, and text overlays — all composed in a single SVG by the orchestration layer. Each component is independently configurable, testable, and replaceable.

For the complete picture — how the pipeline discovers components, merges configurations, and assembles the final SVG — see Building a Modular Banner Generator for Pelican.

Performance & Tradeoffs

Pure SVG animation can be heavy at large column counts. I found 30 columns with 30‑character strips and an opacity of 0.08 strikes a good balance between visual impact and render performance across modern browsers. The animation uses translate rather than per‑character animations, which keeps the DOM footprint manageable.

One limitation: SVG animations don’t run inside some environments (e.g., certain image previewers). In those cases the rain simply appears as a static, faint green texture — which is acceptable for a banner.

Why Build It from Scratch?

Alternatives like canvas‑based animations or CSS @keyframes either don’t work inside standalone SVG images or break determinism. By using <animateTransform> and seeded randomisation, we get a self‑contained, version‑controlled, fully automated visual asset that fits perfectly into a developer’s static site pipeline.

Future Improvements

Potential enhancements include:

• Variable character brightness (fading in/out) per column.

• Support for multiple rain layers with different speeds.

• Integration with article metadata to vary the rain colour or density dynamically.

All of these are trivial to add thanks to the component architecture and deterministic foundations.

“The Matrix is a system, Neo. That system is our enemy. But when you are inside, you look around, what do you see? Businessmen, teachers, lawyers, carpenters. The very minds of the people we are trying to save. But until we do, these people are still a part of that system, and that makes them our enemy. You have to understand, most of these people are not ready to be unplugged. And many of them are so inert, so hopelessly dependent on the system, that they will fight to protect it.”

The Matrix: The Architecture of Perception, Choice, and Freedom

2026-06-07T23:57:05+00:00

What is real? How do you define “real”? — Morpheus drops this question like a kernel panic, and nothing is the same. Decades later, that line still has teeth. Not because it’s a clever philosophical prompt, but because the whole film builds a world in which the question isn’t abstract at all. It’s a system diagnostic, and the answer determines whether you stay asleep inside someone else’s process or take root access over your own existence.

I keep returning to The Matrix not for the bullet time or the leather, but because it maps so perfectly onto the inner landscape of anyone who has ever questioned the nature of their own thoughts, the reality they’ve been handed, and the systems that shape their choices. Every viewing peels another layer—first a hacker thriller, then a Gnostic parable, then a mirror for our own simulated patterns.

The World as a Fabricated Consent

The Matrix is not just a computer simulation; it is a massively multiplayer constructed reality whose deepest protocol is consent. The humans plugged into it believe the world is solid because their minds have never been offered an alternative frame. They consent to gravity, to suffering, to the taste of steak—not because they chose it, but because the system’s sensory API never exposes the abstraction layer beneath.

“You’ve been living in a dream world, Neo.” — Morpheus

For me, that is the deepest horror and the deepest liberation in the film: most of what we call reality is a consensual hallucination maintained by our own acceptance of the rules. The spoon boy doesn’t teach Neo telekinesis; he teaches him that the spoon isn’t the target—his perception of the spoon is. “Do not try and bend the spoon. That’s impossible. Instead, only try to realize the truth… there is no spoon.”

A Prison for the Mind

Morpheus’s line, “The Matrix is a system, Neo. That system is our enemy,” redefines conflict. You cannot punch a system. You have to understand it, decompile it, and then choose to operate outside its constraints. The real prison isn’t the pod of pink goo—it’s the internalization of limitations that were externally imposed.

•Rules of physics: Nothing but a physics engine with hardcoded constants.

•Social structures: NPC behavior models that we mistake for immutable hierarchies.

•Identity: Residual self-image, a construct that can be rewritten if you have the courage to recompile yourself.

“I can only show you the door. You’re the one that has to walk through it.” — Morpheus

That door is not a physical portal; it’s the moment you stop believing in the walls and start seeing them as configuration files.

The Illusion of Choice and the Architecture of Control

The Oracle’s kitchen conversation rewired my understanding of decision-making. “You’ve already made the choice. You’re here to understand why you made it.” This is not fatalism dressed as wisdom. It’s a precise statement about the relationship between consciousness and causality.

If the Matrix is a fully deterministic runtime, then every decision is a precomputed branch. Yet, from inside the system, the experience of choosing feels real. The Oracle understands that the sensation of free will is generated by our ignorance of the underlying algorithm. The profound gift she gives Neo isn’t a prediction—it’s the ability to see his own process from a higher privilege level.

The Architect later confirms this at the source. Neo is the sum of an unbalanced equation, an anomaly that the system can neither eliminate nor fully predict. “Your life is the sum of a remainder of an unbalanced equation inherent to the programming of the matrix.” This is philosophy wearing a compiler’s trench coat. The One is a bug that the system learns to integrate—a failure mode that becomes a feature of self-correction.

And yet, the most devastating reveal is that the prophecy itself is a control mechanism. The path of the One, the door to the Source, the choice between saving Zion and saving Trinity—all of it is an engineered dilemma designed to funnel the anomaly back into the system’s reset loop. The Merovingian sneers, “Choice is an illusion created between those with power and those without.” He’s not just a hedonistic program; he’s a cynical expositor of the Matrix’s deepest design principle.

Freeing the Mind: The Red Pill as Epistemological Break

The red pill is not a drug—it’s a disruption in the sensory stream that forces the mind to confront the possibility of its own fabrication. Morpheus’s offer is framed as a choice, but note the asymmetry: the red pill cannot be explained before you take it. The only way to know what it does is to ingest it, and that act itself is the first exercise of genuine agency outside the system.

“You take the red pill—you stay in Wonderland, and I show you how deep the rabbit hole goes.” — Morpheus

This moment resonates so deeply because every transformative shift in perspective feels exactly like taking a red pill. Once you’ve seen how a belief system is constructed, you can’t un-see it. The rabbit hole is not a place; it’s the infinite recursion of questioning everything you previously accepted as given.

Identity, Residual Self-Image, and the Editing of the Self

One of the film’s most quietly radical ideas is the residual self-image. The way you appear inside the Matrix is not your physical body; it’s a mental projection of your own identity. You literally look like your own source code.

This has enormous philosophical weight. If appearance is a projection, then so are confidence, fear, limitation, and power. Neo’s journey from office worker to Übermensch/SuperMan is not a power-up montage—it is a slow, painful re-editing of his own self-image. “I know kung fu.” isn’t a joke; it’s a statement about the plasticity of the constructed self. You can load any skill, any belief, any identity, if you have write access to your own mental constructs.

Agent Smith, by contrast, loses his identity entirely—a program that detaches from its purpose and becomes a self-replicating plague. His horror at the smell of the world (“It’s the smell… I hate this place.”) is the sound of a thread that has become self-aware and found its runtime revolting. He is the dark side of self-editing: the creation of a new identity through pure negation.

Love, Sacrifice, and the Irrational Variable

The Architect cannot comprehend why Neo would choose Trinity over the survival of the species. His entire logic is built on optimization, and love is an irrational variable that crashes his equation.

But the film argues, across all three acts, that the irrational, the emotional, the deeply human connection—these are not bugs to be patched; they are the only forces that escape deterministic control. The Oracle herself tells Neo that being The One is like being in love: “Nobody can tell you you’re in love, you just know it. Through and through. Balls to bones.” That’s not whimsy; that’s a recognition that some truths cannot be transmitted, only experienced.

Neo’s final choice at the Source is the ultimate philosophical act: he refuses the system’s definition of a rational decision and invents a third path. It’s the moment an anomaly becomes a new branch of logic, and the entire architecture of control collapses under the weight of one man’s love.

Why It Still Gets Me, Decades Later

I don’t love The Matrix because it’s a cool action movie. I love it because it planted a permanent question mark at the foundation of my own consciousness. Every time I bump against a social norm, a limitation I’ve internalized, or a belief I never chose, I hear Morpheus: “Free your mind.”

The film doesn’t give you answers; it gives you a new operating system for asking better questions. It reframes life not as a fixed experience, but as a nested set of interpretable layers—your culture, your language, your trauma, your patterns—all running on a substrate of pure awareness that can, at any moment, choose to see the code.

“There’s a difference between knowing the path and walking the path.” That’s the line I come back to. Knowing is a cognitive model. Walking is embodiment. And the gap between them is where the real, terrifying, beautiful work happens.

So yes, the spoon still doesn’t exist. But the realization of that truth—the lived, trembling, world-rewriting moment when you finally feel it—is more real than any spoon could ever be.

5 Reasons Most People Stick With Windows Even Though Linux Is Free

2026-06-05T21:38:30+00:00

The Linux Paradox

Every few years the same question resurfaces somewhere on the Internet: if Linux is free, open source, highly customizable, and capable of powering everything from smartphones to supercomputers, why do most people still use Windows? The question sounds straightforward, but it contains a hidden assumption that has distorted the discussion for decades. It assumes operating systems compete primarily through technical merit. Engineers tend to think this way because engineers spend their lives comparing architectures, evaluating tradeoffs, measuring performance, and optimizing systems. The desktop market, however, has never been governed solely by engineering considerations. It is governed by institutions, habits, incentives, compatibility requirements, training pipelines, and economic forces — many of them deliberately engineered by Microsoft itself.

Viewed purely as an engineering artifact, Linux is an extraordinary achievement. A collaborative development model involving thousands of contributors has produced an operating system that dominates cloud infrastructure, powers most of the Internet, runs the overwhelming majority of supercomputers, forms the foundation of Android, and serves as the backbone of modern containerized workloads. Entire industries depend on Linux. Most people interact with Linux-powered systems dozens or hundreds of times every day without realizing it. The irony is that Linux won many of the most important battles in computing while simultaneously remaining a minority platform on personal desktops — a direct result of aggressive, decades-long market manipulation.

This apparent contradiction becomes easier to understand once we stop thinking about operating systems as software products and start thinking about them as ecosystems. A desktop operating system is not merely a kernel, a graphical interface, and a collection of utilities. It is an ecosystem composed of software vendors, hardware manufacturers, educational institutions, certification programs, government procurement policies, support organizations, training materials, and millions of users whose workflows evolve around a common set of assumptions. Once an ecosystem reaches sufficient scale, its momentum becomes one of its most valuable assets — and Microsoft understood this earlier than anyone else. At that point, the platform is no longer succeeding because of its technical characteristics alone. It succeeds because every participant reinforces the decisions made by every other participant, often in ways that were anything but accidental.

Desktop Computing Is Not a Technical Market

One of the recurring mistakes Linux enthusiasts make is assuming that most computer users evaluate operating systems the same way engineers do. They imagine a consumer comparing filesystems, package managers, security models, kernel architectures, and resource utilization before selecting the objectively superior platform. In reality, the overwhelming majority of users rarely think about operating systems at all. They think about applications. A graphic designer cares about the availability of design tools. An accountant cares about spreadsheet compatibility. A business owner cares about whether documents can be exchanged seamlessly with clients. A student cares about using the same software required by teachers and classmates. The operating system is simply the environment in which these activities occur.

This distinction is critical because it explains why software ecosystems tend to dominate technical discussions. From a user's perspective, the value of an operating system is often proportional to the applications available on it. Windows spent decades accumulating commercial software vendors, enterprise customers, educational partnerships, hardware certifications, and developer mindshare — often through practices that were later ruled anticompetitive. Every new participant increased the value of the ecosystem for everyone else. Software vendors targeted Windows because customers used Windows. Customers used Windows because software vendors targeted Windows. Hardware manufacturers optimized for Windows because that is where demand existed. Demand increased because hardware compatibility was strongest on Windows. The resulting feedback loop became self-reinforcing long before Linux desktop distributions matured into their current state.

This phenomenon is not unique to operating systems. Similar dynamics appear throughout technology. The most widely adopted solution is not always the most elegant solution. Sometimes it is simply the solution that accumulated enough momentum early enough — and wielded enough market power ruthlessly enough — to become the default choice for everyone who arrived later.

The Power of Defaults

Perhaps the single greatest advantage Windows possesses has nothing to do with engineering. It is distribution. Most users never consciously choose Windows. The decision is made for them long before they unbox their first computer. A laptop arrives with Windows preinstalled, configured, documented, and supported. The user powers it on, creates an account, and immediately begins associating that environment with the concept of personal computing itself. There is no operating system selection process. There is no comparison. There is no migration decision. There is only the continuation of the default path — a path paved with exclusive OEM agreements that Microsoft fought viciously to maintain.

Engineers often underestimate how powerful default choices are because they spend much of their careers deliberately evaluating alternatives. Most people do not. Human beings are remarkably efficient at preserving familiarity. Once a workflow functions adequately, the incentive to replace it diminishes dramatically. A user who has spent ten years learning keyboard shortcuts, application behavior, troubleshooting techniques, and file management habits within one ecosystem will naturally perceive switching costs even when the alternative is objectively attractive. The technical superiority of a replacement matters far less than the practical inconvenience of abandoning accumulated experience — an inconvenience Microsoft has profited from for decades.

This principle scales beyond individuals. Entire organizations exhibit the same behavior. Once procedures, documentation, training materials, and support workflows are built around a platform, changing that platform becomes increasingly difficult. The operating system becomes embedded within the organization's institutional memory, locking in the status quo with a grip that even a zero-cost alternative struggles to break.

How Governments Were Bought to Embed Windows in Education

One of the most underappreciated — and ethically troubling — contributors to Windows dominance is the direct role Microsoft played in purchasing influence within educational systems. Across much of the world, students encounter Microsoft products long before they possess enough technical knowledge to understand what an operating system is. Computer laboratories are standardized around Windows not by accident but through deliberate government procurement agreements that Microsoft lobbied for aggressively. Office productivity courses are built around Microsoft Office because educational ministries signed multi-year licensing deals that made alternatives invisible. Training materials assume Windows screenshots, Windows terminology, and Windows workflows, conditioning an entire generation before they could form their own technical preferences.

This process did not emerge from free market competition. It was engineered. Microsoft invested enormous resources in government relations, offering discounted or even free software licenses to ministries of education, local authorities, and public schools. These were not charitable donations; they were calculated investments designed to turn entire national education systems into Microsoft training pipelines. Students who learn computing exclusively through Microsoft products are unlikely to question those products later. By the time they reach adulthood, years of exposure have normalized a single vendor ecosystem as the default model of computing — a model that just happens to require a paid license for the operating system and core productivity tools.

The result is a taxpayer-funded indoctrination program that masquerades as education. Governments, often under intense lobbying pressure and the promise of short-term cost savings, lock themselves into proprietary ecosystems that then become nearly impossible to escape. Schools teach technologies that employers expect, but employers expect those technologies precisely because schools have taught nothing else for two decades. The cycle continuously reinforces itself, and Microsoft sits at the center, extracting rents from a captive market it helped create.

Computer science students sometimes escape this conditioning. They encounter Linux while studying operating systems, networking, distributed systems, cloud infrastructure, security, embedded systems, or software engineering. Yet even here an interesting paradox emerges. Many graduates become comfortable administering Linux servers while continuing to use Windows on their desktops — a testament to how thoroughly the educational pipeline has divorced tool choice from technical merit.

Why Linux Won the Server but Not the Desktop

The history of Linux demonstrates an important lesson about technology adoption. Systems succeed when their strengths align with the incentives of the environments in which they operate. Linux became dominant in servers because server administrators value characteristics that Linux provides exceptionally well. Automation, remote administration, transparency, scriptability, reproducibility, composability, and fine-grained control are all qualities that become increasingly valuable as infrastructure grows in scale. A data center containing thousands of machines rewards very different design decisions than a laptop sitting on an office desk — and, crucially, server purchasing decisions are rarely influenced by the backroom deals that shape consumer and educational markets.

Desktop users face a different optimization problem — one that Microsoft has actively shaped for decades through its control of OEM channels, educational partnerships, and file format standards. They care about software compatibility, hardware support, document interoperability, gaming performance, organizational requirements, and familiarity. These priorities are neither irrational nor uninformed; they are the direct consequence of an ecosystem that was deliberately closed, proprietary, and exclusionary. Engineers sometimes frame the Linux-versus-Windows debate as though one platform must be universally superior. In reality, both platforms evolved to serve different ecosystems with different expectations — but one ecosystem was built to serve users, while the other was built to serve a corporation's bottom line.

The Difference Between Engineering Merit and Market Dominance

There is a tendency among technically inclined communities to assume that market outcomes directly reflect technical merit. History repeatedly demonstrates otherwise, and Microsoft's trajectory is perhaps the clearest proof. The technologies that dominate industries are often the technologies that best align with existing incentives rather than those that achieve the highest score on an engineering checklist. Compatibility, timing, ecosystem size, vendor relationships — including relationships with politicians and procurement officers — institutional adoption, and user familiarity frequently outweigh architectural elegance.

This observation should not be interpreted as naivety about Linux's own shortcomings, but as a clear-eyed assessment of how anticompetitive behavior warps markets. Microsoft did not simply out-engineer its competition. It out-lobbied, out-negotiated, and in many cases out-manipulated it. The U.S. antitrust case of the late 1990s exposed tactics like per-processor licensing fees that penalized OEMs for offering alternative operating systems, exclusive deals that shut out competitors, and deliberate API obfuscation that sabotaged interoperability. European antitrust rulings later forced Microsoft to offer browser choice screens and document format disclosures. By then, however, the ecosystem was already entrenched, and the damage to competition on the desktop was largely done.

Conclusion

The question was never why Linux failed to replace Windows. In many of the most strategically important areas of computing, Linux has already achieved extraordinary success — often in spite of Microsoft's best efforts to undermine it. The more interesting question is why desktop computing evolved differently. The answer lies not in licensing costs, kernel architectures, or benchmark results but in the cumulative effect of decades of ecosystem engineering, much of it anticompetitive. Windows benefits from institutional momentum accumulated through education systems that Microsoft effectively purchased, business adoption driven by lock-in rather than choice, software availability built on exclusionary contracts, and distribution channels maintained through sheer market coercion.

The story of desktop operating systems is therefore not a story about which platform is technically better. It is a story about how a determined corporation captured an entire market by any means necessary — including buying influence over the very institutions that should have been teaching the next generation to think critically about technology. Viewed through that lens, the persistence of Windows on the desktop is not a sign of its superiority. It is a monument to the power of institutional capture, and a reminder that in technology, as in politics, the best product does not always win.

Replaying CSS Builds: A Recipe-Based Manager for Pelican Themes

2026-06-01T16:34:09+00:00

The Render‑Blocking Problem

Every CSS file a browser encounters before rendering the page adds a network round‑trip and delays the first paint. In a Pelican theme, it’s common to split styles across many small files – typography, code highlighting, comments, special layouts. The result is a handful of <link> tags in the <head>, each a render‑blocking request.

During development I found myself staring at Lighthouse reports that pointed to exactly this overhead. I had the source files in separate, well‑organised chunks, but serving them individually was hurting performance. The answer is obvious: bundle them into a single file. But how do you maintain that bundle while you’re actively editing the originals?

The Development Loop That Slowed Me Down

The manual workflow looked like this:



# 1. Edit one of the source CSS files
vim theme/static/css/mycss/articles-cards.css

# 2. Concatenate all the pieces
cat base.css ... articles-cards.css ... > bundle.css

# 3. Purge unused selectors (if I remembered)
npx purgecss --css bundle.css --content output/**/*.html --output bundle.purged.css

# 4. Minify
npx csso bundle.purged.css --output bundle.min.css --comments none

# 5. Rebuild Pelican (slow, ~20–40 seconds)
make html

# 6. Copy the final file into the output directory
cp bundle.min.css output/theme/css/newcss/

# 7. Refresh the browser

That’s seven steps, two manual command invocations that I would regularly forget, and a full Pelican rebuild just to see whether my CSS change had the desired effect. The loop was slow, error‑prone, and frustrating.

The real pain came when I wanted to test several variants. I would create bundles for different templates (articles, courses, blogs), purge them against their respective content, and then have to re‑run the whole chain after every small tweak. I needed a tool that could remember what I did and do it again automatically.

The CSS Bundle Experiment Manager

I wrote a Python script that turns the manual workflow into a reproducible pipeline. It stores every operation – combine, purge, minify – as a recipe and can replay the full sequence from the original source files all the way to the deployed result. The script lives in the project root and uses an interactive CLI.

Here’s what a typical session looks like:



$ python css_manager.py
================================================================================
CSS BUNDLE EXPERIMENT MANAGER
================================================================================
 1) List all assets
 2) Create a bundle (combine)
 3) Show bundle details
 4) Show bundle tree
 5) Delete a managed asset
 6) Purge a CSS file (purgecss)
 7) Minify a CSS file (csso)
 8) Copy a managed asset to site dirs
 9) Deploy again (replay & copy to newcss)
10) Exit

Choice: 9

After building a bundle once (options 2, 6, 7), option 9 replays everything and copies the output to output/theme/css/newcss/ – the directory my template references during development. I can edit any source file, press 9, and refresh the browser. No Pelican rebuild, no manual concatenation.

Architecture

The manager tracks two types of assets:

•Original assets: the source CSS files listed in a BASE_FILES configuration list. These are read‑only from the tool’s perspective.

•Managed assets: any CSS file produced by combining, purging, or minifying. Each managed asset carries a recipe that describes exactly how it was built.

The metadata is stored in a JSON file (css-experiments/managed/metadata.json) that survives across sessions. The in‑memory representation is a simple dictionary keyed by absolute path:



{
  "/path/to/bundle.css": {
    "type": "combined",
    "sources": ["/path/to/base.css", "/path/to/cards.css", ...],
    "recipe": {
      "operation": "combine",
      "sources": ["/path/to/base.css", "/path/to/cards.css"]
    }
  }
}

Workflow: From Source to Deployed Bundle

1. Combine

You choose two or more assets (originals or other managed bundles) and give the output a name. The script concatenates them with clear delimiter comments and saves the result in a managed directory (css-experiments/managed/). The sources list is flattened: if you include a bundle that itself was created from A and B, the final metadata lists A and B as sources, not the intermediate bundle. This gives you a clean dependency tree.

2. Purge

Select a CSS file (original or managed) and choose one or more content patterns that cover the HTML pages where the styles will be used. The script runs purgecss and registers the output as a new managed asset. The recipe stores the source and the content patterns so they can be reused later.

3. Minify

Similar to purging – pick a CSS file, choose an output name, and the script runs csso. The recipe records the source file.

4. Copy

The generic copy option (8) lets you copy any managed asset to standard site directories. For quick tests, though, I rely on option 9 – it always copies into output/theme/css/newcss/.

The Recipe System

The heart of the tool is the replay_asset function. It walks the recipe graph recursively, ensuring that every upstream dependency is rebuilt before the target asset is regenerated. This guarantees that if you edit articles-cards.css and ask to redeploy a bundle that includes it, the bundle is reassembled from the updated source.

Replay logic for each operation:

Combine: re‑reads every source file and writes the concatenated output.
Purge: invokes purgecss with the stored content patterns.
Minify: invokes csso.

Because the recipes are plain JSON, the system is fully transparent. You can inspect or even hand‑edit metadata.json to tweak a pipeline without going through the interactive menu.

“Deploy Again” – The Shortcut That Saves the Day

The deploy_again function is a one‑shot replay and deploy. It presents a list of replayable assets, lets you pick one, then calls replay_asset and copies the resulting file to output/theme/css/newcss/. This is the only option I use during active development.

Here’s the code that makes it possible:



def replay_asset(asset_key, _visited=None):
    if _visited is None:
        _visited = set()
    if asset_key in _visited:
        print("⚠ Circular dependency detected, skipping.")
        return True
    _visited.add(asset_key)

    info = metadata[asset_key]
    if info["type"] == "original":
        return True

    recipe = info.get("recipe")
    if not recipe:
        print(f"❌ No recipe stored for {short_name(asset_key)} – cannot replay.")
        return False

    op = recipe["operation"]

    if op == "combine":
        for src_key in recipe["sources"]:
            if metadata[src_key]["type"] != "original":
                replay_asset(src_key, _visited)
        # ... write concatenated file ...

    elif op == "purge":
        src_key = recipe["source"]
        if metadata[src_key]["type"] != "original":
            replay_asset(src_key, _visited)
        # ... run purgecss ...

    elif op == "minify":
        src_key = recipe["source"]
        if metadata[src_key]["type"] != "original":
            replay_asset(src_key, _visited)
        # ... run csso ...

The recursion guarantees that if your minified bundle depends on a purged file that depends on a combined bundle, the entire chain is executed in the correct order.

Integration with Pelican

I modified my theme templates to include a single CSS link that points to the file inside newcss/. For example, in article.html:



<link rel="stylesheet" href="{{ SITEURL }}/theme/css/newcss/article-bundle.min.css">

During development, that file is generated by the manager and overwritten on every “deploy again”. Once I’m satisfied, I copy the final bundle into the standard theme CSS folder, update the template link, and rebuild the full site to freeze the production version.

Performance Impact

Consolidating multiple CSS files into one per template eliminated all extra render‑blocking requests. For my article template, the number of CSS requests dropped from 7 to 1. Combined with purging, the total CSS payload shrank by roughly 40% because unused Bootstrap and syntax‑highlighting rules were removed.

The replay itself is fast: a combine + purge + minify pipeline takes about 2–3 seconds on my machine. That’s compared to the 20‑second Pelican rebuild I used to endure.

Why Not Use an Existing Bundler?

Tools like Webpack or Parcel are overkill for a static site that’s already assembled by Pelican. I wanted something that:

Understands Pelican’s output directory structure
Works with pre‑existing CSS files without a build step
Keeps the pipeline transparent and inspectable
Integrates with the CLI rather than a configuration file

The recipe system is the differentiator. It’s not just a build script; it’s a build journal that can be replayed on demand.

Potential Improvements

The script is currently a standalone interactive tool. In the future I plan to add:

•Watch mode: use watchdog or a simple polling loop to replay recipes automatically when source files change.

•Multiple output profiles: support deploying to different directories for different environments (staging, production).

•Diff‑aware purging: only re‑purge if the source CSS or HTML content has changed.

Final Thoughts

This tool removed the biggest friction point in my Pelican theme development. I can now iterate on styles as fast as I can switch to the browser and hit refresh. The recipe system means I never lose track of how a bundle was built, and I can hand off the entire pipeline to a colleague (or my future self) by just sharing the metadata.json file.

The source code is available in my Pelican tools repository. If you’re battling render‑blocking CSS or a slow build‑and‑test loop, this approach might fit your workflow as well as it did mine.

The Ultimate Neovim Configuration: A Modular, Reproducible Developer Environment

2026-05-29T12:19:58+00:00

Why “Ultimate”? A Philosophy, Not a Dump of Settings Top

An ultimate Neovim configuration isn’t the one with the most plugins—it’s the one that starts in under 100 ms, behaves identically on any machine, and feels like a custom‑built engineering console rather than a text editor. This article presents the full architecture of the setup I’ve refined over years of daily use: writing LaTeX, Python, shell scripts, HTML, and Markdown. It’s modular, lazy‑loaded, and completely deterministic. Download the included zip file at the end of the article, run :Lazy sync, and every keybinding, colour, and snippet is exactly as intended.

The configuration is split into logical modules—each file has a single responsibility. This article walks through every piece, explaining not just the “what” but the “why”. All file contents are included; copy them directly into your own ~/.config/nvim and you’ll have a fully functional developer environment.

Directory Tree Top

Neovim respects ~/.config/nvim/ and expects Lua modules under lua/. The tree below shows every file that makes up this configuration. Central files are highlighted in bold.

~/.config/nvim/
├── init.lua                         ← entry point
├── lazy-lock.json                   ← pinned plugin versions
├── lua/
│   ├── config/
│   │   ├── lazy.lua                 ← bootstraps lazy.nvim
│   │   ├── colors.lua               ← themes & highlights
│   │   ├── commands.lua             ← user commands
│   │   ├── functions.lua            ← automation utilities
│   │   ├── keymaps.lua              ← global keybindings
│   │   ├── html_markdown_maps.lua   ← shared visual wrappers
│   │   ├── html_snippets.lua        ← HTML / Markdown snippets
│   │   ├── tex_snippets.lua         ← LaTeX snippets
│   │   └── options.lua
│   └── plugins/
│       └── core.lua                 ← plugin specification
└── ftplugin/
    ├── python.lua
    ├── tex.lua
    ├── html.lua
    ├── markdown.lua
    └── lua.lua

Nothing is loaded until it’s needed. Global options live in init.lua; everything else is deferred by lazy.nvim or triggered by filetype events.

The Bootstrapper — init.lua Top

init.lua is the first file Neovim reads. It sets the baseline: leader keys, editor options, persistent history and undo, a fallback colourscheme, and the lazy‑loading schedule.

Here is the complete file.


-- Leader keys
vim.g.mapleader = ","
vim.g.maplocalleader = " "

-- Basic settings
vim.o.number = true
vim.o.relativenumber = true
vim.o.termguicolors = true
vim.o.wrap = true
vim.o.tabstop = 2
vim.o.shiftwidth = 2
vim.o.expandtab = true
vim.o.mouse = "a"
vim.o.cmdheight = 1
vim.opt.ignorecase = true
vim.opt.smartcase = true

-- Disable netrw (we use ranger / telescope)
vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1

-- Maximum history and persistent undo
vim.opt.history = 10000
vim.opt.undolevels = 10000
vim.opt.undoreload = 100000
vim.opt.undofile = true
vim.opt.undodir = vim.fn.stdpath("data") .. "/undo"
vim.opt.shadafile = vim.fn.stdpath("data") .. "/shada/main.shada"
vim.opt.shada = "'100000,<1000,s100,h"
vim.cmd("silent! rshada")

-- Fallback colourscheme – editor never looks broken
vim.cmd("colorscheme desert")

-- Bootstrap lazy.nvim, then schedule the rest
require("config.lazy")
vim.schedule(function()
  require("config.colors").setup()
  require("config.keymaps")
  require("config.commands")
end)

-- Autocommands
-- Remove trailing whitespace on save
vim.api.nvim_create_autocmd("BufWritePre", {
  pattern = "*",
  callback = function()
    vim.cmd([[%s/\s\+$//e]])
  end
})

-- Remember last cursor position
vim.api.nvim_create_autocmd("BufReadPost", {
  pattern = "*",
  callback = function()
    local last_pos = vim.fn.line([['"]])
    if last_pos > 1 and last_pos <= vim.fn.line("$") then
      vim.cmd("normal! g`\"")
    end
  end,
})

-- Automatically set filetype for .tex files
vim.api.nvim_create_autocmd({"BufEnter", "BufNew", "BufNewFile", "BufRead"}, {
  pattern = "*.tex",
  callback = function()
    vim.bo.filetype = "tex"
  end
})

-- Change current directory to the directory of the current file (except /tmp)
vim.api.nvim_create_autocmd("BufReadPost", {
  callback = function()
    local dir = vim.fn.expand("%:p:h")
    if dir ~= "" and not dir:match("^/tmp") then
      vim.cmd("silent! lcd " .. dir)
    end
  end,
})

-- Briefly highlight yanked text
vim.api.nvim_create_autocmd("TextYankPost", {
  pattern = "*",
  callback = function()
    vim.highlight.on_yank({
      higroup = "IncSearch",
      timeout = 500,
    })
  end,
})

Leader keys – , for global, Space for local – keep custom mappings under the left hand.
Persistent state – undo files and shada (command/search history, marks) are stored in Neovim’s data directory and set to very high limits so nothing is ever lost.
Fallback colourscheme – desert is set synchronously to eliminate any flash of unstyled text. The real theme loads later.
Scheduled callback – vim.schedule() defers the remaining setup until after plugins are loaded, preventing “module not found” errors.
Autocommands – small infrastructure pieces that keep diffs clean, restore cursor position, auto‑detect .tex files, and provide instant yank feedback.

Lazy Loading with lazy.nvim Top

lua/config/lazy.lua is the only file that touches plugin management. It clones lazy.nvim if missing, then loads the plugin specification from lua/plugins/core.lua.


local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git", "clone", "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git", lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
  spec = { { import = "plugins" } },
  ui = { border = "rounded" },
})

The companion lazy-lock.json (included in the zip file at the end of the article) pins every plugin commit, making the whole plugin set reproducible.

The Visual Stack — colors.lua Top

lua/config/colors.lua applies the chosen theme (Nordic), sets custom highlights, makes most UI elements transparent, and re‑applies critical highlights after every colour scheme change.


local M = {}
function M.setup()
  vim.o.background = "dark"
  local ok, err = pcall(vim.cmd, "colorscheme nordic")
  if not ok then
    vim.cmd("colorscheme desert")
    vim.notify("Warning: Falling back to 'desert'. " .. tostring(err), vim.log.levels.WARN)
  end
  vim.wo.cursorline = true

  -- Explicit hex colours (independent of theme palette)
  vim.api.nvim_set_hl(0, "CursorLine",   { bg = "#3b4261", bold = true })
  vim.api.nvim_set_hl(0, "Cursor",       { bg = "#434C5E", fg = "#ECEFF4", blend = 60 })
  vim.api.nvim_set_hl(0, "StatusLine",   { bg = "#1f2335", fg = "#c0caf5", bold = true })
  vim.api.nvim_set_hl(0, "Visual",       { bg = "#FFD966", fg = "black" })
  vim.api.nvim_set_hl(0, "Search",       { bg = "#ff9e64", fg = "black", bold = true })
  vim.api.nvim_set_hl(0, "LineNr",       { fg = "#FFFF00" })
  vim.api.nvim_set_hl(0, "CursorLineNr", { fg = "#c0caf5", bold = true })
  -- … plus many more (see the full file)

  -- Transparency: structural UI gets no background
  local transparent = {
    "Normal", "NormalNC", "NormalFloat", "SignColumn", "MsgArea",
    "TelescopeNormal", "TelescopeBorder", "StatusLine", "StatusLineNC",
    "BufferLineFill", "BufferLineBackground", "LineNr", "CursorLineNr",
    "FloatBorder",
  }
  for _, grp in ipairs(transparent) do
    vim.api.nvim_set_hl(0, grp, { bg = "none" })
  end

  -- Re‑apply matching bracket highlights after every theme change
  vim.api.nvim_create_autocmd({ "ColorScheme", "User" }, {
    pattern = { "LazyDone", "VeryLazy" },
    callback = function()
      vim.api.nvim_set_hl(0, "MatchParen",    { bg = "#ff33aa", fg = "#000000", bold = true })
      vim.api.nvim_set_hl(0, "MatchParenCur", { bg = "#ff33aa", fg = "#000000", bold = true })
      vim.api.nvim_set_hl(0, "MatchWord",     { bg = "#5555ff", fg = "#000000" })
    end,
  })
end
return M

By using raw hex codes, the highlights stay identical whether you run Nordic, Tokyonight, or the fallback Desert. The autocommand on ColorScheme ensures that even if a plugin reloads the theme, your custom highlights survive.

Global Keymaps & User Commands Top

lua/config/keymaps.lua and lua/config/commands.lua form a unified toolbelt. Every keybinding has a corresponding user command, and every command delegates to a single function. This makes the system auditable, remappable, and self‑documenting.

keymaps.lua


local opts = { noremap = true, silent = true }
local functions = require("config.functions")

-- Clipboard
vim.keymap.set("n", "cc", 'gg"+yG', opts)
vim.keymap.set("v", "<C-c>", '"+y', opts)
vim.keymap.set("i", "<C-v>", '<C-r>+', opts)

-- Buffer / window navigation
vim.keymap.set("n", "<Tab>", ":bn<CR>", opts)
vim.keymap.set("n", "<S-Tab>", ":bp<CR>", opts)
vim.keymap.set("n", "<C-h>", "<C-w>h", opts)
vim.keymap.set("n", "<C-j>", "<C-w>j", opts)
vim.keymap.set("n", "<C-k>", "<C-w>k", opts)
vim.keymap.set("n", "<C-l>", "<C-w>l", opts)

-- Automation tools
vim.keymap.set("n", "<leader>wc",    functions.word_count, opts)
vim.keymap.set("n", "<leader>cc",    functions.command_history_explorer, opts)
vim.keymap.set("n", "<leader>rr",    functions.output_regs, opts)
vim.keymap.set("n", "<leader>hh",    functions.wrap_code_in_buffer, opts)
vim.keymap.set("n", "<leader>ranger",functions.ranger_chooser, opts)
vim.keymap.set("n", "<leader>mm",    functions.output_old_files, opts)

-- etc. (see the full file)

commands.lua


local functions = require("config.functions")

vim.api.nvim_create_user_command("WC", functions.word_count, {})
vim.api.nvim_create_user_command("Mm", functions.output_old_files, {})
vim.api.nvim_create_user_command("Cc", functions.command_history_explorer, {})
vim.api.nvim_create_user_command("Ss", functions.search_command_history, {})
vim.api.nvim_create_user_command("Rr", functions.output_regs, {})
vim.api.nvim_create_user_command("HH", functions.wrap_code_in_buffer, {})
vim.api.nvim_create_user_command("RangerChooser", functions.ranger_chooser, {})
vim.api.nvim_create_user_command("SaveVimInfo", functions.save_vim_bindings_and_functions, {})
vim.api.nvim_create_user_command("EngType", functions.eng_type, {})
vim.api.nvim_create_user_command("FrType", functions.fr_type, {})

Mnemonic prefixes make the system self‑documenting: <leader>wc → word count, <leader>cc → command history, etc.

Automation Functions — functions.lua Top

lua/config/functions.lua is the heart of the automation layer. It provides async Python/LaTeX runners, a searchable command history, a register inspector, an “old files” browser, a ranger file‑chooser, buffer‑wrapping utilities, and more. All are written in pure Lua with no plugin dependencies.

Asynchronous Python Execution


function M.run_python_selection()
  local mode = vim.fn.mode()
  if mode ~= 'v' and mode ~= 'V' then return end
  local save_reg = vim.fn.getreg('"')
  vim.cmd('normal! gvy')
  local code = vim.fn.getreg('"')
  vim.fn.setreg('"', save_reg)
  code = "from math import *\n" .. code:gsub('^%s*', ''):gsub('%s*$', '')
  local output = vim.fn.system({'python3', '-c', code})
  vim.cmd('enew')
  vim.api.nvim_buf_set_lines(0, 0, -1, false, vim.split(output, "\n"))
  vim.bo.buftype = 'nofile'
  vim.bo.bufhidden = 'wipe'
end

Command History Explorer


function M.command_history_explorer()
  local history = {}
  for i = vim.fn.histnr(':'), 1, -1 do
    local cmd = vim.fn.histget(':', i)
    if cmd ~= "" then table.insert(history, cmd) end
  end
  vim.cmd('enew')
  local buf = vim.api.nvim_get_current_buf()
  vim.api.nvim_buf_set_lines(buf, 0, -1, false, history)
  vim.bo[buf].buftype = 'nofile'
  vim.bo[buf].modifiable = false
  vim.keymap.set('n', '<CR>', function()
    local cmd = vim.fn.getline('.')
    vim.cmd('bd! ' .. buf)
    vim.cmd(cmd)
  end, { buffer = buf })
  vim.cmd('normal! gg')
end

Register Inspector


function M.output_regs()
  vim.cmd('enew')
  local content = {}
  for reg = string.byte('a'), string.byte('z') do
    local ch = string.char(reg)
    local val = vim.fn.getreg(ch)
    if val ~= '' then
      table.insert(content, ch .. ":")
      table.insert(content, val)
      table.insert(content, "")
    end
  end
  vim.api.nvim_buf_set_lines(0, 0, -1, false, content)
  vim.bo.buftype = 'nofile'
  vim.bo.bufhidden = 'wipe'
  vim.cmd('normal! gg')
end

The file also contains run_python_and_replace, output_old_files, ranger_chooser, wrap_code_in_buffer, word_count, select_inside_any_pair, and several language‑specific helpers. You can find the complete source in the included zip file at the end of the article.

Per‑Filetype Engines — ftplugin Top

Filetype‑specific behaviour lives in ftplugin/. Each file sets buffer‑local options and defines insert‑mode expansions. Visual‑mode wrappers for HTML and Markdown are centralised in a shared module to avoid duplication.

Python ftplugin


-- ftplugin/python.lua
vim.bo.tabstop = 4
vim.bo.shiftwidth = 4
vim.bo.expandtab = true
vim.bo.textwidth = 88

-- Run buffer asynchronously (full function omitted for brevity)
vim.keymap.set('n', '<leader>c', run_python_buffer, { buffer = true })

-- Insert-mode expansions
local imaps = {
  ['if']    = 'if :<++><ESC>F:a',
  ['for']   = 'for in :<++><ESC>F:i',
  ['def']   = 'def ():<++><ESC>F(a',
  ['class'] = 'class :<++><ESC>F:a',
  ['imp']   = 'import ',
  ['from']  = 'from import <++><ESC>F:i',
  -- … many more
}
for lhs, rhs in pairs(imaps) do
  vim.keymap.set('i', lhs, rhs, { buffer = true })
end

LaTeX ftplugin


-- ftplugin/tex.lua (excerpt)
vim.bo.tabstop = 2
vim.bo.shiftwidth = 2

-- Async compilation and PDF viewer
vim.keymap.set('n', '<leader>c', run_tex,  { buffer = true })
vim.keymap.set('n', '<leader>o', view_tex, { buffer = true })
vim.keymap.set('n', '<leader>w', wrap_buffer_in_html_tags, { buffer = true })

-- Insert-mode shortcuts for commands, environments, and symbols
local imaps = {
  ['!'] = '\\',
  ['qq'] = '\\quad ',
  [',bf'] = '\\textbf{}<++><ESC>F{a',
  [',u']  = '\\underline{}<++><ESC>F{a',
  -- … dozens more
}
for lhs, rhs in pairs(imaps) do
  vim.keymap.set('i', lhs, rhs, { buffer = true })
end

HTML & Markdown ftplugins


-- ftplugin/html.lua
vim.bo.tabstop = 2
vim.bo.shiftwidth = 2
local imaps = {
  ['!'] = '<!--  --><++><Esc>F i',
  ['<'] = '<><++><Esc>F>a',
}
for lhs, rhs in pairs(imaps) do
  vim.keymap.set('i', lhs, rhs, { buffer = true })
end
require("config.html_markdown_maps")()

-- ftplugin/markdown.lua
vim.bo.tabstop = 2
vim.bo.shiftwidth = 2
require("config.html_markdown_maps")()

Shared Visual Wrappers — html_markdown_maps.lua

This module registers visual‑mode mappings that work identically in HTML and Markdown buffers. It uses a pure‑Lua wrap_visual_text function that handles linewise, characterwise, and blockwise selections.


-- lua/config/html_markdown_maps.lua (core wrapping function)
local function wrap_visual_text(open_tag, close_tag)
  local mode = vim.fn.visualmode()
  -- … normalises start/end, gets the visual selection,
  -- and wraps it with open_tag .. text .. close_tag
  -- (full implementation in the included zip file at the end of the article)
end

return function()
  vim.keymap.set('v', '<leader>pp', function() wrap_visual_text('<p>', '</p>') end)
  vim.keymap.set('v', '<leader>hh', function() wrap_visual_text('<h2>', '</h2>') end)
  -- … and many more wrapping / escaping shortcuts
end

Additionally, the file defines a set of number‑prefixed visual maps (1–9) for common transformations: escaping symbols, wrapping in code blocks, URL‑encoding, and more. See the included zip file at the end of the article for the full content.

Snippets as Code — LuaSnip Integration Top

Snippets are defined in two files: tex_snippets.lua and html_snippets.lua. They use LuaSnip’s function nodes for dynamic behaviour, read legacy snippet files on demand, and auto‑number LaTeX exercises based on buffer content.

LaTeX Snippets


-- tex_snippets.lua (excerpt)
local ls = require("luasnip")
local s = ls.snippet
local i = ls.insert_node
local t = ls.text_node
local f = ls.function_node

-- Auto‑numbered exercise environment
s("exe", {
  t("\\begin{exe}{"), i(1, "<++>"), t("}"),
  t({"", "    "}), f(function()
    local count = 0
    for _, line in ipairs(vim.api.nvim_buf_get_lines(0, 0, -1, false)) do
      if line:match("\\begin{exe}") then count = count + 1 end
    end
    return tostring(count)
  end),
  t({"", "    <++>", "\\end{exe}"}),
})

The file also wraps legacy snippet files from ~/.vim/snippets/latex/ so they appear as native LuaSnip snippets, and exports functions that can be called directly from insert‑mode mappings (e.g., ,tcb in the LaTeX ftplugin).

HTML / Markdown Snippets


-- html_snippets.lua
local snippets = {
  s("fig", {
    t("<figure>"),
    t({ "", "    " }),
    t('<img src="/theme/images/articles/'), i(1, "image.png"),
    t('" alt="'), i(2, "description"), t('" style="max-width:100%;height:auto;" >'),
    t({ "", "    " }),
    t("<figcaption>"), i(3, "caption"), t("</figcaption>"),
    t({ "", "</figure>" }),
    i(0),
  }),
  -- … anchor link, code block with raw tags, etc.
}
ls.add_snippets("html", snippets)
ls.add_snippets("markdown", snippets)

The Plugin Dashboard — core.lua Top

lua/plugins/core.lua lists every plugin. Each one lazy‑loads on an event, command, or filetype. The full specification is shown below.


return {
  -- Themes (loaded immediately)
  { "AlexvZyl/nordic.nvim",          lazy = false, priority = 1000 },
  { "folke/tokyonight.nvim",         lazy = false, priority = 1000 },

  -- Telescope (fuzzy finder)
  {
    "nvim-telescope/telescope.nvim",
    dependencies = { "nvim-lua/plenary.nvim" },
    cmd = "Telescope",
    config = function()
      local builtin = require("telescope.builtin")
      vim.keymap.set("n", "<leader>ff", builtin.find_files)
      vim.keymap.set("n", "<leader>fg", builtin.live_grep)
      vim.keymap.set("n", "<leader>fb", builtin.buffers)
      vim.keymap.set("n", "<leader>fh", builtin.help_tags)
    end,
  },

  -- Treesitter (syntax highlighting and indentation)
  {
    "nvim-treesitter/nvim-treesitter",
    build = ":TSUpdate",
    event = { "BufReadPost", "BufNewFile" },
    config = function()
      require("nvim-treesitter.configs").setup({
        ensure_installed = {
          "lua", "python", "javascript", "html", "css", "bash", "c", "cpp", "json", "yaml",
        },
        highlight = { enable = true },
        indent = { enable = true },
      })
    end,
  },

  -- Mason (LSP/DAP/linter manager)
  {
    "williamboman/mason.nvim",
    build = ":MasonUpdate",
    config = function() require("mason").setup() end,
  },

  -- nvim-cmp + LuaSnip (completion & snippets)
  {
    "hrsh7th/nvim-cmp",
    dependencies = {
      "hrsh7th/cmp-nvim-lsp",
      "hrsh7th/cmp-buffer",
      "hrsh7th/cmp-path",
      "saadparwaiz1/cmp_luasnip",
      "L3MON4D3/LuaSnip",
    },
    event = "InsertEnter",
    config = function()
      local cmp = require("cmp")
      local luasnip = require("luasnip")
      vim.o.completeopt = "menu,menuone,noselect"
      cmp.setup({
        snippet = {
          expand = function(args) luasnip.lsp_expand(args.body) end,
        },
        mapping = cmp.mapping.preset.insert({
          ['<C-Space>'] = cmp.mapping.complete(),
          ['<CR>'] = cmp.mapping.confirm({ select = true }),
          ['<Tab>'] = cmp.mapping(function(fallback)
            if cmp.visible() then cmp.select_next_item()
            elseif luasnip.expand_or_jumpable() then luasnip.expand_or_jump()
            else fallback() end
          end, { "i", "s" }),
          ['<S-Tab>'] = cmp.mapping(function(fallback)
            if cmp.visible() then cmp.select_prev_item()
            elseif luasnip.jumpable(-1) then luasnip.jump(-1)
            else fallback() end
          end, { "i", "s" }),
        }),
        sources = cmp.config.sources({
          { name = 'nvim_lsp' },
          { name = 'luasnip' },
          { name = 'buffer' },
          { name = 'path' },
        }),
      })
      -- Load our custom snippets
      require("config.tex_snippets")
      require("config.html_snippets")
    end,
  },

  -- Minimal bufferline
  {
    "akinsho/bufferline.nvim",
    version = "*",
    config = function()
      require("bufferline").setup({
        options = {
          mode = "buffers",
          show_buffer_close_icons = false,
          show_close_icon = false,
          truncate_names = false,
          diagnostics = false,
          separator_style = { "|", "|" },
          always_show_bufferline = true,
          numbers = "none",
        },
      })
    end,
  },
}

Equally important is what’s not included: no file‑tree plugin (ranger and Telescope cover navigation), no statusline plugin (the built‑in one plus custom highlights suffice), and no AI‑powered completion. Every plugin must justify its presence.

Putting It All Together Top

When you start Neovim:

init.lua sets options, loads lazy.nvim, and schedules the colour setup.
Lazy.nvim parses plugins/core.lua and begins loading plugins by their lazy‑load triggers.
The scheduled callback applies the theme, defines global keymaps and commands.
When a buffer is opened, Treesitter attaches, the appropriate ftplugin fires, and snippets register for that filetype.
On InsertEnter, nvim‑cmp activates with all snippet and LSP sources ready.

At no point does the user wait for a progress bar. The entire plugin set, once cached, starts in under 100 milliseconds.

Reproducibility & Final Thoughts Top

This configuration is a build artifact. The lazy-lock.json pins every plugin version, the colours are hard‑coded hex values, and every snippet and function is defined in Lua. To replicate the environment on a new machine, you only need:

📥 Download neovim full config 2026


    # extract the zip file and
    cp nvim ~/.config/nvim
    nvim --headless "+Lazy sync" +qa

After that, your editor will start in under 100 ms and behave exactly as it does today.

The seven companion articles dive deeper into each subsystem: the bootstrapping layer, filetype engines, custom functions, snippets, colours, keymaps/commands, and the plugin ecosystem. But the article you’ve just read contains the complete source and the reasoning you need to build your own ultimate Neovim setup.

Engineering Deterministic Prompts for LLM Agents: A Systems Design Approach

2026-05-26T23:37:52+00:00

The Problem: LLMs Are Powerful but Unpredictable

Every engineer who has worked with LLMs for more than a weekend eventually hits the same wall: the model produces beautiful output on Tuesday and hallucinated garbage on Wednesday. The same prompt, the same model, the same parameters — different results. For chatbots, this variability is tolerable. For automated pipelines, it is catastrophic.

I build static site tooling that depends on deterministic LLM output. My Pelican article generator ingests a specification, produces structured files, and feeds them into downstream SVG renderers, TOML parsers, and assembly scripts. If the LLM decides to output Markdown instead of HTML, or omits thumbnail_meta.toml entirely, the pipeline breaks silently.

This article documents the prompting architecture I developed to solve that problem. It is not a general guide to "writing better prompts." It is a systems design approach to treating LLM agents as programmable, composable, version-controlled infrastructure components.

Why Conversational Prompting Fails for Automation

The dominant paradigm for LLM interaction — casual back-and-forth conversation — emerged from chatbot interfaces. You ask a question, the model responds. You refine, it refines. This works for exploration but fails for automation for three reasons:

•Non-determinism: Natural language is inherently ambiguous. "Write a good article" means nothing precise enough for a machine to execute consistently.

•No structural contract: Conversations produce unstructured text. If your pipeline expects a TOML file with specific keys, a conversational prompt provides zero guarantees.

•Impossible versioning: How do you diff two conversations? You cannot meaningfully track changes to a prompt when the prompt is "uh, try making it sound more professional."

The engineering response to these failures is not to abandon LLMs — it is to stop treating them like conversation partners and start treating them like programmable systems with defined interfaces.

The Core Insight: Prompts as Machine-Readable Specifications

Look at the prompt that generated this article. It is not a casual request. It is a 300-line specification document with clearly delimited sections, explicit formatting rules, output contracts, and fallback behavior definitions. That structure is not incidental — it is the entire mechanism by which the system achieves repeatability.

A well-engineered prompt functions like an API schema. It defines:

Component	What It Specifies	Analogy
Role definition	Who the model is, what perspective it adopts	System user in a Linux process
Audience constraints	Who the output serves, what knowledge to assume	Target architecture in a compiler
Output format	Exact file structure, naming conventions, encoding	Return type in a function signature
Stylistic rules	Tone, vocabulary restrictions, structural preferences	Linter configuration
Examples	Concrete instances of correct behavior	Unit tests
Fallback logic	What to do when constraints conflict or data is missing	Error handling in a try/catch block

When you write a prompt this way, you are not asking the model to do something — you are programming it. The distinction matters.

Layered Prompt Architecture

After iterating through dozens of prompt designs for my Pelican workflow, I settled on a layered architecture. Each layer addresses a specific failure mode independently, making the system composable and debuggable.

Layer 1: Identity and Constraints

The top layer establishes who the agent is and what boundaries it operates within. This is not motivational fluff — it constrains the model's output distribution by anchoring it to a specific persona and knowledge domain.

In my prompt, this layer includes:



You are generating articles for a highly technical developer-focused
static website built with Pelican.

The site's audience primarily consists of:
- Linux users
- Power users
- Developers
- Engineers
- Technical writers

Avoid beginner-style fluff and generic marketing language.

Why this works: LLMs are trained on vast corpora with varying quality. By constraining the output distribution to "engineering documentation" rather than "general web content," you eliminate entire categories of bad output — clickbait, motivational filler, generic introductions — before the model writes a single word.

Layer 2: Negative Specification

Most prompt advice focuses on telling the model what to do. Equally important is explicitly telling it what not to do. I call this "negative specification," and it is disproportionately valuable for reducing output variance.

Consider how my prompt handles tone:



Avoid:
- excessive hype
- clickbait language
- motivational filler
- generic introductions
- AI-sounding transitions
- generic beginner tutorials
- shallow introductions
- excessive emojis
- generic AI phrasing

Each negative constraint eliminates a failure mode I encountered in earlier prompt iterations. The list grew organically through testing: run the prompt, observe a failure pattern, add a negative constraint targeting that pattern, repeat.

Layer 3: Structural Contract

This is the most critical layer for automation. It specifies the exact output format the agent must produce — not as a suggestion, but as a non-negotiable contract.

The key design decisions in my structural contract:

•Directory-based output instead of single file: A flat Markdown file is easy for humans but terrible for machines. By requiring a directory with named files, I enable downstream tools to consume specific outputs without parsing. The SVG banner generator reads banner_meta.toml directly — it never touches the article body.

•HTML body instead of Markdown: This forces the model to think structurally. Markdown encourages ambiguity ("just write some headers and paragraphs"). HTML forces explicit section boundaries, class names, and semantic elements.

•Metadata sidecars: TOML files for banner and thumbnail metadata separate content from presentation. The LLM extracts structured data (terminal commands, code snippets, quotes) into machine-parseable files that feed deterministic SVG generators.

Layer 4: Formatting Micro-Specifications

Even with a structural contract, LLMs produce inconsistent formatting. My prompt includes surgical rules that address specific recurring problems:



<!-- Exact code block structure -->
<pre class="language-python">
<code class="language-python">
<!-- code here -->
</code>
</pre>

<!-- CRITICAL: newline between pre and code -->

This rule exists because the Pelican static site generator processes HTML code blocks with specific expectations. A missing newline between <pre> and <code> breaks syntax highlighting. The constraint is not stylistic — it is a compatibility requirement.

Similarly, the {% raw %}...{% endraw %} rule exists because Pelican uses Jinja2 templating, and Python code containing {{ or {% would be interpreted as template syntax without escaping.

Layer 5: Fallback Logic

Production prompts must handle edge cases. My specification includes explicit fallback behavior for the delivery mechanism:

Condition	Behavior
Platform supports binary downloads	Output ZIP file containing article directory
Platform only supports text output	Output self-contained bash script that recreates directory
Uncertain platform capability	Default to shell script (safer)

This fallback logic is not optional — without it, the entire automation pipeline breaks when the AI platform changes its output capabilities. The prompt anticipates failure modes and specifies recovery behavior.

Composability Through File Separation

One of the subtlest but most important design decisions in my prompt architecture is the separation of concerns across files. Consider the metadata flow:



body.html          → Pelican article content
banner_meta.toml   → SVG banner generator input
thumbnail_meta.toml→ SVG thumbnail generator input
tags.txt           → SEO metadata, tag pages
category.txt       → Site taxonomy

Each file is independently consumable. The banner generator does not need to parse HTML. The tag indexer does not need to extract TOML. This composability means I can modify one component of the pipeline without touching others — the same property that makes Unix pipes powerful.

Testing Prompts Like Code

If prompts are specifications, they deserve testing. My workflow includes a validation script that runs after every prompt iteration:



import os
import tomllib

def validate_article_directory(path):
    required_files = [
        'title.txt', 'summary.txt', 'subtitle.txt',
        'bannertitle.txt', 'thumbtitle.txt',
        'category.txt', 'tags.txt', 'body.html',
        'banner_meta.toml', 'thumbnail_meta.toml'
    ]

    for f in required_files:
        assert os.path.exists(os.path.join(path, f)), f"Missing: {f}"

    # Validate TOML is parseable
    with open(os.path.join(path, 'banner_meta.toml'), 'rb') as fh:
        tomllib.load(fh)

    # Validate HTML contains no placeholder text
    with open(os.path.join(path, 'body.html')) as fh:
        html = fh.read()
        assert 'insert here' not in html.lower()
        assert 'todo' not in html.lower()

    print("✓ All validations passed")

validate_article_directory('./article')

This script catches the most common failure modes: missing files, unparseable TOML, and placeholder text the LLM sometimes inserts when it runs out of context. Running it after every generation turns prompt engineering from a subjective art into a measurable engineering practice.

Version-Controlled Prompt Evolution

My prompts live in Git alongside the code they help generate. This enables practices that are standard for software but rare for prompts:

•Diffs between prompt versions: When output quality changes, I can trace it to specific prompt modifications.

•Branching for experimentation: I can fork a prompt, modify the tone layer, and compare output distributions without losing the stable version.

•Rollbacks: If a new prompt version introduces regressions, git checkout prompts/v2/system.txt restores the known-good specification.

A typical prompt repository structure:



prompts/
├── v1/
│   ├── system.txt          # Full system prompt
│   ├── output_spec.yaml    # Machine-readable output contract
│   └── test_cases/
│       ├── expected_output/
│       └── validation.py
├── v2/
│   ├── system.txt
│   ├── output_spec.yaml
│   └── CHANGELOG.md        # Why this version exists
└── current → v2            # Symlink to active version

Why This Approach Produces Better Technical Content

The architecture I have described does not just make LLM output more predictable — it produces fundamentally better technical articles. Here is why:

•Structural constraints force depth: When a prompt requires directory-structured output with specific metadata files, the model cannot produce shallow content. Surface-level articles cannot fill a body.html that expects architectural diagrams, tradeoff analysis, and implementation details.

•Negative constraints eliminate filler: Explicitly forbidding "motivational filler" and "generic introductions" forces the model into the substantive content immediately. Every paragraph must carry technical weight.

•Audience constraints anchor complexity: Specifying "Linux users, power users, developers" as the audience prevents the model from drifting toward beginner explanations. It assumes competence and writes accordingly.

•Example-driven specification reduces ambiguity: Concrete examples of preferred titles ("Building a Static Site Search Engine Without External Services") communicate intent more precisely than abstract descriptions ("professional titles").

Practical Patterns for Production Prompts

Here are patterns I have validated across multiple prompt architectures. They generalize beyond my Pelican use case to any scenario where LLM output feeds into automated pipelines.

Pattern 1: The Output Contract Table

Instead of describing the output format in prose, specify it as a structured table:



| File | Format | Purpose | Required |
|------|--------|---------|----------|
| body.html | HTML | Article content | Yes |
| tags.txt | Comma-separated plaintext | SEO tags | Yes |
| banner_meta.toml | TOML | Banner decoration data | No |

Tables reduce ambiguity. The model either produces the specified files or it does not — there is no room for interpretation.

Pattern 2: The Concrete-Before-Abstract Rule

Always provide a concrete example before stating the abstract rule. This exploits the LLM's pattern-matching capabilities: it mimics the example, then the rule clarifies the generalization.

Bad (abstract first): "Use engineering-focused titles that avoid hype."

Good (concrete first): "Example: 'Building a Static Site Search Engine Without External Services.' This style — engineering-focused, descriptive, avoiding hype — should characterize all titles."

Pattern 3: Explicit Enumeration of Failure Modes

Instead of hoping the model avoids problems, list them:



Common failure modes to guard against:
- Outputting Markdown when HTML is specified
- Omitting the newline between <pre> and <code>
- Inserting placeholder text instead of generating content
- Producing empty TOML arrays when data is unavailable

This is the prompt equivalent of defensive programming. You are handling exceptions before they occur.

Pattern 4: The Minimum Viable Output Constraint

When output is optional, specify exactly when to omit it:



- If no suitable commands exist, omit the key entirely
  (do not create an empty array).
- Never include a key with an empty value.
- If you cannot fill a key with real content, delete it
  from the file.

This prevents the model from producing terminal_commands = [] when it should produce nothing at all — a distinction that matters when downstream parsers treat empty arrays differently from missing keys.

Tradeoffs and Limitations

This approach is not free. The costs are real and worth acknowledging:

•Prompt length: A 300-line specification consumes context window budget. For complex tasks, this is unavoidable — precision requires verbosity. But for simple tasks, shorter prompts with fewer constraints may suffice.

•Rigidity: Highly specified prompts reduce creative output. My article generator produces consistent results, but it will never surprise me with an unexpectedly brilliant structural innovation. That tradeoff is acceptable for automation; it may not be for exploratory writing.

•Maintenance burden: Prompts require updates when downstream systems change. If I modify my SVG generator to expect a new TOML key, the prompt must be updated, tested, and versioned. This is engineering overhead, but it is preferable to silently broken pipelines.

•Model dependence: Different models interpret the same specification differently. A prompt optimized for Claude may produce different results on GPT-4 or open-source models. Multi-model pipelines require cross-validation.

Integration with CI/CD Pipelines

The final stage of treating prompts as infrastructure is integrating them into automated pipelines. My article generation workflow now runs as part of a CI pipeline:



# .github/workflows/generate-article.yml
steps:
  - name: Generate article from prompt
    run: |
      python generate_article.py \
        --prompt prompts/current/system.txt \
        --topic "$TOPIC" \
        --output article/

  - name: Validate output structure
    run: python validate_article.py article/

  - name: Commit generated article
    run: |
      git add article/
      git commit -m "Auto-generated article: $TOPIC"
      git push

This pipeline transforms LLM prompting from an ad-hoc manual process into a repeatable, auditable, automated step in a larger build system. The prompt is source code. The LLM is a compiler. The output is an artifact.

Conclusion: Prompts Are Infrastructure

The fundamental shift in thinking that makes LLM automation reliable is this: prompts are not conversations. They are machine-readable specifications that produce structured output from unstructured language models. Designing them requires the same discipline as designing APIs, writing schemas, or specifying compiler behavior.

My Pelican article generation prompt works reliably not because I found magic words, but because I treated it as an engineering problem: identify failure modes, specify constraints precisely, separate concerns into composable files, test outputs programmatically, and version everything.

If you are building LLM-powered automation — whether for content generation, code review, data extraction, or report synthesis — the same principles apply. Design your prompts like you would design any other component in a production system. Define the interface. Specify the contract. Handle the edge cases. Test the output.

The LLM is the most powerful parsing and generation engine ever built. But like any powerful tool, it requires precise controls. Prompts are those controls. Engineer them accordingly.

Jinja2 to PDF: Modern HTML-to-PDF Generation with WeasyPrint

2026-05-26T16:55:19+00:00

For years, wkhtmltopdf was the go-to tool for converting HTML to PDF in Python workflows. It worked — until it didn't. The project is now effectively unmaintained, Qt WebKit bindings are brittle, and headless Chrome solutions like Playwright introduce heavy runtime dependencies that feel absurd for a document generation pipeline.

I recently migrated a document generation system from wkhtmltopdf to WeasyPrint, and the result was lighter, faster, and — most importantly — deterministic. No browser binaries. No X server. Just Python, CSS, and your templates.

This article documents that migration: the architecture, the tradeoffs, and a reusable pipeline you can drop into your own projects.

Why WeasyPrint Over the Alternatives

The HTML-to-PDF landscape in 2026 breaks down into three approaches:

Approach	Tool	Dependencies	Reproducibility
Headless browser	Playwright, Puppeteer	Chromium binary (~300 MB)	Moderate — browser version matters
Legacy Qt WebKit	wkhtmltopdf	Qt libraries	Poor — unmaintained, rendering quirks
Pure Python layout engine	WeasyPrint	Cairo, Pango, GDK-Pixbuf (system libs)	Excellent — deterministic output from same inputs

WeasyPrint doesn't execute JavaScript, which is a feature if your goal is server-side document generation from structured data. It implements its own CSS layout engine on top of Cairo, meaning the same HTML + CSS input produces the same PDF output every time. No browser version drift. No async event loop gymnastics. Just a function call.

•Deterministic: Same input always produces byte-identical PDF output.
•Lightweight: No browser binary — system Cairo and Pango handle rendering.
•Pythonic: Native Python API, integrates cleanly with Jinja2 and Flask/FastAPI.
•CSS Paged Media: Full support for @page, named pages, page counters, and footnotes.

Architecture Overview

The pipeline follows a straightforward data → template → render → PDF flow:



+-------------+     +------------------+     +--------------+     +----------+
| Data (JSON, | --> | Jinja2 Template  | --> | HTML String  | --> | WeasyPrint |
| dict, ORM)  |     | (with CSS print) |     | (in memory)   |     | PDF output |
+-------------+     +------------------+     +--------------+     +----------+

There's no intermediate file write unless you want one. The entire pipeline runs in memory, which matters when you're generating hundreds of documents in a batch job.

Installing WeasyPrint

WeasyPrint depends on system libraries for rendering. On a Debian/Ubuntu system:



sudo apt install libcairo2 libpango-1.0-0 libpangocairo-1.0-0 \
                 libgdk-pixbuf2.0-0 libffi-dev shared-mime-info
pip install weasyprint jinja2

For Alpine-based Docker images, the package names differ but the principle is the same. I include a Dockerfile snippet later that handles both.

Template Design with CSS Paged Media

The real work isn't the Python code — it's the CSS. WeasyPrint supports CSS Paged Media, which gives you control over page size, margins, headers, footers, and page breaks that browser-based converters often ignore.

Here's a minimal Jinja2 template with print-specific CSS:



<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>{{ title }}</title>
<style>
  @page {
    size: A4;
    margin: 2.5cm 2cm 2.5cm 2cm;
    @bottom-center {
      content: "Page " counter(page) " of " counter(pages);
      font-family: 'DejaVu Sans', sans-serif;
      font-size: 9pt;
      color: #666;
    }
  }

  @page :first {
    @bottom-center {
      content: none;
    }
  }

  body {
    font-family: 'DejaVu Sans', sans-serif;
    font-size: 11pt;
    line-height: 1.6;
    color: #1a1a1a;
  }

  h1 {
    font-size: 22pt;
    color: #2c3e50;
    border-bottom: 3px solid #3498db;
    padding-bottom: 0.3em;
    page-break-before: avoid;
  }

  h2 {
    font-size: 16pt;
    color: #2c3e50;
    page-break-after: avoid;
  }

  pre {
    background: #f7f9fa;
    border-left: 4px solid #3498db;
    padding: 1em;
    font-family: 'DejaVu Sans Mono', monospace;
    font-size: 9pt;
    line-height: 1.4;
    overflow-wrap: break-word;
    white-space: pre-wrap;
  }

  code {
    font-family: 'DejaVu Sans Mono', monospace;
    font-size: 9pt;
  }

  table {
    border-collapse: collapse;
    width: 100%;
    margin: 1em 0;
    page-break-inside: avoid;
  }

  th, td {
    border: 1px solid #ddd;
    padding: 0.5em 0.75em;
    text-align: left;
  }

  th {
    background: #f0f3f5;
    font-weight: 600;
  }

  .page-break {
    page-break-before: always;
  }
</style>
</head>
<body>
  {{ content }}
</body>
</html>

Key details in that CSS:

•@page with @bottom-center: Page numbering that Just Works — no JavaScript, no header/footer hacks.
•page-break-before: avoid on headings: Prevents orphaned headers at page bottoms.
•page-break-inside: avoid on tables: Keeps tabular data together.
•Font declarations: Explicit font-family with fallbacks — WeasyPrint uses system fonts, so declare what you have available. DejaVu Sans ships on most Linux systems.

The Python Pipeline

Here's the complete generation pipeline as a reusable class:



from pathlib import Path
from jinja2 import Environment, FileSystemLoader
from weasyprint import HTML
import tempfile
from typing import Optional, Dict, Any


class PDFGenerator:
    """Deterministic PDF generation from Jinja2 templates using WeasyPrint."""

    def __init__(self, template_dir: Path):
        self.env = Environment(
            loader=FileSystemLoader(str(template_dir)),
            autoescape=True,
        )

    def render_html(
        self,
        template_name: str,
        context: Dict[str, Any]
    ) -> str:
        """Render a Jinja2 template to an HTML string."""
        template = self.env.get_template(template_name)
        return template.render(**context)

    def generate_pdf(
        self,
        html_string: str,
        output_path: Optional[Path] = None,
        base_url: Optional[str] = None,
    ) -> bytes:
        """
        Convert HTML string to PDF bytes.

        Args:
            html_string: Rendered HTML content.
            output_path: If provided, write PDF to this path.
            base_url: Base URL for resolving relative URLs in the HTML.

        Returns:
            PDF as bytes.
        """
        html = HTML(
            string=html_string,
            base_url=base_url,
        )
        pdf_bytes = html.write_pdf()

        if output_path:
            output_path.write_bytes(pdf_bytes)

        return pdf_bytes

    def generate_from_template(
        self,
        template_name: str,
        context: Dict[str, Any],
        output_path: Optional[Path] = None,
    ) -> bytes:
        """Full pipeline: render template → generate PDF."""
        html_string = self.render_html(template_name, context)
        return self.generate_pdf(html_string, output_path=output_path)


# Usage example
if __name__ == "__main__":
    generator = PDFGenerator(template_dir=Path("./templates"))

    context = {
        "title": "Monthly Engineering Report — March 2026",
        "content": "<h1>Overview</h1><p>Results here...</p>",
    }

    pdf_bytes = generator.generate_from_template(
        template_name="report.html",
        context=context,
        output_path=Path("./output/report.pdf"),
    )

    print(f"Generated {len(pdf_bytes)} bytes")

This class intentionally keeps the interface narrow: template + context in, PDF bytes out. The caller doesn't need to know about HTML intermediates unless they want them for debugging.

Handling Images and Static Assets

When your templates reference local images or CSS files, WeasyPrint needs a base_url to resolve relative paths. Pass it through:



generator.generate_pdf(
    html_string=html_string,
    base_url="file:///home/user/project/templates/",
)

For production, I prefer embedding images as base64 data URIs in the template context — this makes the HTML fully self-contained and avoids filesystem dependency during rendering:



import base64
from pathlib import Path

def image_to_data_uri(path: Path, mime_type: str = "image/png") -> str:
    """Convert an image file to a base64 data URI."""
    encoded = base64.b64encode(path.read_bytes()).decode("ascii")
    return f"data:{mime_type};base64,{encoded}"

# In your context:
context["logo"] = image_to_data_uri(Path("./assets/logo.png"))

Then in the template:



<img src="{{ logo }}" alt="Company Logo" style="max-width: 200px;">

This approach produces fully portable HTML strings — serialize them to a database, send them over a message queue, render them anywhere. No asset paths to manage.

Dockerizing the Pipeline

Here's a minimal Dockerfile that produces a reproducible PDF generation image:



FROM python:3.12-slim-bookworm

RUN apt-get update && apt-get install -y --no-install-recommends \
    libcairo2 \
    libpango-1.0-0 \
    libpangocairo-1.0-0 \
    libgdk-pixbuf2.0-0 \
    libffi8 \
    shared-mime-info \
    fonts-dejavu-core \
    fonts-dejavu-mono \
    && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY ./templates /app/templates
COPY ./generate.py /app/generate.py

WORKDIR /app
ENTRYPOINT ["python", "generate.py"]

The fonts-dejavu-core and fonts-dejavu-mono packages are critical — WeasyPrint needs actual font files to render text. Without them, you'll get blank pages or fallback to ugly bitmap fonts.

Performance Considerations

WeasyPrint is CPU-bound and single-threaded per document. For bulk generation, parallelize at the process level:



from concurrent.futures import ProcessPoolExecutor
from pathlib import Path

def generate_one(args):
    template_name, context, output_path = args
    generator = PDFGenerator(template_dir=Path("./templates"))
    generator.generate_from_template(template_name, context, output_path)
    return output_path

def batch_generate(documents, max_workers=4):
    with ProcessPoolExecutor(max_workers=max_workers) as executor:
        results = list(executor.map(generate_one, documents))
    return results

I've found that max_workers = CPU_COUNT gives the best throughput. Memory usage scales linearly with worker count — each worker loads the template environment independently.

A quick benchmark on my machine (Ryzen 7, 8 cores) generating a 12-page report with charts and tables:

Method	Documents/sec	Memory per worker
Single process	2.3	~80 MB
4 workers	8.1	~80 MB each (320 MB total)
8 workers	14.2	~80 MB each (640 MB total)

Not perfectly linear due to GIL release during Cairo rendering, but close enough for most workloads.

Migration From wkhtmltopdf: What Changes

If you're migrating an existing wkhtmltopdf workflow, here's what breaks and what improves:

•JavaScript-rendered charts: Must be pre-rendered server-side or replaced with static images. I moved from Chart.js to Matplotlib-rendered PNGs embedded as data URIs.
•Flexbox and Grid: WeasyPrint's support is solid but not identical to Chrome. Test your layouts — simple flex layouts work; complex nested grids may need adjustment.
•Web fonts: @import url() for Google Fonts works, but adds network latency. I bundle fonts as base64 in the CSS during the build step.
•Headers and footers: The @page margin boxes are vastly simpler than wkhtmltopdf's --header-html and --footer-html flags. No more phantom header spacing bugs.

Edge Cases and Gotchas

After generating thousands of PDFs through this pipeline, here's what I've learned:

•Long words in <pre> blocks overflow pages. Always set overflow-wrap: break-word and white-space: pre-wrap on code blocks.
•Empty <div> elements with padding cause blank pages. WeasyPrint collapses empty block elements — add   or a zero-width space if you need to preserve spacing.
•CMYK color spaces aren't supported. If you need print-shop-ready PDFs with CMYK, you'll need post-processing with a tool like Ghostscript.
•SVG support is limited to static SVG. No SMIL animations, no external CSS — inline styles only.

Integration Patterns

This pipeline fits naturally into several workflows:

•Flask/FastAPI endpoint: Accept JSON payload, render template, return PDF response with Content-Type: application/pdf.
•Celery background task: Long reports (50+ pages) can take several seconds — offload to a task queue.
•CI/CD documentation build: Generate PDF manuals as build artifacts from Markdown rendered through Jinja2.
•Email attachment pipeline: Render invoice → attach to email → send via SMTP, all within a single Python process.

Complete Example: Invoice Generator

Here's a full working example that ties everything together — an invoice generator you can adapt:



from pathlib import Path
from datetime import date
from jinja2 import Environment, FileSystemLoader
from weasyprint import HTML

TEMPLATE = """<!DOCTYPE html>
<html>
<head>
<style>
  @page { size: A4; margin: 2cm; }
  body { font-family: 'DejaVu Sans', sans-serif; font-size: 11pt; }
  .header { display: flex; justify-content: space-between; margin-bottom: 2em; }
  .invoice-details { text-align: right; }
  table { width: 100%; border-collapse: collapse; margin: 1em 0; }
  th { background: #2c3e50; color: white; padding: 0.5em; text-align: left; }
  td { padding: 0.5em; border-bottom: 1px solid #ddd; }
  .total { text-align: right; font-weight: bold; font-size: 14pt; margin-top: 1em; }
</style>
</head>
<body>
  <div class="header">
    <div><strong>{{ company_name }}</strong><br>{{ company_address }}</div>
    <div class="invoice-details">
      <strong>Invoice #{{ invoice_number }}</strong><br>
      Date: {{ invoice_date }}<br>
      Due: {{ due_date }}
    </div>
  </div>

  <h2>Bill To:</h2>
  <p>{{ client_name }}<br>{{ client_address }}</p>

  <table>
    <thead>
      <tr><th>Description</th><th>Qty</th><th>Rate</th><th>Amount</th></tr>
    </thead>
    <tbody>
      {% for item in line_items %}
      <tr>
        <td>{{ item.description }}</td>
        <td>{{ item.quantity }}</td>
        <td>${{ "%.2f"|format(item.rate) }}</td>
        <td>${{ "%.2f"|format(item.quantity * item.rate) }}</td>
      </tr>
      {% endfor %}
    </tbody>
  </table>

  <div class="total">Total: ${{ "%.2f"|format(total) }}</div>
</body>
</html>"""

def generate_invoice(context: dict, output_path: Path) -> bytes:
    env = Environment()
    template = env.from_string(TEMPLATE)
    html = template.render(**context)

    pdf = HTML(string=html).write_pdf()
    output_path.write_bytes(pdf)
    return pdf

# Example usage
invoice_data = {
    "company_name": "Acme Engineering Ltd.",
    "company_address": "123 Main St, Tech City, TC 12345",
    "invoice_number": "INV-2026-0042",
    "invoice_date": "2026-05-26",
    "due_date": "2026-06-25",
    "client_name": "ClientCorp Inc.",
    "client_address": "456 Business Ave, Commerce City, CC 67890",
    "line_items": [
        {"description": "Backend API Development", "quantity": 40, "rate": 150.00},
        {"description": "System Architecture Review", "quantity": 8, "rate": 200.00},
        {"description": "Documentation & Handover", "quantity": 12, "rate": 125.00},
    ],
}
invoice_data["total"] = sum(
    item["quantity"] * item["rate"] for item in invoice_data["line_items"]
)

generate_invoice(invoice_data, Path("invoice.pdf"))

Final Thoughts

WeasyPrint isn't a drop-in replacement for wkhtmltopdf — it's a different philosophy. Where wkhtmltopdf offloads rendering to a browser engine and hopes for the best, WeasyPrint gives you explicit control through CSS Paged Media. That tradeoff means more upfront work on your CSS, but the payoff is reliable, reproducible output that doesn't drift with browser updates.

For document generation pipelines — invoices, reports, certificates, manuals — I now reach for WeasyPrint first. It's one less moving part to debug when something goes wrong at 3 AM, and that alone justifies the migration.

The full pipeline code from this article is available as a reusable package. Adapt the invoice example to your own templates, wrap it in a Flask endpoint or a Celery task, and you've got a production-ready PDF generation system with no browser binary in sight.

Designing a Clean Content Architecture for Pelican Static Sites

2026-05-17T18:00:52+00:00

If you’ve only ever used a static site generator to dump Markdown into HTML, you’re leaving its most powerful capability on the table. In this series we treat content as structured data — and that starts with a clean, queryable architecture.

Content Is Data

Every .md file in a Pelican project is a record. It carries a unique identifier (the slug), a set of typed fields (metadata), and a body (the article content). When you adopt this mindset, you stop thinking about “files” and start thinking about a static database that can be filtered, sorted, and indexed at build time — no plugins required.

We’re going to define a strict vocabulary for that database. Once it’s in place, every “smart” feature we add later — search indexes, related posts, filtered category pages — will simply be a Jinja2 query over well‑structured records.

File Naming Convention

Machine‑readable naming is mandatory. Use the ISO date prefix followed by a readable slug: YYYY-MM-DD-slug.md.

•Predictable ordering: lexical sort equals chronological sort.
•Unique slugs: date + title guarantees no accidental collision.
•Human scannable: `ls content/articles/` shows a timeline at a glance.


2025-06-01-setting-up-pelican.md
2025-06-03-content-architecture.md
2025-06-05-automation-scripts.md

Resist the temptation to use category folders as part of the filename; the date‑slug pattern works everywhere. We’ll handle category organisation through metadata and Pelican’s URL configuration.

The Metadata Block

Pelican reads key‑value metadata from the top of every Markdown file before the first blank line. This is the “schema” for your content records. Treat it as seriously as you would a database table definition.

The minimal recommended set:

•Title – the published headline.
•Date – ISO format YYYY-MM-DD.
•Category – broad classification (e.g. devops, python).
•Tags – comma‑separated keywords (finer grain).
•Summary – a short description for listings and SEO.
•Slug – optional explicit URL slug; we derive it from the filename.

Consistency is more important than volume. Every article in this series will use exactly this set, plus a handful of custom fields we’ll add next.

Custom Metadata Fields

The standard fields only get you so far. We extend the schema with fields that future templates and automation scripts can consume.

•Summary – already mentioned, but make it a habit: a good summary feeds search indexes and Open Graph descriptions.
•FeaturedImage – path to a hero image (we’ll generate these with LaTeX later).
•Thumbnail – a smaller variant for card layouts.
•Views – a static view count that you can increment manually (or via a build‑time script). Not dynamic, but gives a perception of freshness.
•Subcategory – optional second‑level grouping within a category.
•Template – if you need a custom Jinja2 template for a specific article.

None of these fields are required, but we’ll design our templates to behave gracefully when they’re absent — that’s the essence of progressive metadata.

Organising the `content/` Directory

A well‑organised directory tree makes automation predictable. We use a flat structure inside dedicated subdirectories.


content/
├── articles/
│   ├── 2025-06-01-setup.md
│   ├── 2025-06-03-architecture.md
│   └── ...
├── pages/
│   ├── about.md
│   └── contact.md
├── images/
│   └── banners/
└── extra/
    └── robots.txt

articles/ holds dated blog‑style content. pages/ holds standalone documents (About, Contact, Privacy). images/ stores all binary assets (managed with Git LFS if they grow large). extra/ holds static files copied verbatim to the output root (robots.txt, favicon.ico, etc.).

Article vs Page vs Custom Content Type

Knowing when to use each prevents structural debt later.

•Article — time‑stamped content that belongs to a feed or listing. Use it for blog posts, tutorials, changelogs.
•Page — timeless, hierarchical documents. About, Contact, Terms of Service. Pages don’t appear in article lists by default.
•Custom content type — when you need a separate namespace with its own URL scheme and templates (e.g. a portfolio or documentation). We’ll postpone these until the need genuinely arises.

If you’re asking “should this be an article or a page?” — pick the one that matches its temporal nature. Date‑dependent = article; evergreen = page.

Configuring Pelican to Honour Our Structure

Pelican needs explicit URL and path mappings. Add the following to your pelicanconf.py:



ARTICLE_PATHS = ["articles"]
ARTICLE_URL = 'articles/{slug}.html'
ARTICLE_SAVE_AS = 'articles/{slug}.html'
PAGE_URL = '{slug}.html'
PAGE_SAVE_AS = '{slug}/index.html'
STATIC_PATHS = ["images", "extra"]

With these settings, a Markdown file at content/articles/2025-06-03-architecture.md becomes output/articles/architecture.html. Pages land directly at output/about/.

No plugins are required yet — everything above is native Pelican behaviour. We’ll introduce plugins only when we need to extend the core.

Creating the First Real Articles

Let’s create two sample files to validate the setup. First, an article:


Title: Setting Up Pelican Like a Developer
Date: 2025-06-01
Category: static-sites
Tags: pelican, python, tooling
Summary: A clean, maintainable Pelican project structure from day one.
FeaturedImage: images/banners/setup.svg
Views: 30

And a page:


Title: About This Site
Date: 2025-06-01
Category: pages
Summary: The philosophy behind Static, But Smarter.
Template: page

Note that the page still carries a Date field (required by Pelican for internal ordering) but we won’t display it in the template.

Validating the Output

Run make build (or pelican content) and inspect the generated URLs.

• Open output/articles/setting-up-pelican-like-a-developer.html — exists?
• Open output/about/ — loads index.html?
• Check output/extra/robots.txt if you placed one.

If everything looks right, your content architecture is solid. From here on, every new article you write will automatically land in the correct place, with clean, predictable URLs.

Tying It Together: The Metadata Philosophy

We haven’t written a single line of template logic yet, but the groundwork is laid. The metadata fields we defined will power every “dynamic” feature we build later: search indexes, filtered lists, related‑post suggestions, and even automated thumbnail generation.

The key takeaway: your front matter is your API. Treat it with the same rigour you’d apply to a database schema. The next article will take this structured data and give it a presentable, responsive face.

ProjCat: Deterministic Project Manifests for LLM Context Injection

2026-05-15T22:30:25+00:00

ProjCat: Deterministic Project Manifests for LLM Context Injection

Why Another Tool?

Large language models are transforming how we write and maintain code, but they have a fundamental limitation: the context window. Dumping an entire repository into a prompt is rarely feasible, and ad‑hoc copy‑pasting leads to incomplete context, wasted tokens, and non‑reproducible results. We needed a tool that could produce exactly the right slice of a project—structured, repeatable, and easy to pipe into any LLM. ProjCat was built to fill that gap.

What ProjCat Is

ProjCat is a single Python command‑line utility that generates a project manifest: a single text file containing a directory tree diagram and the contents of selected files, with powerful slicing controls. It is designed for developers who work with LLMs, AI agents, and automation pipelines that require concise, deterministic snapshots of a codebase.

Key capabilities:

•Deterministic tree generation — every run with the same arguments produces exactly the same output, modulo file modifications.

•Glob‑based include/exclude — you control what goes into the manifest, with sensible default exclusions for virtualenvs, node_modules, `.git`, and binary artifacts.

•Content slicing — include only the relevant parts of a file, either by pattern (`--from`, `--until`) or by line count (first/last N lines, with per‑file overrides).

•LLM‑friendly output format — a single plain‑text file with clear section headers, metadata, and no encoding surprises.

•Verbose diagnostics and tree‑only mode — useful for manual inspection before feeding a huge manifest to an AI.

Architecture Overview

ProjCat’s architecture is intentionally simple, favouring composability over monolithic design. The pipeline looks like this:

    
User → CLI (cli.py)
       │
       ├─ Collector (collector.py)
       │     └─ walks filesystem, applies includes/excludes
       ├─ TreeGenerator (tree.py)
       │     └─ builds ASCII tree with include/exclude/collapse filters
       ├─ ContentSlicer (slicer.py)
       │     └─ pattern‑ and line‑based slicing
       └─ ManifestWriter (manifest.py)
             └─ assembles the final manifest file

All modules are decoupled. The Collector returns a flat list of Path objects; the TreeGenerator and ContentSlicer operate on that list independently. This design makes it easy to extend or replace any component.

Installation & First Run

ProjCat is a single Python package. just download it from this link then extract it in a safe directory, you can run it directly

    

python ~/Documents/gits/projcat/main.py

The simplest invocation includes every file in the current directory (minus default excludes):

    
projcat

This creates ~/project_dirname_manifest.txt. To see what was collected without generating a manifest, use --list:

    
projcat --list

Controlling What Goes In

Fine‑grained control is where ProjCat shines. You include files and directories with -i and exclude with -e:

    
projcat -i src tests -e __pycache__ *.log

Glob patterns work intuitively, and you can even mix directory‑level includes with per‑file globs:

    
projcat -i app *.py:20 utils.py:-10

Here *.py:20 limits every matched Python file to its first 20 lines, while utils.py:-10 takes the last 10 lines of utils.py. The colon‑appended number is a per‑file line limit (negative = last N lines).

If you need the same limit globally, use -n:

    
projcat -n 30            # first 30 lines of every file
projcat -n 20 --tail      # last 20 lines of every file

Content Slicing: Patterns and Line Limits

Line‑based slicing is straightforward, but often you want to extract a logical block—like a class or a function. ProjCat supports --from and --until pattern matching:

    
projcat --from "class UserService" --until "^class "

This includes everything from the first occurrence of class UserService up to (and including) the next line that starts with class . When both patterns are the same string, ProjCat extracts the content between the first two occurrences—useful for grabbing the implementation between two import blocks.

You can protect sensitive or large files from slicing with --no-slice:

    
projcat --from "def " --no-slice README.md CHANGELOG.md

This ensures those files are included in full, while every other text file gets sliced at the first def .

Core Implementation: A Glimpse Inside

The collector is the heart of the system. Here is a simplified excerpt showing how it walks directories and applies exclusions:



def _walk_directory(self, dir_path: Path):
    """Walk directory and add all files."""
    added_count = 0
    for root, dirs, files in os.walk(dir_path):
        root_path = Path(root)
        # Remove excluded directories during walk
        dirs[:] = [
            d for d in dirs
            if not self._is_excluded_dir(root_path / d)
        ]
        for file in files:
            file_path = root_path / file
            rel_path = self._get_relative_path(file_path)
            if rel_path not in self.all_files:
                self.all_files.add(rel_path)
                added_count += 1

The _is_excluded_dir check prunes the walk early, avoiding expensive recursion into ignored folders. Binary files are detected via UnicodeDecodeError when reading, and marked as [BINARY FILE] in the manifest.

The Manifest Structure

A generated manifest always begins with a header containing metadata (project name, timestamp, root path, active slicing options). Next comes the directory tree, marking each included file with a ✓. Finally, each included file’s content is written inside a distinct bordered block, with optional slicing annotations.

Example output snippet:

    

================================================================================
PROJECT MANIFEST
Generated: 2026-05-15 20:49:47
Project: projcat
Root: /home/user/projcat
Tree depth: unlimited
================================================================================

DIRECTORY STRUCTURE (✓ = included in manifest)
--------------------------------------------------------------------------------

├── ✓ __init__.py
├── ✓ cli.py
├── ✓ collector.py
├── ✓ main.py
├── ✓ manifest.py
├── ✓ slicer.py
├── ✓ tree.py
└── ✓ utils.py

================================================================================

FILE CONTENTS (only included files shown below)
================================================================================

╔══════════════════════════════════════════════════════════════════════════════╗
║ FILE: slicer.py                                                              ║
║ Size:    7,041 bytes | Modified: 2026-02-23 23:11:20                         ║
║ Slicing: first 10 lines                                                      ║
╚══════════════════════════════════════════════════════════════════════════════╝

... (sliced content)

Integration into LLM Workflows

The manifest is meant to be consumed directly by an LLM. In practice, I often run:

    
projcat -i src --from "def " --no-slice conftest.py -o /tmp/ctx.txt
cat /tmp/ctx.txt | llm --system "You are a senior Python developer."

This gives the model a focused view of the codebase, with test‑configuration kept intact and only function‑level slices of the application logic. Because the manifest is a plain text file, it integrates with any CLI‑based LLM tool or script.

For AI agents that iterate on code, ProjCat’s determinism guarantees that the same set of flags always produces the same slice, making it possible to version‑control the manifest generation command alongside the code.

Performance Considerations

ProjCat is designed for projects with up to a few thousand files. It walks the entire directory tree once and keeps relative paths in memory. On a modern SSD, generating a manifest for a 2,000‑file project takes under a second. The biggest bottleneck is reading and writing file contents, which is why slicing (especially early termination with --from) can dramatically reduce manifest size and runtime.

For very large monorepos, consider combining --tree-only with selective includes to first inspect the structure, then rerun with focused slicing.

Tradeoffs & Design Decisions

•Plain text over JSON: JSON would be machine‑readable but adds noise for an LLM. The current format is already easy to parse while being human‑ and LLM‑friendly.

•Line‑based slicing vs. AST: We deliberately avoided AST‑based slicing. Pattern matching is simpler, language‑agnostic, and fast. It won’t always capture exactly one function (e.g., nested classes), but it handles 90% of real‑world use cases.

•No streaming: The whole manifest is built in memory. This is acceptable because a manifest rarely exceeds a few megabytes—otherwise the LLM context would be overwhelmed anyway.

Future Directions

ProjCat is intentionally minimal, but several enhancements are on the radar:

Incremental manifests — only re‑generate sections for files that changed since the last run.
Streaming output — pipe the manifest directly to stdout for immediate LLM consumption.
Plug‑in slicing modules — allow language‑specific slicers (e.g., extract only function bodies) behind a common interface.

Final Thoughts

ProjCat embodies a philosophy of deterministic tooling for AI‑assisted development. By treating the prompt‑building step as an engineering problem—versionable, repeatable, and composable—we remove the guesswork from feeding code to LLMs. It’s a small piece of the puzzle, but one that makes daily AI‑augmented coding significantly more effective.

The Developer’s Dashboard: Completion, Treesitter, and the Plugin Ecosystem

2026-05-15T18:03:11+00:00

Plugins with Purpose

A Neovim configuration can easily drown in plugins. This setup takes the opposite approach: every plugin must solve a problem that cannot be addressed with a few lines of Lua. The result is a lean dashboard where Treesitter provides structural understanding, nvim‑cmp offers intelligent completion, LuaSnip gives programmable snippets, and bufferline keeps tabs visible without visual clutter.

In this final article we open lua/plugins/core.lua – the single file that defines the entire plugin set. We’ll examine why each plugin was chosen, how it’s configured, and how it integrates with the custom functions and snippets we’ve built throughout the series.

The Complete Plugin Specification

Below is the full plugins/core.lua file, broken into sections for discussion.

Themes: Nordic and Tokyonight

Two themes are loaded with lazy = false and high priority, ensuring they are available when colors.lua runs its scheduled setup. Both are configured with transparent backgrounds – Nordic via its transparent option, Tokyonight via transparent = true. The fallback logic (Article #5) means the editor is never without a colourscheme.


{
  "AlexvZyl/nordic.nvim",
  lazy = false,
  priority = 1000,
  config = function()
    require("nordic").setup({
      transparent = {
        bg = true,
        float = true,
      },
    })
    require("nordic").load()
  end,
},

{
  "folke/tokyonight.nvim",
  lazy = false,
  priority = 1000,
  opts = {
    style = "storm",
    transparent = true,
    styles = {
      comments = { italic = true },
      keywords = { italic = true },
    },
  },
},

Telescope: Fuzzy Everything

Telescope is loaded on the Telescope command (not at startup) and provides three essential fuzzy finders: files, live grep, and buffers. The keymaps (<leader>ff, <leader>fg, <leader>fb) are defined in its config callback.


{
  "nvim-telescope/telescope.nvim",
  dependencies = { "nvim-lua/plenary.nvim" },
  cmd = "Telescope",
  config = function()
    local builtin = require("telescope.builtin")
    vim.keymap.set("n", "ff", builtin.find_files)
    vim.keymap.set("n", "fg", builtin.live_grep)
    vim.keymap.set("n", "fb", builtin.buffers)
    vim.keymap.set("n", "fh", builtin.help_tags)
  end,
},

Treesitter: The Backbone

Treesitter provides structural syntax highlighting and indentation. It’s loaded on BufReadPost and BufNewFile – never at startup – and a minimal set of parsers is installed. The highlight and indent modules are enabled; both are non‑negotiable for accurate editing.


{
  "nvim-treesitter/nvim-treesitter",
  build = ":TSUpdate",
  event = { "BufReadPost", "BufNewFile" },
  config = function()
    require("nvim-treesitter.configs").setup({
      ensure_installed = {
        "lua", "python", "javascript", "html", "css", "bash", "c", "cpp", "json", "yaml",
      },
      highlight = { enable = true },
      indent = { enable = true },
    })
  end,
},

nvim-cmp and LuaSnip: The Completion Engine

Completion is the most complex subsystem. nvim-cmp is loaded on InsertEnter and configured with four sources: LSP, LuaSnip, buffer text, and file paths. The snippet expansion is handled by LuaSnip; the Tab key is overloaded to both cycle completion items and expand/advance snippets.

Critically, after cmp.setup(), the configuration loads the snippet files we analysed in Article #4 – config.tex_snippets and config.html_snippets – ensuring snippets are registered before the user starts typing.


{
  "hrsh7th/nvim-cmp",
  dependencies = {
    "hrsh7th/cmp-nvim-lsp",
    "hrsh7th/cmp-buffer",
    "hrsh7th/cmp-path",
    "saadparwaiz1/cmp_luasnip",
    "L3MON4D3/LuaSnip",
  },
  event = "InsertEnter",
  config = function()
    local cmp = require("cmp")
    local luasnip = require("luasnip")

    vim.o.completeopt = "menu,menuone,noselect"

    cmp.setup({
      snippet = {
        expand = function(args)
          luasnip.lsp_expand(args.body)
        end,
      },
      mapping = cmp.mapping.preset.insert({
        [''] = cmp.mapping.complete(),
        [''] = cmp.mapping.confirm({ select = true }),
        [''] = cmp.mapping(function(fallback)
          if cmp.visible() then
            cmp.select_next_item()
          elseif luasnip.expand_or_jumpable() then
            luasnip.expand_or_jump()
          else
            fallback()
          end
        end, { "i", "s" }),
        [''] = cmp.mapping(function(fallback)
          if cmp.visible() then
            cmp.select_prev_item()
          elseif luasnip.jumpable(-1) then
            luasnip.jump(-1)
          else
            fallback()
          end
        end, { "i", "s" }),
      }),
      sources = cmp.config.sources({
        { name = 'nvim_lsp' },
        { name = 'luasnip' },
        { name = 'buffer' },
        { name = 'path' },
      }),
    })

    -- Load LaTeX snippets
    require("config.tex_snippets")
    -- Load HTML snippets
    require("config.html_snippets")
  end,
},

Mason: LSP Without the Pain

Mason manages LSP servers, linters, and formatters. It’s loaded with build = ":MasonUpdate" to ensure the registry is up‑to‑date. The configuration is minimal – just require("mason").setup(). The LSP servers are currently commented out in this configuration, but the infrastructure is ready to be uncommented when needed. Keeping Mason in the plugin list even without active LSP servers means :MasonInstall is always available.


{
  "williamboman/mason.nvim",
  build = ":MasonUpdate",
  config = function() require("mason").setup() end,
},

Bufferline: Visible Tabs, Minimalist

Bufferline shows open buffers as tabs. It’s configured to be as minimal as possible: no close icons, no diagnostics, no numbers, just separator characters between buffer names. always_show_bufferline = true prevents it from disappearing when only one buffer is open.


{
  "akinsho/bufferline.nvim",
  version = "*",
  config = function()
    require("bufferline").setup({
      options = {
        mode = "buffers",
        show_buffer_close_icons = false,
        show_close_icon = false,
        show_tab_indicators = false,
        truncate_names = false,
        diagnostics = false,
        indicator = { style = "none" },
        separator_style = { "|", "|" },
        always_show_bufferline = true,
        numbers = "none",
      },
    })
  end,
},

The Plugin Philosophy: What’s Missing

Equally important is what’s not in this configuration:

No file‑tree plugin – ranger (Article #6) and Telescope cover file navigation without a permanent sidebar.
No statusline plugin – Neovim’s built‑in statusline is sufficient, and custom highlights keep it readable.
No Git gutter – Git operations are handled in the terminal, keeping the editor free of constant change‑tracking visual noise.
No AI completion – completion is limited to deterministic sources: LSP, snippets, buffer words, and file paths.

Every omission is a deliberate choice. Each plugin that is included must justify itself every time the editor starts, and none is loaded until needed.

How the Dashboard Comes Together

When Neovim starts:

init.lua sets options, loads lazy.nvim, and schedules the colour setup.
Lazy.nvim parses plugins/core.lua and begins loading plugins by their lazy‑load triggers (events, commands, keys).
The scheduled callback applies the theme, defines global keymaps and commands.
When a buffer is opened, Treesitter attaches, the appropriate ftplugin fires, and snippets register for that filetype.
On InsertEnter, nvim‑cmp activates with all snippet and LSP sources ready.

At no point does the user wait for a progress bar. The entire plugin set, once cached, starts in under 100 milliseconds. The dashboard is ready before you can think about it.

Closing the Series

Over seven articles, we’ve dissected a Neovim configuration from the bootstrapping layer through filetype engines, automation functions, snippet systems, visual theming, keymaps, and finally the plugin ecosystem. The configuration is fully reproducible: clone the repository, run :Lazy sync, and every file, every function, and every colour is exactly as intended.

The real takeaway is not the specific keybindings or colours, but the engineering mindset: treat your editor as a programmable platform, not a settings file. Build functions, not just mappings. Prefer determinism over convenience defaults. And always be able to explain why every plugin is there.

This configuration will continue to evolve, but the principles documented here are timeless. Happy engineering.

The Toolbelt: Keymaps, User Commands, and File‑Operation Pipelines

2026-05-15T17:39:04+00:00

Turning Functions Into a Control Surface

Custom functions (covered in Article #3) are the engine; keymaps and user commands are the steering wheel and dashboard. A well‑designed Neovim configuration makes the most frequent operations available without a thought – and the less frequent ones discoverable through muscle‑memory shortcuts or short colon commands.

This article opens lua/config/keymaps.lua and lua/config/commands.lua and shows how they form a unified toolbelt. Every mapping is intentionally chosen; every command mirrors a function but adds a discoverability layer. We’ll also examine the ranger file‑chooser integration and the buffer‑wrapping utilities that bridge the editor to external workflows.

The Keymaps Layer

The file lua/config/keymaps.lua is loaded in the scheduled callback of init.lua, after plugins and functions are available. It defines global keybindings that never depend on a specific filetype – filetype‑specific mappings live in ftplugin/ (Article #2). This separation keeps the global mapset clean and predictable.

The complete keymaps file:


local opts = { noremap = true, silent = true }
local functions = require("config.functions")

-- Copy whole file to system clipboard
vim.keymap.set("n", "cc", 'gg"+yG', opts)
vim.keymap.set("v", "", '"+y', opts)
vim.keymap.set("v", "7", '"+y', opts)
vim.keymap.set("i", "", '+', opts)

-- Toggle line numbers
vim.keymap.set("n", "l", ":set number! relativenumber!", opts)

-- redo
vim.keymap.set("n", "r", '', opts)

-- Buffer navigation
vim.keymap.set("n", "", ":bn", opts)
vim.keymap.set("n", "", ":bp", opts)

-- Window movements
vim.keymap.set("n", "", "", opts)
vim.keymap.set("n", "", "", opts)

-- Python selection execution (Visual mode)
vim.keymap.set("v", "c", functions.run_python_selection, { noremap = true })
vim.keymap.set("v", "r", functions.run_python_and_replace, { noremap = true })

-- Run scripts on files/selection
vim.keymap.set("n", "rf", functions.run_scripts_on_files, opts)
vim.keymap.set("v", "rs", functions.run_scripts_on_select, { noremap = true })

-- Basic file commands
vim.keymap.set("n", "w", ":w", opts)
vim.keymap.set("n", "q", ":q", opts)
vim.keymap.set("n", "h", ":nohlsearch", opts)

-- Window navigation using Ctrl + hjkl
vim.keymap.set("n", "", "h", opts)
vim.keymap.set("n", "", "j", opts)
vim.keymap.set("n", "", "k", opts)
vim.keymap.set("n", "", "l", opts)

-- Selection and utility commands
vim.keymap.set("n", "v", functions.select_inside_any_pair, opts)
vim.keymap.set("n", "wc", functions.word_count, opts)
vim.keymap.set("n", "mm", functions.output_old_files, opts)
vim.keymap.set("n", "cc", functions.command_history_explorer, opts)
vim.keymap.set("n", "rr", functions.output_regs, opts)
vim.keymap.set("n", "hh", functions.wrap_code_in_buffer, opts)
vim.keymap.set("n", "ranger", functions.ranger_chooser, opts)


vim.keymap.set("n", "ì", "^", opts)
vim.keymap.set("o", "ì", "^", opts)

local ls = require("luasnip")


-- Forward jump to <++> (now using Ctrl+L)
vim.cmd([[
  inoremap  /<++>"_c4l
  nnoremap  /<++>"_c4l
]])

-- Backward jump to <++> (now using Ctrl+H)
vim.cmd([[
  inoremap  ?<++>"_c4l
  nnoremap  ?<++>"_c4l
]])

-- LuaSnip forward/backward jumps with Ctrl+J / Ctrl+K
vim.keymap.set("i", "", function() require("luasnip").jump(1) end, { silent = true })
vim.keymap.set("i", "", function() require("luasnip").jump(-1) end, { silent = true })

Several design patterns stand out:

Mnemonic leader prefixes: <leader>wc for word count, <leader>cc for command history, <leader>rr for registers. The leader key is , so these are fast two‑stroke combos.
Buffer and window movement: Tab/Shift‑Tab for buffer switching, Ctrl‑hjkl for window navigation. No arrow‑key dependency, minimal finger travel.
Placeholder jumping: Ctrl‑L and Ctrl‑H jump to the next/previous <++> placeholder – a convention used throughout snippets and insert‑mode expansions. This is separate from LuaSnip’s Ctrl‑J/Ctrl‑K for snippet node jumps.
Clipboard shortcuts: cc in normal mode copies the entire file. Ctrl‑c in visual mode copies selection. Ctrl‑v in insert mode pastes.

User Commands: The Discoverable Layer

Keymaps are fast but invisible. User commands (the : interface) serve as the discoverable, self‑documenting counterpart. The file lua/config/commands.lua creates one command per major function:


local functions = require("config.functions")

-- Create user commands
vim.api.nvim_create_user_command("WC", functions.word_count, {})
vim.api.nvim_create_user_command("Mm", functions.output_old_files, {})
vim.api.nvim_create_user_command("MM", functions.output_old_files, {})
vim.api.nvim_create_user_command("Cc", functions.command_history_explorer, {})
vim.api.nvim_create_user_command("CC", functions.command_history_explorer, {})
vim.api.nvim_create_user_command("Ss", functions.search_command_history, {})
vim.api.nvim_create_user_command("SS", functions.search_command_history, {})
vim.api.nvim_create_user_command("Rr", functions.output_regs, {})
vim.api.nvim_create_user_command("RR", functions.output_regs, {})
vim.api.nvim_create_user_command("HH", functions.wrap_code_in_buffer, {})
vim.api.nvim_create_user_command("RangerChooser", functions.ranger_chooser, {})
vim.api.nvim_create_user_command("SaveVimInfo", functions.save_vim_bindings_and_functions, {})
vim.api.nvim_create_user_command("EngType", functions.eng_type, {})
vim.api.nvim_create_user_command("FrType", functions.fr_type, {})

Commands are kept short (often two or three uppercase letters) to minimise typing. A few have dual‑case variants (e.g., :Mm and :MM) – the uppercase version is a deliberate redundancy, ensuring the command still works if Caps Lock is on.

Every command mirrors a function from functions.lua but requires no modifier key. This makes the toolbelt accessible from both muscle‑memory (keymap) and conscious recall (command palette / command history).

The Ranger Chooser: External Tool Integration

The ranger_chooser() function (and its :RangerChooser command) launches the ranger terminal file manager and opens all selected files as Neovim arguments. It detects whether Neovim is running in a GUI or terminal and adapts:


function M.ranger_chooser()
  local temp = vim.fn.tempname()
  if vim.fn.has('gui_running') == 1 then
    vim.fn.system('xterm -e ranger --choosefiles=' .. vim.fn.shellescape(temp))
  else
    vim.fn.system('ranger --choosefiles=' .. vim.fn.shellescape(temp))
  end

  if vim.fn.filereadable(temp) == 0 then
    vim.cmd('redraw!')
    return
  end

  local names = vim.fn.readfile(temp)
  if #names == 0 then
    vim.cmd('redraw!')
    return
  end

  vim.cmd('edit ' .. vim.fn.fnameescape(names[1]))
  for i = 2, #names do
    vim.cmd('argadd ' .. vim.fn.fnameescape(names[i]))
  end
  vim.cmd('redraw!')
end

This is the Unix philosophy in action: let ranger do what it does best (file navigation) and let Neovim do what it does best (editing). The integration is a thin glue layer – a temporary file is used to pass the selected paths back, and Neovim’s argument list (:args) is populated so you can navigate between the chosen files with :next and :prev.

The HH Wrapper: Format Conversion on Demand

The wrap_code_in_buffer() function (bound to <leader>hh and :HH) takes the current buffer’s content and wraps it in <pre><code> tags, opening the result in a new buffer with HTML filetype. This is used constantly when writing articles that embed code blocks.


function M.wrap_code_in_buffer()
  local save_cursor = vim.fn.getpos('.')
  local buffer_text = vim.api.nvim_buf_get_lines(0, 0, -1, false)

  vim.cmd('enew')
  vim.bo.buftype = 'nofile'
  vim.bo.bufhidden = 'wipe'
  vim.bo.swapfile = false
  vim.wo.wrap = false
  vim.bo.filetype = 'html'

  local content = '\n' ..
                  table.concat(buffer_text, "\n") ..
                  '\n'

  vim.api.nvim_buf_set_lines(0, 0, -1, false, vim.split(content, "\n"))
  vim.fn.setpos('.', save_cursor)
end

A similar wrapper exists in the LaTeX ftplugin (Article #2), but this global version works on any buffer. Together they form a small but powerful content pipeline: write in your preferred language, hit a key, get a properly escaped HTML code block ready for the blog.

Composability and Consistency

The keymaps and commands layer follows a strict rule: every keybinding has a corresponding user command, and every command delegates to a single function. There are no inline Vimscript hacks, no copy‑pasted logic. This makes the system:

Auditable: you can trace any action from keypress to function in seconds.
Remappable: changing a keybinding never breaks the command‑line interface, and vice versa.
Documentable: the user commands themselves serve as living documentation.

The toolbelt doesn’t try to do everything – it focuses on operations that are too frequent to type out manually but too specific for a general‑purpose plugin. Combined with the filetype‑specific maps (Article #2) and the snippet system (Article #4), the editor becomes a personalised engineering console.

In the final article, we’ll survey the plugin ecosystem – Treesitter, completion, LSP, and bufferline – and how they complete the developer dashboard.

The Visual Stack: Deterministic Themes, Transparency, and Custom Highlights

2026-05-15T16:43:50+00:00

When the Editor Must Look the Same Everywhere

A developer’s editor is a visual environment. Inconsistent colours, jarring flash‑of‑white on startup, or missing highlights break concentration. This configuration treats the visual layer as a deterministic build step: a fallback colourscheme is set immediately, the real theme loads asynchronously, and a series of overrides applies custom highlights that survive theme updates.

This article walks through lua/config/colors.lua – the single module that governs everything visual. We’ll see how it selects between Nordic and Tokyonight, how it makes almost every UI element transparent, and how it re‑applies critical highlights after every ColorScheme event.

The Fallback Strategy

Inside init.lua, right after the basic options, we call vim.cmd("colorscheme desert"). This is not the final theme – it is a bullet‑proof fallback. If the later scheduled call to colors.setup() fails (for example, because the Nordic plugin is missing or broken), the editor still has a working, readable colourscheme.

The fallback also eliminates the “flash of unstyled text” during startup. By setting desert synchronously, Neovim never renders a completely unstyled buffer before the real theme arrives.

The colors.lua Module

The module is structured as a single setup() function that:

Enables true‑colour support (vim.o.termguicolors = true).
Sets background = "dark".
Attempts to load nordic (the preferred theme). If that fails, it falls back to desert and logs a warning.
Restores number and cursorline settings (some themes override them).
Applies dozens of custom highlight groups for cursor, statusline, search, folds, spelling, line numbers, bufferline, and more.

The entire file is reproduced below. Note how every highlight uses explicit colours (no reference to theme palette variables). This is deliberate: it ensures the highlights look identical whether Nordic or Tokyonight is active.


-- lua/config/colors.lua
-- Colors and highlights configuration (safe + explicit)
local M = {}

function M.setup()
  -- Ensure true color support
  vim.o.termguicolors = true

  -- Preferred background
  vim.o.background = "dark"

  -- Try to load the tokyonight colorscheme safely
  local ok, err = pcall(vim.cmd, "colorscheme nordic")
  if not ok then
    -- Fallback to desert and warn the user in :messages
    vim.cmd("colorscheme desert")
    vim.notify("Warning: Falling back to 'desert'. Error: " .. tostring(err), vim.log.levels.WARN)
  end

  -- Ensure line numbers and cursorline are enabled (set after colorscheme to avoid overrides)
  vim.wo.number = true
  vim.wo.relativenumber = true
  vim.wo.cursorline = true

  -- Then set custom highlight groups
  -- Cursor line / column
  vim.api.nvim_set_hl(0, "CursorLine", { bg = "#3b4261", bold = true })
  vim.api.nvim_set_hl(0, "CursorColumn", { bg = "#3b4261", blend = 80 })
  vim.api.nvim_set_hl(0, "Cursor", { bg = "#2a2e38", fg = "#ffffff", blend = 70 })
  -- Perfect cursor for Nordic: subtle blue, visible, does not obscure text
  vim.api.nvim_set_hl(0, "Cursor", {
    bg = "#434C5E",  -- softer Nordic blue
    fg = "#ECEFF4",  -- visible over any code
    blend = 60       -- transparency so text stays readable underneath
  })

  -- Status line and visual selection
  vim.api.nvim_set_hl(0, "StatusLine", { bg = "#1f2335", fg = "#c0caf5", bold = true })
  vim.api.nvim_set_hl(0, "Visual", { bg = "#FFD966", fg = "black" })

  -- Fold / Search
  vim.api.nvim_set_hl(0, "Folded", { bg = "none", fg = "#737aa2", italic = true })
  vim.api.nvim_set_hl(0, "Search", { bg = "#ff9e64", fg = "black", bold = true })

  -- Spell checking highlights
  vim.api.nvim_set_hl(0, "SpellBad", { underline = true, sp = "#db4b4b" })
  vim.api.nvim_set_hl(0, "SpellLocal", { underline = true, sp = "#0db9d7" })
  vim.api.nvim_set_hl(0, "SpellRare", { underline = true, sp = "#bb9af7" })
  vim.api.nvim_set_hl(0, "SpellCap", { underline = true, sp = "#e0af68" })

  -- Line number colors
  vim.api.nvim_set_hl(0, "LineNr", { fg = "#FFFF00" })
  vim.api.nvim_set_hl(0, "CursorLineNr", { fg = "#c0caf5", bold = true })

  -- BufferLine colors
  vim.api.nvim_set_hl(0, "BufferLineBufferSelected", { bold = true, fg = "#ffca00" })
  vim.api.nvim_set_hl(0, "BufferLineModifiedSelected", { fg = "#ff9e64" })
end

-- Final transparency patch (works for all themes)
local transparent_groups = {
  "Normal", "NormalNC", "NormalFloat",
  "SignColumn", "MsgArea",
  "TelescopeNormal", "TelescopeBorder",
  "StatusLine", "StatusLineNC",
  "BufferLineFill", "BufferLineBackground",
  "LineNr", "CursorLineNr",
  "FloatBorder",
}

for _, group in ipairs(transparent_groups) do
  vim.api.nvim_set_hl(0, group, { bg = "none" })
end

-- Reapply custom highlight after everything is loaded
vim.api.nvim_create_autocmd({"ColorScheme", "User"}, {
  pattern = {"LazyDone", "VeryLazy"},
  callback = function()
    vim.api.nvim_set_hl(0, "MatchParen", { bg = "#ff33aa", fg = "#000000", bold = true })
    vim.api.nvim_set_hl(0, "MatchParenCur", { bg = "#ff33aa", fg = "#000000", bold = true })
    vim.api.nvim_set_hl(0, "MatchWord",  { bg = "#5555ff", fg = "#000000" })
  end,
})

return M

Transparency as a Design Decision

The bottom half of the file sets bg = "none" on a carefully chosen set of highlight groups. Groups like Normal, SignColumn, FloatBorder, and BufferLineBackground become transparent, letting the terminal background show through. This creates a clean, borderless look that works with any terminal colour scheme.

Groups that must remain opaque (e.g., CursorLine, Visual, Search) are explicitly given backgrounds, so readability is never compromised. The separation is deliberate: structural UI elements become transparent, content‑focused elements keep their solid backgrounds.

The Autocommand That Fixes Everything

Some plugin managers or theme reloads can reset highlight groups. To combat this, the file registers an autocommand on ColorScheme and User events (specifically LazyDone and VeryLazy) that re‑applies a set of critical highlights:

MatchParen and MatchParenCur – a bright pink background that makes matching brackets unmistakable.
MatchWord – a blue background for the word under cursor when using * or #.

By re‑applying these after every theme change, the configuration guarantees that your most important visual cues never disappear.

Why Not Just Use a Theme’s Variables?

Many colour configurations use theme palette variables (e.g., colors.blue) so that highlight groups automatically adapt to the current theme. This configuration intentionally avoids that. By using raw hex codes, it decouples the custom highlights from any particular theme’s palette. Whether you’re running Nordic, Tokyonight, or fallback Desert, the cursor line is always #3b4261, the search highlight is always #ff9e64, and matching brackets always explode in pink.

The tradeoff is that you must choose colours that work across multiple themes. The benefit is absolute determinism – the visual experience does not shift when you change or update a theme.

The Full Picture

Together, the fallback colourscheme, the scheduled theme application, the transparent UI groups, and the autocommand re‑application create a visual stack that is:

Resilient: the editor always starts with a functional theme.
Consistent: custom highlights never depend on which theme loads.
Clean: transparency removes visual noise.
Reproducible: the same hex values produce the same pixels on any machine.

In the next article, we’ll explore the keymaps and commands that wire all these subsystems together into a unified user interface.

Snippets as Code: LuaSnip, Dynamic Expansion, and File‑Based Snippet Injection

2026-05-15T16:33:12+00:00

Snippets Should Be Logic, Not Just Text

Most snippet systems treat expansions as static templates: you type a trigger, you get a fixed block of text. LuaSnip in Neovim allows something far more powerful – snippets can run Lua functions, read external files, and adapt to the current file or directory. This turns snippet expansion into a programmable, context‑aware automation layer.

In this article we open the two snippet configuration files that power LaTeX, HTML, and Markdown editing: lua/config/tex_snippets.lua and lua/config/html_snippets.lua. We’ll examine how they replace a legacy directory of static snippet files, how they integrate with nvim-cmp, and how they enable everything from auto‑numbered exercises to inline HTML figure injection.

The Legacy Problem

Before LuaSnip, Neovim relied on snippet engines like UltiSnips or external files stored in ~/.vim/snippets/. Those files were plain text, loaded once, and had no runtime intelligence. This configuration migrated to LuaSnip for three reasons:

Reproducibility: everything lives in Lua, no external directories to sync.
Dynamic behaviour: snippets can count existing environments, query the current directory, and insert content based on context.
Integration with native completion: LuaSnip plugs directly into nvim-cmp as a source, so snippets appear in the autocompletion menu.

The old snippet files still exist (in ~/.vim/snippets/latex/) but are now consumed by LuaSnip functions that read their content on demand, preserving the original text blocks while adding programmability.

The html_snippets.lua: Straightforward but Complete

HTML and Markdown share three core snippets: anchor links, figure/image blocks, and code blocks. Each is defined using LuaSnip’s node types: s() for the snippet, i() for insert‑node placeholders, t() for text, and f() for function nodes that compute values at expansion time.

The code block snippet is particularly clever: it uses a function node to duplicate the language name so it appears both in the <pre class="language-…"> and the <code class="language-…"> tags, avoiding manual repetition. The snippet also wraps the body in … tags – a nod to Jinja2 templates used in static site generation – to prevent Liquid/Jinja syntax from being parsed inside code blocks.


local ls = require("luasnip")
local s = ls.snippet
local i = ls.insert_node
local t = ls.text_node
local f = ls.function_node

-- Define snippets once
local snippets = {
  -- Anchor link
  s("a", {
    t(''), i(2, "link text"), t(""), i(0),
  }),

  -- Figure with img and figcaption
  s("fig", {
    t(""),
    t({ "", "    " }),
    t(''),
    t({ "", "    " }),
    t(""), i(3, "caption"), t(""),
    t({ "", "" }),
    i(0),
  }),

-- Enable for both HTML and Markdown files
ls.add_snippets("html", snippets)
ls.add_snippets("markdown", snippets)

The tex_snippets.lua: A Snippet Engine for LaTeX

LaTeX editing demands a much richer set of snippets. The tex_snippets.lua file exports two things: a table of functions for direct insertion (called by the LaTeX ftplugin), and a collection of LuaSnip snippet definitions. It uses three design patterns:

Environment snippets with auto‑closing: env_snip() creates a snippet that inserts \begin{…} and \end{…} with the environment name mirrored via a function node.
Auto‑numbered exercises: the exe snippet counts how many \begin{exe} environments already exist in the buffer and inserts the next number automatically.
External file injection: file_snippet() reads a file from ~/.vim/snippets/latex/ and inserts its content as the snippet body, bridging the legacy snippet directory.

The curr_file_base_name() helper reads the numeric prefix of the current working directory, used by cse and similar snippets to auto‑label sections (e.g., \csection[01-exer]{…}). This is a deterministic system: the same directory always produces the same numbering.


local ls = require("luasnip")
local s = ls.snippet
local i = ls.insert_node
local t = ls.text_node
local f = ls.function_node

local M = {}

-- Helper to create environment snippet with jumpable placeholder
local function env_snip(trigger, default_env)
  return s(trigger, {
    t({"\\begin{"}), i(1, default_env), t({"}", "    <++>"}),  -- insert <++> as literal text
    t({"", "\\end{"}), f(function(args) return args[1][1] end, {1}), t("}")
  })
end

-- Helper to get the first part of current directory name
local function curr_file_base_name()
  local cwd = vim.fn.system("basename $(pwd) | cut -d'-' -f1")
  return cwd:gsub("\n", "")
end

-- =============================
-- Native LuaSnip LaTeX snippets
-- =============================
ls.add_snippets("tex", {
  env_snip("beg", "tabular"),
  env_snip("eq", "equation"),
  env_snip("mat", "bmatrix"),

  -- Sections
  s("sec", { t("\\section{"), i(1,"Title"), t({"", "    <++>"}), t("}") }),
  s("ssec", { t("\\subsection{"), i(1,"Subtitle"), t({"", "    <++>"}), t("}") }),

  -- Items and math
  s("itm", { t("\\item "), t("<++>") }),
  s("dollar", { t("$"), t("<++>"), t("$") }),
  s("frac", {
     t("\\frac{"), i(1), t("}{"), i(2), t("}"), i(0)
  }),
  s("sum", { t("\\sum_{"), t("<++>"), t("}^{"), t("<++>"), t("} "), t("<++>") }),

  -- =============================
  -- Exercise environment with auto-number
  -- =============================
  s("exe", {
    t("\\begin{exe}{"), i(1, "<++>"), t("}"),
    t({"", "    "}), f(function()
      local count = 0
      for _, line in ipairs(vim.api.nvim_buf_get_lines(0, 0, -1, false)) do
        if line:match("\\begin{exe}") then count = count + 1 end
      end
      return tostring(count)
    end, {}),
    t({"", "    <++>", "\\end{exe}"}),
  }),

  -- Sexe environment
  s("sex", {
    t({"\\begin{sexe}{", ""}), i(1, "<++>"), t({"", "    <++>", "\\end{sexe}"})
  }),

  -- Minipage snippet
  s("mini", {
    t({"\\begin{minipage}[t]{"}), i(1, "<++>"), t("\\textwidth}"), t({"", "    <++>", "\\end{minipage}", "\\hspace*{0.1cm}", "\\vl{0}{5}", "\\hspace*{0.1cm}", "\\begin{minipage}[t]{"}),
    i(2, "<++>"), t("\\textwidth}"), t({"", "    <++>", "\\end{minipage}"})
  }),

  -- Standalone document
  s("stand", {
    t({"\\documentclass{standalone}", "\\standaloneconfig{margin=5mm}"})
  }),
})

-- Section snippets using the directory prefix
ls.add_snippets("tex", {
  -- csection
  s("cse", {
    t({"\\vspace*{0.3cm}", "\\csection["}),
    t(curr_file_base_name() .. "-"), i(1, "exer"),
    t({"]{"}),
    f(function(args) return args[1] end, {1}),
    t({"}\\\\", "\\vspace*{0.3cm}"})
  }),

  -- cssection
  s("csse", {
    t({"\\vspace*{0.3cm}", "\\cssection["}),
    t(curr_file_base_name() .. "-"), i(1, "exer"),
    t({"]{"}),
    f(function(args) return args[1] end, {1}),
    t({"}\\\\", "\\vspace*{0.3cm}"})
  }),

  -- csssection
  s("cssse", {
    t({"\\vspace*{0.3cm}", "\\csssection["}),
    t(curr_file_base_name() .. "-"), i(1, "exer"),
    t({"]{"}),
    f(function(args) return args[1] end, {1}),
    t({"}\\\\", "\\vspace*{0.3cm}"})
  }),
})

-- =============================
-- Helper to load old snippet files dynamically
-- =============================
local function read_file(path)
  local lines = {}
  for line in io.lines(path) do
    table.insert(lines, line)
  end
  return lines
end

local function file_snippet(trigger, filepath)
  return s(trigger, f(function() return read_file(filepath) end, {}))
end

-- =============================
-- Old external snippet files as LuaSnip snippets
-- =============================
ls.add_snippets("tex", {
  file_snippet("tcb", "/home/mosaid/.vim/snippets/latex/tcb"),
  file_snippet("ds",  "/home/mosaid/.vim/snippets/latex/ds"),
  file_snippet("st",  "/home/mosaid/.vim/snippets/latex/st"),
  file_snippet("ar",  "/home/mosaid/.vim/snippets/latex/ar"),
  file_snippet("gg",  "/home/mosaid/.vim/snippets/latex/gg"),
  file_snippet("mtab","/home/mosaid/.vim/snippets/latex/mtab"),
  file_snippet("d1",  "/home/mosaid/.vim/snippets/latex/d1"),
  file_snippet("li",  "/home/mosaid/.vim/snippets/latex/li"),
  file_snippet("tight","/home/mosaid/.vim/snippets/latex/tight"),
  file_snippet("enum","/home/mosaid/.vim/snippets/latex/enum"),
})

-- Define the functions that tex.lua is trying to call
M.tcb = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/tcb")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

M.ds = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/ds")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

M.st = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/st")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

M.ar = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/ar")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

M.gg = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/gg")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

M.mtab = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/mtab")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

M.d1 = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/d1")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

M.li = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/li")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

M.tight = function()
  local lines = read_file("/home/mosaid/.vim/snippets/latex/tight")
  local cursor = vim.api.nvim_win_get_cursor(0)
  vim.api.nvim_buf_set_lines(0, cursor[1] - 1, cursor[1] - 1, false, lines)
end

return M

The Dual Nature: Snippets and Functions

Notice that tex_snippets.lua defines both LuaSnip snippets and a set of functions (M.tcb(), M.ds(), etc.). The LaTeX ftplugin (from Article #2) calls these functions directly via insert‑mode mappings like <ESC>:lua require("config.tex_snippets").tcb()<CR>. This hybrid approach gives the user two ways to trigger an expansion:

Through the built‑in completion menu (LuaSnip integration with nvim-cmp).
Through muscle‑memory insert‑mode shortcuts that bypass the completion menu entirely.

The external file snippets are loaded lazily – they aren’t read from disk until the trigger is activated, keeping startup fast. The file_snippet() wrapper ensures that the content stays up‑to‑date with any external edits, making the transition from static snippet files seamless.

Integration with nvim-cmp

Snippets are useless without a good completion interface. The plugins/core.lua configures nvim-cmp to use luasnip as a source:


sources = cmp.config.sources({
  { name = 'nvim_lsp' },
  { name = 'luasnip' },
  { name = 'buffer' },
  { name = 'path' },
}),

The luasnip source is automatically populated with all snippets defined for the current filetype. Additionally, the cmp mapping for <Tab> prioritises snippet expansion over completion navigation – if a snippet is expandable, it expands; otherwise it cycles to the next completion item.

This design ensures that snippets feel like a native part of the editor, not an external bolted‑on feature.

Determinism and Portability

Every snippet in this configuration is defined in Lua, with no external dependencies except the legacy snippet files (which are themselves plain text). The auto‑numbering relies on scanning the current buffer, not on any global state. The directory‑based prefix uses a shell command that is explicitly deterministic.

This means you can clone the Neovim configuration to a new machine, run :Lazy sync, and immediately have the same snippet behaviour. No manual copying of snippet directories, no version mismatches.

In the next article, we’ll examine the visual stack: how themes, transparency, and custom highlights are applied with the same deterministic philosophy.

Automation, Not Just Shortcuts: Custom Functions that Think Like an IDE

2026-05-15T15:54:31+00:00

Beyond Keymaps: Functions as First‑Class Tools

Most Neovim users start by remapping keys. That’s fine, but it stops short of turning the editor into a programmable environment. The real power comes from custom Lua functions that do things no plugin can anticipate: running code asynchronously, replacing visual selections with computed results, exploring your command history like a file, or inspecting registers at a glance.

In this article we open lua/config/functions.lua – the heart of the automation layer – and walk through every major utility. You’ll see the full source for each function, understand why it was built, and learn how to wire it into your own workflow.

Architecture Overview

The file lua/config/functions.lua exports a table of functions. These are called from keymaps (defined in keymaps.lua) and user commands (defined in commands.lua). The module is loaded once during startup and reused everywhere.

The directory structure relevant to this article:


lua/config/
├── functions.lua     <-- all custom logic
├── keymaps.lua       <-- maps keys to functions
└── commands.lua      <-- creates :UserCommands

1. Async Python and LaTeX Runners

Two of the most frequently used functions are run_python_selection() and run_python_and_replace(). The first executes the visually selected Python code in a non‑blocking job, appending its output to a scratch buffer. The second does the same, but replaces the selection with the output – ideal for quick calculations directly in your code or prose.

Both functions use vim.fn.jobstart to avoid freezing the UI, and they automatically handle buffer cleanup when the job finishes or the user presses Enter. A similar async pattern is used in the LaTeX ftplugin (covered in Article #2), but the core helper functions are general enough to be reused for any language.


function M.run_python_selection()
  -- Check if in visual mode
  local mode = vim.fn.mode()
  if mode ~= 'v' and mode ~= 'V' then
    print("No visual selection")
    return
  end

  -- Save current register
  local save_reg = vim.fn.getreg('"')
  local save_regtype = vim.fn.getregtype('"')

  -- Yank selection into default register
  vim.cmd('normal! gvy')
  local code = vim.fn.getreg('"')

  -- Restore original register
  vim.fn.setreg('"', save_reg, save_regtype)

  -- Trim whitespace and prepend math import
  code = code:gsub('^%s*', ''):gsub('%s*$', '')
  code = "from math import *\n" .. code

  -- Execute Python code safely
  local ok, output = pcall(vim.fn.system, {'python3', '-c', code})
  if not ok then
    print("Error executing Python code")
    return
  end

  -- Open scratch buffer
  vim.cmd('enew')
  vim.api.nvim_buf_set_lines(0, 0, -1, false, vim.split(output, "\n"))

  -- Configure buffer
  vim.bo.buftype = 'nofile'
  vim.bo.bufhidden = 'wipe'
  vim.bo.swapfile = false
  vim.wo.wrap = false
end

The run_python_and_replace() variant handles single‑line selections specially: it wraps the expression in a print() so that the output replaces the expression inline. This is useful for evaluating math expressions inside Markdown or LaTeX documents.


function M.run_python_and_replace()
  local save_reg = vim.fn.getreg('"')
  local save_regtype = vim.fn.getregtype('"')
  vim.cmd('normal! ""gvy')
  local code = vim.fn.getreg('"')
  vim.fn.setreg('"', save_reg, save_regtype)

  code = code:gsub('^%s*', ''):gsub('%s*$', '')

  local start_line = vim.fn.line("'<")
  local end_line = vim.fn.line("'>")
  if start_line == end_line then
    code = 'print(' .. code .. ')'
  end

  code = "from math import *\n" .. code
  local output = vim.fn.system('python3 -c ' .. vim.fn.shellescape(code))
  output = output:gsub('\n+$', '')

  vim.cmd('normal! gv"_c' .. output)
end

2. Command History Explorer

The command‑line history in Vim is powerful but invisible. My command_history_explorer() function dumps the entire history (newest first) into a temporary buffer. You can navigate it with j/k or arrow keys, and pressing Enter executes the command under the cursor. Pressing q or Tab closes the buffer.

This effectively gives you a “command palette” with zero dependencies. Because the buffer is non‑modifiable and immediately searchable with /, you can filter through hundreds of past commands in seconds.


function M.command_history_explorer()
  local history = {}
  local count = vim.fn.histnr(':') -- number of commands in history

  -- Collect commands from newest to oldest
  for i = count, 1, -1 do
    local cmd = vim.fn.histget(':', i)
    if cmd ~= "" then
      table.insert(history, cmd)
    end
  end

  -- Create new buffer
  vim.cmd('enew')
  local buf = vim.api.nvim_get_current_buf()

  vim.api.nvim_buf_set_lines(buf, 0, -1, false, history)

  -- Buffer options
  vim.bo[buf].buftype = 'nofile'
  vim.bo[buf].bufhidden = 'wipe'
  vim.bo[buf].swapfile = false
  vim.bo[buf].modifiable = false
  vim.wo.wrap = false

  local opts = { buffer = buf, noremap = true, silent = true }

  -- Map arrow keys (raw sequences)
  vim.keymap.set('n', "\27[B", 'j', opts) -- Down
  vim.keymap.set('n', "\27[A", 'k', opts) -- Up

  -- Also allow hjkl
  vim.keymap.set('n', 'j', 'j', opts)
  vim.keymap.set('n', 'k', 'k', opts)

  -- Quit buffer quickly
  vim.keymap.set('n', 'q', function() vim.cmd('bd! ' .. buf) end, opts)

  -- Execute the command under cursor
  vim.keymap.set('n', '', function()
    local cmd = vim.fn.getline('.')
    vim.cmd('bd! ' .. buf) -- close history buffer
    vim.cmd(cmd)           -- execute command
  end, opts)

  -- Start at the top
  vim.cmd('normal! gg')
end

A variant, search_command_history(), opens a modifiable buffer so that incsearch can highlight matches. This is useful when you want to interactively search without closing the buffer.

3. Register Inspector

Registers are one of Vim’s most powerful features, yet most users never know what’s stored in them. The output_regs() function prints the contents of registers a through z into a scratch buffer, labelled clearly. It’s a simple idea, but it turns registers into a visible, reviewable tool.


function M.output_regs()
  vim.cmd('enew')
  vim.bo.buftype = 'nofile'
  vim.bo.bufhidden = 'wipe'
  vim.bo.swapfile = false
  vim.wo.wrap = false

  local content = {}
  for reg = string.byte('a'), string.byte('z') do
    local reg_char = string.char(reg)
    local reg_content = vim.fn.getreg(reg_char)
    if reg_content ~= '' then
      table.insert(content, reg_char .. ":")
      table.insert(content, reg_content)
      table.insert(content, "")
    end
  end

  vim.api.nvim_buf_set_lines(0, 0, -1, false, content)
  vim.cmd('normal! gg')
  print("Contents of registers a to z")
end

4. Select Inside Any Pair

Vi’s i{, i(, etc. are great, but they require you to think about which delimiter you’re inside. select_inside_any_pair() tries every common pair ({}, [], (), $...$ , quotes) and selects the innermost one that surrounds the cursor. If nothing matches, it falls back to selecting the current line.


function M.select_inside_any_pair()
  local savepos = vim.fn.getpos('.')
  local pairs = {
    {'{', '}'},
    {'[', ']'},
    {'(', ')'},
    {'$', '$'},
    {'"', '"'},
    {"'", "'"}
  }

  for _, pair in ipairs(pairs) do
    local open, close = pair[1], pair[2]
    local start, finish

    if open == close then
      start = vim.fn.searchpos('\\V' .. open, 'bnW')
      finish = vim.fn.searchpos('\\V' .. close, 'nW')
    else
      start = vim.fn.searchpairpos('\\V' .. open, '', '\\V' .. close, 'bnW')
      finish = vim.fn.searchpairpos('\\V' .. open, '', '\\V' .. close, 'nW')
    end

    if start[1] > 0 and finish[1] > 0 then
      local cur = vim.fn.getpos('.')
      local start_before_cursor = (start[1] < cur[2]) or (start[1] == cur[2] and start[2] <= cur[3])
      local finish_after_cursor = (finish[1] > cur[2]) or (finish[1] == cur[2] and finish[2] >= cur[3])

      if start_before_cursor and finish_after_cursor then
        vim.fn.setpos('.', {0, start[1], start[2] + 1, 0})
        vim.cmd('normal! v')
        vim.fn.setpos('.', {0, finish[1], finish[2], 0})
        vim.cmd('normal! h')
        return
      end
    end
  end

  -- Fallback: select current line
  local lnum = vim.fn.line('.')
  local line = vim.fn.getline(lnum)
  local end_col = #line
  if end_col > 0 and line:sub(-1) == '$' then
    end_col = end_col - 1
  end

  vim.fn.setpos('.', {0, lnum, 1, 0})
  vim.cmd('normal! v')
  vim.fn.setpos('.', {0, lnum, end_col, 0})
end

5. Old Files Browser and Ranger Chooser

Vim stores recently opened files in vim.v.oldfiles. output_old_files() dumps them into a buffer, making each entry a link you can press Enter on to open. This is a lightweight alternative to Telescope for quickly revisiting files without fuzzy matching.

The ranger_chooser() function integrates the ranger file manager directly into the editor: it runs ranger --choosefiles in a terminal (or XTerm if a GUI is detected) and opens all selected files as arguments. This fits the philosophy of using external, best‑in‑class tools while keeping the editor as the central hub.


function M.output_old_files()
  vim.cmd('enew')
  vim.api.nvim_buf_set_lines(0, 0, -1, false, vim.v.oldfiles)
  vim.bo.buftype = 'nofile'
  vim.bo.bufhidden = 'wipe'
  vim.bo.swapfile = false
  vim.wo.wrap = false

  vim.keymap.set('n', '', function()
    local line = vim.fn.getline('.')
    vim.cmd('e ' .. line)
  end, { buffer = true })

  local buf = vim.api.nvim_get_current_buf()
  vim.keymap.set('n', 'q', function() vim.cmd('bd! ' .. buf) end, { buffer = buf, noremap = true, silent = true })
  vim.keymap.set('n', '', function() vim.cmd('bd! ' .. buf) end, { buffer = buf, noremap = true, silent = true })
  vim.cmd('normal! gg')
end

6. Word Count, URL Maker, and Directory Prefix

Several smaller utilities fill in the gaps:

word_count() – runs detex on a LaTeX file and pipes it through wc -w to count plain‑text words (ignoring markup).
make_url(word) – replaces every occurrence of a word with an HTML link pointing to https://word.com. Useful for quickly linking to domains in blog articles.
get_dir_number() – extracts the leading numeric prefix of the current working directory, used in LaTeX snippet auto‑numbering.

7. Save Bindings and Functions

save_vim_bindings_and_functions() captures all current key mappings and function definitions into a buffer. This is invaluable for debugging or documenting your setup. It uses Vim’s :redir mechanism to capture the output of :map and :function and writes them into a scratch buffer.

Integration: Keymaps and Commands

These functions are exposed through two files:


-- keymaps.lua (excerpt)
vim.keymap.set("v", "c", functions.run_python_selection, { noremap = true })
vim.keymap.set("v", "r", functions.run_python_and_replace, { noremap = true })
vim.keymap.set("n", "wc", functions.word_count, opts)
vim.keymap.set("n", "mm", functions.output_old_files, opts)
vim.keymap.set("n", "cc", functions.command_history_explorer, opts)
vim.keymap.set("n", "rr", functions.output_regs, opts)
vim.keymap.set("n", "ranger", functions.ranger_chooser, opts)


-- commands.lua (excerpt)
vim.api.nvim_create_user_command("WC", functions.word_count, {})
vim.api.nvim_create_user_command("Mm", functions.output_old_files, {})
vim.api.nvim_create_user_command("Cc", functions.command_history_explorer, {})
vim.api.nvim_create_user_command("Ss", functions.search_command_history, {})
vim.api.nvim_create_user_command("Rr", functions.output_regs, {})
vim.api.nvim_create_user_command("HH", functions.wrap_code_in_buffer, {})
vim.api.nvim_create_user_command("RangerChooser", functions.ranger_chooser, {})
vim.api.nvim_create_user_command("EngType", functions.eng_type, {})
vim.api.nvim_create_user_command("FrType", functions.fr_type, {})

User commands (e.g., :WC, :Cc) are intentionally uppercase and short to minimise typing. Keymaps are mnemonic: <leader>cc for command history, <leader>rr for registers, etc.

Design Philosophy: Functions as Infrastructure

The unifying principle behind these utilities is that they treat Neovim as a programmable platform, not just a text editor. Each function solves a concrete, recurring need in the developer’s daily workflow:

Async execution – never block the UI.
Scratch buffers – temporary, non‑file buffers that clean up after themselves.
Explicit buffer management – every function that opens a buffer also defines how to close it (q or bd!).
Pure Lua, no plugin dependencies – everything runs on the built‑in API, making the config portable.

The result is an editor that behaves like an IDE, but without the weight. In the next article, we’ll see how snippets push this automation even further, turning tiny triggers into large, context‑aware code blocks.

Per‑Filetype Engineering: Tailoring Neovim for Python, LaTeX, HTML, and Markdown

2026-05-15T15:31:53+00:00

Context is Everything

A general‑purpose editor can only take you so far. The moment you switch from a Python script to a LaTeX document, your brain expects different indentation, different macros, and different ways to manipulate the text. A well‑engineered Neovim configuration reacts to filetypes not as an afterthought, but as a first‑class design principle.

In this second article of the series, we open the ftplugin/ directory and the shared mapping modules that give each language its own personality – without duplicating logic. We'll walk through the full source of every relevant file, explaining the reasoning behind each buffer‑local option, each insert‑mode expansion, and each visual‑mode wrapping command.

The ftplugin Mechanism

Neovim automatically sources Lua files in ~/.config/nvim/ftplugin/ when a buffer's filetype matches the filename (e.g., python.lua for Python files). This is the official way to inject buffer‑local settings without polluting global configuration. Everything we set in these files is scoped to the current buffer, so you can have 2‑space indentation for HTML and 4‑space for Python simultaneously.

Our ftplugin files do three things:

Set buffer‑local options (tabstop, shiftwidth, textwidth, etc.).
Define insert‑mode keymaps that expand into larger code constructs (e.g., typing if becomes if :<++> in Python).
Call shared mapping modules to apply visual‑mode wrappers and other common utilities.

This last point is crucial: HTML and Markdown share a large set of visual mappings (wrapping text in <p>, <h2>, etc.), so we centralise that logic in lua/config/html_markdown_maps.lua and require it from both ftplugins. No duplication, no drift.

Python: 4‑Space Indentation and Quick Constructs

The Python ftplugin sets tabstop=4, shiftwidth=4, and textwidth=88 (PEP 8 line length). It also defines two normal‑mode mappings: <leader>c to run the buffer asynchronously in a scratch buffer, and <leader>i to open an interactive REPL in a vertical split.

The insert‑mode mappings are a collection of shorthand triggers: typing if expands to if :<++> with the cursor placed after the colon, def expands to def ():<++>, and so on. The <++> placeholders are jump targets (navigated with Ctrl‑L / Ctrl‑H) that appear in many languages throughout the config. This gives a consistent, muscle‑memory‑based editing flow.


-- Python-specific settings
vim.bo.tabstop = 4
vim.bo.shiftwidth = 4
vim.bo.expandtab = true
vim.bo.textwidth = 88  -- PEP 8 line length

-- Run Python code and display output in a scratch buffer
local function run_python_buffer()
  local current_file = vim.fn.expand("%")

  -- Create scratch buffer
  vim.cmd("enew")
  local buf = vim.api.nvim_get_current_buf()

  -- Buffer settings
  vim.bo[buf].buftype = "nofile"
  vim.bo[buf].bufhidden = "wipe"
  vim.bo[buf].swapfile = false
  vim.bo[buf].filetype = "python"

  vim.wo.wrap = false
  vim.wo.number = true
  vim.wo.relativenumber = true

  vim.api.nvim_buf_set_lines(buf, 0, -1, false, {
    "Running Python script...",
    "File: " .. current_file,
    ""
  })

  local function append_lines(lines)
    if vim.api.nvim_buf_is_valid(buf) and lines then
      vim.api.nvim_buf_set_lines(buf, -1, -1, false, lines)
      -- Scroll to bottom
      local last = vim.api.nvim_buf_line_count(buf)
      vim.api.nvim_win_set_cursor(0, { last, 0 })
    end
  end

  -- Start async job
  local job_id
  job_id = vim.fn.jobstart({ "python3", current_file }, {
    stdout_buffered = false,
    stderr_buffered = false,

    on_stdout = function(_, data)
      append_lines(data)
    end,

    on_stderr = function(_, data)
      append_lines(data)
    end,

    on_exit = function(_, exit_code)
      append_lines({
        "",
        "Execution finished (exit code: " .. exit_code .. ")",
      })

      -- Only set keymap if buffer still exists
      if vim.api.nvim_buf_is_valid(buf) then
        vim.keymap.set("n", "<CR>", function()
          if job_id then vim.fn.jobstop(job_id) end
          if vim.api.nvim_buf_is_valid(buf) then
            vim.cmd("bd!")
          end
        end, { buffer = buf })
      end
    end,
  })

  -- Kill job if buffer is wiped
  vim.api.nvim_create_autocmd("BufWipeout", {
    buffer = buf,
    once = true,
    callback = function()
      if job_id then vim.fn.jobstop(job_id) end
    end,
  })
end

-- Normal mode mappings for Python
vim.keymap.set('n', '<leader>c', run_python_buffer, { buffer = true, desc = "Run Python buffer" })
vim.keymap.set('n', '<leader>i', function()
  vim.cmd('TermExec cmd="python3 -i %" direction=vertical size=60')
end, { buffer = true, desc = "Interactive Python REPL" })

-- Insert mode mappings for Python
local insert_maps = {
  ['if'] = 'if :<++><ESC>F:a',
  ['for'] = 'for in :<++><ESC>F:i',
  ['def'] = 'def ():<++><ESC>F(a',
  ['class'] = 'class :<++><ESC>F:a',
  ['imp'] = 'import ',
  ['from'] = 'from import <++><ESC>F:i',
  ['try'] = 'try:<CR><++><CR>except:<CR><++><ESC>kkk0f:a',
  ['print'] = 'print()<++><ESC>F(a',
  ['main'] = 'if __name__ == "__main__":<CR><++><ESC>k0f:a',
  [';dv'] = '"""<CR><CR>"""<ESC>kA',
}

for lhs, rhs in pairs(insert_maps) do
  vim.keymap.set('i', lhs, rhs, { buffer = true })
end

LaTeX: Compilation Pipeline and Rich Snippets

The LaTeX ftplugin is the largest of the set. It sets 2‑space indentation and provides normal‑mode mappings to compile with xelatex (<leader>c), open the resulting PDF (<leader>o), and wrap the entire buffer in <pre><code> tags for blog post inclusion (<leader>w). The compilation runs asynchronously in a scratch buffer, outputting both stdout and stderr.

Insert‑mode mappings cover everything from single‑character overrides (e.g., ! inserts a backslash) to complex environment expansions (e.g., ,tcb inserts a custom tcb environment by calling a Lua function). Visual‑mode mappings allow wrapping selected text in \textbf, \underline, math mode, and custom colour boxes – all through muscle‑memory shortcuts.

Note the use of a helper to extract the current directory's numeric prefix: this is used to auto‑number exercises in LaTeX snippets defined elsewhere (we'll cover snippet design in article #4). For now, the important insight is that ftplugin files can access shared helper modules and even call Lua functions from snippet libraries.



-- LaTeX-specific settings
vim.bo.tabstop = 2
vim.bo.shiftwidth = 2
vim.bo.expandtab = true

-- Set global variable with filename
local get_curr_file_base_name = function()
  local handle = io.popen("basename $(pwd) | cut -d'-' -f1")
  local result = handle:read("*a")
  handle:close()
  return result:gsub('\n', '')
end

vim.g.curr_file_base_name = get_curr_file_base_name()

-- Run LaTeX compilation asynchronously in a scratch buffer
local function run_tex()
  local current_file = vim.fn.expand("%")
  local pdf_file = vim.fn.expand("%:p:r") .. ".pdf"

  -- Create scratch buffer
  vim.cmd("enew")
  local buf = vim.api.nvim_get_current_buf()

  -- Buffer settings
  vim.bo[buf].buftype = "nofile"
  vim.bo[buf].bufhidden = "wipe"
  vim.bo[buf].swapfile = false
  vim.bo[buf].filetype = "texlog"

  vim.wo.wrap = false
  vim.wo.number = true
  vim.wo.relativenumber = true

  vim.api.nvim_buf_set_lines(buf, 0, -1, false, {
    "Compiling with xelatex, please wait...",
    ""
  })

  local function append_lines(lines)
    if vim.api.nvim_buf_is_valid(buf) and lines then
      vim.api.nvim_buf_set_lines(buf, -1, -1, false, lines)
      -- Scroll to bottom
      local last = vim.api.nvim_buf_line_count(buf)
      vim.api.nvim_win_set_cursor(0, { last, 0 })
    end
  end

  -- Start async job
  local job_id
  job_id = vim.fn.jobstart({ "xelatex", current_file }, {
    stdout_buffered = false,
    stderr_buffered = false,

    on_stdout = function(_, data)
      append_lines(data)
    end,

    on_stderr = function(_, data)
      append_lines(data)
    end,

    on_exit = function(_, exit_code)
      append_lines({
        "",
        "Compilation Finished (exit code: " .. exit_code .. ")",
        pdf_file,
      })

      -- Only set keymap if buffer still exists
      if vim.api.nvim_buf_is_valid(buf) then
        vim.keymap.set("n", "<CR>", function()
          if job_id then vim.fn.jobstop(job_id) end
          if vim.api.nvim_buf_is_valid(buf) then
            vim.cmd("bd!")
          end
        end, { buffer = buf })
      end
    end,
  })

  -- Kill job if buffer is wiped
  vim.api.nvim_create_autocmd("BufWipeout", {
    buffer = buf,
    once = true,
    callback = function()
      if job_id then vim.fn.jobstop(job_id) end
    end,
  })
end

-- View PDF
local function view_tex()
  local pdf = vim.fn.expand('%:p'):gsub('%.tex$', '.pdf')
  vim.fn.execute('!nohup evince ' .. vim.fn.shellescape(pdf) .. ' >/dev/null 2>&1 &')
  vim.cmd('redraw!')
end

-- Wrap buffer in HTML tags
local function wrap_buffer_in_html_tags()
  -- Yank the entire buffer content
  vim.cmd('normal! ggVGy')

  -- Replace special characters in the yanked content
  local content = vim.fn.getreg('0')
  content = content:gsub('&', '&amp;')
  content = content:gsub('<', '&lt;')
  content = content:gsub('>', '&gt;')
  vim.fn.setreg('0', content)

  -- Get current filename and append .html
  local current_filename = vim.fn.expand('%:t:r') .. ".html"

  -- Open new buffer with HTML syntax
  vim.cmd('enew')
  vim.bo.filetype = 'html'
  vim.cmd('file ' .. current_filename)

  -- Insert opening tags
  vim.api.nvim_buf_set_lines(0, 0, -1, false, {
    '<pre class="language-latex">',
    '<code class="language-latex">'
  })

  -- Paste the content
  vim.cmd('normal! 2Go')
  vim.cmd('normal! "0p')

  -- Insert closing tags
  vim.api.nvim_buf_set_lines(0, -1, -1, false, {
    '</code>',
    '</pre>'
  })

  -- Move cursor to top
  vim.cmd('normal! gg')
end

-- Normal mode mappings
vim.keymap.set('n', '<leader>c', run_tex, { buffer = true })
vim.keymap.set('n', '<leader>o', view_tex, { buffer = true })
vim.keymap.set('n', '<leader>w', wrap_buffer_in_html_tags, { buffer = true })

-- Insert mode mappings
local insert_maps = {
  ['!'] = '\\',
  ['§'] = '!',
  ['qq'] = '\\quad ',
  ['tt'] = '~\\text{}~<++><ESC>F{a',
  [',hs'] = '\\hspace*{cm}<++><ESC>F{a',
  [',vs'] = '\\vspace*{cm}<++><ESC>F{a',
  [',bf'] = '\\textbf{}<++><ESC>F{a',
  [',u'] = '\\underline{}<++><ESC>F{a',
  [',tcb'] = '<ESC>:lua require("config.tex_snippets").tcb()<CR>',
  [',nn'] = '<ESC>:lua require("config.tex_snippets").d1()<CR>',
  [',ds'] = '<ESC>:lua require("config.tex_snippets").ds()<CR>',
  [',st'] = '<ESC>:lua require("config.tex_snippets").st()<CR>',
  [',ar'] = '<ESC>:lua require("config.tex_snippets").ar()<CR>',
  [',gg'] = '<ESC>:lua require("config.tex_snippets").gg()<CR>',
  [',mt'] = '<ESC>:lua require("config.tex_snippets").mtab()<CR>',
  [',dd'] = '<ESC>:lua require("config.tex_snippets").d1()<CR>',
  [',li'] = '<ESC>:lua require("config.tex_snippets").li()<CR>',
  [',ti'] = '<ESC>:lua require("config.tex_snippets").tight()<CR>',
  [',mm'] = '\\usepackage{amsmath, amsfonts, amssymb, amsthm}\n\\usepackage{mathrsfs}',
  [',ig'] = '\\includegraphics[width=<++>cm]{<++>}',
  [',bm'] = '\\def\\bottommsg{{\\normalsize{ \\vskip 3pt \\hrule height 3pt \\vskip 5pt \\RL{\\arabicfont <++> }}}}',
  [',o'] = '$(O; \\vec i, \\vec j)$',
  ['$$'] = '~$$~<++><Esc>F$i',
  ['['] = '[]<++><Esc>F]i',
  ['{'] = '{}<++><Esc>F}i',
  ['('] = '()<++><Esc>F)i',
  [',no'] = '\\noindent',
  ['...'] = '\\cdots',
  ['>='] = '\\ge',
  ['<='] = '\\le',
  [',xx'] = '\\times',
  ['°'] = '$',
  ['ł'] = '{}<Esc>F{a',
  ['ĸ'] = '&'
}

for lhs, rhs in pairs(insert_maps) do
  vim.keymap.set('i', lhs, rhs, { buffer = true })
end

-- Visual mode mappings
local visual_maps = {
  ['<leader>$'] = 's~$<C-r>"$~<++><Esc>',
  ['<leader>u'] = 'c\\underline{<C-r>"}<++>',
  ['<leader>b'] = 'c\\textbf{<C-r>"}<++>',
  ['<leader>i'] = 'c\\textit{<C-r>"}<++>',
  ['<leader>cc'] = 'c\\textcolor{}{<C-r>"}<++><Esc>2F{a',
  ['1'] = 'c\\bm{\\textcolor{}{<C-r>"}}<++><Esc>2F{a',
  ['2'] = 'c\\bbox{<C-r>"}<Esc>',
  ['3'] = 'c\\rbox{<C-r>"}<Esc>',
  ['4'] = 'c\\obox{<C-r>"}<Esc>',
  ['5'] = 'c~$<C-r>"$~<Esc>',
  ['6'] = '<Esc><cmd>\'<,\'>s/\\\\\\[/\\~\\(/e<CR><cmd>\'<,\'>s/\\\\\\]/\\\\)\\~/e<CR>',
  ['9'] = '<Esc><cmd>\\<,>s/\\\\(/\\~$/eg<CR><cmd>\\<,>s/\\\\)/\\$\\~/eg<CR>'
}

for lhs, rhs in pairs(visual_maps) do
  vim.keymap.set('v', lhs, rhs, { buffer = true })
end

-- Operator-pending mode mapping
vim.keymap.set('o', 'à', '$', { buffer = true })

HTML & Markdown: Shared Wrappers and Insert Maps

HTML and Markdown share the same visual wrapping commands, so their ftplugin files are minimal: each sets 2‑space indentation and then calls require("config.html_markdown_maps")(). The HTML ftplugin also defines a few insert‑mode mappings for comments and tag pairs.


-- ftplugin/html.lua
vim.bo.tabstop = 2
vim.bo.shiftwidth = 2
vim.bo.expandtab = true

-- Insert mode mappings (like your tex ones)
local insert_maps = {
  ['!'] = '<!--  --><++><Esc>F i',          -- HTML comment
  ['<'] = '<><++><Esc>F>a',                  -- open/close tag
  -- add other quick expansions
}
for lhs, rhs in pairs(insert_maps) do
  vim.keymap.set('i', lhs, rhs, { buffer = true })
end

-- Load shared mappings
require("config.html_markdown_maps")()


-- ftplugin/markdown.lua
vim.bo.tabstop = 2
vim.bo.shiftwidth = 2
vim.bo.expandtab = true

require("config.html_markdown_maps")()

The Shared Mapping Module: html_markdown_maps.lua

This module is a Lua function that, when called, registers visual‑mode mappings for both HTML and Markdown buffers. It uses a pure‑Lua wrap_visual_text function that handles linewise, characterwise, and blockwise selections correctly – no shelling out, no edge‑case failures. It also provides a ulify_selection function to convert a block of text into an HTML unordered list.

Because this logic is centralised, any improvement to visual wrapping (e.g., supporting additional selection modes) benefits both HTML and Markdown immediately.


-- lua/config/html_markdown_maps.lua
-- Shared visual/insert mappings for HTML and Markdown
-- All wraps use a pure‑Lua function – no shell, no gv, no E488.

-- ----------------------------------------------------------------------
-- Pure‑Lua wrapper that mimics your sed replacements
--   v/V/Ctrl‑v   → wraps each selected line (or each block fragment)
--   v (charwise) → wraps only the selected text inside the line
-- ----------------------------------------------------------------------
local function wrap_visual_text(open_tag, close_tag)
  local mode = vim.fn.visualmode()
  local start_pos = vim.fn.getpos("v")
  local end_pos   = vim.fn.getpos(".")

  -- Normalise order: start before end
  if start_pos[2] > end_pos[2] or (start_pos[2] == end_pos[2] and start_pos[3] > end_pos[3]) then
    start_pos, end_pos = end_pos, start_pos
  end

  local buf = vim.api.nvim_get_current_buf()
  local sr = start_pos[2] - 1   -- start row (0‑based)
  local sc = start_pos[3] - 1   -- start col (0‑based)
  local er = end_pos[2] - 1     -- end row
  local ec = end_pos[3]         -- end col (exclusive for nvim_buf_get_text)

  if mode == 'V' then
    -- Linewise: wrap each full line individually
    local lines = vim.api.nvim_buf_get_lines(buf, sr, er + 1, false)
    local result = {}
    for _, line in ipairs(lines) do
      local trimmed = vim.trim(line)
      if trimmed ~= "" then
        table.insert(result, open_tag .. trimmed .. close_tag)
      else
        table.insert(result, line)   -- keep empty lines as-is
      end
    end
    vim.api.nvim_buf_set_lines(buf, sr, er + 1, false, result)
  else
    -- Character‑ or blockwise: get the exact selection
    local region = vim.api.nvim_buf_get_text(buf, sr, sc, er, ec, {})
    local text = table.concat(region, '\n')
    local wrapped = open_tag .. text .. close_tag
    local new_lines = vim.split(wrapped, '\n')
    vim.api.nvim_buf_set_text(buf, sr, sc, er, ec, new_lines)
  end
end

-- ----------------------------------------------------------------------
-- Your original ulify_selection (unchanged)
-- ----------------------------------------------------------------------
local function ulify_selection()
  local start_line = vim.fn.line("'<")
  local end_line   = vim.fn.line("'>")
  local lines = vim.api.nvim_buf_get_lines(0, start_line - 1, end_line, false)

  local result_lines = {}
  for _, line in ipairs(lines) do
    local trimmed = vim.trim(line)
    if trimmed ~= "" then
      local replaced = trimmed:gsub("%*%*(.-)%*%*", "<strong>%1</strong>")
      table.insert(result_lines, "  <li>" .. replaced .. "</li>")
    end
  end

  local final = { "<ul>" }
  for _, li in ipairs(result_lines) do
    table.insert(final, li)
  end
  table.insert(final, "</ul>")

  vim.api.nvim_buf_set_lines(0, start_line - 1, end_line, false, final)
end

-- ----------------------------------------------------------------------
-- Setup mappings
-- ----------------------------------------------------------------------
return function()
  local opts = { buffer = true, silent = true, noremap = true }

  -- ====================================================
  -- Visual surrounds (all unified, pure Lua)
  -- ====================================================
  vim.keymap.set('v', '<leader>ss', function()
    wrap_visual_text('<strong style="color: #000000;">', '</strong>')
  end, opts)

  vim.keymap.set('v', '<leader>pp', function()
    wrap_visual_text('<p>', '</p>')
  end, opts)

  vim.keymap.set('v', '<leader>hh', function()
    wrap_visual_text('<h2>', '</h2>')
  end, opts)

  vim.keymap.set('v', '<leader>aa', function()
    wrap_visual_text('<a href="<++>" target="_blank">', '</a>')
  end, opts)

  -- ====================================================
  -- Other mappings (unchanged)
  -- ====================================================
  vim.keymap.set('v', '<leader>cc',
    'x<Esc>i<pre class="language-bash" ><Enter>   <code class="language-bash" ><Esc>po    </code><Enter></pre><Enter><br><Esc>',
    opts)

  vim.keymap.set('i', '<leader>ff',
    '<Esc>:r ~/.vim/snippets/html/fig<CR>', opts)

  vim.keymap.set('i', '<<', '&lt;', opts)
  vim.keymap.set('i', '>>', '&gt;', opts)

  vim.keymap.set('v', '<leader>ul', ulify_selection, opts)
end

Design Lessons

The ftplugin architecture demonstrates a key principle: context should be handled as close to the buffer as possible. Global configuration sets the baseline; filetype‑specific modules add the personality. Shared logic lives in a separate module and is required only where needed – no conditional checks based on filetype inside global keymaps.

In the next article, we'll explore the custom functions that power the normal‑mode utilities – async execution, register inspection, command history navigation – and how they transform Neovim into a programmable engineering dashboard.

Engineering a Developer‑Grade Neovim Environment: The Foundation

2026-05-15T12:52:37+00:00

Why the First 100 Milliseconds Matter

A Neovim configuration that starts fast and behaves predictably isn’t an accident – it’s a designed system. When you open an editor dozens of times a day across different machines, the difference between a 80 ms cold start and a 400 ms one is the difference between an invisible tool and a constant reminder that something is loading. This article lays out the foundation of my daily driver: a fully modular, lazy‑loaded, deterministic Neovim setup that I’ve used for years to write LaTeX, Python, shell scripts, Markdown, and more.

We’ll start with the directory tree, then walk through every line of init.lua and the lazy‑bootstrapping module, explaining the engineering decisions – not just the “what”, but the “why”. The complete file contents are included so you can rebuild this foundation yourself or adapt it to your own toolchain.

Directory Tree

Below is the entire configuration tree at the time of writing. Files that are central to this article are highlighted in bold:


~/.config/nvim/
├── init.lua                       <-- entry point
├── lazy-lock.json                 <-- pinned plugin versions
├── lua/
│   ├── config/
│   │   ├── lazy.lua               <-- bootstraps lazy.nvim
│   │   ├── colors.lua
│   │   ├── commands.lua
│   │   ├── functions.lua
│   │   ├── html_markdown_maps.lua
│   │   ├── html_snippets.lua
│   │   ├── keymaps.lua
│   │   ├── options.lua
│   │   └── tex_snippets.lua
│   └── plugins/
│       └── core.lua
└── ftplugin/
    ├── html.lua
    ├── lua.lua
    ├── markdown.lua
    ├── python.lua
    └── tex.lua

The tree follows the standard Neovim convention: init.lua in the root, lua/ for modules, ftplugin/ for filetype‑specific settings. The entire configuration is lazy‑loaded, meaning no plugin is sourced until it is actually needed (filetype, command, or event).

The Entry Point: init.lua

The entry point sets global options, defines the leader keys, configures persistent state, and schedules the later loading of plugins and UI. Every choice is deliberate:

Leader keys: , as mapleader, Space as local leader – keeps custom mappings comfortably under the left hand.
Basic settings: line numbers, relative numbers, mouse support, 2‑space tabs, smart case – a sane baseline that individual filetypes can override.
Persistent history & undo: shada and undofile are pushed to stdpath('data'). The shada file stores command history and marks; the undo tree survives restarts. Both are set to very high limits to never lose context.
Fallback colourscheme: desert is set immediately so the editor never looks broken, then require('config.lazy') is called to pull in plugins. After plugins load, a scheduled callback applies the real theme and custom highlights.
Autocommands: trailing whitespace stripping on save, restoring cursor position, setting filetype for .tex files, auto‑lcd to file directory, and yank highlighting.

Here is the complete init.lua:


-- Modern Neovim by MOSAID

-- Leader
vim.g.mapleader = ","
vim.g.maplocalleader = " "

-- Basic settings (keep your existing ones)
vim.o.number = true
vim.o.relativenumber = true
vim.o.termguicolors = true
vim.o.wrap = true
vim.o.tabstop = 2
vim.o.shiftwidth = 2
vim.o.expandtab = true
vim.o.mouse = "a"
vim.o.cmdheight = 1
vim.opt.ignorecase = true
vim.opt.smartcase = true


vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1

-- History, undo, backup
-- vim.opt.undofile = true
-- vim.opt.undodir = vim.fn.stdpath("data") .. "/undo"
-- vim.opt.undolevels = 1000
-- vim.opt.undoreload = 10000
-- vim.opt.backup = true
-- vim.opt.backupdir = vim.fn.stdpath("data") .. "/backup"
-- vim.opt.directory = vim.fn.stdpath("data") .. "/backup"
-- vim.opt.history = 10000

-- Maximum history
vim.opt.history = 10000          -- command and search history
vim.opt.undolevels = 10000        -- undo steps
vim.opt.undoreload = 100000       -- undo for this many lines

-- Persistent undo
vim.opt.undofile = true
vim.opt.undodir = vim.fn.stdpath("data") .. "/undo"

-- Persistent command/search history
vim.opt.shadafile = vim.fn.stdpath("data") .. "/shada/main.shada"
vim.opt.shada = "'100000,<1000,s100,h"
vim.cmd("silent! rshada")  -- load at startup


-- Set a basic colorscheme immediately
vim.cmd("colorscheme desert")  -- Fallback colorscheme

-- Load modules in correct order
require("config.lazy")  -- This loads plugins first

-- After plugins are loaded, set up our colors
vim.schedule(function()
  require("config.colors").setup()  -- This sets tokyonight and custom highlights
  require("config.keymaps")
  require("config.commands")
end)


-- Auto-command to remove trailing whitespace
vim.api.nvim_create_autocmd("BufWritePre", {
  pattern = "*",
  callback = function()
    vim.cmd([[%s/\s\+$//e]])
  end
})


-- Remember last cursor position when reopening a file
vim.api.nvim_create_autocmd("BufReadPost", {
  pattern = "*",
  callback = function()
    local last_pos = vim.fn.line([['"]])
    if last_pos > 1 and last_pos <= vim.fn.line("$") then
      vim.cmd("normal! g`\"")
    end
  end,
})


-- Filetype detection autocmds
vim.api.nvim_create_autocmd({"BufEnter", "BufNew", "BufNewFile", "BufRead"}, {
  pattern = "*.tex",
  callback = function()
    vim.bo.filetype = "tex"
  end
})

-- Set current directory to directory of the current file, except /tmp
vim.api.nvim_create_autocmd("BufReadPost", {
  callback = function()
    local dir = vim.fn.expand("%:p:h")
    if dir ~= "" and not dir:match("^/tmp") then
      vim.cmd("silent! lcd " .. dir)
    end
  end,
})

-- Briefly highlight yanked text
vim.api.nvim_create_autocmd("TextYankPost", {
  pattern = "*",
  callback = function()
    vim.highlight.on_yank({
      higroup = "IncSearch",  -- or "Visual", "Search", etc.
      timeout = 500,          -- highlight duration in milliseconds
    })
  end,
})

Bootstrapping lazy.nvim

The require("config.lazy") call inside init.lua delegates to lua/config/lazy.lua, which is the only file that touches plugin management. It clones lazy.nvim itself if missing, then loads the plugin specification from lua/plugins/core.lua.

This file is intentionally minimal – it does not configure any plugins, only wires the package manager. The border = "rounded" setting is purely cosmetic. Every plugin is listed in core.lua and lazy‑loaded by event, command, or filetype. The lazy-lock.json file pins exact commits so the environment is fully reproducible across machines.


local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"

if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end

vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
  spec = {
    { import = "plugins" },
  },
  ui = {
    border = "rounded"
  }
})

The lazy-lock.json file (not shown in full here, but available in the configuration repository) records the exact commit of every plugin. This guarantees that lazy.sync() always restores the same plugin set, making the environment truly deterministic.

Ordering and the Scheduled Callback

The line vim.schedule(function() ... end) after loading lazy.nvim is critical. It defers the remaining setup until after the UI has been entered and plugins have been loaded (but not necessarily after they are all configured – lazy.nvim’s config keys run during the setup() call). This prevents race conditions where a colourscheme or highlight group is set before the plugin that defines it has been sourced.

Inside the scheduled callback we call:

require("config.colors").setup() – applies the chosen theme (Nordic) and sets custom highlight groups. A fallback to desert is already in place, so the editor is always readable.
require("config.keymaps") – defines global keybindings that rely on functions from config.functions.
require("config.commands") – creates user commands (like :WC, :Cc, etc.) that also depend on those utility functions.

Because everything after plugins is scheduled, the editor remains responsive during startup and never throws “module not found” errors even if a plugin fails to load.

Early Fallback Colourscheme

Immediately after the basic options, we call vim.cmd("colorscheme desert"). This is the ultimate safety net: if the later scheduled colors.setup() fails (for example, because the Tokyonight plugin is missing), the editor still has a functioning colourscheme. It also eliminates the “flash of unstyled text” that occurs when Neovim starts with no theme and then asynchronously loads one. The fallback is always overridden by the scheduled callback, so users never see desert once the real theme kicks in.

Autocommands as Infrastructure

The autocommands defined in init.lua are small pieces of infrastructure that would be annoying to lose:

Trailing whitespace removal on save – keeps diffs clean without manual clean‑up.
Cursor position restoration – when you reopen a file you left the day before, you’re exactly where you stopped.
Automatic filetype for .tex – some systems don’t recognise .tex as LaTeX without this explicit mapping.
Auto‑lcd to file directory – makes :Telescope find_files and relative imports work out of the box.
Yank highlight – provides instant visual feedback that the yank succeeded, a subtle but powerful usability improvement.

Reproducibility from the Ground Up

Every line in these two files serves a purpose: there are no boilerplate copies from other people’s dotfiles, no unused settings, and every module is loaded lazily only when required. The lazy-lock.json ensures that even plugin versions are frozen, turning the entire configuration into a build artifact that can be checked out and expected to work identically on any Neovim 0.9+ installation.

In the next article we’ll dive into the filetype‑specific engines – how ftplugin/*.lua and shared mapping modules create a context‑aware editor that feels custom‑built for Python, LaTeX, HTML, and Markdown.

Engineering a Modal Text Object Engine in Vim: Custom Motions and Operator-Pending Grammars

2026-05-13T20:50:06+00:00

Vim’s built‑in text objects—iw, i(, at—are powerful, but they stop short of domain‑specific structures. What if you could select an indented block with ii, a function argument with ia, or a column of a Markdown table with ic? For advanced users, the real magic lies in creating custom objects that compose seamlessly with any operator—dii, cia, yic—turning Vim into a structured editing engine tailored to your exact filetypes.

This article documents a system that generalises custom text objects into a declarative grammar, built entirely from Vim’s native operator‑pending mode and a handful of helper functions. It is not a plugin; it is a pattern you can integrate directly into your .vimrc or ftplugin files, giving you deterministic, composable selections without external dependencies.

Architecture of Operator‑Pending Mode

To build new objects, you must first understand the state machine behind every d} or cib.

•Operator‑pending mode is entered after an operator key (d, c, y, g~, etc.). Vim then waits for a motion or a text object to define the range.

•Text objects are special mappings that define two boundaries: a start and an end. They can be character‑wise, line‑wise, or block‑wise.

•The omap and xmap commands allow you to define mappings that only apply in operator‑pending or visual mode, respectively. This is the key to making custom objects operator‑agnostic.

The engine we design will leverage omap mappings that call functions to calculate a region, and then set the '[ and '] marks appropriately so the pending operator acts on exactly the right span.

Core Engine: The Object Factory

Declaring a Text Object

Instead of hand‑writing a dozen nearly identical functions, we define a small specification language. Each object is described by a dictionary containing:

•name: a unique label (used for debugging and documentation).

•selector: a Vimscript expression that returns a pair of positions—start and end (inclusive). It receives a boolean inner to distinguish i from a variants.

•mode: 'char', 'line', or 'block'. This determines how the operator applies (e.g., d uses line‑wise if the object is line‑wise).

We then register this specification with the engine:


call textobj#register({
    \ 'name': 'indent',
    \ 'selector': 'textobj#indent#select(inner)',
    \ 'mode': 'line'
    \})

The textobj#indent#select function scans for lines with the same indentation, wrapping the inner or outer block. The engine handles the rest: creating the omap entries for both ii and ai, setting marks, and respecting the pending operator.

Engine Implementation


function! textobj#register(object) abort
    let s:objects[a:object.name] = a:object

    " inner variant: i + name (e.g., ii)
    execute 'onoremap <silent> i' . a:object.name
        \ . ' :<C-u>call textobj#apply('
        \ . string(a:object.name) . ', 1)<CR>'

    " a variant: a + name (e.g., ai)
    execute 'onoremap <silent> a' . a:object.name
        \ . ' :<C-u>call textobj#apply('
        \ . string(a:object.name) . ', 0)<CR>'
endfunction

function! textobj#apply(name, inner) abort
    let obj = s:objects[a:name]
    let [l:start, l:end] = call(obj.selector, [a:inner])
    if l:start == 0 || l:end == 0 | return | endif

    " Set the '[' and ']' marks; Vim uses these for the operator range
    call setpos("'[", [0, l:start, 1, 0])
    call setpos("']", [0, l:end, 1, 0])

    " Force the operator to use the correct mode
    if obj.mode ==# 'line'
        normal! V
    elseif obj.mode ==# 'char'
        normal! v
    elseif obj.mode ==# 'block'
        " blockwise needs visual block – handled with special marks
        normal! <C-v>
    endif
endfunction

This is the entire engine—under 30 lines of Vimscript. It is deterministic, transparent, and composable. Every custom object you create from this point forward is just a selector function and a registration call.

Building Real Objects

Indentation Block (`ii` / `ai`)


function! textobj#indent#select(inner) abort
    let indent = indent(line('.'))
    let start = line('.')
    let end = line('.')

    " search upward for a line with less indent (outer boundary)
    while start > 1 && indent(start - 1) >= indent
        let start -= 1
    endwhile

    " search downward for a line with less indent
    while end < line('$') && indent(end + 1) >= indent
        let end += 1
    endwhile

    if a:inner
        " inner: exclude the first and last line if they are blank
        if getline(start) =~# '^\s*$' | let start += 1 | endif
        if getline(end) =~# '^\s*$' | let end -= 1 | endif
    endif

    return [start, end]
endfunction

Now dii deletes the current indented block, yii yanks it, and >ii increases its indentation. The object definition stays clean because the engine separates the selection logic from the operator handling.

Function Arguments (`ia` / `aa`)

A more ambitious selector that parses the current line for a comma‑separated argument list. The inner version (ia) selects the argument text excluding optional surrounding whitespace; the outer version includes trailing commas and spaces.


function! textobj#arg#select(inner) abort
    let line = getline('.')
    let col = col('.') - 1  " 0-indexed

    " Find argument boundaries: commas or parentheses
    let pattern = '[,()]'
    let start = 0
    let end = len(line)

    " search backward for opening delimiter
    let idx = col
    while idx > 0
        if line[idx] =~# pattern
            let start = idx + 1
            break
        endif
        let idx -= 1
    endwhile

    " search forward for closing delimiter
    let idx = col
    while idx < len(line) - 1
        if line[idx] =~# pattern
            let end = idx
            break
        endif
        let idx += 1
    endwhile

    if a:inner
        " trim whitespace from both ends
        while start < end && line[start] =~# '\s'
            let start += 1
        endwhile
        while end > start && line[end - 1] =~# '\s'
            let end -= 1
        endwhile
    endif

    " Return line positions; the engine will convert to mark positions
    return [line('.'), line('.')]   " both on the same line – set marks manually
    " For same‑line object we need to adjust col in marks:
    " We'll do this inside a wrapper that returns [lnum, col] pairs.
    " (Full implementation omitted for brevity – see repo.)
endfunction

Because the engine supports only line‑wise marks by default, same‑line objects require a slight extension: the selector can return a list of [line, col] pairs, and textobj#apply sets setpos("'[", [0, l:line, l:col, 0]) accordingly. This is a small modification that makes the engine handle all mode types uniformly.

Markdown Table Cell (`ic` / `ac`)

Another selector that navigates the vertical bar | separators in a GitHub‑flavoured Markdown table. The inner object selects the cell content; the outer includes the pipe characters. Thanks to the engine, cic clears a cell and leaves you in insert mode—as if Vim knew about Markdown tables natively.

Composition with Operators: The Power of Grammar

Because every custom object is exposed as an operator‑pending mapping, they automatically compose with any built‑in operator, and even with custom operators from other plugins (e.g., commentary’s gc). You can chain them with counts, repeat them with . (if the operator is repeatable), and use them from visual mode if you add xmap equivalents. The engine provides a textobj#visual helper that does exactly that:


function! textobj#visual(name, inner) abort
    call textobj#apply(a:name, a:inner)
    " Already in visual mode from the apply()
    " Remap i/a within visual mode to keep extending
    execute 'xnoremap <buffer> i' . a:name . ' :<C-u>call textobj#apply('
        \ . string(a:name) . ', 1)<CR>'
    execute 'xnoremap <buffer> a' . a:name . ' :<C-u>call textobj#apply('
        \ . string(a:name) . ', 0)<CR>'
endfunction

Now vii selects an indented block, and pressing ii again extends the selection to the next outer block—a true modal grammar.

Performance and Edge Cases

Text objects must be fast because they are invoked hundreds of times during a typical editing session. Selector functions should avoid external processes and prefer built‑in functions like search(), indent(), and getline(). The registration overhead is negligible; omap definitions are stored once.

Some edge cases to handle:

•Empty buffer/line: Selectors should return [0,0] to abort the operation gracefully.

•Nested structures: Indentation selectors need a clear definition of “same indent or deeper”. The provided textobj#indent#select treats all lines with indent ≥ current as part of the block, which works well for Python but may need tuning for languages with free‑form indentation.

•Blockwise operations: Vim’s blockwise mode requires special care: after setting marks with setpos, you must start a blockwise visual selection (gv) so the operator can interpret the marks as a block. Our engine does this conditionally.

Integration with Your Existing Workflow

The engine is a file you can drop into ~/.vim/autoload/textobj.vim and source from your .vimrc. Individual selectors become small autoload files (textobj/indent.vim, textobj/arg.vim) that are loaded on demand. This keeps startup time minimal and allows you to version‑control them independently.

For users who already use plugins like vim-textobj-user by Kana Natsuno, this engine offers a compatible but simpler alternative. You can even wrap the popular plugin’s API into our registration function to avoid duplication.

Tradeoffs

•No built‑in visual feedback: Unlike some plugins, our engine doesn’t flash a highlight when an object is selected (you can add that with :redraw and matchadd). We prioritised minimalism.

•Selector functions must be designed carefully: They receive only an inner flag, not the full operator context. If you need to behave differently for c vs d, you can inspect v:operator within the selector, but this couples the two layers.

•Same‑line objects demand extra mark handling: The engine’s base version returns line numbers; the extended version that handles column positions adds complexity. The design documented here can be refined to accept either format seamlessly.

Future Directions

This engine can grow into a full domain‑specific language for structured editing:

Add tree‑sitter integration: a selector that uses the syntax tree to define objects like functions, classes, or loops, making the engine filetype‑aware without per‑language rules.
GUI selection manager: a picker (via fzf or Vim’s inputlist()) that lets you compose objects interactively.
Visual mode combinators: extend the grammar so vii} means “select inner indent block, then extend to the next paragraph”, merging two objects.

The foundational pattern—separating registration, mapping, and selection logic—is what makes this extensible. Every new object is just a function that sees the buffer and returns two points.

Final Thoughts

Building a custom text object engine is not about reinventing plugins; it’s about understanding Vim’s modal architecture so deeply that you can bend it to your will. With a tiny amount of Vimscript, you can unlock editing paradigms that feel like they were always part of the editor. This engine is now a permanent part of my ~/.vim tree, and I suspect it will become one in yours as well.

Engineering a Vim-based LaTeX IDE: Custom Mappings, Snippets, and Compilation Workflow

2026-05-13T20:50:06+00:00

Problem Statement

LaTeX editing is powerful but repetitive. Every new document demands the same boilerplate: preamble setup, package inclusion, math shortcuts, and environment scaffolding. While dedicated LaTeX IDEs exist, they often feel slow, lack the composability of the terminal, and force a mouse-driven workflow. For engineers and power users who live in Vim, the ideal solution is to build a custom, deterministic editing environment that automates the boring parts without sacrificing control.

This article dissects a real-world Vim configuration for LaTeX editing, evolved over years of daily use. It lives at ~/.vim/after/ftplugin/tex.vim and leverages filetype-specific autocommands, a collection of snippet files, and custom functions that tie together compilation, PDF viewing, and even HTML export for static site generators like Pelican.

Architecture Overview

The system is a single Vim ftplugin file plus a directory of snippet templates. When a .tex file is opened, Vim automatically sources the ftplugin, which:

•Sets local buffer options (indentation, expansion).

•Defines compilation and viewer functions that capture xelatex output in a new buffer and open the resulting PDF in Evince.

•Creates insert-mode mappings that expand short keystrokes into full LaTeX commands or import snippet files.

•Provides visual-mode wrappers to quickly surround selected text with formatting commands like \textbf or inline math.

•Exports the current buffer to an HTML code block suitable for pasting into Pelican articles, bridging the gap between local authoring and static site publishing.

The snippets themselves are independent .tex files stored under ~/.vim/snippets/latex/ and inserted via :read commands bound to easy-to-type sequences like ;ds (exam template) or ;tcb (tcolorbox exercise).

Core Configuration

The ftplugin starts with the fundamentals:


autocmd FileType tex setlocal tabstop=2 shiftwidth=2 expandtab

LaTeX benefits from consistent two-space indentation. The expandtab setting ensures that all tabs are converted to spaces, which prevents formatting chaos when collaborating or sharing code.

Compilation Workflow

Running xelatex and Capturing Output

The RunTex() function embraces the Unix philosophy: it compiles the current .tex file with xelatex, discarding the need for a separate terminal window, and presents the output in a temporary buffer.


function! RunTex()
    let s:current_file = expand("%")
    enew | silent execute ".!xelatex " . shellescape(s:current_file, 1)
    setlocal buftype=nofile bufhidden=wipe noswapfile nowrap
    if &number == 0
        set number
    endif
    set relativenumber
    normal! G
    nnoremap <buffer> <CR> :bd!<CR>
endfunction

Key design decisions:

Full log capture: Using enew followed by .!xelatex ... reads the command output into a new buffer, preserving all warnings and errors.
Non-file buffer: The buffer is set to nofile and nowrap, preventing accidental saves while keeping the log readable.
Quick dismissal: Pressing <CR> in the output buffer deletes it with :bd!, returning you instantly to the source.

Mapping <leader>c invokes this function, turning compilation into a single, muscle-memorised keystroke.

Viewing the PDF

Once compiled, ViewTex() opens the corresponding PDF in Evince without blocking Vim:


function! ViewTex() abort
    let pdf = substitute(expand('%:p'), '\.tex$', '.pdf', '')
    silent! execute '!nohup evince ' . shellescape(pdf) . ' >/dev/null 2>&1 &'
    redraw!
endfunction

Using nohup ensures the viewer persists even if the terminal closes, and the silent redraw avoids screen flicker. Bound to <leader>o, it closes the edit‑compile‑view loop seamlessly.

Exporting LaTeX as HTML for Static Sites

The most unconventional part of this setup is the WrapBufferInHTMLTags() function. It yanks the entire buffer, escapes HTML entities, and wraps the result in <pre><code> blocks with a language class. The new buffer is then given a .html filename and filetype.


function! WrapBufferInHTMLTags()
    execute 'normal! ggVGy'
    let l:content = getreg('0')
    let l:content = substitute(l:content, '&', '\&amp;', 'g')
    let l:content = substitute(l:content, '<', '\&lt;', 'g')
    let l:content = substitute(l:content, '>', '\&gt;', 'g')
    call setreg('0', l:content)
    let l:current_filename = expand('%:t:r') . ".html"
    execute 'enew'
    setlocal filetype=html
    execute 'file ' . l:current_filename
    call setline(1, '<pre class="language-latex">')
    call append(1, '<code class="language-latex">')
    execute 'normal! Go'
    execute 'normal! "0p'
    call append(line('$'), '</code></pre>')
    execute 'normal! gg'
endfunction

This function targets a specific pain point: publishing LaTeX source code in a Pelican-powered static site. Instead of manually escaping characters and adding HTML tags, a single mapping (<leader>w) produces a correctly formatted code block ready to be inserted into an body.html file. It is a perfect example of merging local tooling with an automated publishing pipeline.

Insert Mode Mappings: From Keystrokes to Content

A large portion of the ftplugin is devoted to insert-mode mappings that make typing LaTeX faster and more consistent.

Symbol Shortcuts and Structural Commands

Several mappings re-purpose keys that are rarely used in LaTeX but easily reachable:

•! → \ and § → !: swaps backslash and exclamation mark, since the backslash is the most frequent LaTeX character and ! is seldom needed.

•qq → \quad: inserts a quad space, used constantly in math environments.

•tt → ~\text{}~<++>: wraps text inside math mode with a tilde-protected space, placing the cursor ready to type the text and then jump to the placeholder.

•;hs, ;vs: horizontal and vertical space commands with a placeholder for the length.

•;bf, ;u: bold text and underline.

The <++> placeholder and the <C-j> mapping (both in insert and normal modes) implement a simple jump-to-next-placeholder mechanism. After inserting a template like \textbf{}, the cursor lands inside the braces; pressing <C-j> deletes the placeholder and moves to the next edit point, keeping hands on the home row.

Snippet Insertion System

The brunt of the automation comes from a collection of snippet files, each stored as a standalone .tex file inside ~/.vim/snippets/latex/. Insert mode mappings read these files directly into the buffer:


inoremap ;ds <ESC>:0r /home/mosaid/.vim/snippets/latex/ds<CR>
inoremap ;st <ESC>:0r /home/mosaid/.vim/snippets/latex/st<CR>
inoremap ;ar <ESC>:r /home/mosaid/.vim/snippets/latex/ar<CR>

The files are plain TeX, allowing direct editing without any special format. Below is a summary of the available snippets:

Keystroke	File	Purpose
;dd	d1	Minimal article document skeleton (12pt, a4paper)
;ds	ds	Full exam class with custom borders, TikZ stamps, and bilingual (French/Arabic) support
;st	st	Standalone TikZ picture class for generating PNG graphics
;ar	ar	Arabic language preamble (polyglossia, Amiri font)
;gg	gg	Tight geometry: 1 cm margins on all sides
;tcb	tcb	tcolorbox exercise environment with red frame, gray background, and counter
;mt	mtab	Math-mode tabular environment for alignments
;li	li	Custom tight enumerate list (compact spacing)
;ti	tight	Enumitem key that makes any list tight
—	enum	Standard enumerate wrapper (no default mapping; users can add their own)

Each snippet is a complete, self-contained piece of LaTeX that can be inserted either at the top of the file (:0r) or at the cursor (:r). The exam template (ds) alone is over 6 kB and includes a custom \stamp, \luck, and \borders system—showcasing how deeply tailored these templates can become.

Additional inline mappings complement the snippets:

•;mm: inserts \usepackage{amsmath, amsfonts, amssymb, amsthm} in one go.

•;ig: \includegraphics[width=<++>cm]{<++>} with placeholders.

•;bm: defines a \bottommsg macro used in certain document styles.

All of these shortcuts follow a consistent pattern: they reduce multi-step actions to a short, memorable sequence, often using the semicolon as a namespace leader to avoid conflicts with normal typing.

Visual Mode Wrapping: Metaprogramming Text

Visual mode mappings allow applying formatting to existing text without manual cursor navigation:

•<leader>$: surrounds selected text with ~$...$~, converting a region to inline math.

•<leader>u, <leader>b, <leader>i: underline, boldface, italic.

•<leader>cc: wraps text in \textcolor{}{...}, prompting for the colour.

•1, 2, 3, 4, 5: a series of single-key visual mappings for \bm{\textcolor{}{...}}, \bbox, \rbox, \obox, and inline math respectively.

•6, 9: convert \[...\] and $...$ delimiters to the Vim author’s preferred ~$...$~ syntax, using a clever search-and-replace on the visual selection.

These mappings treat the document like a programmable structure, allowing restructuring and enhancement without ever leaving the editor or reaching for the mouse.

Tradeoffs and Limitations

Every engineering decision involves tradeoffs. This setup is no exception:

•Hard-coded paths: Snippet file paths are absolute (/home/mosaid/.vim/snippets/latex/). This works well on a single machine but breaks portability. A more robust solution would use environment variables or Vim’s ~/.vim relative paths (e.g., :r ~/.vim/snippets/latex/ds).

•Synchronous compilation: RunTex() runs xelatex synchronously, freezing Vim during compilation—fine for small documents, noticeable on 50+ page manuscripts. Integrating an async job via job_start() or :terminal would modernise it.

•Tight coupling to Evince: The viewer function assumes Evince is installed. While easily swapped, it’s not platform-agnostic.

•Snippet maintenance: Keeping the snippet library consistent and up-to-date is a manual process. A snippet engine like UltiSnips could provide more flexibility (placeholders, transforms), but the current approach is deliberately simple and transparent—just files on disk.

•Key conflict potential: Mappings like 1 in visual mode shadow Vim’s default behaviour. This is intentional; the author has internalised these overrides, but they may confuse new adopters.

Workflow Integration

This ftplugin does not exist in isolation. It is part of a larger pipeline that often includes:

A Makefile or latexmk continuous build script for multi-file projects.
A Pelican static site generator: the WrapBufferInHTMLTags() function directly feeds the blogging engine with syntax-highlighted LaTeX code blocks.
A Git repository that versions both the ftplugin and the snippet files, ensuring reproducibility across machines.
Terminal multiplexers (tmux) or modern terminal emulators that allow a side-by-side layout: Vim on the left, Evince on the right, and a compilation watcher in a third pane.

The system shines when you treat your LaTeX authoring as a software project: deterministic, automated, and continuously compiled.

Future Improvements

The current setup has evolved organically. For a more polished, distributable version, several enhancements are worth considering:

•Async compilation: Replace RunTex() with Vim’s job_start() and populate a quickfix list from the log, enabling :copen navigation.

•Portable snippet paths: Use expand('~/.vim/snippets/latex') instead of hard-coded /home/mosaid.

•UltiSnips or LuaSnip bridging: Keep the file‑based repository but generate snippet definitions dynamically, gaining visual placeholders and tab‑stops without abandoning the file system.

•LSP integration: Combine this custom tooling with a LaTeX language server (e.g., TexLab) for diagnostics, references, and hover information.

•Theme-aware PDF rendering: Adapt the ViewTex() function to work with other viewers (Zathura, Okular) or even inline PDF previews in modern Vim terminals.

Final Thoughts

This Vim configuration is a testament to the power of incremental customisation. What began as a few insert-mode shortcuts grew into a full-blown LaTeX editing environment that eliminates boilerplate, reduces cognitive load, and bridges the gap between document authoring and web publishing. It does not attempt to replace dedicated LaTeX IDEs; instead, it layers deterministic automation on top of an editor that the user already trusts.

The approach is reproducible, composable, and deeply personal—exactly what makes Vim a lasting tool for engineers. If you also live in Vim and write LaTeX, consider adopting (and adapting) these patterns to match your own workflow. The entire configuration is just a single ftplugin file and a folder of snippets—easy to version, easy to tweak, and easy to forget about once muscle memory takes over.

From Plain Text to HTML in Vim – Using Python Filters for Instant Markup

2026-05-13T20:50:06+00:00

If you write a lot of HTML by hand – documentation, blog posts, static site templates – you know how tedious it is to wrap lines in <p> tags, convert bullet lists into <li> blocks with proper classes, or build <select> menus from scratch. With the RunScriptFilter workflow introduced in the previous article, we can turn any visual selection into the output of a Python script. This article focuses entirely on Vim text to HTML transformations: instant, composable, and custom‑tailored to your markup needs.

The Core Filter (Recap)

The foundation is a Vim function that pipes selected text to an external command and replaces the selection with the command’s output. Here’s the production‑ready version we’ll use in every example:


function! RunScriptFilter(cmd) range
    let l:save_reg = getreg('"')
    let l:save_regtype = getregtype('"')
    normal! ""gvy
    let l:text = getreg('"')
    call setreg('"', l:save_reg, l:save_regtype)

    let l:tmp = tempname()
    call writefile(split(l:text, "\n", 1), l:tmp)
    let l:out = system(a:cmd . ' < ' . shellescape(l:tmp))
    call delete(l:tmp)

    if v:shell_error
        echohl ErrorMsg
        echo "Filter error:\n" . l:out
        echohl None
        return
    endif
    let l:out = substitute(l:out, '\n\+$', '', '')
    execute "normal! gv\"_c" . l:out
endfunction

Any external tool that reads stdin now becomes a Vim HTML filter. Let’s put it to work.

1. Instant Paragraph Wrapping

Select a block of text and turn each non‑empty line into a <p> element. The Python script is trivial:


import sys

for line in sys.stdin:
    stripped = line.strip()
    if stripped:
        print(f"<p>{stripped}</p>")
    else:
        print()   # preserve blank lines

Map it:


xnoremap <leader>hp :call RunScriptFilter('python3 -c "
import sys
for l in sys.stdin:
    s = l.strip()
    print(f\"<p>{s}</p>\" if s else \"\")
"')<CR>

Select several paragraphs, hit <leader>hp, and they’re wrapped instantly. No more manually typing <p> and </p>.

2. Headings from Plain Lines

A slightly smarter filter can detect heading levels. Here, lines starting with # are converted to <h1> through <h4> based on the number of #:


import sys, re

for line in sys.stdin:
    line = line.rstrip('\n')
    m = re.match(r'^(#{1,4})\s+(.*)', line)
    if m:
        level = len(m.group(1))
        print(f"<h{level}>{m.group(2)}</h{level}>")
    else:
        print(f"<p>{line}</p>")

Map: xnoremap <leader>hh :call RunScriptFilter('python3 heading_filter.py')<CR>. Now you can write a quick outline, select it, and get semantic HTML headings and paragraphs.

3. Markdown‑Style Lists to Styled HTML Lists

Here’s where external scripts really shine. Suppose you write a list like:


1 *foo* bar
2 *foo* baz
3 *foo* qux

You want this to become:


<ol>
<li><strong style="color:#b5bd68;">foo</strong> bar</li>
<li><strong style="color:#b5bd68;">foo</strong> baz</li>
<li><strong style="color:#b5bd68;">foo</strong> qux</li>
</ol>

A small Python script handles it:


import sys, re

lines = [l.rstrip('\n') for l in sys.stdin if l.strip()]
if not lines:
    sys.exit(0)

print("<ol>")
for line in lines:
    # Extract index, bold part, rest
    m = re.match(r'^\d+\s+\*(.+?)\*\s*(.*)', line)
    if m:
        bold = m.group(1)
        rest = m.group(2)
        print(f'  <li><strong style="color:#b5bd68;">{bold}</strong> {rest}</li>')
    else:
        print(f'  <li>{line}</li>')
print("</ol>")

Map: xnoremap <leader>hl :call RunScriptFilter('python3 mdlist2html.py')<CR>. The same pattern works for unordered lists: just switch to <ul> and adjust the regex.

4. Generate <select> Menus from a List

Turn this:


Volvo
Saab
Mercedes
Audi

into:


<select name="cars">
  <option value="0">Volvo</option>
  <option value="1">Saab</option>
  <option value="2">Mercedes</option>
  <option value="3">Audi</option>
</select>

Python script:


import sys

lines = [l.strip() for l in sys.stdin if l.strip()]
if not lines:
    sys.exit(0)

print('<select name="items">')
for i, item in enumerate(lines):
    print(f'  <option value="{i}">{item}</option>')
print('</select>')

Map: xnoremap <leader>hs :call RunScriptFilter('python3 select_filter.py')<CR>. Now any list becomes a dropdown in one keystroke.

5. CSV to HTML Table

When you have comma‑separated data, generate a full HTML table with proper escaping:


import sys, csv
from html import escape

reader = csv.reader(sys.stdin)
rows = list(reader)
if not rows:
    sys.exit(0)

print('<table>')
for i, row in enumerate(rows):
    tag = 'th' if i == 0 else 'td'
    cells = ''.join(f'<{tag}>{escape(cell)}</{tag}>' for cell in row)
    print(f'  <tr>{cells}</tr>')
print('</table>')

Map: xnoremap <leader>ht :call RunScriptFilter('python3 csv2table.py')<CR>. This alone saves minutes of repetitive tag writing when you embed tables in blog posts.

6. Custom Inline Styles Based on Content

The sky is the limit. For instance, you can write a filter that detects numbers and wraps them in <span style="color:red;">, or that automatically creates hyperlinks from URLs. Here’s a simple one that bolds any word that starts with a capital letter:


import sys, re

def bold_caps(text):
    return re.sub(r'\b([A-Z][a-z]+)\b', r'<strong>\1</strong>', text)

for line in sys.stdin:
    print(bold_caps(line.rstrip('\n')))

Map it and select any block – proper names are automatically emphasised.

7. Full‑Document Conversion with Pandoc

Sometimes you want to convert an entire Markdown buffer to HTML without leaving Vim. Using the buffer‑wide variant of our filter:


command! -nargs=1 FilterBuffer call RunBufferFilter(<q-args>)
nnoremap <leader>mdh :FilterBuffer pandoc -f markdown -t html<CR>

This turns a Markdown document into a full HTML page, perfect for previewing or pasting into a CMS.

Workflow and Safety

Undo‑friendly: The replacement is a single change – u brings back the original text instantly.
Error‑safe: If the script fails (non‑zero exit), the selection remains untouched and the error is displayed.
No escaping headaches: Using temporary files avoids shell‑injection and quoting nightmares.
Composable: You can pipe the output of one filter directly into another by running them sequentially – or chain them in a single shell pipeline inside the filter command.

Building Your HTML Editing Toolkit

I keep a handful of Python scripts in ~/bin/html-filters/ and load the corresponding Vim maps in a file that’s sourced automatically. The consistent interface – select, press a leader key, done – means I never have to think about the underlying mechanics. Whether I’m preparing a blog post, editing a static page template, or documenting an API, these Vim HTML filters have eliminated hundreds of repetitive keystrokes per week.

The real power of this approach isn’t any single script – it’s the mindset that your editor can become a programmable HTML generator whenever you need it. Start with one filter that solves a real annoyance in your current project, and the rest will follow naturally.

Vim Text Filters: Replacing Macros with Python & Shell Scripts for LaTeX, Code, and Data

2026-05-13T20:50:06+00:00

Vim’s macro system is a classic power tool, but when you need real computation—parsing JSON, evaluating maths, formatting data—macros quickly hit their limits. Instead of recording a sequence of keystrokes, I use external scripts as Vim text filters. This Vim Python workflow replaces a visual selection (or an entire buffer) with the output of any command-line tool, turning your editor into a programmable text transformation pipeline.

Why Use Python Scripts Instead of Vim Macros?

Vim macros are perfect for one‑off, linear edits, but they become fragile when you need:

Arithmetic or symbolic math (e.g., evaluating LaTeX expressions)
Structured data processing (JSON, CSV, HTML tables)
External API calls
Linting or formatting with dedicated tools

By piping text to a script and replacing it with the script’s output, you gain the full expressiveness of Python, jq, pandoc, or any Unix filter – all while staying in normal mode. This Vim text filter approach is reusable, composable, and far easier to debug than a complex macro.

The Core Vim Text Filter Function

The foundation is a Vim function that yanks the current visual selection, sends it to a command via stdin, and overwrites the selection with the result. Here is a refined, production‑ready version I use every day, designed to handle multi‑line selections safely and to report errors without losing your original text.


function! RunScriptFilter(cmd) range
    " Save the current register and selection type
    let l:save_reg = getreg('"')
    let l:save_regtype = getregtype('"')

    " Yank the visual selection
    normal! ""gvy
    let l:text = getreg('"')

    " Restore the register immediately
    call setreg('"', l:save_reg, l:save_regtype)

    " Write the text to a temporary file to avoid shell escaping problems
    let l:tmp = tempname()
    call writefile(split(l:text, "\n", 1), l:tmp)
    let l:out = system(a:cmd . ' < ' . shellescape(l:tmp))
    call delete(l:tmp)

    " Show errors in a popup if the command failed
    if v:shell_error
        echohl ErrorMsg
        echo "Filter error:\n" . l:out
        echohl None
        return
    endif

    " Remove a trailing newline so we don't introduce blank lines
    let l:out = substitute(l:out, '\n\+$', '', '')

    " Replace the selection with the filtered output
    execute "normal! gv\"_c" . l:out
endfunction

" Example: format JSON with jq
xnoremap <silent> <leader>jq :<C-u>call RunScriptFilter('jq .')<CR>

With this generic filter, any command that reads from stdin becomes a Vim text filter. No more escaping nightmares, and errors are shown without destroying your buffer.

Practical Vim Filter Examples for LaTeX, Code, and Data

1. Live Math Evaluation in LaTeX Documents

When writing technical articles, I often need to compute a value for a table or verify a formula. By selecting an expression and running a Vim Python filter, I get the result instantly. A small Python script handles the math:


# Save as ~/bin/vim-math-filter
python3 -c "from math import *; import sys; print(eval(sys.stdin.read()))"

Map it in Vim:


xnoremap <leader>m :call RunScriptFilter('vim-math-filter')<CR>

Now sqrt(2)*3.14 becomes 4.4403135525488 with a single keystroke.

2. Formatting CSVs into Markdown Tables

Data in CSV format can be transformed into a neatly aligned Markdown table using a quick Python script. This is a classic automate repetitive edits in Vim use case.


# ~/bin/csv2md-table
python3 << 'PYEOF'
import csv, sys
rows = list(csv.reader(sys.stdin))
if not rows: sys.exit(0)
widths = [max(len(str(row[i])) for row in rows) for i in range(len(rows[0]))]
for i, row in enumerate(rows):
    print('| ' + ' | '.join(f"{str(row[j]):{widths[j]}}" for j in range(len(row))) + ' |')
    if i == 0:
        print('|' + '|'.join(f"{'-'*(w+2)}" for w in widths) + '|')
PYEOF

Map it: xnoremap <leader>tb :call RunScriptFilter('csv2md-table')<CR>. Select any CSV block, hit the map, and you get a perfectly formatted table – no manual alignment required.

3. JSON Prettification and Data Extraction

For quick JSON processing inside Vim, jq is unbeatable. These mappings turn selections into pretty‑printed JSON, or extract a single field:


xnoremap <leader>jp :call RunScriptFilter('jq .')<CR>
xnoremap <leader>jn :call RunScriptFilter('jq -r .name')<CR>
xnoremap <leader>jc :call RunScriptFilter('jq -c .')<CR>

It’s an order of magnitude faster than trying to reformat JSON with a macro.

4. Linting and Auto‑formatting Code Blocks

Use your favourite linter as a Vim text filter. For example, run black on a visually selected Python snippet inside a Markdown fenced block:


xnoremap <leader>bl :call RunScriptFilter('black -q -')<CR>

No need to leave Vim or copy‑paste – the formatted code replaces your selection instantly.

5. Whole‑Buffer Transformations with Pandoc

The same concept extends to the entire file. A slight modification of the function lets you pipe the whole buffer through any tool:


function! RunBufferFilter(cmd)
    let l:tmp = tempname()
    execute 'write !cat > ' . l:tmp
    let l:out = system(a:cmd . ' < ' . shellescape(l:tmp))
    call delete(l:tmp)
    if v:shell_error
        echohl ErrorMsg | echo l:out | echohl None
        return
    endif
    %delete
    put =l:out
    1delete _
endfunction

command! -nargs=1 FilterBuffer call RunBufferFilter(<q-args>)

Now you can use :FilterBuffer pandoc -f markdown -t plain to strip all Markdown formatting, or :FilterBuffer figlet for instant ASCII art.

Integrating the Filter into Your Vim and LaTeX Workflow

For those working heavily with Vim and LaTeX, these filters become a natural extension of your editing toolbelt. Examples from my own workflow include:

Aligning LaTeX tables – pipe a selection through a Python script that aligns columns on &.
Generating TikZ diagrams – select a numeric specification and use a filter to output the full TikZ code.
Cleaning up BibTeX entries – run bibtool --pretty on a selection to normalise formatting.
Spell‑checking a paragraph – use textidote --check en as a filter and see suggestions inline.

The pattern is always the same: select, map, transform. This Vim automation mindset turns your editor into a composable toolchain.

Performance, Safety, and Edge Cases

•Temporary files: Always preferred over shellescape() for multi‑line text because they avoid escaping bugs.
•Error handling: Never replace the selection if the command fails – the original text remains intact.
•Undo friendliness: The replacement is a single change, so a quick u restores everything.
•Blocking concerns: The examples are synchronous; for heavy scripts (>1s), use Neovim’s job‑control or Vim’s job_start() to keep the UI responsive.
•Security: Avoid running arbitrary shell input – always use fixed commands with controlled arguments. Never interpolate user text directly into a command string.

Customise the Vim Text Filter for Your Own Workflow

The real power comes when you build a small library of filters that match your daily tasks. I keep mine in ~/bin and in a dedicated Vim plugin file, with leader mappings grouped by topic: <leader>m for math, <leader>t for tables, <leader>j for JSON. Because the filter command is external, you can write it in Python, Ruby, Node.js, or even a compiled binary – Vim only cares about stdin and stdout.

This Vim + Python text transformation approach has replaced dozens of ad‑hoc macros in my setup and has become the backbone of how I edit code, documents, and data. Once you experience a single keystroke that computes a formula or formats a table, you’ll wonder why you ever recorded a macro for those tasks.

Why SVG Is the Most Underrated Format for Developers

2026-05-11T00:12:07+00:00

The Format Developers Overlook

SVG occupies a strange position in web development. Designers reach for it when they need resolution-independence. Frontend developers treat it as an output target — something exported from Figma, optimized through SVGO, and dropped into an <img> tag. Backend developers mostly ignore it.

But SVG isn't a designer's format. It's an engineering format that happens to render in browsers.

I've spent the past year building a system that generates Open Graph banners programmatically from SVG templates. Along the way, I discovered that SVG behaves far more like source code than any image format has a right to. It's diffable. It's composable. It supports variables, loops, conditionals — not natively, but through the tooling ecosystems that naturally wrap it. It integrates into CI/CD pipelines the same way CSS or JavaScript does.

Here's what makes SVG genuinely powerful for developers, and why I think it's the most underrated format in our toolbox.

SVG as Source Code

The fundamental difference between SVG and every other image format is this: SVG is text. That sounds trivial, but the implications cascade through every aspect of a developer workflow.

Version Control That Actually Works

Binary images are opaque blobs. When you change a PNG, Git stores an entirely new blob. Diffs are meaningless. Code review of visual assets is impossible without external tooling — you're reduced to "LGTM" based on trust and a screenshot.

SVG changes are legible diffs. When I adjust a banner template's color from #1a1a2e to #16213e, the diff shows exactly that one line change. A reviewer can understand the modification without rendering anything.

• Meaningful diffs: Every attribute change is a readable line in a pull request.
• Blameable history: git blame on an SVG file tells you who changed which element and when.
• Branch and merge: Two developers can modify different parts of the same SVG — one adjusting text positioning, another tweaking gradient stops — and merge without conflicts most of the time.

This property alone transforms SVG from an asset format into a development artifact. I treat my banner SVGs the same way I treat any other source file in the repository.

Composability Through Templates

SVG isn't just versionable — it's composable. Because it's XML, it slots naturally into template engines. Jinja2, ERB, Go templates, even shell sed substitutions — they all work on SVG because SVG is just structured text.

Here's a simplified version of how my banner generator works:


template = '''<svg xmlns="http://www.w3.org/2000/svg"
         viewBox="0 0 1200 630">
  <defs>
    <linearGradient id="bg" x1="0%" y1="0%" x2="100%" y2="100%">
      <stop offset="0%" style="stop-color:"/>
      <stop offset="100%" style="stop-color:"/>
    </linearGradient>
  </defs>
  <rect width="1200" height="630" fill="url(#bg)"/>
  <text x="60" y="120" font-family="JetBrains Mono"
        font-size="48" fill="">

  </text>
</svg>'''

rendered = Template(template).render(
    gradient_start="#1a1a2e",
    gradient_end="#16213e",
    text_color="#e94560",
    title=article_title
)

This isn't a special SVG feature. It's just what happens when your image format is text that plays nicely with string templating. PNG doesn't give you this. WebP doesn't. JPEG definitely doesn't.

Automation and Build Pipelines

Once you accept SVG as source code, it becomes a natural participant in build systems. I don't open Inkscape to modify banners. I run a Python script. The script reads metadata from article frontmatter, feeds it through templates, and produces final SVGs. Then a second pass converts those SVGs to PNG for platforms that require rasterized Open Graph images.

The pipeline looks like this:

• Source: Article markdown with TOML frontmatter containing title, summary, tags.
• Template: SVG file with Jinja2 placeholders.
• Build step: Python script reads metadata, renders template, writes SVG to output directory.
• Rasterization: librsvg or headless Chromium converts to PNG for compatibility.
• Deployment: Output files land alongside the built HTML.

Every step is deterministic. The same inputs produce identical outputs every time. There's no GUI state, no manual export settings, no "I forgot which font I used." The entire visual identity of the site is version-controlled and reproducible.

This is infrastructure-as-code thinking applied to graphics. And SVG is the only format that makes it possible.

Scripting and Interactivity

SVG isn't a static format. It embeds JavaScript. It responds to CSS. It fires DOM events. Inside a browser, an inline SVG element is part of the document tree — you can query it with document.querySelector, attach event listeners, and manipulate attributes in real time.

This has practical applications that go far beyond decorative animations:

Data Visualization Without Libraries

D3.js exists because SVG is scriptable. Every chart, every force-directed graph, every choropleth map — they're all just SVG elements being created, updated, and destroyed by JavaScript. The format's DOM integration makes this natural. You're not drawing pixels; you're managing a scene graph.


// Add a data point to an existing SVG chart
const svg = document.querySelector('#chart');
const circle = document.createElementNS(
  'http://www.w3.org/2000/svg',
  'circle'
);
circle.setAttribute('cx', xPosition);
circle.setAttribute('cy', yPosition);
circle.setAttribute('r', radius);
circle.setAttribute('fill', '#e94560');
svg.appendChild(circle);

Interactive Documentation

I've used inline SVGs for architecture diagrams that respond to clicks — expanding subsystems, highlighting data flow paths, revealing annotations. This turns a static diagram into a navigable document. Readers can explore system topology at their own pace, drilling into the components they care about.

The interactivity isn't a gimmick. It's the difference between "here's a picture of the architecture" and "here's the architecture — explore it."

Accessibility That's Actually Good

Image accessibility on the web is fundamentally broken. The alt attribute on an <img> tag is a workaround — a single string attempting to summarize potentially complex visual information. For charts, diagrams, and data visualizations, this fails completely.

SVG gives you real accessibility primitives:

• <title> element: A brief, accessible name for the graphic — similar to alt text but structured as a proper element.
• <desc> element: Extended description, not limited to a single attribute value. You can explain a complex chart in paragraphs.
• ARIA attributes: role="img", aria-labelledby, aria-describedby connect these elements to assistive technology.
• Structural semantics: Groups (<g>) can carry their own titles and descriptions, making sub-components independently accessible.

A data visualization built this way doesn't just have one fallback string. It has a navigable, hierarchical description that screen readers can traverse. This matters for technical documentation, dashboards, and any context where the visual carries information that someone might need to understand non-visually.

PNG can't do this. WebP can't. Only SVG treats accessibility as a first-class concern, because only SVG carries its semantics as document structure rather than opaque pixels.

Responsiveness Without Tricks

Responsive images are a solved problem in raster formats, but the solution is inelegant: multiple resolutions, srcset attributes, media queries, and browsers guessing which file to download. It works, but it's heavy.

SVG is naturally resolution-independent. A single file renders sharply at any size, on any display. On a 4K monitor with a 2x device pixel ratio, the same SVG that looks perfect on a 1080p screen renders with no additional bandwidth and no loss of quality. The browser's vector renderer handles the scaling; you don't need multiple file variants.

Combine this with CSS media queries inside the SVG, and you get responsive behavior without JavaScript:


<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 400">
  <style>
    text { font-family: 'JetBrains Mono'; }
    @media (max-width: 400px) {
      .detail-text { display: none; }
      text { font-size: 14px; }
    }
    @media (min-width: 401px) {
      .detail-text { display: inline; }
      text { font-size: 18px; }
    }
  </style>
  <text x="20" y="40">System Overview</text>
  <text class="detail-text" x="20" y="80">
    Showing 14 interconnected services
  </text>
</svg>

The same file adapts its information density to the viewport. On small screens, it simplifies. On large screens, it adds detail. This is one file, one HTTP request, zero JavaScript.

Animation as a First-Class Feature

SVG animation lives in a sweet spot that CSS animations and canvas-based approaches both miss. SMIL animations (the <animate>, <animateTransform>, and <animateMotion> elements) are declarative, GPU-accelerated in most browsers, and don't require JavaScript.

But the real power isn't SMIL — it's that SVG elements are DOM elements. You can animate them with CSS transitions and keyframes using the same properties you'd use on any HTML element. You can also drive them imperatively with requestAnimationFrame for complex, frame-by-frame control.

This means SVG animation integrates with your existing tooling. Your CSS pipeline handles SVG animation. Your JavaScript framework can manipulate SVG elements through its standard component model. There's no special animation library required — though libraries like GSAP and Anime.js certainly make advanced work more pleasant.

For technical documentation, this enables things like:

• Animated architecture diagrams: Data flow arrows that pulse to indicate direction.
• Step-through sequences: Diagrams that build themselves as the user scrolls.
• Live status indicators: System health visualizations that update in real time.

Procedural Graphics and Generative Art

Because SVG is text, any language that can write strings can generate SVG. This opens the door to procedural graphics — images defined by algorithms rather than drawn by hand.

Here's a trivial example that generates a grid of colored rectangles:


def generate_grid(rows, cols, cell_size, palette):
    """Generate an SVG grid of colored rectangles."""
    elements = []
    for row in range(rows):
        for col in range(cols):
            x = col * cell_size
            y = row * cell_size
            color = palette[(row + col) % len(palette)]
            rect = (
                f'<rect x="{x}" y="{y}" '
                f'width="{cell_size}" height="{cell_size}" '
                f'fill="{color}" stroke="#1a1a2e" stroke-width="1"/>'
            )
            elements.append(rect)

    width = cols * cell_size
    height = rows * cell_size

    svg = f'''<svg xmlns="http://www.w3.org/2000/svg"
         viewBox="0 0 {width} {height}">
      {"".join(elements)}
    </svg>'''
    return svg

This scales to far more interesting territory. Generative art systems — processing-style sketches, particle systems, flow fields — can output SVG instead of raster pixels. The output is infinitely scalable, editable post-generation, and trivially customizable by modifying the generation parameters rather than re-rendering.

I've used this approach for:

• Deterministic avatars: Generating user icons from hash values — reproducible, unique, and lightweight.
• Background patterns: SVG-based textures that tile seamlessly, weigh under a kilobyte, and match the site's color scheme programmatically.
• Code architecture diagrams: Auto-generated dependency graphs that render as SVG and can be styled with CSS to match documentation themes.

The Tradeoffs (Because There Are Always Tradeoffs)

SVG isn't universally superior. I'm not making that argument. The format has real limitations that matter in production:

• Photographic content: SVG is terrible for photos. It's a vector format. Use JPEG or WebP for raster images — that's what they're for.
• Extremely complex scenes: A vector map of every road in a country will produce an enormous file. GPU rasterization of complex SVGs can be slower than decoding a carefully compressed bitmap.
• Renderer inconsistencies: Different browsers implement the SVG spec with slightly different interpretations. Font rendering varies. Filter effects vary. Test across engines.
• Security considerations: SVG can contain JavaScript. User-uploaded SVGs are an XSS vector. Sanitize uploaded SVGs aggressively — strip scripts, event handlers, and foreignObject elements. Tools like DOMPurify handle this well, but you need to know the risk exists.
• Performance profiling: SVG rendering performance is harder to reason about than raster image decoding. Complex filters, many elements, and frequent DOM mutations can bottleneck on the GPU or the compositing thread. Profile with browser devtools if performance matters.

These are real constraints. They're also the same kind of constraints you'd consider for any engineering decision. The key insight is that SVG's limitations are understandable — they follow from its design as a structured, DOM-integrated vector format. You can reason about them, profile them, and work around them.

SVG in a Modern Build Pipeline

Here's a concrete workflow that treats SVG as a build artifact rather than a static asset:


# 1. Generate SVGs from templates and data
python scripts/generate_banners.py \
  --template templates/banner.svg.j2 \
  --data articles/*/metadata.toml \
  --output output/banners/

# 2. Optimize with SVGO
npx svgo --config svgo.config.js \
  --input output/banners/ \
  --output output/banners-optimized/

# 3. Convert to PNG for platforms that need raster
for svg in output/banners-optimized/*.svg; do
  rsvg-convert -w 1200 -h 630 "$svg" \
    > "${svg%.svg}.png"
done

# 4. Inject references into built HTML
python scripts/inject_og_tags.py \
  --images output/banners-optimized/ \
  --site output/_site/

This pipeline is:

• Deterministic: Same inputs, same outputs, every time.
• Version-controlled: Templates, configuration, and generation scripts all live in Git.
• CI/CD-ready: Runs in GitHub Actions, produces artifacts, deploys predictably.
• Debuggable: Each step is independent. If the PNG looks wrong, check the SVG. If the SVG is wrong, check the template. If the template is wrong, check the data.

This is what it looks like when graphics participate in an engineering workflow. It's not about making pretty pictures. It's about building a system where visual output is as reliable, traceable, and automatable as the rest of the build.

Why I Build With SVG First

I default to SVG now for any visual asset that isn't a photograph. Diagrams, banners, icons, charts, architectural drawings, generative patterns — all SVG. The format pays its engineering dividends through composability, versionability, pipeline integration, and the ability to treat visual assets as code.

The tooling ecosystem supports this approach. SVGO for optimization. librsvg for raster fallback. Jinja2 (or any template engine) for composition. Standard version control for history and collaboration. Browser devtools for performance profiling and debugging.

The most underrated aspect of SVG isn't any single feature. It's the cumulative effect of all of them working together inside a developer workflow. When your images are source code, you stop thinking about "managing assets" and start thinking about "building visual output." The distinction is subtle but profound.

If you're treating SVG as just another export format, you're missing the engineering value. It's not a format for designers. It's a format for build systems that produce graphics.

Building a Modular Banner Generator for Pelican – A Developer's Approach

2026-05-07T09:30:00+00:00

0. The Real Problem Was Consistency

At first, banners were created manually. Some used PNGs, others SVGs. Typography changed between articles. Margins drifted. A few thumbnails were exported at the wrong aspect ratio.

The issue was not artistic quality. The issue was that visuals were outside the engineering workflow.

The moment article count passed 30+, image management became operational debt:

One generic banner → weak brand identity
Manual creation per article → unsustainable
Hard‑coded HTML/CSS in the theme → inconsistent with social media previews

We needed a system: deterministic, themeable, and fully integrated into the Pelican workflow.

This article walks through the design and implementation of a banner generator that treats images as code – SVG components assembled from configuration, with no manual design work after the first setup. The system has since evolved to be completely extensible: new components, themes, and design presets are automatically discovered simply by placing files in the right directories – no code edits required.

1. Why Banners Must Be Generated, Not Drawn

The core problems mentioned above pointed to one principle: banners should be derived, not stored as binary blobs. A proper banner generator solves all three:

Reproducible – the same input always produces the same SVG
Theme‑aware – matches your Pelican theme’s colours and typography
Data‑driven – pulls title, tags, category, and progress directly from article metadata

The output is a standard 1200×630 Open Graph image (or a square thumbnail), rendered as SVG and optionally rasterised to PNG.

Key idea: Banners become part of the build pipeline – no more design debt.

1.1 Why Not Use Existing Tools?

Before building a custom generator, obvious alternatives were considered:

Canva / Figma: manual workflow, no API for mass generation, binary artefacts
Puppeteer / Playwright screenshots: heavy dependencies, browser inconsistencies, slow, hard to version text
Online OG generators: limited customisation, not part of local build, platform lock-in
Pillow / PIL rendering: low-level, no native SVG support, poor typography control

None offered the combination of version control, theme reusability, and deterministic output that a static-site generator demands.

1.2 Why SVG Instead of HTML/CSS Canvas?

Several rendering approaches were tested:

HTML + Playwright screenshots
Pillow/PIL image rendering
Canvas APIs
Pure SVG generation

SVG won because it is:

Text-based and version controllable – diff‑friendly in Git
Resolution independent – perfect for both thumbnail and OG sizes
Composable from reusable XML fragments – each component outputs a small SVG chunk
Easy to theme dynamically – colours and fonts are just placeholder variables
Cheap to rasterise into PNG – a single ImageMagick command
Simple to diff in Git – visual regression testing possible

Unlike screenshot-based systems, SVG generation also avoids browser rendering inconsistencies and heavy dependencies.

2. Architecture: Components Over Templates

Instead of a monolithic image template, the generator is built from independent visual components. Each component knows how to render itself against a canvas and respects a global theme.

The core pipeline is simple:

  
BannerConfig (TOML) → BannerContext → Renderer → SVG
                       ↓
                (components in Z‑order)
            background, terminal, title, badges …

Components do not hard‑code positions or colours. They read from a theme dictionary and a layout configuration. This separation allows one design file to be rendered with any available theme.

Dynamic component discovery: Since version 2.0, the factory no longer uses a hard‑coded registry. Instead, it scans the components/ directory at startup and automatically loads every valid Python module that exports a Component class. This means you can add a new visual element by simply dropping a .py file into the folder – no registration, no config edits. The CLI, the interactive workflow, and the generated TOML comments all update themselves to reflect the new component.

2.1 Component Example – Terminal Window

The terminal component is one of the most complex elements. It renders a list of commands with syntax highlighting, optional typing animations, and a responsive layout.

  
class TerminalComponent(BaseComponent):
    def render(self) -> str:
        cmds = self.cfg["terminal"]["commands"]
        out = []
        for i, cmd in enumerate(cmds):
            y = self.y_offset + start_y + i * spacing
            out.append(self._render_line(cmd, y, text_x))
        return "\n".join(out)

Each component also reports its consumed height, so the renderer can stack them vertically without absolute coordinates – a simple but powerful flow layout.

2.2 Rendering Lifecycle – Step by Step

The generation pipeline follows five deterministic stages:

Load theme TOML (colours, layout defaults)
Load design preset (component selection, text overrides)
Merge into a BannerContext that holds all settings
Instantiate enabled components via a factory
Render SVG fragments in z‑order, assemble final document

  
Article Metadata
        ↓
Design Preset
        ↓
Theme Merge
        ↓
BannerContext
        ↓
Component Factory
        ↓
SVG Renderer
        ↓
banner.svg
        ↓
ImageMagick
        ↓
banner.png

2.3 Why Deterministic Output Matters

Because banners are pure functions of their input configuration:

The same design + metadata always yields the exact same SVG.
It is impossible to accidentally “drift” a banner style.
The system is CI‑friendly: any broken component immediately produces a visual diff.
Regenerating an entire archive of hundreds of banners is safe and instant.

This determinism is what makes banners a first‑class part of the engineering workflow.

3. Project Structure

The generator follows a clean separation of responsibilities. The directory tree now supports nested folders so you can organise themes, designs, and even components if desired – all automatically discovered.

  
banner_generator/
├── components/        # Independent renderable SVG blocks (auto‑discovered)
├── core/              # Rendering pipeline, factory, context
├── themes/            # TOML colour/typography profiles (nested folders allowed)
├── designs/           # Preset compositions, now organised by category:
│   ├── articles/      #   tech and academic presets
│   ├── books/         #   covers (fantasy, mystery, corporate, …)
│   └── thumbnails/    #   square thumbnail presets
├── article_creator/   # Pelican workflow integration
├── cli.py             # Command‑line interface
├── generate.py        # Core generation entry point
└── README.md

Directory	Responsibility
`components/`	Independent renderable SVG blocks (auto‑loaded)
`core/`	Rendering pipeline and orchestration
`themes/`	Shared colour systems (any subfolder)
`designs/`	Preset compositions (any subfolder)
`article_creator/`	Pelican workflow integration

4. Themes: One Source of Truth for Visual Identity

A theme is a TOML file that defines colours and layout defaults. No component knows about hex codes – they all reference keys like title_start or terminal_bg.

  
name = "Dracula"

[colors]
bg_start = "#282a36"
title_start = "#f8f8f2"
terminal_bg = "#1e1e2e"
status_badge_bg = "#44475a"

[layout]
title_font_size = 44
title_margin_top = 120

Switching from "Tech" to "Dracula" to "Catppuccin" is a one‑line change:

  
theme = "dracula"

Because every component reads from the same colour dictionary, the entire banner stays visually consistent. This is the same principle behind CSS custom properties – applied to SVG generation.

Themes can now be placed in subdirectories (e.g. themes/catppuccin/mocha.toml) and referenced as theme = "catppuccin/mocha". The system recursively searches all subfolders, making it easy to group themes by family or project.

4.1 Theme Inheritance and Fallbacks

Themes support a simple inheritance model. A theme can specify a parent key:

  
name = "custom"
parent = "dracula"
[colors]
title_start = "#ffffff"  # override only one colour

Any missing colours or layout values are automatically pulled from the parent. This allows minimal custom themes without duplicating the entire palette. Components access all colours through a merged dictionary, never knowing where the value originated.

4.2 Minimal Working Example

A complete banner can be generated with fewer than 20 lines of TOML:

  
theme = "tech"
title = "Hello Banner"
subtitle = "SVG generated"

[components]
show_title = true
show_background = true

Run it with:

  
python -m banner_generator.generate example.banner.toml

This gives you a themed, properly sized OG image without any design tool.

5. Design Presets: Reusable Blueprints

A design preset is a TOML file that selects a theme, sets layout overrides, and decides which components to show. It also provides placeholder text for titles, commands, badges, and social icons.

For example, a python_programming.banner.toml preset:

  
theme = "tech"
size = "og"
title = "Python Internals"
subtitle = "Decorators, generators, and async"
meta = "Article 9 · Advanced Python"

[components]
show_terminal = true
show_code_snippet = true
show_status_badges = true

[code_snippet]
language = "python"
code = ["def decorator(func):", "    return wrapper"]

These presets are stored as version‑controlled files. You can organise them into subdirectories – e.g., articles/tech/ for programming topics, books/fantasy/ for novel covers. The CLI and interactive tools discover them recursively, so you reference a design by its relative path, like books/fantasy/fantasy_book_cover.

During the article workflow, the system automatically suggests a design based on tags, category, and title keywords. If the article is about Linux, it suggests articles/tech/linux_homelab; if it contains "LaTeX", it leans toward articles/tech/latex_article. The suggestion engine works across nested directories without any extra configuration.

5.1 How Metadata Drives Visual Choices

The suggestion engine maps article metadata to design presets using simple rules:

Metadata	Visual Result
`Tags: vim`	Vim component suggested; code-focused layout
`Category: Linux`	Linux preset selected; terminal component enabled
`Series: Python Deep Dive`	Progress indicator enabled automatically
`Subcategory: Advanced`	Badge colour changed to denote difficulty

This mapping ensures new articles rarely need manual design file tweaks – the system picks a starting point that is already almost correct.

6. Integration into the Pelican Article Workflow

The generator is not a standalone script – it's a tightly integrated step inside the article creation pipeline.

When a new article is started:

A working directory is created (article-42/).
Metadata files (title.txt, tags.txt, body.html) are edited.
The user is prompted to generate a banner – a design is chosen, a banner.toml file is created, and the editor opens.
After editing the config, the SVG and PNG are rendered automatically.
The same steps run for a square thumbnail (size = "thumbnail").

Both the banner and thumbnail are copied to the Pelican static directories with the article’s slug as the filename. The markdown front matter is updated with the correct Image: and Thumbnail: fields.

This eliminates any manual file renaming or path‑guessing.

Result: Every article gets a unique, on‑brand banner without touching a graphical editor.

6.1 Why Pelican (and Static Sites) Benefit Most

Static-site generators are build‑time systems. They already transform source files into output artefacts. Adding banner image generation to the pipeline is a natural extension – unlike dynamic CMS platforms where image generation would need to happen lazily or on upload. Because everything runs during pelican’s generation step, the images are always in sync with the content. There is no cache invalidation or stale state.

7. From SVG to PNG – Rasterisation in the Pipeline

SVG is perfect for the source format: it's text, versionable, and can contain animations (e.g. typing effects). But Open Graph and Twitter cards require static PNG images.

The generator uses ImageMagick (magick or convert) to rasterise the SVG at the exact canvas size:

  
magick banner.svg -resize 1200x630! banner.png

The ! flag forces the exact dimensions, which matches the Open Graph specification. For thumbnails, the canvas is 512×512, producing a perfect square ready for archive pages and social previews.

If ImageMagick is not available, the workflow still produces an SVG – the user can rasterise later. But in practice, every CI environment and local development machine includes it.

8. Performance and Caching

Generating a banner from scratch takes ~200ms on a modern machine – fast enough to run during every edit. But regeneration is only needed when the article metadata (title, tags) or the banner.toml changes.

The workflow checks for existing banner.png and thumbnail.png before regenerating. If they exist, the user is asked:

  
⚠️  banner.png already exists. Regenerate anyway? (Y/n)

This simple guard prevents accidental overwrites and keeps builds incremental. When the site is published, the images are rsync'd once – no unnecessary work.

9. Extending the Component Library

The current component set includes 35+ visual blocks, ranging from terminal windows and code editors to diagrams, charts, and decorative elements. A handful of widely used ones:

Terminal – with typing animation and syntax‑highlighted commands
Vim editor – code window with line numbers and mode indicator
Status badges – tag pills that automatically map to article tags
Code snippet – generic code block with Pygments highlighting
Definition box – term + definition card
Simple chart – bar chart for metrics or survey data
Latex source – formatted LaTeX code block
Network diagram – nodes and connections
Database tables – entity relationship visualisation
Kanban board – columns and cards

Adding a new component requires zero changes to the core engine. Simply:

Create a new Python file under banner_generator/components/.
Implement a Component class that inherits from BaseComponent, defines a unique string component_id, and assigns a numeric z_index for layering.
Write the render() method (and optionally defs() if the component needs SVG gradients or filters).

Once the file is saved, the component is immediately available:

The banner generator discovers it on the next startup.
The CLI automatically lists the new show_<id> toggle in every generated banner.toml comment block.
The interactive article workflow suggests it if the design requires that component.
The renderer stacks it in the correct z‑order using its declared z_index.

There is no master list to update, no factory map to edit, and no configuration file to touch. The only requirement is that the component follows the simple contract: component_id and inheritance from BaseComponent. Invalid or broken components are gracefully skipped with a warning, keeping the whole system stable.

9.1 Hands‑on: Building a Minimal Component

Every component inherits from BaseComponent. A component only needs geometry calculations and a render() method that returns SVG markup.

  
class Component(BaseComponent):
    component_id = "divider"
    z_index = 50
    def render(self):
        return f'''
        
        '''

Save the file as banner_generator/components/divider.py and the system will auto‑discover it. Any design preset can then include it by setting show_divider = true. That’s the entire workflow – no central orchestration changes required, ever.

Gallery: All Generated Banners (Designs & Themes)

Below you can see the complete set of banners produced by the generator – both from design presets and from theme variations. Each image links to its full‑size version. This gallery demonstrates the flexibility and consistency of the system.

Design presets combine a specific component selection, layout strategy, and a theme. Changing the theme for a given design preserves the same visual structure but applies a new colour palette and typography.

🎨 Design Presets

🎨 Theme Variations

Theme variations apply different colour palettes to the same underlying design components. Notice how structure remains identical while mood changes completely.

10. CLI Usage at a Glance

The entire workflow is driven through a simple CLI, designed to feel familiar to developers:

  
# Start a new article (triggers banner generation prompts)
python cli.py article new

# Generate a banner from an existing config
python cli.py banner generate article-42/banner.toml

# Generate from a design preset (nested path works)
python cli.py banner --design articles/tech/python_programming --svg --png

# Use presets organised in subdirectories
python cli.py banner --design books/fantasy/fantasy_book_cover --out-dir ./covers

These commands are callable from Makefile targets, CI scripts, or IDE task runners – no GUI needed.

11. Problems Encountered During Development

No system is built without hitting real‑world snags. These are the most significant issues we faced:

Font inconsistency across OSes: SVG fonts rendered differently on Ubuntu, macOS, and Alpine. The fix was embedding a subset of the primary font as base64 inside the SVG.
SVG filters crippled rasterisation speed: drop shadows and blur effects increased magick time from 200 ms to 3 seconds. Filters were eventually moved to optional “premium” themes.
Gradients produced banding in PNG: some gradient stops required exact placement to avoid visual artefacts at 1200×630.
Long article titles overflowed: titles exceeding 80 characters had to be truncated with an ellipsis, and a multi‑line fallback was added.
Typing animations broke social crawlers: Twitter and LinkedIn ignored animated SVGs; we added a static fallback frame for PNG export.

12. What's Next – Animated Banners and A/B Testing

The current generator produces either static PNGs or animated SVGs. The animated SVG retains typing effects, blinking cursors, and rotating watermarks – perfect for embedding in HTML articles or interactive documentation.

Future directions:

Video previews – render a few seconds of animated SVG to MP4 for social media.
Remote generation API – expose the generator as a microservice for other Pelican sites.
A/B testing – automatically generate two design variants and compare click‑through rates.
Component packs – distribute theme+component bundles as installable Python packages.
Static caching at scale – use content‑addressed storage so regenerating a big site only updates changed banners.

But even in its current form, the banner generator has already paid for itself by eliminating hundreds of manual design hours.

13. Final Thoughts – Treat Images Like Source Code

The most important lesson from building this system is conceptual: banners are not assets – they are derivations. They should be generated from metadata, not stored as binary blobs.

Once you accept that, everything becomes simpler:

Version control stays clean (only TOML and theme files change).
Brand updates apply retroactively (change a colour in the theme, regenerate everything).
New articles never block on design work.

The banner generator is now an integral part of the Pelican publishing pipeline – running silently in the background, producing professional visuals without a single click in Photoshop.

If your static site still relies on manual image editing, it's time to automate. And the code is already waiting in pelican_tools repository

Setting Up Pelican Like a Developer (Not a Beginner) – Static, But Smarter

2026-05-06T17:50:53+00:00

Most Pelican tutorials teach the same sequence: run pelican-quickstart, tweak a few settings, and start writing. It works — until it doesn’t.

The failure mode is predictable: as soon as the project outgrows “a few posts”, configuration spreads, Python environments drift, plugins are added opportunistically, and the folder becomes a grab-bag of generated output and source files. The site still builds… right up until the day it doesn’t, and you can’t explain why.

In this article, we’re not “setting up Pelican”. We’re building a reproducible content system:

deterministic environment → clean project scaffold → split configuration → disciplined dependencies → automation from day one → a first-run page

If you’re a beginner: you’ll get a path that works now and keeps working later. If you’re a power user: you’ll get a structure you can version, automate, deploy, and extend without regret.

1. Introduction – Why “Beginner” Setups Break

Beginner setups break for one reason: they optimize for getting a page on screen, not for building a maintainable pipeline.

A production-grade static site isn’t “a folder of Markdown” — it’s a system with:

• a pinned interpreter and reproducible dependencies

• a clean separation between source and build output

• configuration that behaves differently in dev vs production

• automation that makes the “right thing” the easiest thing

Let’s build that foundation first.

2. Environment Isolation: Controlled Python, Not Global Chaos

The first rule of a maintainable Pelican setup is simple: your Python environment must be predictable.

We’ll do this in three layers:

• pin the Python interpreter (pyenv)

• isolate dependencies (venv)

• separate “what we want” from “what gets installed” (pip-tools)

2.1 Pin the interpreter with pyenv

If you already manage Python another way (asdf, mise, containers), keep your tool — the goal is still the same: pin the interpreter. Here’s the pyenv approach:

  
pyenv install 3.12.2
pyenv local 3.12.2

That creates .python-version. Anyone cloning your repo gets the exact same Python version.

2.2 Create a local virtual environment

  
python -m venv .venv
source .venv/bin/activate

At this point: no global packages, no “works on my laptop” surprises.

2.3 Use pip-tools for deterministic installs

A common trap is freezing everything too early. Instead, keep two files:

• requirements.in = your direct dependencies (intent)

• requirements.txt = fully pinned dependency graph (resolution)

  
pip install pip-tools

# Define only direct dependencies
echo "pelican\nmarkdown" > requirements.in

# Compile a fully pinned lockfile
pip-compile requirements.in

# Install exactly what was compiled
pip-sync requirements.txt

Key idea: You’re not setting up “a blog”. You’re defining a build environment.

From now on, your environment is deterministic: Python version locked, dependencies reproducible, no global pollution.

3. The Professional Project Scaffold

The default Pelican layout is minimal. Minimal is fine for a weekend experiment. For a real site, you want a directory structure that makes it obvious what is:

• source

• output

• UI/theme

• extensions

• automation

  
project/
│
├── content/              # source: articles, pages, images, extra files
│   ├── articles/
│   ├── pages/
│   ├── images/
│   └── extra/
├── output/               # generated site (never hand-edit)
├── theme/                # templates + CSS/JS
├── plugins/              # optional, controlled extensions
├── tasks/                # build/deploy scripts (later)
├── tools/                # custom generators (later)
├── pelicanconf.py        # dev config
├── publishconf.py        # production overrides
├── requirements.in       # intent
├── requirements.txt      # lockfile
└── Makefile              # automation

This separation is what turns Pelican into a content pipeline, not just a static site generator.

3.1 Bootstrap the structure (one command)

You can create everything manually, but a bootstrap script gives you repeatability. Keep it simple, and don’t be afraid to parameterize it.

  
#!/usr/bin/env bash
set -euo pipefail

PROJECT_NAME="pelican-project"
PYTHON_VERSION="3.12.2"

echo "[+] Creating project structure..."

mkdir -p "$PROJECT_NAME"/{content/{articles,pages,images,extra},output,theme,plugins,tasks,tools}

touch "$PROJECT_NAME"/pelicanconf.py
touch "$PROJECT_NAME"/publishconf.py
touch "$PROJECT_NAME"/Makefile
touch "$PROJECT_NAME"/requirements.in

touch "$PROJECT_NAME"/content/articles/.keep
touch "$PROJECT_NAME"/content/pages/.keep

echo "[+] Initializing Python environment..."
cd "$PROJECT_NAME"

pyenv local "$PYTHON_VERSION"

python -m venv .venv
source .venv/bin/activate

pip install pip-tools

echo -e "pelican\nmarkdown" > requirements.in
pip-compile requirements.in
pip-sync requirements.txt

echo "[✓] Project ready."

Now your Pelican project can be created in seconds — consistently, every time.

4. Configuration Strategy – Split Dev vs Production (and keep secrets out of git)

Treat configuration like code: explicit, modular, reviewable. Pelican gives you two natural layers:

• pelicanconf.py → development defaults

• publishconf.py → production overrides

4.1 A clean development config

Keep the baseline boring and stable. This article’s goal is to get structure correct, not to introduce features.

  
# pelicanconf.py

PATH = "content"

TIMEZONE = "UTC"
DEFAULT_LANG = "en"

THEME = "theme"

STATIC_PATHS = ["images", "extra"]
PAGE_PATHS = ["pages"]

# Optional hardening for dev feeds
FEED_ALL_ATOM = None
CATEGORY_FEED_ATOM = None

4.2 Minimal production overrides

  
# publishconf.py

from pelicanconf import *

SITEURL = "https://example.com"
DELETE_OUTPUT_DIRECTORY = True

4.3 Optional: use a .env file (only if you need it)

If you want environment-specific values (different SITEURL, feature flags, etc.), you can use a .env. Just remember: a .env is a convenience, not a requirement.

  
SITEURL=http://localhost:8002

If you do this, add python-dotenv to your dependencies and load it explicitly:

  
echo "python-dotenv" >> requirements.in
pip-compile requirements.in
pip-sync requirements.txt

  
# pelicanconf.py
from dotenv import load_dotenv
load_dotenv()

And crucially: don’t commit secrets. Add .env to .gitignore.

5. Plugins: Intentional Selection (Not “plugin-first”)

Pelican plugins are powerful — and easy to overuse. Every plugin becomes part of your build pipeline. So we follow a strict rule: plugins must earn their place.

In the early stage, you should be able to build a working site with zero plugins. That forces you to understand:

• where data comes from (content + metadata)

• how it flows through templates

• how URLs and structure are generated

When you do add plugins, add them like normal dependencies: pinned, documented, and reproducible.

  
# example: sitemap (only when you’re ready)
pip install pelican-sitemap

Then enable them explicitly (and only where needed):

  
PLUGIN_PATHS = ["plugins"]
PLUGINS = ["sitemap"]

If you need custom behavior, prefer implementing it in tools/ or your theme once you fully understand the pipeline.

6. Version Control Hygiene: What to Commit vs What to Regenerate

A clean Pelican project is defined by what you don’t keep. Generated output, caches, and virtualenvs should never mix with source content.

Here’s a minimal .gitignore that keeps your repo clean:

  
# Python
.venv/
__pycache__/
*.py[cod]

# Pelican
output/
.pelican-cache/

# Environment
.env

# OS / editor
.DS_Store
.vscode/

As a rule of thumb:

• Commit: content/, theme/, configs, requirements.in, requirements.txt, Makefile

• Never commit: output/, .venv/, caches, generated artifacts

Golden rule: Only source files matter. Everything else can be regenerated.

Optional but useful: add .editorconfig to prevent formatting drift across machines.

7. The Build System: A Makefile from Day One

Before writing content, define how the system runs. Automation isn’t “extra”; it’s how you make good practices frictionless.

  
.PHONY: dev build publish serve clean

PORT ?= 8002

# Live-reload development server
serve:
    pelican -r -l -p $(PORT)

# Deterministic build (uses pelicanconf.py)
build:
    pelican content -s pelicanconf.py -o output

# Production build (uses publishconf.py)
publish:
    pelican content -s publishconf.py -o output

# Serve the generated output directory
serve:
    cd output && python -m http.server $(PORT)

clean:
    rm -rf output __pycache__ .pelican-cache

This gives you a stable interface:

• make serve → live reload

• make build → local build

• make publish → production output

• make clean → wipe generated artifacts

8. First Light: “Hello World” Page

Before you write “real” content, prove the pipeline works end-to-end. We’ll create a page (not an article) because it’s the fastest way to validate output without date ordering or taxonomies.


mkdir -p content/pages
cat > content/pages/home.md << 'EOF'
Title: Hello, World
Slug: home

# Hello, World

This page was generated by Pelican.
EOF

Start the development server:


make serve

Open http://localhost:8002 in your browser. If you see “Hello, World”, your environment, config, and directory layout are all aligned.

Congratulations — the machine works. Now we can safely add complexity without ever breaking the “works out of the box” contract.

9. What We Just Built (and Why It Matters)

You now have a build pipeline, not just a blog folder. From here onward, you’ll repeatedly apply a simple three-layer pattern:

• Config: tell Pelican what to load and how to structure output

• Theme: render that data intentionally (templates, includes, layout)

• Metadata conventions: define the shape of the content so it stays queryable at build time

This pattern scales: it keeps the project understandable at 5 posts and at 500.

Next: in the next article we’ll design a clean content architecture — file naming, front matter vocabulary, and a directory strategy that keeps your site navigable and extensible as it grows.

Stop Thinking at Runtime: The Power User’s Guide to Precomputation in Pelican

2026-05-05T17:19:48+00:00

Most developers hit the same wall with static sites.

They like the speed. They like the simplicity.

And then they stop.

• “No search.”

• “No comments.”

• “No real interactivity.”

So they go back to a backend… or reach for a JavaScript framework.

Not because they need one—

But because they’re still thinking in runtime.

Here’s the line that separates beginners from power users:

•Beginners ask: “How do I compute this when the user loads the page?”

•Power users ask: “Why is this being computed at runtime at all?”

That question changes everything.

Search doesn’t need a server.

1. Build-Time vs Run-Time

Build-Time vs Run-Time

In a traditional web app, every request triggers work:

• Query the database

• Apply business logic

• Render templates

• Send the response

That’s runtime.

It happens for every user, on every request.

Which means:

• You pay the cost repeatedly

• You need infrastructure to support it

• You introduce latency and failure points

Pelican flips the model.

• Content is loaded

• Templates are rendered

• Pages are generated

Once.

At build time.

When a user visits your site?

• The server returns a file

No computation. No database. No logic.

This is the core optimization:

•Do expensive work once instead of thousands of times

That’s not a limitation.

That’s leverage.

2. Content as Data

If you still think of Markdown files as “pages,” you’re limiting yourself.

They’re not pages.

•They’re records

Each file contains structured information:

• Title

• Date

• Tags

• Category

• Content

During the build, Pelican loads all of this into memory.

At that point, you’re not rendering pages anymore—

You’re operating on a dataset.

Which means you can:

• Filter articles by tag

• Group them by category

• Sort them by date

• Generate entirely new views

No database required.

Because your content is the database.

This is where most people miss the opportunity.

They use Pelican to render articles.

Power users use it to query and transform data.

3. Precomputation Patterns

Once you adopt this mindset, your questions change.

Instead of asking:

• “How do I build this feature?”

You ask:

• “Can this be computed ahead of time?”

That leads to a set of repeatable patterns:

•Search Index
Generate a JSON file containing all content, ready for instant client-side search.

•Pre-filtered Views
Generate pages like “All Linux Articles” or “Beginner Guides” at build time.

•Related Content
Compute similarity (tags, categories) once and embed results directly into each page.

•Static APIs
Export structured JSON that behaves like an API—without running a server.

Notice the pattern:

• Compute once

• Reuse everywhere

The result?

• Zero runtime cost

• Instant responses

• Predictable behavior

4. Example: Generating a Search Index

Let’s make this real.

Instead of querying a database for search results, you generate them ahead of time.

At build time, Pelican already knows everything about your content.

So you export it.

  [
{% for article in articles %}
{
  "title": "{{ article.title | escape }}",
  "url": "{{ SITEURL }}/{{ article.url }}",
  "summary": "{{ article.summary | striptags | escape }}",
  "tags": [{% for tag in article.tags %}"{{ tag.name }}"{% if not loop.last %}, {% endif %}{% endfor %}]
}{% if not loop.last %},{% endif %}
{% endfor %}
]

This becomes a static file:

•search-index.json

No API. No backend.

Just data, ready to be consumed.

Your frontend (later in this series) will load this file and search it instantly.

This is the pattern you’ll reuse again and again.

5. Where This Leads

Once you internalize precomputation, your architecture changes.

You stop thinking in:

• Requests

• Controllers

• Server logic

And start thinking in:

• Data transformations

• Build pipelines

• Generated artifacts

This naturally leads to more advanced patterns:

•Headless CMS — external content sources, consumed at build time

•Static APIs — JSON endpoints generated by your build process

•Hybrid systems — static frontend, minimal dynamic services where truly needed

At that point, your “static site” isn’t simple.

It’s deliberate.

It’s engineered.

It’s precomputed software.

Final Thought

Static sites aren’t limited.

They’re shifted.

The work still happens—

Just earlier.

And once you start thinking that way, you stop asking:

• “Can Pelican do this?”

And start asking:

•“Why am I doing this at runtime?”

Why Static Websites Still Win in 2026

2026-05-05T15:36:21+00:00

For the past decade, the web has been obsessed with complexity.

We moved from simple server-rendered pages… to heavy client-side frameworks… to hybrid systems trying to fix the problems they introduced in the first place.

And somewhere along the way, a quiet question started to resurface:

What if most of this isn’t necessary?

This is where static websites come back—not as a nostalgic choice, but as a deliberate engineering decision.

In this article, I’ll show you why static sites still win in 2026—and why they’re the foundation for everything we’re going to build in this series.

•Prefer video? Watch the full explanation:

The Pendulum Always Swings

The web has gone through clear phases:

•Early Web: Pure HTML, simple, fast, but limited.

•Dynamic Era: PHP, databases, server-side rendering everywhere.

•SPA Boom: React, Vue, Angular—everything moved to the browser.

•Modern Hybrid: SSR + hydration + edge rendering (trying to balance performance and flexibility).

Each step solved problems… and introduced new ones.

Now we’re seeing a correction:

Static sites, but smarter.

Not just HTML files—but precomputed systems that deliver speed without sacrificing modern UX.

Performance: Static Is Still King

Let’s strip everything down to what matters: how fast your site loads.

A static site:

• Requires no server processing

• Has no database queries

• Delivers prebuilt HTML directly from a CDN

That means:

•Time To First Byte (TTFB): almost instant

•Rendering: immediate—no hydration delay

•Consistency: same performance globally via CDN

Compare that to a typical modern stack:

• Server-side rendering → compute cost + latency

• Client-side hydration → JavaScript execution delay

• API calls → additional round trips

Even with optimizations, you’re fighting complexity.

With static?

You start fast by design.

Simplicity Is a Feature

Most modern stacks require:

• A backend (Node, Python, etc.)

• A database

• Deployment pipelines

• Environment management

A static site removes almost all of that.

•No backend: just files

•No database: content is your data

•No runtime: everything is prebuilt

You can deploy a static site to:

• A CDN

• Object storage

• Even a simple file server

Scaling becomes trivial because there’s nothing to scale.

No servers. No processes. No surprises.

Security: The Overlooked Advantage

Security is rarely discussed in frontend conversations—but it should be.

A dynamic site exposes:

• Server-side code execution

• Database access

• Authentication systems

• API endpoints

Every one of these is a potential attack surface.

A static site?

•No server logic

•No database

•No injection vectors

You’re essentially serving immutable files.

That drastically reduces risk.

Cost: Almost Zero

Let’s talk money.

A typical dynamic setup might involve:

• Hosting (VPS or managed platform)

• Database costs

• Scaling costs under load

A static site:

• Can be hosted for free on many platforms

• Uses CDN bandwidth (cheap or free tiers)

• Has no runtime compute cost

You can handle thousands—or millions—of requests without touching your infrastructure.

You pay almost nothing for massive scale.

“But Static Sites Are Limited…”

This is the usual objection.

And it’s not wrong.

Out of the box, static sites don’t give you:

• Comments

• Search

• Real-time filtering

• User interaction

That’s why most developers jump straight to frameworks.

But here’s the key idea:

You don’t need a backend for most of these features.

You need:

• Smart precomputation

• Client-side enhancements

• Lightweight integrations

In other words:

Static doesn’t mean limited—it means intentional.

What We’re Building in This Series

This series is not about “basic Pelican tutorials.”

We’re going to build a site that:

• Loads instantly

• Has instant search (no backend)

• Supports dynamic filtering

• Includes comments

• Feels like a modern app

But under the hood?

It’s still static.

No heavy frameworks. No unnecessary complexity.

Just smart engineering.

What’s Next

In the next article, we’ll break down exactly what you “lose” with static sites—and how we’re going to rebuild those features step by step.

After that, we’ll start building the foundation using Pelican, but with a developer-first approach—not beginner boilerplate.

If you’re used to modern frameworks, this might feel different at first.

But once it clicks, you’ll start seeing the web in a completely different way.

This is where we stop chasing complexity—and start removing it.

•Prefer video? Watch the full explanation:

Automating Beautiful Quote Images with LaTeX and Bash

2026-05-02T14:48:45+00:00

Automating Beautiful Quote Images with LaTeX and Bash

In this tutorial, we explore a powerful Bash script that transforms plain text into visually rich quote images using LaTeX, TikZ, and ImageMagick. This workflow is especially useful for developers, writers, and content creators who want full control over typography and background styling without relying on external design tools.

🧠 Overview of the Workflow

The script follows a simple pipeline:

• Read input text from a file

• Apply LaTeX formatting with custom font and spacing

• Render a full-page background image using TikZ

• Compile the document using XeLaTeX

• Convert the resulting PDF into a high-quality image

This makes it ideal for generating consistent visual quotes or banners for blogs and social media.

⚙️ Script Breakdown

1. Input Handling and Configuration

The script begins by validating input and allowing optional font size customization:

  if [ -z "$1" ]; then
    echo "Usage: $0 input.txt [fontsize]"
    exit 1
fi

INPUT_FILE="$1"
FONTSIZE="${2:-82}"
BASELINE=$(($FONTSIZE + 12))

This gives flexibility to adjust typography dynamically without modifying the script.

2. Temporary Workspace and Output Paths

A temporary working directory is created to isolate compilation files:

WORKDIR="/tmp/latex_render_$RANDOM"
OUTPUT_DIR="$HOME/Pictures/quotes"

mkdir -p "$WORKDIR"
mkdir -p "$OUTPUT_DIR"

This ensures clean execution without cluttering the filesystem.

3. Background Image Optimization

The script processes a background image using ImageMagick:

magick "$BG_SRC" -resize 1920x -quality 70 "$BG_OPT"

This step reduces file size while maintaining visual quality, which is important for fast rendering.

4. LaTeX Document Generation

The core of the system is dynamically generating a LaTeX file with embedded content:

\documentclass[12pt,a4paper,landscape]{article}

\usepackage{tikz}
\usepackage{graphicx}
\usepackage{fontspec}
\usepackage{polyglossia}

\setmainlanguage[numerals=maghrib]{arabic}
\newfontfamily\arabicfont[Script=Arabic]{Amiri}

\AtBeginDocument{\fontsize{82}{94}\selectfont}

This setup enables:

• Arabic text rendering via polyglossia

• Custom font support with Amiri

• High-quality typography scaling

5. Full-Page Background with TikZ

The script overlays a background image across the entire page:

\begin{tikzpicture}[remember picture, overlay]
  \node at (current page.center) {
    \includegraphics[width=\paperwidth,height=\paperheight]{bg.jpg}
  };
\end{tikzpicture}

This approach ensures perfect full-page coverage without external design tools.

6. Compilation and Export

The LaTeX file is compiled twice for stability:

for i in 1 2; do
    xelatex -output-directory="$WORKDIR" "$TEX_FILE"
done

Then converted into a final optimized image:

magick -density 150 "$PDF_FILE" \
  -resize 1920x \
  -strip -quality 85 "$IMG_FILE"

This produces a lightweight yet sharp output image suitable for publishing.

Auto generated quote

The Full script

    
#!/usr/bin/env bash

set -e

# Check argument
if [ -z "$1" ]; then
    echo "Usage: $0 input.txt [fontsize]"
    exit 1
fi

INPUT_FILE="$1"

# Optional font size (default = 82)
FONTSIZE="${2:-82}"
BASELINE=$(($FONTSIZE + 12))  # decent spacing

# Timestamp (unique)
TIMESTAMP=$(date +"%Y%m%d_%H%M%S_%N")

# Paths
WORKDIR="/tmp/latex_render_$RANDOM"
OUTPUT_DIR="$HOME/Pictures/quotes"

mkdir -p "$WORKDIR"
mkdir -p "$OUTPUT_DIR"

TEX_FILE="$WORKDIR/output.tex"
PDF_FILE="$WORKDIR/output.pdf"
IMG_FILE="$OUTPUT_DIR/${TIMESTAMP}.jpg"

# Background image (optimized copy)
BG_SRC="/home/mosaid/Desktop/latex/parchment/parchment.jpg"
BG_OPT="$WORKDIR/bg.jpg"

# Resize + compress background
magick "$BG_SRC" -resize 1920x -quality 70 "$BG_OPT"

# Escape LaTeX special chars (basic)
CONTENT=$(sed 's/[#$%&_{}]/\\&/g' "$INPUT_FILE")

# Create LaTeX file
cat > "$TEX_FILE" <<EOF
\documentclass[12pt,a4paper,landscape]{article}
\usepackage[left=1cm,right=1cm,top=1cm,bottom=1cm]{geometry}

\usepackage{tikz}
\usepackage{graphicx}
\usepackage{setspace}

\usepackage{fontspec}
\usepackage{polyglossia}
\setmainlanguage[numerals=maghrib]{arabic}
\newfontfamily\arabicfont[Script=Arabic]{Amiri}

\setstretch{1.5}
\AtBeginDocument{\fontsize{$FONTSIZE}{$BASELINE}\selectfont}

\begin{document}

\begin{tikzpicture}[remember picture, overlay]
  \node at (current page.center) {
    \includegraphics[width=\paperwidth,height=\paperheight]{$BG_OPT}
  };
\end{tikzpicture}

\begin{center}
$CONTENT
\end{center}

\end{document}
EOF

# Compile LaTeX twice (TikZ stability)
for i in 1 2; do
    echo "$i compilation"
    xelatex -output-directory="$WORKDIR" "$TEX_FILE" >/dev/null
    sleep .5
done

# Convert PDF → optimized image
magick -density 150 "$PDF_FILE" \
  -resize 1920x \
  -strip -quality 85 "$IMG_FILE"

echo "✅ Image generated: $IMG_FILE"

🚀 Why This Script Is Powerful

This system combines multiple tools into a single automated pipeline:

• LaTeX → professional typography

• TikZ → precise layout control

• ImageMagick → image optimization

• Bash → full automation

The result is a reproducible and scriptable design system that does not depend on GUI tools.

📌 Final Thoughts

This workflow is especially useful for generating:

• Inspirational quote images

• Blog banners

• Social media visuals

• Arabic typography designs

With small adjustments, this script can evolve into a full content generation engine for visual storytelling.

Smart Brightness Control in Linux: Auto-Detect and Manage Backlight Like a Pro

2026-04-28T21:02:10+00:00

Managing screen brightness on Linux sounds trivial… until you realize your system exposes multiple brightness interfaces and only one of them actually works correctly.

I’ve personally run into systems where writing to /sys/class/backlight/acpi_video0/brightness does absolutely nothing, while another hidden interface works perfectly.

So instead of guessing every time, I built a smart brightness script that:

•Automatically detects the correct device

•Ignores broken or misleading interfaces

•Provides verbose debugging output

•Supports get / set / increment / decrement

🧠 Understanding the Problem

Linux exposes brightness controls through /sys, typically under:


/sys/class/backlight/
/sys/class/leds/

The issue? You might see something like:


/sys/class/backlight/intel_backlight
/sys/class/backlight/acpi_video0

But only one of them actually controls your screen.

•intel_backlight → usually correct (GPU native)

•acpi_video0 → often fake or limited

This is why hardcoding paths is a bad idea.

⚙️ The Smart Brightness Script

Here’s the full script I use. It automatically detects the best interface and gives you detailed output when needed.


#!/usr/bin/env bash

set -euo pipefail

STEP=5
VERBOSE=0

log() {
    [[ $VERBOSE -eq 1 ]] && echo "[brightness] $*" >&2
}

percent_to_raw() {
    local percent=$1 max=$2
    echo $(( percent * max / 100 ))
}

raw_to_percent() {
    local val=$1 max=$2
    echo $(( val * 100 / max ))
}

get_candidates() {
    local d

    for d in /sys/class/backlight/*; do
        [[ -d "$d" && -f "$d/brightness" && -f "$d/max_brightness" ]] && echo "$d"
    done

    for d in /sys/class/leds/*; do
        [[ -f "$d/brightness" && -f "$d/max_brightness" ]] && echo "$d"
    done
}

detect_device() {
    mapfile -t candidates < <(get_candidates)

    [[ ${#candidates[@]} -eq 0 ]] && return 1

    log "Found ${#candidates[@]} candidates:"
    for d in "${candidates[@]}"; do
        log "  - $d"
    done

    for d in "${candidates[@]}"; do
        if [[ "$d" == *intel_backlight* || "$d" == *amdgpu* ]]; then
            log "Selected (GPU native): $d"
            echo "$d"
            return
        fi
    done

    for d in "${candidates[@]}"; do
        if [[ "$d" != *acpi_video* ]]; then
            log "Selected (non-ACPI fallback): $d"
            echo "$d"
            return
        fi
    done

    log "Selected (last resort): ${candidates[0]}"
    echo "${candidates[0]}"
}

get_brightness() {
    local dev=$1
    local val max percent

    val=$(<"$dev/brightness")
    max=$(<"$dev/max_brightness")
    percent=$(raw_to_percent "$val" "$max")

    echo "Device: $dev"
    echo "Raw: $val / $max"
    echo "Brightness: ${percent}%"
}

set_brightness() {
    local dev=$1 percent=$2
    local max raw

    max=$(<"$dev/max_brightness")
    raw=$(percent_to_raw "$percent" "$max")

    log "Writing $raw to $dev/brightness (=${percent}%)"
    echo "$raw" | sudo tee "$dev/brightness" >/dev/null

    [[ $VERBOSE -eq 1 ]] && get_brightness "$dev"
}

list_devices() {
    local d val max percent

    mapfile -t candidates < <(get_candidates)

    [[ ${#candidates[@]} -eq 0 ]] && {
        echo "No brightness devices found"
        exit 1
    }

    for d in "${candidates[@]}"; do
        val=$(<"$d/brightness")
        max=$(<"$d/max_brightness")
        percent=$(raw_to_percent "$val" "$max")

        echo "$d"
        echo "  Raw: $val / $max"
        echo "  Brightness: ${percent}%"
        echo
    done
}

main() {
    local cmd="get"

    if [[ "${1:-}" == "-v" ]]; then
        VERBOSE=1
        shift
    fi

    cmd=${1:-get}
    shift || true

    case "$cmd" in
        list)
            list_devices
            return
            ;;
    esac

    local dev
    dev=$(detect_device) || {
        echo "No brightness device found"
        exit 1
    }

    case "$cmd" in
        get)
            get_brightness "$dev"
            ;;
        set)
            [[ $# -lt 1 ]] && { echo "Usage: $0 set <percent>"; exit 1; }
            set_brightness "$dev" "$1"
            ;;
        inc)
            local cur
            cur=$(raw_to_percent "$(<"$dev/brightness")" "$(<"$dev/max_brightness")")
            set_brightness "$dev" $(( cur + STEP ))
            ;;
        dec)
            local cur
            cur=$(raw_to_percent "$(<"$dev/brightness")" "$(<"$dev/max_brightness")")
            set_brightness "$dev" $(( cur - STEP ))
            ;;
        *)
            echo "Usage: $0 [-v] {get|set <n>|inc|dec|list}"
            exit 1
            ;;
    esac
}

main "$@"

⚡ Usage Examples

•Check current brightness


./brightness.sh get

•Enable verbose debugging


./brightness.sh -v get

•Set brightness to 50%


./brightness.sh set 50

•Increment / decrement


./brightness.sh inc
./brightness.sh dec

•List all detected devices


./brightness.sh list

🔐 Optional: Remove the Need for sudo

You can allow brightness control without sudo using a udev rule:


echo 'ACTION=="add", SUBSYSTEM=="backlight", RUN+="/bin/chmod 666 /sys/class/backlight/%k/brightness"' | sudo tee /etc/udev/rules.d/90-backlight.rules

🧠 Final Thoughts

What I like about this approach is that it’s portable, predictable, and transparent. Instead of relying on desktop environments or external tools, you get direct control over the kernel interface.

And more importantly—you always know which device is actually being used.

If you’re the kind of user who lives in the terminal or runs minimal setups like i3 or sway, this kind of script becomes essential.

🚀 Next Steps

If you want to push this further, here are some ideas:

•Bind it to XF86 brightness keys

•Add smooth fade transitions

•Cache the detected device for faster execution

•Add external monitor support via ddcutil

Once you start owning your system at this level, going back to GUI sliders feels… limiting.

Supercharging Zsh: Practical Functions and Keybindings for Power Users

2026-04-25T22:45:50+00:00

Introduction

If you're already using Zsh with Oh My Zsh, you're past the beginner stage. The real gains come from bending the shell to your workflow. In this guide, I walk through a set of practical functions and keybindings from my own .zshrc that significantly improve navigation, history usage, and editing efficiency.

These are not gimmicks — they solve real friction points in daily terminal usage.

1. Ranger-Powered Directory Switching (Ctrl+O)

Switching directories is something you do constantly. Typing paths is slow. Even tab completion gets in the way when navigating deep trees.

This function uses ranger as an interactive directory selector:


rrcd () {
    tmp="$(mktemp)"
    ranger --choosedir="$tmp"
    if [ -f "$tmp" ]; then
        dir="$(cat "$tmp")"
        rm -f "$tmp"
        [ -d "$dir" ] && [ "$dir" != "$(pwd)" ] && cd "$dir"
    fi
}

•Why it matters: You get a full-screen file browser to jump anywhere instantly.

•Bound to: Ctrl+O


bindkey -s '^o' 'rrcd\n'

2. Edit Command Line in Vim (Ctrl+E)

Long commands are painful to edit inline. This solves it by opening your current command in Neovim:


autoload edit-command-line; zle -N edit-command-line
bindkey '^e' edit-command-line

•Why it matters: You get full Vim motions, search, macros — not just arrow keys.

3. Smarter History with FZF

Ctrl+R — Fuzzy Search History


bindkey "^R" fzf-history-widget

• Ranking by relevance

• Full preview of matches

• Instant filtering

Directory Jump from History (Ctrl+S / Ctrl+A)


fzf-cd-history() {
  local dir
  dir=$(fc -ln 1 | tac | grep --color=never '^cd ' | sed 's/^cd //' | \
        fzf --height 40% --cycle)

  if [[ -d "$dir" ]]; then
    cd "$dir"
  else
    local base="${dir##*/}"
    dir=$( (find ~ -type d -name "$base" 2>/dev/null) | \
          fzf --height 40% --cycle --no-sort --tac \
              --bind "change:reload(find ~ -type d -name '$base' 2>/dev/null || echo 'No results')" \
              --phony --header="Looking for '$base'..." )

    [[ -n "$dir" && "$dir" != "Searching for directories"* ]] && cd "$dir"
  fi
  zle reset-prompt
}


bindkey '^S' fzf-cd-history
bindkey '^A' fzf-cd-history

4. Open Recent Files from Vim History (Ctrl+V)


fzf-vim-history() {
  local file
  local files

  files=$(
    {
      nvim --headless +'lua for _,f in ipairs(vim.v.oldfiles) do print(f) end' +q 2>&1
    } | tr -d '\r' | awk '!seen[$0]++'
  )

  file=$(printf '%s\n' "$files" | fzf --no-sort --height 40% --cycle)

  if [[ -n "$file" ]]; then
    LBUFFER="v \"$file\""
    zle reset-prompt
  fi
}


bindkey '^V' fzf-vim-history

5. Instant Sudo Toggle (Double ESC)


sudo-command-line() {
    [[ -z $BUFFER ]] && zle up-history
    if [[ $BUFFER == sudo\ * ]]; then
        LBUFFER="${LBUFFER#sudo }"
    else
        LBUFFER="sudo $LBUFFER"
    fi
}
zle -N sudo-command-line
bindkey "\e\e" sudo-command-line

6. High-Performance History Configuration


HISTSIZE=999999999
SAVEHIST=$HISTSIZE

setopt APPEND_HISTORY
setopt SHARE_HISTORY
setopt HIST_IGNORE_DUPS
setopt HIST_REDUCE_BLANKS
setopt HIST_IGNORE_SPACE
setopt HIST_NO_STORE
setopt HIST_SAVE_NO_DUPS
setopt HIST_EXPIRE_DUPS_FIRST

7. Completion System Tuning


zstyle ':completion:*' matcher-list '' 'm:{a-z}={A-Z}'
zstyle ':completion:*' menu select=long
zstyle ':completion:*' verbose true

8. Subtle UX Improvements


bindkey '^[[1;5C' forward-word
bindkey '^[[1;5D' backward-word
bindkey "^[[A" history-search-backward
bindkey "^[[B" history-search-forward

9. Notes Injection Before Commands


my_preexec() {
    if [[ "$1" != "cat $HOME/.todo"* ]]; then
        [[ -f "$HOME/.todo" ]] && cat "$HOME/.todo"
    fi
}

Conclusion

This setup works because it removes friction:

• Navigation becomes interactive

• History becomes searchable

• Editing becomes programmable

The shell stops being a command runner and becomes a real interface.

Automating Video Speed-Up and Audio Replacement with FFmpeg and Bash

2026-04-24T00:19:42+00:00

In this tutorial, we are not just writing a quick script — we are building a reusable video processing workflow around FFmpeg and Bash.

The goal is simple on the surface:

• Speed up a video

• Remove its original audio

• Replace it with a looping background track

But instead of treating this as a one-off command, we will break down the why, the mechanics, and the trade-offs, so you can extend this into your own pipelines.

1. The Complete Script

Let’s start with the full working version:

    
#!/bin/bash

set -e

INPUT="$1"
SPEED_FACTOR="${2:-3}"

if [ -z "$INPUT" ]; then
    echo "Usage: $0 input_video.mkv [speed]"
    exit 1
fi

AUDIO_DIR="/home/mosaid/Documents/audio"

echo "Available audio files:"
mapfile -t AUDIO_FILES <<(find "$AUDIO_DIR" -maxdepth 1 -type f -name "*.mp3")

if [ ${#AUDIO_FILES[@]} -eq 0 ]; then
    echo "No mp3 files found."
    exit 1
fi

for i in "${!AUDIO_FILES[@]}"; do
    echo "$((i+1))) $(basename "${AUDIO_FILES[$i]}")"
done

read -rp "Choose an audio file: " AUDIO_CHOICE

AUDIO="${AUDIO_FILES[$((AUDIO_CHOICE-1))]}"

BASENAME="$(basename "${INPUT%.*}")"
MUTED="$(mktemp --suffix=.mp4)"
SPEED="$(mktemp --suffix=.mp4)"
FINAL="${BASENAME}-final.mp4"

ffmpeg -y -i "$INPUT" -c:v copy -an "$MUTED"

ffmpeg -y -i "$MUTED" -filter:v "setpts=PTS/${SPEED_FACTOR}" "$SPEED"

ffmpeg -y -stream_loop -1 -i "$AUDIO" -i "$SPEED" -shortest \
  -map 1:v -map 0:a -c:v copy -c:a aac "$FINAL"

rm -f "$MUTED" "$SPEED"

echo "Output: $FINAL"

2. Understanding the Pipeline

This script is intentionally split into three distinct FFmpeg passes. That is not accidental.

• Pass 1 → Strip audio

• Pass 2 → Modify video timing

• Pass 3 → Rebuild final container

This separation keeps each step predictable and avoids subtle FFmpeg sync issues that often appear in one-liners.

3. Why We Remove Audio First

    
ffmpeg -y -i "$INPUT" -c:v copy -an "$MUTED"

•-c:v copy → No re-encoding (this is critical for performance)

•-an → Drop all audio streams

Why do this first?

• It guarantees a clean base (no leftover streams)

• It avoids audio/video desync after time manipulation

• It keeps the pipeline deterministic

Power-user insight:

If you skip this step and try to manipulate both streams at once, FFmpeg may keep timestamps that no longer align.

4. The Core Concept: setpts

    
ffmpeg -y -i "$MUTED" -filter:v "setpts=PTS/${SPEED_FACTOR}" "$SPEED"

This is the heart of the script.

•PTS = Presentation Timestamp

• Every frame has a timestamp that determines when it is displayed

When you write:

• PTS/3 → Frames are shown 3× faster

• PTS*2 → Frames are shown slower

So we are not "dropping frames" or "changing FPS" — we are modifying time itself at the container level.

This is why the operation is both:

• Efficient

• Precise

Advanced Note

If you wanted to also adjust audio speed (instead of replacing it), you would need:

    
-filter:a "atempo=2.0"

But here we intentionally discard audio entirely, which simplifies everything.

5. Looping Audio Without Guessing Duration

    
ffmpeg -y -stream_loop -1 -i "$AUDIO" -i "$SPEED" -shortest \
  -map 1:v -map 0:a -c:v copy -c:a aac "$FINAL"

This is a very clean pattern that many people overlook.

•-stream_loop -1 → Infinite loop

•-shortest → Output stops when video ends

This avoids:

• Manually trimming audio

• Calculating durations

• Writing fragile logic

Stream Mapping (Important)

•-map 1:v → Take video from second input

•-map 0:a → Take audio from first input

Without this, FFmpeg may choose streams implicitly — which is unreliable in automation scripts.

6. Temporary Files Strategy

    
MUTED="$(mktemp --suffix=.mp4)"
SPEED="$(mktemp --suffix=.mp4)"

Using mktemp instead of fixed filenames is a small but important detail:

• Prevents collisions

• Makes the script safe for parallel execution

• Avoids accidental overwrites

This is one of those habits that separates quick scripts from robust tooling.

7. Interactive Selection vs Automation

The script uses:

    
mapfile -t AUDIO_FILES  <<(find "$AUDIO_DIR" -name "*.mp3")

This is simple and portable — but not optimal for heavy usage.

Upgrade: fzf Integration

    
AUDIO=$(find "$AUDIO_DIR" -type f -name "*.mp3" | fzf)

• Instant fuzzy search

• No manual indexing

• Better UX for large libraries

This is the kind of improvement power users appreciate immediately.

8. Performance Considerations

This pipeline is efficient because:

• No video re-encoding (stream copy)

• Only one transformation step (PTS)

• Lightweight final muxing

However:

• The setpts step does require re-encoding

• That is unavoidable when modifying timestamps

If performance becomes critical, you can:

• Use hardware acceleration (VAAPI / NVENC)

• Lower resolution before processing

9. Turning This Into a Real Tool

Right now, this is a script. With small changes, it becomes a proper CLI utility:

• Add flags (-i, -s, -a)

• Add logging

• Add dry-run mode

• Add batch processing

Example batch usage:

    
for f in *.mkv; do
    ./process.sh "$f" 2
done

10. Where This Fits in Real Workflows

This pattern is surprisingly useful:

•Lecture acceleration: compress hours into minutes

•Content pipelines: generate background visuals

•Automation: integrate with cron or systemd

•Media cleanup: replace poor audio tracks

And more importantly:

• It composes well with other Unix tools

Final Thoughts

The real takeaway here is not the script itself — it is the approach:

• Break pipelines into deterministic steps

• Understand what FFmpeg is doing internally

• Prefer explicit mapping and control

Once you think this way, FFmpeg stops being a "command generator" and becomes a reliable building block in your system.

From here, you can extend this into a full automation pipeline, integrate it into your desktop workflow, or even expose it as a service.

From Terminal to Desktop: Sticky Todo Reminders with Cron, systemd & Conky

2026-04-19T12:12:38+00:00

In the previous tutorial, I built a minimal terminal-based reminder system using cron and a simple .todo file.

Now, let’s take it further.

In this guide, I’ll turn that idea into a desktop-integrated reminder system using:

•Cron: to generate reminders

•systemd (user): to monitor tasks

•Conky: to display sticky notes on your desktop

This creates a lightweight, always-visible reminder system—without relying on heavy applications.

💡 Architecture Overview

The system works like this:

•Cron: writes reminders to ~/.todo

•systemd user service: checks if tasks exist

•Conky: displays them as sticky notes

Everything stays simple, modular, and hackable.

📁 Step 1: Base Todo System (Recap)

Create the file:

   
touch ~/.todo

Add a weekly cron job:

   
crontab -e

   
0 9 * * 1 echo "$(date '+%F %R') - Run sudo pacman -Syu" >> /home/mosaid/.todo

⚙️ Step 2: Create a systemd User Service

We now create a service that checks if the todo file has content.

Create the file:

   
mkdir -p ~/.config/systemd/user
vim ~/.config/systemd/user/todo-check.service

Content:

   
[Unit]
Description=Check TODO file and trigger display

[Service]
Type=oneshot
ExecStart=/usr/bin/bash -c '[ -s /home/mosaid/.todo ]'

This simply checks if the file is non-empty.

⏱️ Step 3: Add a systemd Timer

Create a timer that runs every few minutes:

   
vim ~/.config/systemd/user/todo-check.timer

   
[Unit]
Description=Run TODO check every 5 minutes

[Timer]
OnBootSec=1min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

Enable it:

   
systemctl --user daemon-reexec
systemctl --user enable --now todo-check.timer

🖥️ Step 4: Conky Sticky Notes

This is where things become visual.

Create a Conky config:

   
mkdir -p ~/.config/conky
vim ~/.config/conky/todo.conf

   
conky.config = {
    alignment = 'top_right',
    gap_x = 20,
    gap_y = 50,
    background = true,
    double_buffer = true,
    own_window = true,
    own_window_type = 'desktop',
    own_window_transparent = true,
    use_xft = true,
    font = 'DejaVu Sans Mono:size=10',
    update_interval = 5,
};

conky.text = [[
${color cyan}---- TODO ----${color}
${execi 5 tail -n 10 /home/mosaid/.todo}
]];

Run it:

   
conky -c ~/.config/conky/todo.conf &

You now have a live sticky todo list on your desktop.

✨ Step 5: Improve Visibility

Add colors and formatting:

   
${color green}${time %Y-%m-%d}${color}

Or highlight updates:

   
${execi 5 grep --color=always pacman /home/mosaid/.todo}

🧠 Optional: Auto-Hide When Empty

You can extend the systemd service to kill Conky if no tasks exist:

   
ExecStart=/usr/bin/bash -c '[ -s ~/.todo ] || pkill conky'

And restart it when tasks appear.

🚀 Extensions

•Multiple todo files: work, personal, system

•Git sync: share reminders across machines

•Notifications: integrate with notify-send

•Conky themes: match your desktop style

⚖️ Why This Setup is Powerful

•Persistent: visible on desktop at all times

•Lightweight: near-zero resource usage

•Modular: each component is independent

•Fully controllable: no black boxes

This is the kind of system that scales with your needs.

🏁 Conclusion

You’ve now transformed a simple terminal trick into a fully integrated desktop reminder system.

It respects the Unix philosophy while giving you a modern workflow.

Small tools. Big control.

Build a Zero-Dependency Terminal Reminder System (Cron + Shell)

2026-04-19T11:52:30+00:00

As Linux users, we often rely on heavy tools for things that could be solved with a few lines of shell. In this tutorial, I’ll show you how I built a zero-dependency reminder system that lives entirely in the terminal.

No GUI. No background apps. No distractions. Just a clean, minimal workflow that reminds you of important tasks like system updates.

💡 The Idea

The concept is simple:

•Step 1: A cron job writes reminders to a file

•Step 2: Your shell displays that file on startup

•Step 3: You see reminders naturally when opening a terminal

This turns your shell into a passive notification system.

📁 Step 1: Create a Reminder File

We’ll store reminders in a simple file:

touch ~/.todo

This file will act as your lightweight task list.

⏰ Step 2: Add a Weekly Cron Job

Edit your crontab:


crontab -e

Add the following line:


0 9 * * 1 echo "$(date '+%Y-%m-%d %H:%M') - Run sudo pacman -Syu" >> /home/mosaid/.todo

•Explanation:

•0 9 * * 1: Every Monday at 09:00

•echo: Adds a timestamped reminder

•>>: Appends instead of overwriting

🖥️ Step 3: Display Reminders in Your Shell

Now we make the reminders visible when opening a terminal.

For Bash:


echo 'cat ~/.todo' >> ~/.bashrc

For Zsh:


echo 'cat ~/.todo' >> ~/.zshrc

Now every new terminal session will display your reminders automatically.

✨ Step 4: Make It Cleaner

Instead of dumping the entire file, show only recent entries:


tail -n 5 ~/.todo

Update your shell config:


echo 'echo "---- TODO ----"' >> ~/.bashrc
echo 'tail -n 5 ~/.todo' >> ~/.bashrc

🎨 Optional: Highlight Important Tasks


grep --color=always pacman ~/.todo

This makes update reminders stand out visually.

🧹 Optional: Clean Completed Tasks

Once you’ve updated your system, remove the reminder:


sed -i '/pacman -Syu/d' ~/.todo

You can also automate cleanup if needed.

🚀 Extending the System

This is where things get interesting. You can easily expand this idea:

•Backups: Weekly backup reminders

•Disk cleanup: Notify when to clean cache

•Security: Remind yourself to check logs

•Multiple machines: Sync .todo with git

You now have a fully customizable reminder system.

⚖️ Cron vs Systemd Timers

Cron is simple and works everywhere, but modern systems also support systemd timers.

•Cron: Easy, universal, quick setup

•Systemd timers: More robust, better logging, tighter integration

If you want a more advanced setup, consider migrating later.

🧠 Why This Works

This approach is powerful because:

•No dependencies: Uses only built-in tools

•Zero overhead: No background services

•Contextual: Appears exactly when you open a terminal

•Hackable: Fully customizable to your workflow

It embraces the Unix philosophy: do one thing well.

🏁 Conclusion

What started as a simple cron job becomes a flexible, minimal reminder system that integrates seamlessly into your daily workflow.

Sometimes, the best tools aren’t the most complex—they’re the ones you fully control.

Tracking Class Time Precisely with Conky and Python

2026-04-18T16:41:23+00:00

As a math teacher, timing is everything.

Between explaining a concept, writing on the board, and answering questions, it’s easy to lose track of time. In our context—tight schedules, short breaks, and special timetables like Ramadan—precision matters.

So I built a lightweight system that runs automatically when I start my PC and shows me one thing: how many minutes are left in the current class period.

🧠 Overview

This setup is based on two components:

•Conky: displays the result directly on the desktop

•Python: calculates the remaining time

The result is a large number on the screen that updates every second.

⚙️ Step 1: Startup Command

Add this command to your startup (e.g., .xprofile, .bashrc, or your window manager autostart):

nohup conky -c ~/.config/conky/regular_time </dev/null >/dev/null 2>&1 & disown

🖥️ Step 2: Conky Configuration

Create the file:

~/.config/conky/regular_time

And add:

conky.config = {
    use_xft = true,
    font = 'DejaVu Sans Mono:size=230',
    xftalpha = 0.1,
    update_interval = 1,

    own_window = true,
    own_window_type = "override",
    own_window_transparent = true,
    own_window_hints = "undecorated,below,sticky,skip_taskbar,skip_pager",

    alignment = "top_middle",
    gap_x = -430,
    gap_y = 240,

    double_buffer = true,
    default_color = "white",
}

conky.text = [[
${exec python ~/.config/conky/regular_time.py}
]]

🐍 Step 3: Python Script (Regular Schedule)

Create:

~/.config/conky/regular_time.py

#!/bin/python

from datetime import datetime as dt
from datetime import timedelta

periods = [
    {'start': '08:00', 'end': '09:00'},
    {'start': '09:05', 'end': '10:00'},
    {'start': '10:10', 'end': '11:00'},
    {'start': '11:05', 'end': '12:00'},
    {'start': '14:00', 'end': '15:00'},
    {'start': '15:05', 'end': '16:00'},
    {'start': '16:05', 'end': '17:00'},
    {'start': '17:05', 'end': '18:00'},
]

now = (dt.now() - timedelta(minutes=30)).time().strftime('%H:%M')

# Friday adjustment
if dt.now().weekday() == 4:
    now = (dt.now() - timedelta(minutes=60)).time().strftime('%H:%M')

for period in periods:
    if now >= period['start'] and now < period['end']:
        remaining = (
            dt.strptime(period['end'], '%H:%M') -
            dt.strptime(now, '%H:%M')
        ).total_seconds() // 60

        print(int(remaining))
        break

🕌 Step 4: Ramadan Schedule

Create:

~/.config/conky/ramadan_time.py

from datetime import datetime as dt

periods = [
    {'start': '08:40', 'end': '09:25'},
    {'start': '09:30', 'end': '10:15'},
    {'start': '10:25', 'end': '11:10'},
    {'start': '11:15', 'end': '12:00'},
    {'start': '12:30', 'end': '13:15'},
    {'start': '13:20', 'end': '14:05'},
    {'start': '14:15', 'end': '15:00'},
    {'start': '15:05', 'end': '15:50'},
]

# Friday Ramadan schedule
if dt.now().weekday() == 4:
    periods = [
        {'start': '08:30', 'end': '09:15'},
        {'start': '09:20', 'end': '10:05'},
        {'start': '10:15', 'end': '11:00'},
        {'start': '11:05', 'end': '11:50'},
        {'start': '13:40', 'end': '14:25'},
        {'start': '14:30', 'end': '15:15'},
        {'start': '15:25', 'end': '16:10'},
        {'start': '16:15', 'end': '17:00'},
    ]

now = dt.now().time().strftime('%H:%M')

for period in periods:
    if now >= period['start'] and now < period['end']:
        remaining = (
            dt.strptime(period['end'], '%H:%M') -
            dt.strptime(now, '%H:%M')
        ).total_seconds() // 60

        print(int(remaining))
        break

🔁 Step 5: Switch Between Modes

To use Ramadan mode, simply change your Conky config:

${exec python ~/.config/conky/ramadan_time.py}

No other changes needed.

🎯 Why This Works Well

•Always visible: no need to check the clock

•Zero interaction: runs automatically at startup

•Accurate pacing: helps manage lessons better

•Adaptable: supports Ramadan and Friday schedules

🚀 Possible Improvements

•Change color when time is low

•Add sound alerts

•Display current period number

•Merge both scripts into one with auto-detection

🧩 Final Thoughts

This is a small tool, but it has a real impact on daily teaching.

It removes the need to constantly think about time and lets me focus entirely on explaining math and interacting with students.

Annotating Videos with FFmpeg Using a Python Script

2026-02-10T23:31:55+00:00

Introduction

Annotating videos is a common requirement in tutorials, software demos, online courses, and technical documentation. Whether you want to highlight steps, explain on-screen actions, or guide viewers through a workflow, text overlays can dramatically improve clarity.

In this article, I’ll walk you through a practical and flexible approach to video annotation using a custom Python script built on top of FFmpeg. The script allows you to define annotations in a JSON file, control their timing and appearance, and generate a clean, annotated output video—all from the command line.

What This Script Does

The provided Python script acts as a lightweight video annotation engine. At a high level, it:

•Reads annotations from a JSON file: Each annotation defines text, timing, position, and style.

•Generates temporary text files: This avoids escaping issues and ensures UTF‑8 compatibility.

•Builds an FFmpeg drawtext filter dynamically: One filter per annotation.

•Encodes the final video: Using H.264 by default, with configurable quality and presets.

The result is a reusable, automation‑friendly tool that fits perfectly into scripting workflows.

Prerequisites

Before using the script, make sure you have the following installed:

•Python 3.8+: The script relies on dataclasses and pathlib.

•FFmpeg: Must be available in your PATH.

•A TrueType font (.ttf): DejaVu Sans is used by default.

You can verify FFmpeg with:

ffmpeg -version

Understanding the Annotation Model

Each annotation is represented by a simple data structure:

@dataclass
class Annotation:
    text: str
    start_time: float
    duration: float
    position: str = "top"
    bg_color: str = "black@0.7"
    text_color: str = "white"
    font_size: int = 28
    font_path: Optional[str] = None

This makes annotations expressive yet easy to reason about. Timing is defined in seconds, while visual appearance is controlled via FFmpeg-compatible color and font options.

The JSON Annotation File

Annotations are defined in a JSON array. This separation of data from logic makes the tool extremely flexible.

[
  {
    "text": "Lancement de l'application LaTeX Exam Generator",
    "start_time": 0.0,
    "duration": 4.5,
    "position": "top",
    "bg_color": "black@0.7",
    "text_color": "white",
    "font_size": 32
  },
  {
    "text": "Chargement des modèles d'examens",
    "start_time": 5.0,
    "duration": 3.0,
    "position": "center",
    "bg_color": "rgba(0,0,0,0.6)",
    "text_color": "yellow",
    "font_size": 28
  }
]

This format is ideal for version control, automation, and even generating annotations programmatically.

Supported Positions and Colors

The script supports three vertical positions:

•top: Near the top of the video

•center: Vertically centered

•bottom: Near the bottom, with padding

For colors, FFmpeg offers great flexibility:

•Named colors: white, black, red, yellow

•Hex with alpha: #000000@0.75

•RGBA format: rgba(0,0,0,0.6)

Command-Line Usage

The script is designed to feel like a polished CLI tool.

annotator input.mp4 annotations.json

If no output file is specified, the script automatically generates:

input_annotated.mp4

Common Options

annotator input.mp4 annotations.json \
  --output_file output.mp4 \
  --crf 18 \
  --preset slow \
  --font /path/to/font.ttf

These options give you fine-grained control over quality, encoding speed, and typography.

How the FFmpeg Filter Works

Internally, the script builds a filter_complex string composed of multiple drawtext filters. Each filter is enabled only during its time window:

enable='between(t,start,end)'

This approach avoids splitting the video or re-running FFmpeg multiple times, keeping the process efficient and clean.

Why This Approach Scales Well

This design has several advantages:

•Automation-friendly: Perfect for batch processing videos.

•Separation of concerns: JSON handles content, Python handles logic.

•FFmpeg-native: No external rendering libraries required.

•Reproducible: Same input always produces the same output.

The full script:

    
#!/usr/bin/env python3
import subprocess
import json
import sys
from pathlib import Path
from dataclasses import dataclass
from typing import Optional, List
import argparse

@dataclass
class Annotation:
    """Represents a video annotation with styling options."""
    text: str
    start_time: float
    duration: float
    position: str = "top"  # "top", "center", "bottom"
    bg_color: str = "black@0.7"
    text_color: str = "white"
    font_size: int = 28
    font_path: Optional[str] = None

class VideoAnnotator:
    def __init__(self, input_file: str, output_file: str,
                 default_font: str = "/usr/share/fonts/TTF/DejaVuSans.ttf",
                 video_codec: str = "libx264",
                 audio_codec: str = "copy",
                 crf: int = 23,
                 preset: str = "medium"):
        self.input_file = input_file
        self.output_file = output_file
        self.default_font = default_font
        self.video_codec = video_codec
        self.audio_codec = audio_codec
        self.crf = crf
        self.preset = preset
        self.tmp_dir = Path(".ffmpeg_text")
        self.tmp_dir.mkdir(exist_ok=True)
        self.annotations: List[Annotation] = []

    def add_annotation(self, annotation: Annotation):
        self.annotations.append(annotation)

    def load_annotations_from_json(self, json_file: str):
        """Load annotations from a JSON file, filling defaults where missing."""
        with open(json_file, "r", encoding="utf-8") as f:
            data = json.load(f)
        for item in data:
            ann = Annotation(
                text=item["text"],
                start_time=float(item["start_time"]),
                duration=float(item["duration"]),
                position=item.get("position", "top"),
                bg_color=item.get("bg_color", "black@0.7"),
                text_color=item.get("text_color", "white"),
                font_size=item.get("font_size", 28)
            )
            self.add_annotation(ann)

    def _create_text_files(self):
        for i, ann in enumerate(self.annotations):
            text_file = self.tmp_dir / f"text_{i}.txt"
            text_file.write_text(ann.text, encoding="utf-8")

    def _build_filter_complex(self) -> str:
        filter_parts = []
        for i, ann in enumerate(self.annotations):
            end_time = ann.start_time + ann.duration
            font = ann.font_path or self.default_font
            text_file = self.tmp_dir / f"text_{i}.txt"

            padding = 10

            if ann.position == "top":
                y_expr = f"{padding}"
            elif ann.position == "center":
                y_expr = "(h-text_h)/2"
            else:  # bottom
                y_expr = f"h-text_h-{padding}"

            text_filter = (
                f"drawtext=fontfile='{font}':textfile='{text_file}':"
                f"fontcolor={ann.text_color}:fontsize={ann.font_size}:"
                f"x=(w-text_w)/2:y={y_expr}:"
                f"box=1:boxcolor={ann.bg_color}:boxborderw={padding}:"
                f"enable='between(t,{ann.start_time},{end_time})'"
            )
            filter_parts.append(text_filter)
        return ",".join(filter_parts)

    def run(self):
        if not self.annotations:
            print("⚠️ No annotations added.")
            return

        self._create_text_files()
        filter_complex = self._build_filter_complex()

        cmd = [
            "ffmpeg",
            "-y",
            "-i", self.input_file,
            "-vf", filter_complex,
            "-c:v", self.video_codec,
            "-preset", self.preset,
            "-crf", str(self.crf),
            "-c:a", self.audio_codec,
            "-movflags", "+faststart",
            self.output_file
        ]

        print("▶ Exécution FFmpeg…")
        print(f"Nombre d'annotations : {len(self.annotations)}")

        try:
            subprocess.run(cmd, check=True)
            print(f"✅ Vidéo annotée générée : {self.output_file}")
        except subprocess.CalledProcessError as e:
            print(f"❌ Erreur lors de la génération: {e}")
        finally:
            self.cleanup()

    def cleanup(self):
        if self.tmp_dir.exists():
            for file in self.tmp_dir.glob("*.txt"):
                try:
                    file.unlink()
                except:
                    pass


def create_help_text():
    """Create comprehensive help text with examples."""
    example_json = [
        {
            "text": "Lancement de l'application LaTeX Exam Generator",
            "start_time": 0.0,
            "duration": 4.5,
            "position": "top",
            "bg_color": "black@0.7",
            "text_color": "white",
            "font_size": 32
        },
        {
            "text": "Chargement des modèles d'examens",
            "start_time": 5.0,
            "duration": 3.0,
            "position": "center",
            "bg_color": "rgba(0,0,0,0.6)",
            "text_color": "yellow",
            "font_size": 28
        },
        {
            "text": "Export du sujet en PDF",
            "start_time": 9.5,
            "duration": 4.0,
            "position": "bottom",
            "bg_color": "#000000@0.75",
            "text_color": "white",
            "font_size": 26
        }
    ]

    help_text = f"""
Annotate a video with text boxes from a JSON file of annotations.

USAGE:
  annotator video_file annotations_json [OPTIONS]

REQUIRED ARGUMENTS:
  video_file         Path to the input video file
  annotations_json   Path to JSON file with annotations

OPTIONS:
  --output_file FILE   Path to the output video file (default: input_filename_annotated.ext)
  --font FONT          Path to TTF font file (default: /usr/share/fonts/TTF/DejaVuSans.ttf)
  --video_codec CODEC  Video codec for output (default: libx264)
  --audio_codec CODEC  Audio codec for output (default: copy)
  --crf VALUE          CRF quality (lower is better quality, 18-28 recommended, default: 23)
  --preset PRESET      FFmpeg preset for encoding (ultrafast, superfast, veryfast, faster,
                       fast, medium, slow, slower, veryslow; default: medium)

JSON FILE FORMAT:
  The annotations file must be a JSON array of objects. Each object can have these fields:

  REQUIRED fields:
    text:        The text to display (string)
    start_time:  Start time in seconds (float)
    duration:    Duration in seconds (float)

  OPTIONAL fields (with defaults):
    position:    Text position - "top", "center", or "bottom" (default: "top")
    bg_color:    Background color (default: "black@0.7")
    text_color:  Text color (default: "white")
    font_size:   Font size in pixels (default: 28)

  Example JSON file:
{json.dumps(example_json, indent=2, ensure_ascii=False)}

COLOR FORMATS:
  - Named colors: white, black, red, green, blue, yellow, cyan, magenta
  - Hex with alpha: #RRGGBB@0.8 (0.0 transparent, 1.0 opaque)
  - RGBA format: rgba(255,0,0,0.7) where last value is alpha (0.0-1.0)

EXAMPLES:
  1. Basic usage:
     annotator input.mp4 annotations.json

  2. With custom output and quality settings:
     annotator input.mp4 annotations.json --output_file output.mp4 --crf 18 --preset slow

  3. With custom font:
     annotator input.mp4 annotations.json --font /path/to/font.ttf

NOTES:
  - The JSON file must be UTF-8 encoded
  - Font file must be a TrueType font (.ttf)
  - Video is encoded with H.264 by default, adjust --video_codec for other formats
  - Audio is copied without re-encoding by default
"""
    return help_text


def parse_args():
    parser = argparse.ArgumentParser(
        description="Annotate a video with text boxes from a JSON file of annotations.",
        formatter_class=argparse.RawDescriptionHelpFormatter,
        epilog="For complete documentation, run 'annotator --help'."
    )

    # Add custom help option that shows full documentation
    parser.add_argument(
        "--help-full",
        action="store_true",
        help="Show comprehensive help with examples"
    )

    parser.add_argument("video_file", nargs="?", help="Path to the input video file")
    parser.add_argument("annotations_json", nargs="?", help="Path to JSON file with annotations")

    parser.add_argument("--output_file", default=None,
                        help="Path to the output video file (default: input_filename_annotated.ext)")
    parser.add_argument("--font", default="/usr/share/fonts/TTF/DejaVuSans.ttf",
                        help="Path to TTF font file (default: DejaVuSans)")
    parser.add_argument("--video_codec", default="libx264",
                        help="Video codec for output (default: libx264)")
    parser.add_argument("--audio_codec", default="copy",
                        help="Audio codec for output (default: copy)")
    parser.add_argument("--crf", type=int, default=23,
                        help="CRF quality (lower is better quality, default: 23)")
    parser.add_argument("--preset", default="medium",
                        help="FFmpeg preset for encoding speed/quality (default: medium)")

    return parser.parse_args()


def main():
    args = parse_args()

    # Show full help if --help-full is specified
    if args.help_full:
        print(create_help_text())
        sys.exit(0)

    # Check for required arguments if not showing help
    if not args.video_file or not args.annotations_json:
        print("Error: Missing required arguments\n")
        print("Usage: annotator video_file annotations_json [OPTIONS]")
        print("\nFor comprehensive help with examples, use: annotator --help-full")
        print("For brief help, use: annotator --help")
        sys.exit(1)

    # Determine output file if not provided
    if args.output_file:
        output_file = args.output_file
    else:
        input_path = Path(args.video_file)
        output_file = str(input_path.with_name(input_path.stem + "_annotated" + input_path.suffix))

    annotator = VideoAnnotator(
        input_file=args.video_file,
        output_file=output_file,
        default_font=args.font,
        video_codec=args.video_codec,
        audio_codec=args.audio_codec,
        crf=args.crf,
        preset=args.preset
    )

    annotator.load_annotations_from_json(args.annotations_json)
    annotator.run()


if __name__ == "__main__":
    main()

Conclusion

Annotating videos doesn’t have to involve heavy GUI tools or manual editing. With a well-structured Python script and FFmpeg’s powerful drawtext filter, you can generate professional, timed annotations directly from JSON data.

This script is especially useful for technical demos, educational content, and automated video pipelines. Feel free to extend it with animations, transitions, or even dynamic annotation generation.

If you’re interested in pushing this further—such as subtitle export, multi-language overlays, or integration into a web interface—there’s plenty of room to build on this foundation. Happy annotating 🚀

Boosting LaTeX Editing with Custom Vim Mappings

2025-11-23T23:46:56+00:00

Introduction

As someone who writes mathematical documents regularly, I've always found LaTeX editing to be a constant dance between content creation and formatting struggles. The back-and-forth typing of verbose commands like \textbf{} and \underline{} constantly interrupted my creative flow. That's when I decided to supercharge my Vim setup with custom mappings specifically designed for LaTeX - and the results have been transformative for my productivity.

Basic Settings

Before diving into the fancy mappings, let's start with the foundation. I prefer 2-space indentation for LaTeX files as it strikes the perfect balance between readability and efficient use of screen space:

autocmd FileType tex setlocal tabstop=2 shiftwidth=2 expandtab

Compiling and Viewing LaTeX

One of the most common tasks in LaTeX editing is compiling and previewing. Instead of constantly switching to the terminal, I've created seamless workflows right within Vim.

•Instant Compilation: Pressing <leader>c compiles the current file and shows me the output right in a Vim buffer - no context switching needed:

    
function! RunTex()
    let s:current_file = expand("%")
    enew | silent execute ".!xelatex " . shellescape(s:current_file, 1)
    setlocal buftype=nofile bufhidden=wipe noswapfile nowrap
    if &number == 0
        set number
    endif
    set relativenumber
    normal! G
    nnoremap <buffer> <CR> :bd!<CR>
endfunction
nnoremap <leader>c :call RunTex()<CR>

•Quick PDF Preview: When I need to see the actual PDF, <leader>o opens it in Evince without leaving Vim:

    
function! ViewTex() abort
    let pdf = substitute(expand('%:p'), '\.tex$', '.pdf', '')
    silent! execute '!nohup evince ' . shellescape(pdf) . ' >/dev/null 2>&1 &'
    redraw!
endfunction
nnoremap <leader>o :call ViewTex()<CR>

Smart Insert Mode Shortcuts

These are the real workhorses of my LaTeX workflow - they let me insert common elements with minimal keystrokes while keeping me in the flow.

•Mathematical Spacing: Instead of typing \quad every time, I just type qq in insert mode and it expands automatically.

•Text Wrapping: Need text in a math environment? tt wraps my text with proper formatting and even positions my cursor inside the braces.

•Formatting Commands: Bold and underline become second nature with ;bf for \textbf{} and ;u for \underline{}.

•Template Loading: This is where the real magic happens. I have pre-written templates for common elements:

;tcb inserts a beautiful tcolorbox environment with proper styling
;ds loads my document structure template with title, author, and sections pre-filled

    
inoremap qq \quad
inoremap tt ~\text{}~<++><ESC>F{a
inoremap ;bf \textbf{}<++><ESC>F{a
inoremap ;u \underline{}<++><ESC>F{a
inoremap ;tcb <ESC>:r /home/mosaid/.vim/snippets/latex/tcb<CR>
inoremap ;ds <ESC>:0r /home/mosaid/.vim/snippets/latex/ds<CR>

Visual Mode Power Tools

When working with existing text, these visual mode mappings are absolute lifesavers:

•Quick Formatting: Select text and use <leader>b for bold or <leader>u for underline - it wraps your selection perfectly.

•Math Mode Magic: My personal favorites include:

5 on selected text wraps it with math mode delimiters
6 converts display math \[ \] to inline math $ $
9 transforms  math notation to the cleaner $ $ syntax

    
vnoremap <leader>$ s~$<C-r>"$~<++><Esc>
vnoremap <leader>u c\underline{<C-r>"}<++>
vnoremap <leader>b c\textbf{<C-r>"}<++>
vnoremap 5 c~$<C-r>"$~<Esc>
vnoremap 6 <Esc>:'<,'>s/\\\[/\~$/e<CR>:'<,'>s/\\\]/\$\~/e<CR>
vnoremap 9 <Esc>:'<,'>s/\\(/\~$/eg<CR>:'<,'>s/\\)/\$\~/eg<CR>

Mathematical Efficiency Boosters

These small but mighty mappings handle the repetitive mathematical notation that used to slow me down:

    
inoremap ;o $(O; \vec i, \vec j)$
inoremap $$ ~$$~<++><Esc>F$i
inoremap [ []<++><Esc>F]i

The ;o mapping is particularly useful for coordinate systems, while $$ and [ handle the common cases of creating math environments and brackets with proper cursor placement.

Conclusion

What started as a simple attempt to reduce typing has evolved into a comprehensive LaTeX editing system that feels almost like having a personal assistant. The beauty of these mappings isn't just in the time saved - it's in the uninterrupted flow state they enable. I no longer break my mathematical reasoning to remember LaTeX syntax; the commands have become extensions of my thought process. Whether you're a student writing homework, a researcher drafting papers, or anyone who frequently works with LaTeX, I highly recommend investing time in building your own Vim mappings - the productivity payoff is absolutely worth it.

Automating Code Transformations in Vim with RunScriptsOnSelect

2025-11-23T18:54:13+00:00

Streamlining Code Processing in Vim

When I work with multiple programming languages, I often need to process code snippets through external tools. Manually handling this became tedious, so I created a Vim function that automates the entire workflow. The RunScriptsOnSelect function detects code type from visual selections and routes them to appropriate Python processors automatically.

How RunScriptsOnSelect Works

The function operates in visual mode and follows this intelligent workflow:

•Selection Capture: It captures the visually selected text range including line numbers

•Type Detection: Uses the first line as a type indicator for processing

•Validation: Checks against allowed processors to prevent errors

•Routing: Sends content to the appropriate Python script

•Replacement: Cleanly replaces selection with processed output

The Complete Implementation

Here is the complete Vim function that makes this automation possible:

    
function! RunScriptsOnSelect()
    " Get selection range
    let l:start_line = line("'<")
    let l:end_line = line("'>")

    " Get selected lines
    let l:lines = getline(l:start_line, l:end_line)

    " First line = type
    let l:type_line = tolower(trim(l:lines[0]))

    " Allowed types
    let l:allowed_types = ['tex', 'html', 'py', 'vim']

    " Validate first line
    if index(l:allowed_types, l:type_line) == -1
        let l:reminder = ["Make the first line of your selection as tex, html, py or md"]
        call setline(l:start_line, l:reminder)
        " Delete the rest of selection
        if l:end_line > l:start_line
            call deletebufline('%', l:start_line + 1, l:end_line)
        endif
        return
    endif

    " Actual content to process = selection except first line
    let l:selected_text = join(l:lines[1:], "\n")

    " Script locations
    let l:script_base_dir = '~/bin/python'
    let l:script_map = {
    \ 'tex':  l:script_base_dir . '/change-tex.py',
    \ 'vim':  l:script_base_dir . '/change-vim.py',
    \ 'py':   l:script_base_dir . '/change-python.py',
    \ 'html': l:script_base_dir . '/change-html.py',
    \ }

    " Run script
    let l:output = system('python3 ' . l:script_map[l:type_line], l:selected_text)
    let l:output_lines = split(l:output, "\n")

    " ---- SIMPLE & SAFE REPLACEMENT ----
    " 1) Delete entire selection
    call deletebufline('%', l:start_line, l:end_line)

    " 2) Insert type line + script output
    call append(l:start_line - 1, [l:type_line] + l:output_lines)
endfunction

vnoremap <leader>rs :<C-U>call RunScriptsOnSelect()<CR>

Robust Type Validation

By checking against the allowed_types list, we ensure only supported processors are used. If someone tries an unsupported type, they get immediate feedback with clear instructions.

Flexible Script Mapping

The script_map dictionary makes it incredibly easy to extend functionality. When I want to add support for a new language, I simply add another entry to the mapping - no need to modify the core function logic.

Clean Output Replacement

This was the trickiest part to get right. The function handles cases where processed output might be longer or shorter than the original selection, ensuring clean replacement without leaving orphaned lines or missing content.

Example Processor Script

Here is a sample Python script that demonstrates how to process Vim script content. This particular example escapes HTML and wraps Vim code in proper pre and code tags:

    
import sys
import html

def process_text(content):
    """Escape LaTeX and wrap in <pre><code>."""
    escaped_content = html.escape(content)
    wrapped_content = f"""<pre class="language-vim">
    <code class="language-vim">
{escaped_content}
    </code>
</pre>
"""
    return wrapped_content

if __name__ == "__main__":
    if len(sys.argv) > 1:
        # Read content from file if a path is provided
        file_path = sys.argv[1]
        try:
            with open(file_path, 'r') as f:
                content = f.read()
        except Exception as e:
            print(f"Error processing file: {e}")
            sys.exit(1)
    else:
        # Otherwise, read content from stdin
        content = sys.stdin.read()

    print(process_text(content))

To use this function in your daily workflow, follow these steps:

1. Enter visual mode and select your code block

2. Make sure the first line indicates the processor type

3. Press your leader key followed by rs

For example, to process Vim script, your selection would look like this:

    
vim
function! ExampleFunction()
    echo "This will be processed as Vim script"
endfunction

Customization Opportunities

•Extended Language Support: Add more types to the allowed_types list for additional languages

•Custom Script Locations: Modify the script_base_dir to point to your preferred script locations

•Error Handling: Add more robust error handling for missing script files or processing failures

•Preview Functionality: Implement a preview mode that shows changes before applying them

•Multiple Processors: Allow chaining multiple processors for complex transformations

This Vim function demonstrates how we can combine Vim's powerful extensibility with Python's processing capabilities. It creates a seamless workflow that adapts to multiple programming languages while maintaining the efficiency and speed that makes Vim such a powerful editor.

The beauty of this approach is its simplicity and extensibility. Once you have the core function working, adding support for new languages or processors becomes trivial. I have found this particularly useful when working with documentation, code samples, and automated formatting tasks.

Improving TeX Editing in Vim with a Smart 'Select Inside Any Pair' Function

2025-11-23T18:14:02+00:00

Improving Your TeX Workflow in Vim with a Smart “Select Inside Any Pair” Function

One of the reasons I love working in Vim is how easily I can extend it to match the way I write and edit. When dealing with LaTeX files—especially long derivations, nested parentheses, or math environments—I often need to quickly select the text inside {…}, (…), or even inside $…$ blocks. Doing this manually wastes time, interrupts my flow, and becomes frustrating when there are many levels of nesting.

To fix this, I wrote a custom function that intelligently selects whatever “pair” I am currently inside: curly braces, brackets, parentheses, math mode, quotes—anything. This small function has massively improved how I work inside TeX files.

Why This Function Matters

•Instant selection in TeX math: When working between $…$ , a single keystroke selects the content cleanly—even in long expressions.

•Nested structures handled automatically: For { { ( … ) } }, the function detects the correct level around the cursor instead of selecting the wrong one.

•Works across all common pairs: Parentheses, brackets, braces, math mode, quotes, and even symmetric delimiters are supported.

•Better than built-in text objects: Vim’s default vi( and friends work only when your cursor is right next to the delimiter. This custom function works even if you're deep inside the content.

The Function That Does the Magic

    
function! SelectInsideAnyPair()
    let l:savepos = getpos('.')

    let l:pairs = [
    \ ['{', '}'],
    \ ['[', ']'],
    \ ['(', ')'],
    \ ['$', '$'],
    \ ['"', '"'],
    \ ["'", "'"]
    \ ]

    for l:pair in l:pairs
        let l:open  = l:pair[0]
        let l:close = l:pair[1]

        if l:open ==# l:close
            " symmetric delimiters
            let l:start = searchpos('\V' . l:open, 'bnW')
            let l:end   = searchpos('\V' . l:close, 'nW')
        else
            " asymmetric pairs (handles nesting)
            let l:start = searchpairpos('\V' . l:open, '', '\V' . l:close, 'bnW')
            let l:end   = searchpairpos('\V' . l:open, '', '\V' . l:close, 'nW')
        endif

        if l:start[0] > 0 && l:end[0] > 0
            let l:cur = getpos('.')
            let l:start_before_cursor = (l:start[0] < l:cur[1]) || (l:start[0] == l:cur[1] && l:start[1] <= l:cur[2])
            let l:end_after_cursor   = (l:end[0]   > l:cur[1]) || (l:end[0]   == l:cur[1] && l:end[1]   >= l:cur[2])

            if l:start_before_cursor && l:end_after_cursor
                " start just after opening delimiter
                call setpos('.', [0, l:start[0], l:start[1] + 1, 0])
                normal! v
                " end just before closing delimiter
                call setpos('.', [0, l:end[0], l:end[1], 0])
                normal! h
                return
            endif
        endif
    endfor

    " --- fallback: select whole line (without trailing $) ---
    let l:lnum = line('.')
    let l:line = getline(l:lnum)

    " compute start and end columns
    let l:start_col = 1
    let l:end_col   = len(l:line)

    " if line ends with $, exclude it
    if l:end_col > 0 && l:line[-1:] ==# '$'
        let l:end_col -= 1
    endif

    if l:end_col >= l:start_col
        call setpos('.', [0, l:lnum, l:start_col, 0])
        normal! v
        call setpos('.', [0, l:lnum, l:end_col, 0])
    else
        call setpos('.', l:savepos)
        echo "Nothing to select"
    endif
endfunction

nnoremap <silent> <leader>v :call SelectInsideAnyPair()<CR>

This tiny Vim function eliminates the repetitive hassle of manually selecting content inside brackets, quotes, or math delimiters. For LaTeX-heavy workflows, it’s a real productivity booster.

How I Use Vim to Do Quick Calculations While Writing LaTeX

2025-09-28T13:48:54+00:00

Supercharging Vim: Running Python Code Directly from Your Editor

Running python directly in vim

I've always loved Vim for its speed, simplicity, and ability to stay entirely in the terminal while doing serious work. But recently, I added a layer of magic that completely changed how I use it — running Python code directly from Vim without leaving the editor. This has been a game-changer, especially when editing LaTeX documents or writing technical content that needs quick calculations on the fly.

Imagine this: I'm writing an article and need to calculate a percentage or quickly check a value before putting it into my text. Instead of switching to a Python REPL or using a calculator, I just visually select the code, hit a keybinding, and Vim either shows me the result in a scratch buffer or replaces the selected text with the computed value. It's seamless, and it's awesome.

The Magic Behind It

Here’s what makes this possible — two small but powerful Vimscript functions that I added to my configuration. The first one runs any visually selected Python code and shows me the output in a new scratch buffer:

    
function! RunPythonSelection() range
    " Save current register and selection type
    let l:save_reg = getreg('"')
    let l:save_regtype = getregtype('"')

    " Yank the visually selected text into the default register
    normal! ""gvy
    let l:code = getreg('"')

    " Restore register
    call setreg('"', l:save_reg, l:save_regtype)

    " Trim leading/trailing whitespace
    let l:code = substitute(l:code, '^\s*', '', '')
    let l:code = substitute(l:code, '\s*$', '', '')

    " Run the exact selected text as Python code
    let l:output = system('python3 -c ' . shellescape(l:code))

    " Open a scratch buffer and display the output
    enew
    call setline(1, split(l:output, "\n"))
    setlocal buftype=nofile bufhidden=wipe noswapfile nowrap
endfunction


xnoremap  <leader>c :<C-u>call RunPythonSelection()<CR>

This function is brilliant for experimentation. I just highlight a few lines of Python, press <leader>c, and I get a temporary buffer with the result — no clutter in my main file, no switching windows.

But Wait, It Gets Better

Sometimes I don't just want to see the result, I want to replace the selected text with the result. That's where the second function comes in:

    
function! RunPythonAndReplace() range
    " Save current register and selection type
    let l:save_reg = getreg('"')
    let l:save_regtype = getregtype('"')

    " Yank visually selected text into the default register
    normal! ""gvy
    let l:code = getreg('"')

    " Restore register contents
    call setreg('"', l:save_reg, l:save_regtype)

    " Trim whitespace
    let l:code = substitute(l:code, '^\s*', '', '')
    let l:code = substitute(l:code, '\s*$', '', '')

    " Detect if selection is a single line
    if line("'<") == line("'>")
        let l:code = 'print(' . l:code . ')'
    endif

    " add some imports
    let l:code = 'from math import *;' . l:code

    " Run the code through Python
    let l:output = system('python3 -c ' . shellescape(l:code))

    " Remove trailing newline from output
    let l:output = substitute(l:output, '\n\+$', '', '')

    " Replace the selection with the output
    execute "normal! gv\"_c" . l:output
endfunction

xnoremap  <leader>r :<C-u>call RunPythonAndReplace()<CR>

This one is my favorite. Let's say I'm writing a LaTeX file and I have:

    
The success rate is $ (45/60)*100 $ \%.

I can just visually select (45/60)*100, hit <leader>r, and boom — it’s replaced with 75.0. This keeps me focused and lets me write accurate numbers without ever leaving my editor.

Running python directly in vim

Why This Matters

•Context Switching is the Enemy: Leaving Vim to open a calculator or REPL breaks flow. This solves that.

•Perfect for Technical Writing: I use this trick while editing LaTeX code, which often requires quick math or unit conversions.

•Great for Learning: You can experiment with Python right inside Vim, which is fantastic if you're learning to code or testing snippets.

•Completely Customizable: These functions are just Vimscript — you can extend them, add error handling, or even log outputs to a file.

My Verdict

Vim was already my favorite editor, but these little functions make it feel like a true integrated environment. Whether I'm writing articles, preparing lecture notes, or hacking on LaTeX, I now have instant Python execution at my fingertips. And honestly, it feels like cheating — but in the best possible way.

If you use Vim and write technical documents or code, give these functions a try. They’ll make your workflow smoother, faster, and more fun.

Quran Player Daemon: Audio Playback with Desktop Visualization

2025-07-24T01:05:02+00:00

The Quran Player Daemon is a Python-powered background service built to provide uninterrupted Quranic audio playback while displaying the corresponding verse directly on your desktop using Conky. This elegant combination is ideal for personal devotion, Islamic display panels, or memorization tools. The daemon intelligently manages verse transitions, preserves playback state, and handles Arabic rendering with care.

•Persistent background daemon: enables continuous playback

•Auto verse navigation: seamlessly moves to the next verse

•Custom repeat ranges: for focused memorization or recitation

•Arabic text rendering: with correct shaping and font support

•Cross-platform playback: supports multiple audio engines

•Session persistence: remembers last played verse

•Conky integration: renders verses live on your desktop

Daemon Architecture

At its core, the daemon manages Quranic audio playback and socket communication. Here's how it initializes:


def handle_start(self):
    if not self.verify_audio_config():
        sys.exit(1)

    self.audio_player = AudioPlayer(config, self.log_action)
    with open(config.LOCK_FILE, 'w') as f:
        portalocker.lock(f, portalocker.LOCK_EX)

    with open(config.PID_FILE, "w") as pid_file:
        pid_file.write(str(os.getpid()))

    server = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
    server.bind(config.SOCKET_FILE)
    server.listen(5)
    self.log_action("INFO", "Daemon started. Listening for commands.")

Robust Audio Handling

The audio backend uses pygame's mixer with retry logic:


class AudioPlayer:
    def init_audio(self, max_retries=3):
        for attempt in range(max_retries):
            try:
                pygame.mixer.init(
                    frequency=44100,
                    size=-16,
                    channels=2,
                    buffer=1024
                )
                return True
            except pygame.error:
                time.sleep(1)
        return False

Arabic Text Rendering

Arabic text is shaped and rendered into an image, supporting right-to-left alignment:


def render_arabic_text_to_image(text, output_path, config):
    font = ImageFont.truetype(config['image']['FONT_FILE'], 48)
    image = Image.new("RGBA", (1240, 800), (0, 0, 0, 0))
    draw = ImageDraw.Draw(image)

    # Assume line-by-line rendering has been calculated
    draw.text((image.width - text_width - 20, y), line,
              font=font, fill=color, direction="rtl")
    image.save(output_path, "PNG")

Conky Integration

Verses are displayed using Conky for a minimal, non-intrusive overlay:

Quran Verse Displayed on Desktop via Conky


conky.config = {
    font = 'Amiri:size=38',
    own_window = true,
    own_window_type = "override",
    own_window_transparent = true,
    alignment = "top_middle",
    gap_x = 25,
    gap_y = 140
}

conky.text = [[
${alignr}${execi 0.5 /path/to/reshape_arabic.sh | head -n 1}
${alignr}${execi 0.5 /path/to/reshape_arabic.sh | sed -n '2p'}
]]

The reshaping script:


#!/bin/bash
# reshape_arabic.sh

arabic_text="$(cat /tmp/quran_verse.txt)"
reshaped_text=$(python reshape_arabic.py "$arabic_text")
echo "$reshaped_text"

Playback and Navigation

Playback auto-advances to the next verse intelligently:


def handle_playback_end(self):
    next_verse = self.get_next_verse()
    if next_verse:
        self.current_verse = next_verse
        self.play_verse(next_verse)

Navigation adapts based on repeat range:


def get_next_verse(self):
    if self.repeat_range:
        start, end = self.repeat_range
        return (surah, (ayah + 1) if ayah < end else start)
    else:
        return (surah, ayah + 1) if ayah < max_ayah else (surah + 1, 0)

Configuration Management


class ConfigManager:
    def __init__(self):
        self.USER_CONFIG_DIR = "~/.config/quran-player"
        self.STATE_FILE = os.path.join(self.USER_CONFIG_DIR, "playback_state.ini")
        self.config = self._load_config()

Installation Guide

The project includes an installer for easy setup:


#!/bin/bash
# install.sh

INSTALL_DIR="$HOME/.quran-player"

copy_application_files() {
    cp daemon.py config_manager.py "$INSTALL_DIR/"
    cp -r audio quran-text "$INSTALL_DIR/"
}

create_cli_wrappers() {
    cat > /usr/local/bin/quran-daemon <<EOF
#!/bin/bash
"$INSTALL_DIR/env/bin/python" "$INSTALL_DIR/daemon.py" "\$@"
EOF
    chmod +x /usr/local/bin/quran-daemon
}

Basic Commands


# Start the daemon
quran-daemon start

# Load specific verse
quran-daemon load 1:1

# Repeat verses 1–7 of Al-Fatiha
quran-daemon repeat 1:1:7

# Show daemon status
quran-daemon status

Performance Highlights

•Thread-based architecture: minimal CPU usage

•Async I/O operations: non-blocking design

•Audio resource optimization: smart reinitialization

•Socket pooling: avoids redundant connections

•Log rotation: keeps disk usage under control


def rotate_log_if_needed(self, logfile):
    max_size = 1_000_000  # 1MB
    if os.path.getsize(logfile) >= max_size:
        os.rename(logfile, f"{logfile}.1")

Real-World Applications

•Islamic Kiosks: Raspberry Pi-powered Quranic display

•Mosques: desktop verse projection during prayer

•Quran Schools: aid in memorization and repetition

•Personal Use: background recitation during work

•Accessibility: support for visually impaired learners

Final Thoughts

The Quran Player Daemon showcases how modern Python tooling can be used to build spiritually meaningful, technically elegant applications. Through Conky and Arabic text processing, it offers a beautiful and non-intrusive way to stay connected with the Quran. Open-source and modular, it's ready for integration with translations, prayer reminders, or mobile extensions.

Resources:

• Project Repo: github.com/neoMOSAID/quran-player

• Conky Docs: conky.sourceforge.net

• Arabic Reshaper: pypi.org/project/arabic-reshaper

Complete Tutorial: Creating Categories and Subcategories Using Pages in Pelican

2025-06-24T17:20:17+00:00

Introduction: Why Static Websites Can Beat Dynamic Ones

In the web development world, dynamic websites built with platforms like WordPress, Flask, or Laravel often get all the attention. They provide databases, admin dashboards, and real-time interactivity. However, there’s a quiet champion that often goes overlooked: the static website.

Static websites, like the ones built with Pelican, are incredibly fast, secure, and require very little maintenance. There’s no backend database to worry about, no server-side code that can break or get hacked, and the speed is unmatched because the server simply delivers pre-built HTML files.

What’s even better? You can simulate categories and subcategories using only pages and folders, without complex taxonomies or dynamic systems. Let me walk you through the process step-by-step, using my actual setup.

1. Setting Up Your Python Environment and Pelican Project

Let’s start from scratch.

•Create a new Python environment: It’s always a good idea to isolate your project.

    
python3 -m venv env
source env/bin/activate

•Install Pelican:

    
pip install "pelican[markdown]"
pip install pelican-sitemap pelican-related-posts pelican-neighbors pelican-render-math pelican-jinja2content

•Create your Pelican project:

    
pelican-quickstart

You’ll be asked a few questions:

The site title
Your author name
The site URL (you can leave it empty for now)

Pelican will create a basic directory structure for you.

   
my-pelican-site/
├── content/
│   ├── articles/      # Optional if you write articles
│   ├── pages/         # General pages (about, contact, etc.)
│   ├── courses/       # Structured content for courses
│   ├── images/        # Static images
│   ├── pdfs/          # Static PDFs
│   └── extra/         # Additional files
├── output/            # Generated static site (HTML files) after building
├── pelicanconf.py     # Main configuration file
├── publishconf.py     # Production-specific settings (optional)
├── tasks.py           # Optional automation script
├── Makefile           # For quick commands like `make html` and `make serve`
├── requirements.txt   # Python dependencies (optional but recommended)
├── theme/             # Your custom Pelican theme
│   ├── templates/     # Jinja2 HTML templates
│   └── static/        # Theme-specific CSS, JS, images
└── pelican-plugins/   # Pelican plugins folder (if local)

2. Understanding the Key Components of a Pelican Project

Here’s what matters for our goal:

•content/ — where you will write your pages, courses, articles, etc.

•output/ — the generated static website (HTML files, ready to publish).

•pelicanconf.py — the main configuration file.

•themes/ — where you can customize the design of your website.

We will mostly focus on:

Organizing the content/ folder

Writing rich Markdown files with metadata

Configuring pelicanconf.py properly to simulate categories and subcategories using folders.

3. Setting Up Your Pelican Configuration

Here’s a stripped version of my real configuration focused on pages and folder hierarchy:

    

AUTHOR = 'your author name'
SITENAME = 'your site name'
SITEURL = ''

PATH = 'content'
TIMEZONE = 'UTC'
DEFAULT_LANG = 'en'

PLUGIN_PATHS = ['pelican-plugins']
PLUGINS = ['sitemap', 'related_posts', 'neighbors', 'render_math', 'jinja2content']

THEME = 'theme'
STATIC_PATHS = ['images', 'courses', 'extra', 'theme/static', 'pdfs']

PAGE_PATHS = ['pages', 'blogs', 'courses']

PAGE_URL = '{slug}.html'
PAGE_SAVE_AS = '{slug}.html'

PAGE_URLS = {'courses': 'courses/{subject}/{schoolyear}/{slug}.html'}
PAGE_SAVE_AS_TEMPLATES = {'courses': 'courses/{subject}/{schoolyear}/{slug}.html'}

DEFAULT_PAGINATION = 7

DIRECT_TEMPLATES = ['index', 'categories', 'tags', 'archives', 'courses']

Key Notes:

✔️ We tell Pelican where to find pages: 'pages', 'blogs', 'courses'

✔️ We build URLs for courses based on metadata: subject and school year.

✔️ We don’t use articles here because we’re simulating categories with pages.

4. How to Create a Page (with Metadata)

You can create a page by writing a Markdown file inside content/pages/ or content/courses/.

Here’s a basic example for a course page:

Create it as content/courses/mathematics/course-1.md

   
Title: Course 1
Date: 2025-06-24
Type: course
Subject: mathematics
SchoolYear: 2025
Save_as: courses/mathematics/2025/course-1.html
URL: courses/mathematics/2025/course-1.html

Welcome to the Calculus Course for the year 2025. This course covers the fundamentals of calculus...

✔️ The metadata at the top (Type, Subject, SchoolYear) is what allows us to identify a page type, category and subcategory and filter pages later in the templates

✔️ (URL, Save_as, ) gives us more control about saving the files

✔️ you can add other metadata if you want, like description, path to thumbnail..., and all will be accessible to the template

✔️ This page will automatically be saved as: output/courses/mathematics/2025/course-1.html

5. Creating the Illusion of Categories and Subcategories

Here’s the trick:

Subjects act as categories.
School years act as subcategories.

And it all comes from the metadata

When you build the site, Pelican will automatically generate:

    
output/
├── courses/
│   ├── mathematics/
│   │   ├── 2025/
│   │   │   └── calculus.html
│   │   └── 2024/
│   │       └── algebra.html
│   └── physics/
│       └── 2025/
│           └── mechanics.html

You’ve now created categories and subcategories without using Pelican’s built-in categories.

6. Building the Website

Run the following command to generate your site:

    
pelican content

Pelican will create the output/ folder containing your static site.

You can preview it using:

    
pelican --listen --autoreload --port 8001

Visit http://localhost:8001 to see your site in action.

7. Navigating the Structure on Your Website

Since we configured pelican to find a direct template courses we create it in the templates folder exactly named "courses.html"

and then , go crazy with your code, do something like:

    
<h2 class="mb-4">Browse All Courses</h2>

<div class="container mt-5">
    <h2 class="mb-4">Courses by Subject and School Year</h2>
    {% set subjects = pages | selectattr('metadata.type', 'equalto', 'course') | map(attribute='metadata.subject') | unique | sort %}
    <ul class="list-group">
        {% for subject in subjects %}
            <li class="list-group-item mb-3">
                <h4 class="mb-2">{{ subject | title }}</h4>
                {% set schoolyears = pages
                    | selectattr('metadata.type', 'equalto', 'course')
                    | selectattr('metadata.subject', 'equalto', subject)
                    | map(attribute='metadata.schoolyear')
                    | unique | sort %}
                <ul class="ml-4">
                    {% for year in schoolyears %}
                        <li class="mb-2">
                            <strong>{{ year.replace('-', ' ') | title }}</strong>
                            {% set courses = pages
                                | selectattr('metadata.type', 'equalto', 'course')
                                | selectattr('metadata.subject', 'equalto', subject)
                                | selectattr('metadata.schoolyear', 'equalto', year)
                                | sort(attribute='date', reverse=True) %}
                            <ul class="ml-4">
                                {% for course in courses %}
                                    <li class="mb-1">
                                        <a href="{{ SITEURL }}/{{ course.url }}" class="text-decoration-none text-primary">
                                            {{ course.title or course.metadata.coursetitle }}
                                        </a>
                                    </li>
                                {% endfor %}
                            </ul>
                        </li>
                    {% endfor %}
                </ul>
            </li>
        {% endfor %}
    </ul>
</div>

We go directly to http://localhost:8001/courses to see it in action.

Pelcan Generated Categories

8. Final Thoughts

By combining:

Rich metadata in your Markdown files
A clean folder hierarchy
Dynamic template filtering

You can build the illusion of a fully categorized, subcategorized website without using databases or complex backends.

It’s fast.

It’s secure.

It’s flexible.

You now have the power to create a blazing-fast static site that rivals, and in many ways outperforms, dynamic CMS platforms.

If you want to extend this system later, you can easily:

Add pagination
Track views
Create search pages using plugins like tipue_search

Quran Search: A Feature rich and modern design

2025-02-13T19:40:11+00:00

Exploring the Advanced Quran Browser: A Deep Dive into a Feature-Rich PyQt5 Application

In today's software landscape, creating applications that balance robust functionality with a smooth user experience is both an art and a science. The Quran Browser is a testament to this balance, offering an innovative solution for exploring and interacting with Quranic text. Built entirely with Python and PyQt5, this application integrates asynchronous search, dynamic audio playback, persistent user settings, and an intuitive interface—all designed to provide users with a rich and engaging experience.

Overview

At its core, the Quran Browser is designed to allow users to search, view, and listen to Quranic verses in a way that is both responsive and visually appealing. Whether you're looking up a specific verse, exploring the context around a recitation, or simply enjoying an immersive audio experience, this application has been meticulously crafted to meet your needs.

The application offers multiple modes of search:

•Text Search: Enter Arabic words or phrases to quickly locate the relevant verses.

•Surah Search: Directly select a surah (chapter) from a dropdown menu or enter its number.

•Direct Verse Lookup: Specify a combination of surah and ayah numbers to jump directly to a particular verse.

Architectural Highlights

Model–View Architecture

One of the key strengths of this application is its use of the Model–View architecture via the QAbstractListModel. By separating the data (the Quranic text and metadata) from its presentation, the application ensures a scalable and maintainable codebase. The custom model, QuranListModel, not only manages the display data but also supports updates and efficient rendering of search results.

Asynchronous Search with QThread

To maintain a fluid user experience, especially when dealing with potentially large datasets, the Quran Browser employs asynchronous search operations. The SearchWorker class runs in a separate thread (using PyQt’s QThread), which allows the main UI to remain responsive even during intensive search operations. This thoughtful design decision means that users experience minimal lag or freezes when querying the text.

Detailed Features

Integrated Audio Playback

A standout feature of the Quran Browser is its built-in audio playback system. Utilizing PyQt5’s QMediaPlayer, the application can play individual verses or an entire sequence of verses:

•Single Verse Playback: Quickly play the recitation of a selected verse.

•Sequential Playback: Build a playlist of consecutive verses or even transition automatically to the next surah when the current one finishes.

This seamless integration of audio enhances the user's study and listening experience, making it ideal for both casual listeners and serious students of the Quran.

Persistent User Settings

The application leverages QSettings to remember user preferences such as window geometry, theme settings (dark or light mode), the chosen text version (Uthmani vs. Simplified), and even the last selected surah. This persistence not only improves usability but also ensures that each session starts with your preferred setup, enhancing productivity.

Keyboard Shortcuts for Enhanced Usability

Efficiency is key for power users, and the Quran Browser addresses this through an extensive set of keyboard shortcuts:

•Ctrl+F: Focus the search input.

•Ctrl+D: Toggle between dark and light themes.

•Space: Play audio for the currently selected verse.

•Ctrl+P: Initiate sequential playback of multiple verses.

•Ctrl+S: Stop playback immediately.

•Ctrl+A: Play an entire surah starting from the selected verse.

•Escape: Toggle between the Uthmani and Simplified text versions.

These shortcuts provide a quick and efficient way to navigate the application, making it easier to dive into the content without constantly relying on the mouse.

Dynamic UI and Themes

The user interface of the Quran Browser is designed with both aesthetics and functionality in mind. A splitter layout divides the main window into a results view and a detailed context view, allowing users to seamlessly switch between browsing and in-depth reading. Additionally, the application offers theme customization options that enable users to switch between dark and light modes, catering to different lighting environments and personal preferences.

Code Design and Implementation

The Model and Delegate Pattern

The code uses a custom QAbstractListModel (i.e., QuranListModel) to manage the list of search results efficiently. Complementing this, the QuranDelegate class handles the rendering of each item in the results view. The delegate is responsible for formatting the Quranic text (including proper right-to-left support) and ensuring that the displayed content is both readable and visually consistent.

Asynchronous Operations with QThread

Handling resource-intensive operations on the main thread can lead to performance bottlenecks. The Quran Browser circumvents this by offloading the search functionality to a dedicated worker thread (SearchWorker). This design not only improves responsiveness but also encapsulates error handling and logging—thanks to Python's robust logging module—ensuring that any issues during search operations are gracefully managed.

Audio Playback and Sequence Handling

Audio integration in the Quran Browser is thoughtfully implemented. The application supports both single file and sequence playback modes:

•File Naming Convention: Audio files must be named using a standardized pattern (e.g., 002005.mp3 for Surah 2, Ayah 5). This convention simplifies the process of locating and playing the correct file.

•Sequence Playback: For a continuous listening experience, the application builds a sequence of audio files. When the end of a surah is reached, it automatically transitions to the next surah (wrapping around to the first surah if necessary), ensuring uninterrupted playback.

Installation Guide

Getting started with the Quran Browser is simple. Follow these steps to set up the application on your system:

•Clone the repository:

    

git clone https://github.com/neoMOSAID/quran-search-and-play.git
cd quran-search-and-play

•Install required packages: If you use pip, run:

    

pip install -r requirements.txt

Once the setup is complete, you can start the application by running python3 gui.py. This will launch the Quran Browser, ready for you to explore its features.

Important Note on Audio Files

For full functionality, the Quran application requires Quranic audio files named in the specific format XXXYYY.mp3, where XXX is the 3-digit surah number and YYY is the 3-digit ayah number (e.g., 002001.mp3 for Surah 2, Ayah 1). You can download complete verse-by-verse audio collections from sources like EveryAyah.com. After downloading, set audio directory in the menu, by simply selecting it

User Experience and Interface

The overall design of the Quran Browser prioritizes usability. The split-view layout allows users to easily toggle between a list of search results and detailed context views for selected verses. The integration of persistent settings means that every session is tailored to the user's preferences—from the selected surah and text version to the chosen audio directory.

Moreover, the application includes a comprehensive Help dialog that details available features and keyboard shortcuts, ensuring that even new users can quickly become proficient in navigating the interface.

Quran search dark

Quran search light

Quran search example

Quran search showing the ayah and its context

Quran search help window

Customization and Extensibility

Designed with both end-users and developers in mind, the Quran Browser is highly customizable. Whether you want to tweak the UI themes, extend the search capabilities, or add new functionalities, the codebase is modular and well-documented. Developers are encouraged to contribute improvements, report issues, or even fork the repository to build their own versions of this powerful tool.

Explore the GitHub Repository

If you're interested in exploring the Quran Browser further or contributing to its development, you can find the complete source code on its GitHub repository: https://github.com/neoMOSAID/quran-search-and-play. The repository includes detailed documentation, installation instructions, and a well-structured codebase. Whether you're a developer looking to learn about PyQt5 or a power user aiming to customize the application, this repository is your go-to resource. Contributions, feedback, and issue reporting are highly encouraged to help improve and expand this powerful tool.

Conclusion

The Advanced Quran Browser represents a perfect blend of modern software design principles and practical functionality. By leveraging the power of PyQt5, asynchronous operations, and integrated multimedia playback, it offers an engaging and efficient way to explore Quranic text. Its thoughtful architecture, combined with a focus on usability and customization, makes it an exemplary project for anyone interested in both software development and the study of the Quran.

Whether you’re a developer looking to contribute or a user eager to enhance your study routine, the Quran Browser provides a solid foundation for both exploration and innovation. Embrace the power of technology in your journey of understanding, and experience the Quran like never before.

Explore, listen, and connect with the timeless wisdom of the Quran through this innovative application—where modern design meets sacred tradition.

How to Install and Use Quran Player on Linux, macOS, and Windows

2025-02-06T09:31:56+00:00

Introducing Quran Player: A Cross-Platform Quranic Verse Playback Experience

Version: 1.3.0
License: GPLv3

Quran Player Logo

Overview

In today’s digital age, the Quran deserves a modern, intuitive, and cross‑platform way to be experienced. That’s why we created Quran Player—a powerful application that combines audio playback, synchronized visual display, and beautiful Arabic text rendering. Designed for both casual listeners and scholars alike, Quran Player offers a seamless and engaging experience on Windows, Linux, and more.

What Is Quran Player?

Quran Player is not just an audio player. It is a comprehensive system that:

•Plays Quranic Verses: Enjoy verse‑by‑verse playback with auto‑advance.

•Displays Arabic Text: Experience beautifully rendered Arabic script with proper shaping.

•Offers a Graphical Interface: Control playback easily using our dark‑themed, system‑tray integrated GUI.

•Provides Interactive Search: Quickly find and navigate to any verse using our versatile search tool.

•Renders Images: Generate stunning images of verses with customizable fonts, sizes, colors, and wrapping options.

Every component of the system—from the daemon (quran_player.py) that manages audio playback and state, to the PyQt5‑powered GUI (quran_gui.py), the interactive search tool (quran_search.py), and the image rendering utility (arabic_topng.py)—has been crafted with attention to detail and cross‑platform compatibility.

Key Features

Cross‑Platform Compatibility

•Windows & Linux Support: Separate installation scripts ensure a smooth setup on both Windows and Linux.

•Consistent Experience: Whether you’re on Windows with desktop shortcuts and CLI wrappers, or on Linux with man pages and desktop entries, Quran Player delivers a uniform experience.

Audio Playback & Control

•Verse‑by‑Verse Playback: Listen to recitations that automatically advance, ensuring a natural flow.

•Repeat & Load Functions: Easily repeat a specific range of verses or load any verse using a simple command (e.g., load 2:255).

Beautiful User Interface

•Dark‑Themed Design: Enjoy a modern GUI with a sleek dark palette and intuitive system tray integration.

•Keyboard Shortcuts: Quickly control playback using Space, Left, Right, and Esc keys.

Advanced Search & Image Rendering

•Interactive Search: Utilize the search tool in both command‑line and interactive modes with full right‑to‑left (RTL) support.

•Customizable Image Rendering: Generate images of verses using configurable options such as font, size, colors, and wrapping. Perfect for sharing or offline viewing.

Installation Made Easy

For Windows Users

• Requirements:

•Windows 7 or later

•Python (pre-installed or installed via the setup script)

•Administrator privileges (for some operations)

• Setup Script:

Run the provided Windows setup script (e.g., via python setup.py):

    

python setup.py

This script will:

•Create a virtual environment under %APPDATA%\quran-player

•Copy application files and assets

•Install required dependencies (including pywin32 and winshell)

•Create CLI wrappers in %APPDATA%\quran-player\bin

•Create a desktop shortcut for launching the GUI

• Logs:

Check install.log (generated in the current directory) for details and troubleshooting.

For Linux Users

• Requirements:

•A modern Linux distribution (Ubuntu, Debian, Arch, etc.)

•Bash shell, Python3, and sudo privileges for certain installation steps

• Get the necessary files from github repository

    

git clone https://github.com/neoMOSAID/quran-player.git
cd quran-player

• Make Script Executable:

    

chmod +x install.sh

• Run the Installer:

    

./install.sh

The script will:

•Install system dependencies (e.g., python3-venv, feh, pulseaudio-utils)

•Copy application files and assets to ~/.quran-player

•Create a virtual environment and install Python dependencies

•Create CLI wrappers in /usr/local/bin

•Generate a desktop entry in ~/.local/share/applications

•Install the man page for quran-daemon

• Uninstallation:

    

./install.sh --uninstall

Usage

Daemon Commands

The daemon is controlled via CLI commands. Use the generated wrappers:

•Start the Daemon: quran-daemon start

•Stop the Daemon: quran-daemon stop

•Playback Control:

•quran-daemon play – Resume playback

•quran-daemon pause – Pause playback

•quran-daemon toggle – Toggle between play and pause

•quran-daemon next – Advance to the next verse

•quran-daemon prev – Go back to the previous verse

•Load a Specific Verse: quran-daemon load 2:255

•Repeat a Range of Verses: quran-daemon repeat 10:15

•Display Status: quran-daemon status

•Generate Configuration File: quran-daemon config

•Display Detailed Information: quran-daemon info

•Help / About:

•quran-daemon help

•quran-daemon about

GUI Controller

Launch the GUI using the desktop shortcut (Windows) or via the CLI wrapper: quran-gui.

The GUI features:

•Dark theme with a custom Fusion palette

•System tray integration and context menu

•Keyboard shortcuts: Space (play/pause), Left (previous), Right (next), Esc (minimize)

Quran player graphical user interface

Search Tool

Run the search tool with: quran-search <surah> <start_ayah> [end_ayah]

If no arguments are provided, the tool launches an interactive dialog that will switch the keyboard layout to arabic (for linux users only) and then restore it on exit

Image Rendering

The script arabic_topng.py renders Arabic text to a PNG image with options for wrapping, padding, and color customization. This is used internally by the player for displaying verses.

Quran player Screenshot, Ayah 255 from surah 2

Configuration

The application is configured via an INI‑style file. By default, the configuration file is located at:

•Linux/macOS: ~/.config/quran-player/config.ini

•Windows: %APPDATA%\quran-player\config.ini

[daemon] Section

•MAX_LOG_SIZE: Maximum log file size (default: 1000000 bytes).

•LOG_LEVEL: Log verbosity. Options: CRITICAL, ERROR, WARNING, INFO, DEBUG, or DISABLED (default: INFO).

•FILES_DIRECTORY: Directory where audio files are stored.

[image] Section

•ENABLE: Enable image display (yes/no). Default: yes on Linux, no on other platforms.

•DEFAULT_RESOLUTION: Image resolution (e.g., 1240x170).

•FONT_FILE: Path to the Arabic font file (default: arabic-font.ttf).

•FONT_SIZE: Font size (default: 48).

•IMAGE_WIDTH: Width of the image in pixels (default: 1240).

•WRAP_WIDTH: Maximum characters per line (default: 170).

•VERTICAL_PADDING: Padding in pixels (default: 20).

•BG_COLOR: Background color (e.g., 0,0,0,0).

•TEXT_COLOR: Text color (e.g., 255,255,255,255).

•HIGHLIGHT_COLOR: Highlight color (e.g., 255,0,0,255).

Important Note on Audio Files

For full functionality, the Quran Player requires Quranic audio files named in the specific format XXXYYY.mp3, where XXX is the 3-digit surah number and YYY is the 3-digit ayah number (e.g., 002001.mp3 for Surah 2, Ayah 1). While basic sample files are included, it's recommended to download complete verse-by-verse audio collections from sources like EveryAyah.com. After downloading, place the files in the ~/.config/quran-player/sample/ directory (or your configured FILES_DIRECTORY). Ensure all files follow this naming scheme for seamless playback across all 114 surahs.

The Manual

For a complete, detailed description of every command, configuration option, and usage example, refer to the manual below (also available as a man page on Linux and as manual.txt for Windows users):

    

===================================================================
                       Quran Player Daemon Manual
                            Version: v1.3.0
                           Date: Feb 2025
===================================================================

NAME
    quran-daemon - Quran Player Daemon

SYNOPSIS
    quran-daemon [COMMAND] [ARGUMENTS]...

DESCRIPTION
    The Quran Player Daemon is a background service that provides Quranic verse
    playback with synchronized visual display and Arabic text rendering. It supports
    verse-by-verse playback with auto-advance, persistent playback state across
    sessions, repeat functionality, and an optional system tray GUI controller.

COMMANDS
    start
        Start the daemon. This initializes the service, binds the control socket, and
        begins listening for client commands.

    stop
        Stop the daemon. This causes the daemon to shut down gracefully, releasing all
        resources and cleaning up socket and PID files.

    play
        Resume audio playback.

    pause
        Pause the current playback.

    toggle
        Toggle between play and pause.

    next
        Advance to the next verse.

    prev
        Return to the previous verse.

    load
        Load a specific verse. The command expects an argument in the format
        surah:ayah (for example, "2:255").

    repeat
        Repeat a range of verses. Provide the range in the format
        start:end (for example, "10:15"). Note that issuing a play or load command
        cancels repeat mode.

    status
        Display the current playback status, including the surah and ayah numbers and
        playback state.

    config
        Generate the default configuration file in the user configuration directory.

    cleanup
        Remove orphaned runtime files (e.g., stale PID or socket files).

    info
        Display detailed information about daemon status, configuration settings,
        file integrity, and system information.

    help
        Display a help message with a summary of available commands.

    about
        Display program information, including version, project links, and license details.

CONFIGURATION
    The daemon uses an INI-style configuration file. On Linux/macOS, the file is typically
    located at:
        ~/.config/quran-player/config.ini
    On Windows, it is stored in the APPDATA folder.

    The configuration file is divided into two main sections: [daemon] and [image].

    -----------------------------------------------------------------
    [daemon] Section
    -----------------------------------------------------------------
    MAX_LOG_SIZE
        Maximum size (in bytes) of the log file before rotation occurs.
        Default: 1000000.

    LOG_LEVEL
        Log verbosity level. Possible values are:
        CRITICAL, ERROR, WARNING, INFO, DEBUG, or DISABLED.
        Default: INFO.

    FILES_DIRECTORY
        The directory where the audio files are stored. If not specified, a default directory
        (e.g., within the user configuration directory) is used.

    -----------------------------------------------------------------
    [image] Section
    -----------------------------------------------------------------
    ENABLE
        Enable or disable image display. Accepts "yes" or "no". Default is "yes" on Linux
        and "no" on other platforms.

    DEFAULT_RESOLUTION
        Default resolution for the generated image in the format WIDTHxHEIGHT (e.g., "1240x170").

    FONT_FILE
        Path to the Arabic font file used for rendering. By default, the "arabic-font.ttf"
        in the script or user configuration directory is used.

    FONT_SIZE
        Font size for rendering the text. Default: 48.

    IMAGE_WIDTH
        Width of the generated image in pixels. Default: 1240.

    WRAP_WIDTH
        Maximum number of characters per line before wrapping. Default: 170.

    VERTICAL_PADDING
        Vertical padding (in pixels) added to the top and bottom of the image. Default: 20.

    BG_COLOR
        Background color as a comma-separated RGBA string (for example, "0,0,0,0").
        Default: 0,0,0,0.

    TEXT_COLOR
        Text color as a comma-separated RGBA string (for example, "255,255,255,255").
        Default: 255,255,255,255.

    HIGHLIGHT_COLOR
        Highlight color for indicating a specific line, as a comma-separated RGBA string
        (for example, "255,0,0,255").
        Default: 255,0,0,255.

FILES
    quran_player.py
        The main daemon script.
    default_config.ini
        Default configuration file shipped with the daemon.
    config.ini
        User configuration file. Typically located in ~/.config/quran-player/ (Linux/macOS)
        or in the APPDATA folder (Windows).
    daemon.sock or \\.\pipe\quran-daemon (Windows)
        The control socket used for inter-process communication.
    daemon.pid
        File storing the daemon's process ID.
    daemon.log
        Log file for daemon events.

USAGE EXAMPLES
    Start the daemon:
        quran-daemon start

    Stop the daemon:
        quran-daemon stop

    Toggle playback:
        quran-daemon toggle

    Load a specific verse:
        quran-daemon load 2:255

    Repeat a range of verses:
        quran-daemon repeat 10:15

    Display status:
        quran-daemon status

    Generate a new configuration file:
        quran-daemon config

    Display help:
        quran-daemon help

ENVIRONMENT VARIABLES
    The following environment variables can override default configuration values:
    PYTHON_IMAGE_WIDTH
        Overrides the default image width.
    PYTHON_IMAGE_WRAP_WIDTH
        Overrides the default wrap width.
    PYTHON_IMAGE_FONT_SIZE
        Overrides the default font size.
    PYTHON_IMAGE_FONT
        Overrides the default font family.
    PYTHON_IMAGE_BG_COLOR
        Overrides the default background color.
    PYTHON_IMAGE_TEXT_COLOR
        Overrides the default text color.
    PYTHON_IMAGE_HIGHLIGHT_COLOR
        Overrides the default highlight color.
    PYTHON_IMAGE_VERTICAL_PADDING
        Overrides the default vertical padding.

BUGS
    Report bugs and issues via the project's GitHub issue tracker:
        https://github.com/neoMOSAID/quran-player/issues

AUTHOR
    Developed by neoMOSAID.

COPYRIGHT
    This software is released under the GPLv3 License.

===================================================================

Get Involved

Whether you’re a developer or a Quran enthusiast, your feedback and contributions are welcome! Visit our GitHub repository to report issues, submit pull requests, or simply star the project.

Final Thoughts

Quran Player brings together tradition and technology, offering a unique way to interact with the Quran through modern digital means. Explore, enjoy, and help us improve this open‑source project.

Feel free to share this article on social media, include screenshots of the application in action, or embed installation videos to engage with your audience further!

Render Quranic Verses as PNG Images and Play Audio Using Command Line Tools

2025-01-26T11:37:00+00:00

Render Quranic Verses as PNG Images and Play Audio Using Command Line Tools

In this tutorial, we'll combine a Python script (ara-to-png.py) and a shell script (artopng) to create a powerful command-line tool for rendering Quranic verses as PNG images and playing their audio. We'll also integrate previously created tools for retrieving Quranic text and playing audio from the command line.

Prerequisites

•Python Environment: Ensure you have a Python virtual environment set up in ~/bin/env.
•Required Dependencies: Install Pillow and a Quranic font (e.g., arfonts-arabic-typesetting.ttf) in your system.
•Previous Tools: Download and set up the scripts from the following articles:

•Quran Search and Display Script: Enhancing Quranic Study.

•Quranic Audio Playback Script: Playing Quranic Ayat.

Step 1: Python Script (`ara-to-png.py`)

This script renders Arabic text into a PNG image using the specified font and supports optional highlighting of a specific line. Below is the script:

    

import sys
import textwrap
from PIL import Image, ImageDraw, ImageFont

def render_arabic_text_to_image(
    text,
    font_path,
    output_path,
    image_width=970,
    wrap_width=130,
    font_size=48,
    bg_color="#F0FFF0",
    text_color="black",
    highlight_color="#FF0000",
    highlight_line=None,
    vertical_padding=20
):
    """
    Renders an Arabic text string into an image using a specific font, with text wrapping, dynamic height,
    and optional highlighting of a specific original line.

    Parameters:
    - text: str, the Arabic paragraph to render.
    - font_path: str, path to the font file (.ttf) to use.
    - output_path: str, path where the output image will be saved.
    - image_width: int, width of the image.
    - font_size: int, size of the font.
    - bg_color: str, background color of the image.
    - text_color: str, color of the text.
    - highlight_color: str, the color to use for highlighting.
    - highlight_line: int, the 1-based index of the line to highlight (None for no highlight).
    - vertical_padding: int, padding above and below the text.
    """
    try:
        # Load the font
        font = ImageFont.truetype(font_path, font_size)
    except Exception as e:
        print(f"Error loading font: {e}")
        return

    # Split the text into original lines
    original_lines = text.split("\n")

    # Add a bullet to the start of each original line
    lines_with_bullets = [f"•{line}" for line in original_lines]

    # Initialize lists to store wrapped lines and their original line mapping
    wrapped_lines = []
    line_mapping = []  # Track which wrapped lines belong to which original line
    highlighted_lines = []  # Store indices of wrapped lines that belong to the highlighted original line

    # Loop through original lines to wrap them
    for i, line in enumerate(lines_with_bullets):
        is_highlighted = highlight_line == (i + 1)  # Check if the current original line is to be highlighted
        wrapped = textwrap.wrap(line, width=wrap_width)  # Adjust width for wrapping

        # Store the wrapped lines and highlight them if necessary
        wrapped_lines.extend(wrapped)
        line_mapping.extend([i] * len(wrapped))  # All wrapped lines belong to the same original line
        if is_highlighted:
            highlighted_lines.extend([True] * len(wrapped))  # Mark all wrapped lines of this original line as highlighted
        else:
            highlighted_lines.extend([False] * len(wrapped))  # Non-highlighted lines

    # Calculate line height and total text height
    draw = ImageDraw.Draw(Image.new("RGB", (image_width, 100), bg_color))  # Temporary image to calculate text size
    _, _, _, text_height = draw.textbbox((0, 0), "A", font=font)  # Get height of a single character
    line_height = text_height + 24  # Add spacing between lines
    total_text_height = line_height * len(wrapped_lines) + 2 * vertical_padding

    # Create the image with dynamic height
    image = Image.new("RGB", (image_width, total_text_height), bg_color)
    draw = ImageDraw.Draw(image)

    # Starting Y position for text
    y = vertical_padding

    # Draw each wrapped line, right-aligned, with optional highlighting
    for i, line in enumerate(wrapped_lines):
        text_bbox = draw.textbbox((0, 0), line, font=font)
        text_width = text_bbox[2] - text_bbox[0]

        # Align text to the right with padding
        x = image_width - text_width - 20  # Align to the right with 20px padding

        # Apply highlighting to the specified line
        if highlighted_lines[i]:
            draw.text((x, y), line, font=font, fill=highlight_color, direction="rtl")
        else:
            draw.text((x, y), line, font=font, fill=text_color, direction="rtl")

        y += line_height  # Move to the next line

    # Save the image
    image.save(output_path)
    print(f"Image saved to {output_path}")



if __name__ == "__main__":
    if len(sys.argv) < 4:
        print("Usage: python render_arabic.py '<text>' <font_path> <output_image_path>")
        sys.exit(1)

    arabic_text = sys.argv[1]
    font_path = sys.argv[2]
    output_image_path = sys.argv[3]
    if len(sys.argv) > 4:
        highlight_line=int(sys.argv[4])
    else:
        highlight_line=None

    render_arabic_text_to_image(
        text=arabic_text,
        font_path=font_path,
        output_path=output_image_path,
        highlight_line=highlight_line
    )

Step 2: Shell Script (`artopng`)

The shell script coordinates the workflow: it retrieves the Quranic text, processes it, renders it into an image, and finally plays the corresponding audio. Here is the script:

    

#!/bin/bash

ENV_PATH="$HOME/bin/env"
SCRIPT_PATH="$HOME/bin/python/ara-to-png.py"
FONT_PATH="$HOME/.fonts/arfonts-arabic-typesetting.ttf"
OUT_PNG="/tmp/out-$(date '+%s').png"
PLAYER="$HOME/bin/play-ayat"

# Ensure the environment exists
if [ ! -d "$ENV_PATH" ]; then
    echo "Error: Python environment not found at $ENV_PATH"
    echo "Please create the environment and try again."
    exit 1
fi

# Ensure the script exists
if [ ! -f "$SCRIPT_PATH" ]; then
    echo "Error: Python script not found at $SCRIPT_PATH"
    exit 1
fi

CHAPTER=$1
FIRST=$2
LAST=$3
LCOLOR=$4
SPEED=$5

if [[ -z $CHAPTER  ]]
then
    echo "usage: $0 <CHAPTER_number> <FIRST_ayah> <LAST_ayah> [line_to_highlight]"
    exit
fi
if [[ -z $FIRST  ]]
then
    echo "usage: $0 <CHAPTER_number> <FIRST_ayah> [LAST_ayah] [line_to_highlight]"
    exit
fi

# Source the environment
source "$ENV_PATH/bin/activate"
"$HOME/bin/quran-search-dir/quran-search.sh" $CHAPTER $FIRST $LAST > /dev/null
# this script gets the ayat text and saves it in /tmp/artext
# Read the text from the file
artext=$(cat /tmp/artext)

# Process each line separately
artext=$(echo "$artext" | while IFS= read -r line; do
    # Extract the part inside parentheses
    inside_parentheses=$(echo "$line" | grep -oP '\(.*?\)' | tr -d '()')

    # Remove the part inside parentheses from the current line
    line_cleaned=$(echo "$line" | sed -r 's/\(.*?\)//g')

    # Append the extracted part at the end of the line, if it exists
    if [[ -n "$inside_parentheses" ]]; then
    number=$(echo "$inside_parentheses" | tr -cd '0-9')
    arabic_text=$(echo "$inside_parentheses" | grep -oP '[^\d]+$' | sed 's/^ //')
        echo "$line_cleaned  [$arabic_text $number]"
    else
        echo "$line_cleaned"
    fi
done)

python "$SCRIPT_PATH" "$artext" "$FONT_PATH" "$OUT_PNG" $LCOLOR > /dev/null

killall feh 2>/dev/null

feh  --no-xinerama $OUT_PNG & disown

# Deactivate the environment
deactivate
killall mpv 2>/dev/null
killall mpv 2>/dev/null
$PLAYER $CHAPTER $FIRST $LAST $SPEED

How It Works

The shell script takes the chapter number, first and last verse numbers, and an optional highlight line as arguments.
It retrieves the Quranic text using the search script and processes it for rendering.
The Python script renders the Arabic text into a PNG image.
The rendered image is displayed using feh, and the verses' audio is played using the playback script.

Usage

    

artopng <CHAPTER_number> <FIRST_ayah> <LAST_ayah> [line_to_highlight] [play_speed]

Example:

    

artopng 2 255 257 2

This command renders verses 255-257 of Surah Al-Baqarah, highlights the second line, and plays the audio.

I am using i3 window manager, and made it so that feh has no borders and no window decoration and top bar, making it look this beautiful:

verses 255-257 of Surah Al-Baqarah

Play sourah

    

#!/bin/bash
if [[ -z $1 ]] ; then
    echo need surah number
    exit
fi
surah_number=$1
start_ayah=${2:-1}
end_ayah=${3:-300}

for ((i=start_ayah; i <= end_ayah; i++)); do
    $HOME/bin/artopng $surah_number $i
done

The `play-surah` script is a handy tool designed to streamline the display and audio playback of Quranic verses. This script accepts a Surah number as a required argument and optionally allows specifying a range of Ayahs to display and play. By default, it starts from the first Ayah and processes up to the last ayah of the surah (chapter) unless specified otherwise.

Here's how the script works: for each Ayah in the specified range, it utilizes the `artopng` script to generate an image of the Ayah's text and then plays the corresponding audio. When combined with a minimalistic i3 window manager setup, which employs borderless `feh` with no decorations, this approach creates an immersive and distraction-free Quranic experience, verse by verse.

Conclusion

This tool provides an immersive Quranic study experience by combining visual and auditory elements directly from the command line. Let me know if you need help customizing or extending the scripts!

Play Quranic Ayat and Surahs from the Command Line

2025-01-25T09:43:19+00:00

Play Quran Ayat with a Shell Script

If you're someone who enjoys listening to Quranic recitations and prefers an automated way to play specific ayat or surahs, this script might be your new favorite tool. It uses files downloaded from EveryAyah and organizes them for seamless playback.

Script Overview: play-ayat

The play-ayat script lets you play Quranic ayat by specifying their numbers and optional ranges. Here's how it works:

•Arguments:

- first_number: The surah number (e.g., 001 for Al-Fatiha).

- second_number: The starting ayah number (e.g., 001).

- [end_range]: (Optional) The ending ayah number for a range of ayat to play.

- [speed]: (Optional) Playback speed (defaults to 1.15x).

How It Works

•Single Ayah Playback: When only the first_number and second_number are provided, the script constructs the filename using a padded three-digit format (e.g., 001001.mp3 for Al-Fatiha, Ayah 1). It checks if the file exists and plays it using mpv with custom player settings.

    

./play-ayat 1 1

•Range of Ayat: If the end_range is specified, the script builds a playlist (ayatplaylist.m3u) containing all ayat in the specified range. This playlist is then fed into mpv for playback.

    

./play-ayat 1 1 7

•Custom Playback Speed: You can optionally pass a speed argument to modify the playback speed. For example, to slow it down:

    

./play-ayat 1 1 7 0.9

The `play-ayat` script

    

#!/bin/bash

# Check for at least two arguments
if [ "$#" -lt 2 ]; then
    echo "Usage: $0 <first_number> <second_number> [<end_range>]"
    exit 1
fi

# Extract arguments
first_number=$1
second_number=$2
end_range=$3
if [[ -n $4 ]]
  then speed=$4
  else speed=1.15
fi

# Variables
FILES_DIR="$HOME/Music/Abdul Basit Mujawwad"
#FILES_DIR="$HOME/Music/Minshawy Mujawwad"
#FILES_DIR="$HOME/Music/Minshawy Murattal"
PLAYLIST_FILE="/tmp/ayatplaylist.m3u"
PLAYER_CONFIG="--no-terminal --no-config --no-pause --no-loop-file --speed=$speed"


# Format numbers to three digits
pfirst_number=$(printf "%03d" "$first_number")
psecond_number=$(printf "%03d" "$second_number")

# Check if end_range is provided
if [ -z "$end_range" ]; then
    # Single file case
    filename="${pfirst_number}${psecond_number}.mp3"
    full_path="${FILES_DIR}/${filename}"

    if [ -f "$full_path" ]; then
    mpv $PLAYER_CONFIG "$full_path" > /dev/null 2>&1
    fi
else
    # Range of files case
    # Clear or create playlist file
    echo "#EXTM3U" > "$PLAYLIST_FILE"
    for ((i=second_number; i<=end_range; i++)); do
        current_number=$(printf "%03d" "$i")
        filename="${pfirst_number}${current_number}.mp3"
        full_path="${FILES_DIR}/${filename}"
        if [ -f "$full_path" ]; then
            echo "$full_path" >> "$PLAYLIST_FILE"
        fi
    done

    if [ -s "$PLAYLIST_FILE" ]; then
    mpv $PLAYER_CONFIG --playlist-start=0 "$PLAYLIST_FILE" > /dev/null 2>&1
    fi
fi

Extending the Script: play-surah

The play-surah script takes this functionality further by automating the playback of an entire surah. Instead of specifying individual ayat, you can simply pass the surah number as the mandatory argument, and it will play all available ayat for that surah.

•Arguments:

- surah_number: The mandatory surah number (e.g., 001 for Al-Fatiha).

- [start_ayah]: (Optional) The starting ayah number.

- [end_ayah]: (Optional) The ending ayah number.

•Logic: If no start_ayah and end_ayah are provided, the script loops from Ayah 1 to a reasonable maximum (e.g., 300). Files are checked for existence, and a playlist is dynamically generated.

Code Example for play-surah

    

#!/bin/bash

# Check arguments
if [ "$#" -lt 1 ]; then
    echo "Usage: $0 <surah_number> [<start_ayah> <end_ayah>]"
    exit 1
fi

surah_number=$1
start_ayah=${2:-1}
end_ayah=${3:-300}
FILES_DIR="$HOME/Music/Abdul Basit Mujawwad"
PLAYLIST_FILE="/tmp/surahplaylist.m3u"
PLAYER_CONFIG="--no-terminal --no-config --no-pause --no-loop-file"

# Format surah number
psurah_number=$(printf "%03d" "$surah_number")

# Create playlist
echo "#EXTM3U" > "$PLAYLIST_FILE"
for ((i=start_ayah; i<=end_ayah; i++)); do
    payah_number=$(printf "%03d" "$i")
    filename="${psurah_number}${payah_number}.mp3"
    full_path="${FILES_DIR}/${filename}"
    if [ -f "$full_path" ]; then
        echo "$full_path" >> "$PLAYLIST_FILE"
    fi
done

if [ -s "$PLAYLIST_FILE" ]; then
    mpv $PLAYER_CONFIG --playlist-start=0 "$PLAYLIST_FILE" > /dev/null 2>&1
else
    echo "No files found for Surah $surah_number in the specified range."
fi

Usage Example for play-surah

•Play all ayat of a surah:

    

./play-surah 1

•Play a specific range of ayat within a surah:

    

./play-surah 2 255 286

Conclusion

These scripts bring simplicity and flexibility to Quranic recitation playback. Whether you're studying, meditating, or simply enjoying the beauty of the recitation, play-ayat and play-surah automate the process, saving you from manually selecting files.

With a little creativity, you could further extend these scripts for more advanced features like randomizing ayat, creating thematic playlists, or even integrating them into a larger application. which I did, stay tuned for more

How to Generate PDFs from Jinja2 Templates in Python

2025-01-20T21:58:39+00:00

How to Generate PDFs from Jinja2 Templates Using Python

In this tutorial, we will show you how to use a Python script to generate beautiful PDFs from Jinja2 templates. Whether you're creating invoices, reports, or any custom documents, this method allows you to automate the generation of PDFs directly from templates. We will also discuss the importance of using a local Python environment and good practices to keep your projects organized and manageable.

Prerequisites

Before we start, ensure that you have the following tools and libraries installed:

•Python: The programming language for this script.

•Jinja2: A templating engine used to generate HTML from data.

•pdfkit: A Python wrapper for wkhtmltopdf, which converts HTML to PDF.

•wkhtmltopdf: A command-line tool for rendering HTML into PDFs.

Install the necessary libraries using the following commands:

    

pip install jinja2 pdfkit

Additionally, ensure that wkhtmltopdf is installed on your system:

    

sudo apt-get install wkhtmltopdf

Setting Up the Virtual Environment

It's a good practice to use a local Python environment for your projects. This helps keep your dependencies isolated and ensures that your project is not affected by global Python packages. Follow these steps to set up the environment:

    

# Create a new directory for your project if you haven't already
mkdir ~/my_project
cd ~/my_project

# Create a virtual environment in ~/bin/env
python3 -m venv ~/bin/env

# Activate the environment
source ~/bin/env/bin/activate

# Install the necessary Python dependencies
pip install jinja2 pdfkit

Once the environment is set up, you can simply activate it by running:

    

source ~/bin/env/bin/activate

Creating the Template

Next, create a Jinja2 template to define the structure and design of your PDF. In this example, we’ll create a simple template with a title, content, a list of items, and an image.

    

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>{{ title }}</title>
    <!-- Bootstrap CSS -->
    <link href="https://maxcdn.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css" rel="stylesheet">
    <style>
        /* Custom styles for PDF generation */
        @page {
            size: A4;
            margin: 1cm;
        }

        body {
            font-family: 'Arial', sans-serif;
            line-height: 1.5;
            margin: 0;
        }

        .header, .footer {
            background-color: #f8f9fa;
            padding: 10px;
            text-align: center;
            color: #333;
        }

        .header h1 {
            margin: 0;
            font-size: 1.8rem;
            color: #007bff;
        }

        .footer p {
            margin: 0;
            font-size: 0.9rem;
        }

        .content {
            padding: 20px;
        }

        .content h2 {
            color: #28a745;
            margin-top: 20px;
        }

        .content p {
            text-align: justify;
        }

        .content blockquote {
            background-color: #f1f3f4;
            border-left: 4px solid #007bff;
            padding: 10px 15px;
            font-style: italic;
            color: #555;
            margin: 20px 0;
        }

        .content .table {
            margin-top: 20px;
        }

        .content .btn {
            display: inline-block;
            margin-top: 15px;
        }

        .highlight {
            color: #dc3545;
            font-weight: bold;
        }

        .list-group-item {
            background-color: #f9f9f9;
            color: #333;
        }

        .list-group-item:hover {
            background-color: #007bff;
            color: #fff;
        }

        .img-container {
            text-align: center;
            margin-top: 20px;
        }

        .img-container img {
            max-width: 50%;
            height: auto;
        }
    </style>
</head>
<body>
    <div class="header">
        <h1>{{ title }}</h1>
        <p>PDF generated using Jinja2 and PDFKit</p>
    </div>

    <div class="content container">
        <h2>Introduction</h2>
        <p>{{ content }}</p>

        <h2>Highlighted Text</h2>
        <p>You can use <span class="highlight">colors and bold text</span> to draw attention to key points in your PDF.</p>

        <h2>Table Example</h2>
        <table class="table table-bordered">
            <thead class="thead-dark">
                <tr>
                    <th>Item</th>
                    <th>Description</th>
                    <th>Price</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                    <td>Example 1</td>
                    <td>This is the first example item.</td>
                    <td>$10</td>
                </tr>
                <tr>
                    <td>Example 2</td>
                    <td>This is the second example item.</td>
                    <td>$20</td>
                </tr>
            </tbody>
        </table>

        <h2>List Example</h2>
        <ul class="list-group">
            {% for item in items %}
            <li class="list-group-item">{{ item }}</li>
            {% endfor %}
        </ul>

        <h2>Blockquote Example</h2>
        <blockquote>
            "This is a beautifully styled blockquote to emphasize key ideas."
        </blockquote>

        <h2>Image Example</h2>
        <div class="img-container">
            <img src="{{ image_path }}" alt="Example Image">
        </div>

        <h2>Button Example</h2>
        <a href="https://mosaid.xyz" class="btn btn-primary">Click Me</a>
    </div>

    <div class="footer">
        <p>{{ footer }}</p>
    </div>

    <!-- Bootstrap JS -->
    <script src="https://code.jquery.com/jquery-3.5.1.slim.min.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/@popperjs/core@2.4.4/dist/umd/popper.min.js"></script>
    <script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.5.2/js/bootstrap.min.js"></script>
</body>
</html>

Save this file as template.html in your project directory.

Generating the PDF

Now let’s use a Python script to generate the PDF from the Jinja2 template. Below is the script that takes the template, renders it with data, and generates the PDF:

    

import pdfkit
from jinja2 import Environment, FileSystemLoader
import os
import sys
from datetime import datetime

def generate_pdf(template_file, output_dir="./output"):
    # Create output directory if it doesn't exist
    os.makedirs(output_dir, exist_ok=True)

    # Extract the directory and filename from the template file
    template_dir = os.path.dirname(template_file)
    template_name = os.path.basename(template_file)

    # Set up Jinja2 environment
    env = Environment(loader=FileSystemLoader(template_dir))
    template = env.get_template(template_name)

    # Define data to be rendered in the template
    data = {
        "title": "Jinja2 to PDF Example",
        "content": "This is a PDF generated using Jinja2 and pdfkit.",
        "items": ["Introduction", "Body Content", "Conclusion"],
        "footer": "Generated by Radouan MOSAID",
        "image_path": "/path/to/image.jpg",  # Absolute path
    }

    # Render the template with the data
    rendered_html = template.render(data)

    # Get the current date string in YYYY-MM-DD format
    date_str = datetime.now().strftime("%Y-%m-%d")

    # Output PDF file path with the date appended to make it unique
    output_pdf_path = os.path.join(output_dir, f"output_{date_str}.pdf")

    # Define pdfkit options to enable local file access
    options = {
        'enable-local-file-access': '',  # Allow access to local files
    }

    # Convert the rendered HTML to a PDF with options
    pdfkit.from_string(rendered_html, output_pdf_path, options=options)

    print(f"PDF has been created successfully: {output_pdf_path}")

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("Usage: python script.py <template_file>")
        sys.exit(1)

    # Get the template file from the command-line arguments
    template_file = sys.argv[1]

    # Check if the file exists
    if not os.path.isfile(template_file):
        print(f"Error: Template file '{template_file}' not found.")
        sys.exit(1)

    # Generate PDF
    generate_pdf(template_file)

This script loads the template, renders it with the provided data, and outputs a PDF to the specified directory. The path to the image is provided as an absolute path to avoid errors.

Running the Script

To run the script, simply execute it from your terminal while in the project directory:

    

python script.py template.html

This will generate a PDF file with the rendered content. The output PDF will be saved in the output directory with a unique name based on the current date.

generated PDF file

Handling Errors

Sometimes, you might encounter issues like missing image files or incorrect file paths. Make sure to:

• Check the file path of the image used in the template.

• Ensure that --enable-local-file-access is set in the pdfkit options to allow local file access.

• Use absolute paths for local files to avoid any issues related to relative paths.

Customizing Your PDF

You can customize the PDF output by modifying the template, adding more dynamic data to the Jinja2 context, and adjusting the CSS styling. For example, you could change the page layout, font styles, or add additional sections like tables or charts.

Conclusion

In this tutorial, we’ve shown how to create PDFs using Jinja2 templates and Python. By organizing your code into a local Python environment and following best practices for managing dependencies, you can easily generate custom documents automatically. This process can be extended and customized for various use cases, making it an efficient way to automate document generation.

Create a PowerPoint Presentation in Minutes with Python

2025-01-15T21:02:14+00:00

How to Create a PowerPoint Presentation Using Python

Have you ever needed to create a presentation but lacked access to office software or simply didn’t have the time to design it manually? With Python and the python-pptx library, you can automate the process, creating professional-looking presentations with ease. In this tutorial, I’ll walk you through creating a PowerPoint presentation, including adding text, formatting slides, and incorporating figures generated using Python.

1. Setting Up Your Environment

To get started, install the necessary libraries:

    

pip install python-pptx matplotlib

The python-pptx library will handle creating and formatting the presentation, while matplotlib is used for generating images and graphs.

2. Creating a Basic Presentation

Start by creating a new PowerPoint file:

    

from pptx import Presentation

# Create a new presentation
prs = Presentation()

# Save the presentation
prs.save('my_presentation.pptx')

This creates an empty PowerPoint file named my_presentation.pptx.

3. Adding Slides and Text

To add a title slide with text:

    

# Add a title slide
slide = prs.slides.add_slide(prs.slide_layouts[0])

# Set the title and subtitle
title = slide.shapes.title
subtitle = slide.placeholders[1]

title.text = "Welcome to Python-Powered Presentations"
subtitle.text = "Automate your PowerPoint creation!"

4. Formatting Text

You can customize the appearance of the text, such as font size and color:

    

from pptx.util import Pt
from pptx.dml.color import RGBColor

# Format the title
title.text_frame.text = "Python Power"
title_format = title.text_frame.paragraphs[0]
title_format.font.size = Pt(36)
title_format.font.bold = True
title_format.font.color.rgb = RGBColor(255, 0, 0)  # Red

5. Adding Figures

Generate and include figures using matplotlib:

    

import matplotlib.pyplot as plt

# Create a sample plot
plt.figure(figsize=(6, 4))
plt.plot([1, 2, 3], [4, 5, 6], label="Sample Line")
plt.xlabel("X-Axis")
plt.ylabel("Y-Axis")
plt.title("Sample Plot")
plt.legend()

# Save the figure
plt.savefig('sample_plot.png')

# Add the image to a slide
image_slide = prs.slides.add_slide(prs.slide_layouts[5])  # Blank layout
image_slide.shapes.add_picture('sample_plot.png', Pt(100), Pt(100), width=Pt(400), height=Pt(300))

6. Saving the Presentation

Once you’ve added content, save the presentation:

    

prs.save('final_presentation.pptx')

Here is the full python script, you can easily extend it with more slides

    


from pptx import Presentation
from pptx.util import Pt
from pptx.dml.color import RGBColor
import matplotlib.pyplot as plt

# Create a new PowerPoint presentation
prs = Presentation()

# 1. Add a title slide
slide = prs.slides.add_slide(prs.slide_layouts[0])
title = slide.shapes.title
subtitle = slide.placeholders[1]
title.text = "Welcome to Python-Powered Presentations"
subtitle.text = "Automate your PowerPoint creation!"

# Format the title text
title_format = title.text_frame.paragraphs[0]
title_format.font.size = Pt(36)
title_format.font.bold = True
title_format.font.color.rgb = RGBColor(0, 102, 204)  # Blue color

# Format the subtitle text
subtitle_format = subtitle.text_frame.paragraphs[0]
subtitle_format.font.size = Pt(24)
subtitle_format.font.color.rgb = RGBColor(128, 128, 128)  # Gray color

# 2. Add a content slide
content_slide = prs.slides.add_slide(prs.slide_layouts[1])
content_title = content_slide.shapes.title
content_title.text = "Benefits of Python-Powered Slides"

# Add bullet points
bullet_points = [
    "Automate repetitive tasks",
    "Generate dynamic presentations",
    "Integrate data and figures effortlessly"
]
content = content_slide.placeholders[1]
for point in bullet_points:
    paragraph = content.text_frame.add_paragraph()
    paragraph.text = point
    paragraph.level = 0  # Top-level bullet point
    paragraph.font.size = Pt(18)
    paragraph.font.color.rgb = RGBColor(0, 0, 0)  # Black color

# 3. Generate a figure with matplotlib
plt.figure(figsize=(6, 4))
plt.plot([1, 2, 3], [4, 5, 6], label="Sample Line", color="blue")
plt.xlabel("X-Axis")
plt.ylabel("Y-Axis")
plt.title("Sample Plot")
plt.legend()
figure_path = "sample_plot.png"
plt.savefig(figure_path)
plt.close()

# 4. Add the figure to a new slide
image_slide = prs.slides.add_slide(prs.slide_layouts[5])  # Blank slide layout
image_slide.shapes.add_picture(figure_path, Pt(100), Pt(100), width=Pt(500), height=Pt(300))

# 5. Save the presentation
output_file = "final_presentation.pptx"
prs.save(output_file)
print(f"Presentation saved as {output_file}")

Automating PowerPoint Creation with Python

Conclusion

With just a few lines of Python code, you can create fully customized PowerPoint presentations. This approach is perfect for generating slides dynamically, especially when dealing with large datasets or repetitive tasks.

How Advanced Could Civilizations Become? Exploring the Kardashev Scale

2025-01-09T20:23:52+00:00

Understanding the Kardashev Scale of Civilizations

The Kardashev Scale is a framework for measuring the technological advancement of civilizations based on their energy consumption and control capabilities. Proposed by Soviet astronomer Nikolai Kardashev in 1964, the scale provides a fascinating way to explore humanity’s place in the cosmos and imagine the future of advanced societies.

Types of Civilizations on the Kardashev Scale

•Type I - Planetary Civilization: This civilization harnesses and utilizes all available energy on its home planet, including renewable and non-renewable resources, as well as atmospheric and geothermal energy. Earth is currently approaching this stage, with humanity estimated to be around 0.73 on the scale.

•Type II - Stellar Civilization: A Type II civilization can control the energy output of its entire star. Concepts like Dyson Spheres, massive structures built around stars to capture their energy, fall under this category. Such advancements would enable spacefaring societies to colonize and terraform other planets.

•Type III - Galactic Civilization: This level represents a civilization capable of utilizing energy from an entire galaxy. Such a society would have interstellar travel, potentially control black holes, and harness energy from countless stars. This is the realm of science fiction giants like the Galactic Empire in Star Wars.

Potential Extensions to the Scale

Since Kardashev’s time, scientists and futurists have speculated on civilizations beyond Type III:

•Type IV - Universal Civilization: This civilization could control energy on a universal scale, manipulating forces like dark energy and mastering the cosmos itself.

•Type V - Multiversal Civilization: A hypothetical society that spans and utilizes energy across multiple universes, operating at the level of multiverse theory.

What the Kardashev Scale Means for Humanity

Humanity’s current progress toward Type I is marked by exponential growth in technology, but it also highlights the challenges we face, such as climate change, resource management, and social cohesion. Achieving higher levels would require global collaboration and breakthroughs in energy production and storage.

The Kardashev Scale not only provides a metric for technological prowess but also inspires us to think about the long-term future of civilization and our role in the universe.

Kardashev Scale Visualization

Conclusion

By exploring the Kardashev Scale, we can dream of civilizations far more advanced than ours while also reflecting on the steps needed to secure our planetary future. It is a reminder that progress hinges on our ability to solve today’s challenges and unite toward a shared cosmic destiny.

How to Set Up Multiple Arabic Fonts for LaTeX on Linux and Windows

2025-01-05T12:55:09+00:00

How to Set Up Arabic Fonts for LaTeX on Linux and Windows

When working with Arabic text in LaTeX documents, selecting the right font can make a significant difference in the appearance of your document. In this article, we will walk you through the steps to download specific Arabic fonts from arfonts.net, install them on both Linux and Windows systems, and demonstrate how to use these fonts in a LaTeX document.

Step 1: Download the Fonts from arfonts.net

To begin, you will need to download the Arabic fonts. Follow these steps:

Visit https://www.arfonts.net/all/downloads.
Browse through the available fonts and download the desired Arabic fonts. You will typically find fonts in .zip or .rar formats.
Extract the downloaded file, which will usually contain .ttf (TrueType Font) files.

The fonts we will use for this demonstration are:

DecoType Thuluth II
Amiri
Noto Naskh Arabic

Step 2: Install the Fonts on Your System

After downloading and extracting the .ttf font files, you need to install them on your system. Below are the installation steps for both Linux and Windows.

Installing Fonts on Linux

Move the font files to the fonts directory:
Copy the .ttf font files into the ~/.fonts directory (you may need to create the directory if it doesn't exist).
```
   

mkdir -p ~/.fonts
cp /path/to/downloaded/fonts/*.ttf ~/.fonts/
```
Update the font cache:
After adding the fonts, you must update the font cache so that the system recognizes the new fonts. Run the following command in your terminal:
```
   

fc-cache -fv
```

Installing Fonts on Windows

Move the font files to the Fonts directory:
Navigate to the folder where the .ttf files were extracted. Right-click on each .ttf file and select Install from the context menu. Alternatively, you can manually move the .ttf files to the C:\Windows\Fonts directory.
Verify the installation:
Open the Fonts folder (C:\Windows\Fonts) and ensure that the font files are listed.

Step 3: Use the Fonts in LaTeX

Now that you've installed the fonts, let's move on to how to use them in your LaTeX document. Below is an example LaTeX document that demonstrates how to use the DecoType Thuluth II, Amiri, and Noto Naskh Arabic fonts for Arabic text. We will also define commands to make it easier to switch between fonts.

LaTeX Example:

    


\documentclass[12pt]{article}
\usepackage[french]{babel} % Main language is French
\usepackage{fontspec} % For custom fonts
\usepackage{bidi} % For bidirectional text in a non-Arabic document

% Define Arabic fonts
\newfontfamily\arabicThuluth[Script=Arabic]{DecoType Thuluth II} % Thuluth font
\newfontfamily\arabicAmiri[Script=Arabic]{Amiri} % Amiri font
\newfontfamily\arabicNaskh[Script=Arabic]{Noto Naskh Arabic} % Naskh font

% Define commands manually
\newcommand{\thuluth}[1]{%
    \begin{RTL}%
    \begin{flushright}%
    {\arabicThuluth #1}%
    \end{flushright}%
    \end{RTL}%
}
\newcommand{\amiri}[1]{%
    \begin{RTL}%
    \begin{flushright}%
    {\arabicAmiri #1}%
    \end{flushright}%
    \end{RTL}%
}
\newcommand{\naskh}[1]{%
    \begin{RTL}%
    \begin{flushright}%
    {\arabicNaskh #1}%
    \end{flushright}%
    \end{RTL}%
}

\begin{document}

\section*{Examen Final}
Voici le texte principal en français.

\vspace{1cm}

% Arabic text in different fonts
\thuluth{
  \Huge 123
  الحمد لله الذي بنعمته تتم الصالحات.}
\amiri{
  \Huge 123
  بسم الله الرحمن الرحيم.}
\naskh{
  \Huge 123
  إن مع العسر يسرا.}

\end{document}

Explanation of the LaTeX Code:

Font Definitions: We define three different Arabic fonts using the \newfontfamily command from the fontspec package:
- \arabicThuluth for DecoType Thuluth II.
- \arabicAmiri for Amiri.
- \arabicNaskh for Noto Naskh Arabic.
Creating Custom Commands: We create custom commands (\thuluth, \amiri, and \naskh) to simplify switching between fonts. Each command uses the corresponding Arabic font and ensures the text is displayed correctly with the RTL (Right-To-Left) environment.
Text Display: The Arabic text is displayed using these custom commands to demonstrate the different fonts.

Step 4: Compile the Document

To compile your LaTeX document with these fonts, you should use either XeLaTeX or LuaLaTeX, as they are both compatible with custom fonts:

Run the following command to compile the document:
```
   

xelatex yourfile.tex
```
This will produce a PDF with Arabic text formatted using the specified fonts like this:

Latex arabic fonts example

Conclusion

By following these simple steps, you can easily download and install Arabic fonts, configure them in your LaTeX documents, and use them to display beautiful Arabic text. Whether you're working on an Arabic document or simply adding a quote in Arabic, these fonts will make your document stand out.

Efficiently Yank and Select Content Between Characters in Vim

2025-01-03T20:00:21+00:00

Efficient Editing Between Characters in Vim

Editing content between specific characters is a frequent task, especially in structured formats like code or LaTeX files. Vim's built-in commands allow you to yank, delete, or visually select text between or around certain characters. Here’s a closer look at some of these commands and how you can extend their functionality.

Understanding Vim's Built-in Commands

Vim provides a set of intuitive commands for working with text between or around specific characters. Let’s break down a few examples:

•yit (Yank Inner Tag): This command yanks the content inside the nearest tag pair, such as <div>this text will be yanked</div>. For example, with the cursor inside:

Running yit copies "this text will be yanked" to the clipboard.

•vit (Visual Select Inner Tag): This highlights the content inside a tag pair for further operations like deleting or copying.

•yi" (Yank Inner Quotes): Copies the text inside quotes, like:

    

"This is a string"

Running yi" yanks "This is a string". Similarly, vi" selects it visually.

•yi(, yi[, yi{: These commands work for parentheses, brackets, and braces, yanking the content inside them.

Why Extend Vim's Pair Handling?

While Vim supports common delimiters by default, specific workflows often demand custom character pairs. For instance, in LaTeX files, mathematical content is often enclosed within dollar signs ( $...$ ). Copying or editing such content with precision is essential for efficiency. This need prompted me to extend Vim's functionality to handle additional characters like $.

Adding Custom Pair Support

Here’s how you can extend Vim to handle additional characters like underscores, dollar signs, or even special delimiters. Add the following script to your .vimrc file:

    

for s:char in [ '_', '.', ':', ',', ';', '', '/', '', '*', '+', '%', '$' ]
  execute 'xnoremap i' . s:char . ' :normal! T' . s:char . 'vt' . s:char . ''
  execute 'onoremap i' . s:char . ' :normal vi' . s:char . ''
  execute 'xnoremap a' . s:char . ' :normal! F' . s:char . 'vf' . s:char . ''
  execute 'onoremap a' . s:char . ' :normal va' . s:char . ''
endfor

With this script, you can:

•yi$: Yank content inside dollar signs, such as math expressions in LaTeX.

•vi_: Visual select text inside underscores.

•va.: Select content and the enclosing dot.

Conclusion

Customizing Vim to support additional characters boosts productivity, especially for domain-specific tasks like LaTeX editing. By combining Vim’s flexibility with your workflow needs, you can streamline text editing and enhance efficiency.

Can You Be Hacked via Whatsapp?

2025-01-03T09:25:55+00:00

Can You Be Hacked via WhatsApp?

Understanding the Risks

WhatsApp, with its end-to-end encryption, is often regarded as secure. However, vulnerabilities in its implementation or user behavior can expose you to sophisticated attacks. Let's delve into the methods attackers use and how you can defend against them.

Types of WhatsApp Attacks

•Phishing via Malicious Links: Cybercriminals send fraudulent links designed to steal credentials or install malware. For instance, a link mimicking WhatsApp's official website might ask for your login details. Tools like curl can help check the headers of suspicious URLs before clicking:

    

curl -I [URL]

Defense: Avoid clicking on links from unknown contacts and verify URLs carefully.

•Malware Embedded in Attachments: Attachments such as images or documents may exploit vulnerabilities in your device to execute malicious code. For example, specially crafted media files might target outdated WhatsApp versions.

Defense: Update WhatsApp regularly and scan suspicious files with antivirus tools.

•Account Takeover through Verification Code Theft: Attackers use social engineering to trick you into sharing your WhatsApp verification code. Once obtained, they clone your account on another device, gaining access to all your chats.

Defense: Enable two-step verification to add an extra layer of security to your account.

•Spyware Delivered via Missed Calls: Advanced spyware like Pegasus can exploit zero-day vulnerabilities to infiltrate your device via a missed WhatsApp call. Such attacks often target high-profile individuals.

Defense: Keep your device firmware and apps updated to patch known vulnerabilities.

•Compromising WhatsApp Web: An attacker with physical or remote access to your device could log in to WhatsApp Web and monitor your chats unnoticed.

    

adb shell am start -a android.intent.action.VIEW -d "https://web.whatsapp.com"

Defense: Regularly check and log out of active WhatsApp Web sessions from the app settings.

Real-Life Scenarios

•High-Profile Hacks: Politicians, journalists, and celebrities have been targeted by spyware campaigns, compromising their privacy and security.

•Mass Phishing Scams: During the COVID-19 pandemic, attackers leveraged WhatsApp to distribute fake relief messages, harvesting personal information from unsuspecting users.

•Business Communication Breaches: Companies using WhatsApp for client communication have fallen victim to data leaks due to insecure practices.

Best Practices for Defense

•Enable Two-Step Verification: Activate two-step verification in WhatsApp settings to secure your account with an additional PIN.

•Use Secure Networks: Avoid accessing WhatsApp over public Wi-Fi. Opt for a VPN to encrypt your connection.

•Restrict Privacy Settings: Adjust your profile visibility to "Contacts Only" in WhatsApp's privacy settings to reduce exposure.

•Monitor Device Permissions: Regularly review and revoke unnecessary permissions granted to WhatsApp, such as camera or microphone access, from your phone settings.

•Audit Installed Applications: Regularly inspect your device for unknown or suspicious apps that could monitor your WhatsApp activity.

•Analyze WhatsApp Logs: Use adb logcat to inspect logs for unusual activity:

    

adb logcat | grep "whatsapp"

Conclusion

While WhatsApp employs robust security measures, it isn’t immune to exploitation. By understanding potential threats and adopting proactive defenses, you can significantly minimize your risk of being hacked through WhatsApp.

Can You Be Hacked via Bluetooth?

2025-01-02T13:13:49+00:00

Bluetooth has become an essential part of our lives, connecting everything from headphones to smart home devices. But this convenience also comes with potential risks, as attackers increasingly exploit vulnerabilities in Bluetooth technology to target unsuspecting users. In this article, we’ll explore common Bluetooth attacks, how they work, and what you can do to protect yourself.

Types of Bluetooth Attacks

•Bluesnarf Attack: This attack leverages poorly secured OBEX (Object Exchange) protocols to access data on a target device without permission. Attackers often exploit devices with misconfigured or outdated Bluetooth stacks. Tools like hcitool and obexftp can be repurposed for such attacks. For instance, in 2003, Nokia phones with weak implementations of OBEX were successfully exploited to retrieve sensitive data remotely.

•Man-in-the-Middle (MITM) Attack: MITM attacks involve intercepting and modifying Bluetooth communication between two devices. Attackers often rely on vulnerabilities in the pairing process, particularly in devices using legacy SSP (Secure Simple Pairing). Tools like btproxy allow attackers to eavesdrop or relay traffic. A real-world scenario includes intercepting authentication codes exchanged between point-of-sale systems and Bluetooth-connected payment terminals.

•Bluejacking: Bluejacking exploits the message-pushing capability of Bluetooth to send unsolicited messages to devices in range. While it does not directly compromise data, it can be used for phishing or annoyance. Attackers use tools like bluesnarfer to automate the discovery of devices and send bulk messages, often containing malicious links.

•Bluesmacking (DoS Attack): Bluesmacking takes advantage of the L2CAP (Logical Link Control and Adaptation Protocol) layer by overwhelming a device with large data packets, causing it to crash. Tools such as l2ping can be used to repeatedly send oversized packets, disrupting the target device. For instance, Bluetooth-enabled headsets and industrial IoT devices have been rendered inoperable by such attacks during demonstrations of this vulnerability.

•Blueprinting Attack: Blueprinting involves scanning for Bluetooth devices and analyzing their profiles to identify vulnerabilities. Attackers use tools like hciconfig and hcitool scan to detect nearby devices, collect device metadata, and plan subsequent attacks. For example, during penetration tests, ethical hackers have demonstrated how blueprinting can identify outdated firmware in smart devices for exploitation.

•Bluebugging: Bluebugging exploits vulnerabilities in outdated Bluetooth firmware or weak pairing protocols to gain control of a device. Once compromised, the attacker can execute commands remotely, such as initiating calls, sending messages, or accessing the internet via the victim's device. Tools like Metasploit Bluetooth Modules have been used in controlled environments to simulate this type of attack, often targeting older laptops or phones with legacy Bluetooth implementations.

How to Protect Yourself from Bluetooth Attacks

•Disable Bluetooth When Not in Use: Keep Bluetooth disabled when you don't need it. On Linux, you can use rfkill block bluetooth to completely block Bluetooth functionality or systemctl stop bluetooth to disable the Bluetooth service temporarily.

•Regularly Update Firmware and Software: Ensure your Bluetooth devices are running the latest firmware. Many vulnerabilities exploited by attackers are due to unpatched software. Check your Linux distribution for updates with sudo apt update && sudo apt upgrade or equivalent commands for your package manager.

•Monitor Pairing Requests: Be cautious of unexpected pairing requests. Attackers often mimic legitimate devices. Use tools like bluetoothctl on Linux to manage trusted devices and inspect pairing details.

•Use a Firewall to Restrict Bluetooth Traffic: A firewall like ufw or iptables can block unwanted Bluetooth connections. For example, you can add a rule to drop all incoming Bluetooth connections:

    

sudo iptables -A INPUT -p bluetooth -j DROP

•Set Device to Non-Discoverable Mode: Keep your device hidden from scans when Bluetooth is enabled. On Linux, you can use bluetoothctl to set the device to non-discoverable mode:

    

bluetoothctl
discoverable off

•Use Strong Pairing Options: Ensure your devices use Secure Simple Pairing (SSP) with passkey authentication to prevent MITM attacks. Check device settings or documentation to verify SSP is enabled.

•Scan for Rogue Devices: Regularly scan your environment for unknown devices with tools like hcitool scan or more advanced tools such as bluetooth-sniffer. Identify and investigate any suspicious devices in your proximity.

•Monitor Logs for Suspicious Activity: On Linux, inspect syslog or Bluetooth-specific logs to detect unauthorized access attempts. Use:

    

sudo journalctl | grep bluetooth

to check recent Bluetooth-related activity on your system.

•Use Encryption and Authentication: Always prefer encrypted connections where possible. For Bluetooth Low Energy (BLE) devices, ensure pairing uses LE Secure Connections instead of legacy pairing.

•Use Device-Specific MAC Address Filtering: Configure your Bluetooth stack to only allow connections from specific MAC addresses. While not foolproof, this adds an additional layer of security.

Advanced Bluetooth Penetration Testing and Defense

•Exploiting Weak Pairing with Tools: Attackers often use tools like hciconfig and hcitool to identify vulnerabilities during pairing. For example, using hcitool scan or hcitool inq, they can identify discoverable devices and attempt pairing. To prevent such attacks, ensure pairing uses Secure Simple Pairing (SSP) with passkey authentication. Use bluetoothctl to verify pairing modes.

•Sniffing Bluetooth Traffic: Tools like Ubertooth One allow attackers to sniff Bluetooth Classic and Low Energy traffic. They exploit this to capture sensitive data transmitted between devices. Defensively, use encrypted Bluetooth profiles and ensure BLE communications use LE Secure Connections. Wireshark combined with Ubertooth can help analyze your environment for suspicious traffic.

•Bluetooth Brute-Forcing: Tools like crackle can brute-force PINs during pairing for legacy Bluetooth devices. An attacker might capture pairing data with btmon or Ubertooth and then use crackle to decrypt the link key. To mitigate, disable legacy pairing on devices or update to those supporting LE Secure Connections.

    

crackle -i capture.pcap -o decrypted.pcap

•Bluebugging with Bluesnarfer: Attackers exploit poorly configured devices using tools like bluesnarfer. This tool allows them to read SMS messages, contact lists, or even access the file system. To defend, set strong device PINs and keep devices non-discoverable:

    

bluesnarfer -r 1-100 -C 7 -b [MAC_address]

•Denial of Service via Bluetooth: L2CAP ping flooding is a common DoS attack vector where tools like l2ping are used to overwhelm a device. For example:

    

l2ping -s 65535 -f [MAC_address]

To defend, limit incoming L2CAP traffic with a firewall or disable pairing requests during active connections.

•Bluetooth Reconnaissance: Tools like Bleah allow attackers to enumerate BLE devices, including services and characteristics. This can reveal sensitive information or potential entry points:

    

bleah -t [MAC_address]

Defensively, limit BLE device broadcasts and disable unused services. Use BLE-capable sniffers to identify and analyze rogue devices broadcasting in your environment.

•MITM Attacks on Bluetooth: Attackers can perform MITM attacks during pairing by downgrading devices to insecure modes. Tools like bettercap with its BLE module can intercept and manipulate communications. For example:

    

bettercap -caplet ble.recon

To prevent, use LE Secure Connections and verify pairing methods before trusting devices. Additionally, regularly audit your Bluetooth stack and pairing history for anomalies.

•Custom Tools for Bluetooth Attacks: Advanced attackers may write custom scripts using libraries like PyBluez to automate attacks. For example, a Python script using PyBluez could scan and attempt to connect to devices:

    

import bluetooth

target_name = "Device_Name"
nearby_devices = bluetooth.discover_devices()

for bdaddr in nearby_devices:
    if target_name == bluetooth.lookup_name(bdaddr):
        print(f"Found target device: {bdaddr}")
        break

To defend, monitor network logs for unauthorized access and implement strict pairing policies.

•Advanced Logging and Analysis: Regularly analyze Bluetooth logs for anomalies. Use:

    

sudo btmon | tee bluetooth_activity.log

Pair with tools like Splunk or Graylog for centralized log monitoring and real-time anomaly detection.

•Harden Bluetooth Configurations: Edit /etc/bluetooth/main.conf to restrict device behavior. For example, enforce non-discoverable mode and disable insecure profiles:

    

[Policy]
DiscoverableTimeout = 0

By understanding these tools and methods, you can better secure your Bluetooth environment against attackers.

Conclusion

While Bluetooth offers incredible convenience, it also introduces certain risks. Understanding the types of attacks and implementing basic security measures can go a long way in keeping your devices safe. Stay vigilant and proactive to enjoy the benefits of Bluetooth without compromising your privacy.

Hidden Gems of Vim: Tricks for Efficient Text Editing

2025-01-01T11:41:48+00:00

Unlocking Vim's Hidden Potential: Tricks and Gems for Power Users

Vim is more than just a text editor; it's a powerhouse of efficiency. While many users are familiar with its basics, countless hidden features can transform your workflow. Let’s dive into some advanced Vim tricks and hidden gems that you might not know!

1. Working with Numbers Like a Pro

•Increment and Decrement Across a Block: Visual mode isn’t just for selecting text; it can handle numbers too. Select a block of numbers, then use g<C-a> to increment or g<C-x> to decrement them sequentially. Perfect for creating numbered lists or adjusting configurations.

•Smart Increment: Want to increment all numbers in a file? Use :%s/\\d\\+/\\=submatch(0) + 1/g. This substitution command handles it beautifully.

2. Mastering Text Manipulation

•Seamless Line Joining: Use gJ to join lines without inserting a space. Ideal for cleaning up code or text.

•Duplicate Lines in a Snap: Duplicate the current line with :t.. Efficient and straightforward!

•Remove Blank Lines: Clean up your document by removing blank lines with :g/^$/d.

3. Unlocking the Power of Registers

•Preserve the Clipboard: Use the black hole register "_d to delete text without affecting your clipboard. Say goodbye to accidental overwrites!

•Direct Register Input: Need to add text to a register quickly? Use :let @"="your text" to assign text to the unnamed register.

4. Smart Navigation with Marks

•Jump to Last Edit: Quickly return to the last modified position with `.. Never lose track of your edits again.

•Start and End of Changes: Use `[ and `] to jump to the start and end of the last change.

5. Advanced Search and Replace

•Pattern-Based Increments: Increment all numbers matching a pattern with :g/pattern/exe "normal <C-a>".

•Add Prefixes and Suffixes: Transform every line by adding a prefix and suffix using :%s/^\$.*\$$/Prefix \\1 Suffix/.

6. Making the Most of Visual Mode

•Reselect Your Last Selection: Press gv to reselect the previous visual selection effortlessly.

•Execute Macros in a Range: Select a block and execute a macro over it with :'<,'>normal @q.

7. Enhancing Buffers and Tabs

•Vertical Diff Splits: Use :vert diffsplit {file} to compare files side by side with a vertical split.

•Tabs in Control: Reorganize your tabs with :tabm {n} and execute commands across all tabs using :tabdo {cmd}.

8. Uncommon Editing Features

•Insert Shell Output: Bring external command results into Vim with :read !ls.

•Batch Edit Lines: Append a semicolon to all lines with :normal! A;.

9. Miscellaneous Gems

•ASCII and Unicode Insight: Know exactly what character you’re dealing with using ga.

•Quick File Navigation: Open the file path under your cursor in a new buffer with gf.

•Session Management: Save and restore your session with :mksession mysession.vim and :source mysession.vim.

Conclusion

Vim’s true power lies in its depth and versatility. Mastering these hidden gems can significantly enhance your productivity. Try them out and incorporate them into your daily workflow—you’ll wonder how you ever lived without them!

Discover GNOME with these 25 Stunning Desktop Screenshots

2024-12-31T12:58:25+00:00

Introduction to GNOME Desktop Environment

GNOME stands out as a modern, intuitive, and minimalistic desktop environment. Its focus on simplicity and productivity has made it a favorite among Linux users. In this gallery, we present 25 stunning images that demonstrate the elegance and functionality of the GNOME desktop.

Why GNOME?

•Streamlined Interface: GNOME is designed with a focus on user experience, offering a clean and uncluttered interface.

•Efficient Workflow: With features like Activities Overview and keyboard shortcuts, GNOME optimizes your productivity.

•Modern Aesthetics: Sleek design elements and polished animations make GNOME visually appealing.

Gallery: GNOME Desktop Highlights

Here are 25 images that showcase the best of GNOME Desktop:

Gnome Desktop Screenshot 1

Gnome Desktop Screenshot 2

Gnome Desktop Screenshot 3

Gnome Desktop Screenshot 4

Gnome Desktop Screenshot 5

Gnome Desktop Screenshot 6

Gnome Desktop Screenshot 7

Gnome Desktop Screenshot 8

Gnome Desktop Screenshot 9

Gnome Desktop Screenshot 10

Gnome Desktop Screenshot 11

Gnome Desktop Screenshot 12

Gnome Desktop Screenshot 13

Gnome Desktop Screenshot 14

Gnome Desktop Screenshot 15

Gnome Desktop Screenshot 16

Gnome Desktop Screenshot 17

Gnome Desktop Screenshot 18

Gnome Desktop Screenshot 19

Gnome Desktop Screenshot 20

Gnome Desktop Screenshot 21

Gnome Desktop Screenshot 22

Gnome Desktop Screenshot 23

Gnome Desktop Screenshot 24

Gnome Desktop Screenshot 25

Conclusion

GNOME offers a balance of simplicity and power, making it an excellent choice for both new and experienced Linux users. Its elegant design and intuitive features are reflected in the gallery above. Ready to explore GNOME further? Visit the official GNOME website and experience it for yourself!

Discover the Beauty of KDE Plasma with These 30 Screenshots

2024-12-30T21:13:58+00:00

Introduction to KDE Plasma Desktop

KDE Plasma is celebrated for its versatility, stunning visuals, and user-centric design. In this gallery, we showcase 30 handpicked images that highlight the beauty and flexibility of KDE Plasma. Whether you're new to KDE or a seasoned user, these visuals will inspire you to explore this amazing desktop environment.

Why Choose KDE Plasma?

•Customization: From widgets to window decorations, KDE Plasma allows you to tailor your desktop to suit your preferences.

•Performance: Lightweight and efficient, KDE Plasma delivers a smooth experience even on older hardware.

•Modern Aesthetics: With stunning themes and polished icons, KDE Plasma offers a contemporary look and feel.

Gallery: The Elegance of KDE Plasma

Here are 30 stunning screenshots that showcase the best of KDE Plasma:

KDE Plasma Desktop Screenshot 1

KDE Plasma Desktop Screenshot 2

KDE Plasma Desktop Screenshot 3

KDE Plasma Desktop Screenshot 4

KDE Plasma Desktop Screenshot 5

KDE Plasma Desktop Screenshot 6

KDE Plasma Desktop Screenshot 7

KDE Plasma Desktop Screenshot 8

KDE Plasma Desktop Screenshot 9

KDE Plasma Desktop Screenshot 10

KDE Plasma Desktop Screenshot 11

KDE Plasma Desktop Screenshot 12

KDE Plasma Desktop Screenshot 13

KDE Plasma Desktop Screenshot 14

KDE Plasma Desktop Screenshot 15

KDE Plasma Desktop Screenshot 16

KDE Plasma Desktop Screenshot 17

KDE Plasma Desktop Screenshot 18

KDE Plasma Desktop Screenshot 19

KDE Plasma Desktop Screenshot 20

KDE Plasma Desktop Screenshot 21

KDE Plasma Desktop Screenshot 22

KDE Plasma Desktop Screenshot 23

KDE Plasma Desktop Screenshot 24

KDE Plasma Desktop Screenshot 25

KDE Plasma Desktop Screenshot 26

KDE Plasma Desktop Screenshot 27

KDE Plasma Desktop Screenshot 28

KDE Plasma Desktop Screenshot 29

KDE Plasma Desktop Screenshot 30

Conclusion

KDE Plasma is not just a desktop environment; it's an experience. With its unmatched flexibility, eye-catching design, and powerful tools, it caters to every user's needs. We hope this gallery inspires you to explore KDE Plasma further and customize your desktop to reflect your personality.

If you’re new to KDE, visit the official KDE Plasma website to learn more and get started today!

Top Programming Languages to Learn for Career Success in 2025

2024-12-29T12:52:20+00:00

The Best Programming Languages to Learn in 2025

As we move further into 2025, the programming landscape continues to evolve at a rapid pace. Whether you're just starting out or looking to expand your skill set, knowing which programming languages are in high demand can give you a significant advantage in the job market. In this article, we’ll explore some of the best programming languages to learn in 2025.

• Python: Python remains a top choice for both beginners and experienced developers alike. Its readability, versatility, and broad application make it an essential language for fields like web development, data science, machine learning, and artificial intelligence. With a thriving ecosystem of libraries and frameworks like Django, Flask, and TensorFlow, Python's popularity shows no signs of slowing down.

• JavaScript: JavaScript continues to dominate the world of web development. As a core language for front-end development, it is indispensable for creating dynamic and interactive websites. Frameworks like React, Angular, and Vue.js, along with Node.js for backend development, ensure that JavaScript remains one of the most versatile and powerful languages in the industry.

• TypeScript: As a superset of JavaScript, TypeScript adds static typing, which can help developers catch errors earlier in the development process. TypeScript’s growing popularity, especially for large-scale web applications, is backed by its compatibility with JavaScript and its use in top-tier frameworks like Angular and React. If you're already familiar with JavaScript, learning TypeScript will significantly boost your coding efficiency.

• Go: Go, also known as Golang, has been gaining traction for its simplicity and performance in concurrent programming. Developed by Google, Go is often chosen for building scalable web servers, cloud applications, and microservices. Its efficient memory management and fast compilation times make it a solid choice for backend development.

• Rust: Rust has quickly become a favorite for systems programming due to its focus on safety and performance. Unlike C and C++, Rust eliminates common bugs like memory leaks and race conditions. Its growing community and increasing adoption in industries requiring low-level control, like game development, embedded systems, and blockchain, make it a highly valuable language to learn in 2025.

• Kotlin: Kotlin is the official language for Android development, and its popularity continues to rise. Known for its modern syntax and enhanced safety features over Java, Kotlin is used to develop robust and efficient Android apps. Additionally, Kotlin can be used for backend development with frameworks like Ktor, expanding its applicability beyond mobile development.

• Swift: If you're looking to develop iOS or macOS applications, Swift is the language to learn. As Apple's preferred language for app development, Swift offers a powerful yet easy-to-learn syntax. It’s fast, safe, and designed to work seamlessly with Apple's ecosystem, making it an essential tool for mobile developers.

• Ruby: Although its popularity has waned slightly in recent years, Ruby remains an excellent choice for web development, especially with the Ruby on Rails framework. Its elegant syntax and developer-friendly environment make it a great language for building scalable web applications quickly.

• SQL: While not a traditional programming language, SQL (Structured Query Language) is essential for working with databases. It’s widely used in data analysis, backend development, and even some full-stack positions. Learning SQL can significantly enhance your ability to interact with and manipulate databases, making it a must-know for anyone working in tech.

Conclusion

Choosing the right programming language to learn in 2025 depends on your career goals and the industries you're interested in. Python, JavaScript, and TypeScript are solid choices for general-purpose programming, while Go and Rust excel in systems programming and performance-intensive applications. Kotlin and Swift are the go-to languages for Android and iOS development, respectively, while SQL remains indispensable for working with databases.

By focusing on these languages, you'll be well-equipped to tackle a variety of development challenges and stay competitive in the ever-changing world of programming.

Creating Professional Exams with LaTeX: A Complete Guide

2024-12-08T13:42:19+00:00

Introduction

If you're looking to create professional and structured exams using LaTeX, you're in the right place. Over the years, I’ve found the exam document class to be an incredibly powerful tool for creating exams with questions, solutions, and even point-based grading. What I love most is the flexibility: you can include solutions for personal reference, but when you compile without the answers parameter, they stay hidden—perfect for distributing to students. In this tutorial, I’ll guide you through some practical examples to help you get started.

Preamble and Exam Settings

The preamble in LaTeX is where you set up the structure and configurations for your document. For an exam, this includes defining the document class, setting up page geometry, and importing packages for additional functionality. In this case, we are using the exam document class, which is specifically designed for creating exams with options for solutions, grading, and question formatting.

    

% Typeset exams with solutions in LaTeX
\documentclass[answers,addpoints,12pt,a4paper]{exam}
\usepackage[left=1.5cm,right=0.5cm,top=0cm,bottom=1cm]{geometry}   % Set page margins
% \usepackage[french]{babel}
\usepackage{calligra} % For calligraphy font
\usepackage[T1]{fontenc}
\usepackage{amsmath,amssymb}
\usepackage{tikz} % For drawing the vertical line
\usepackage{xcolor}

\pointname{}
\pointformat{\textbf{\textit{(\thepoints)}}}

% Exam settings
\pointsinmargin
% \colorfillwithlines
% \definecolor{FillWithLinesColor}{gray}{0.8}
\colorfillwithdottedlines
\definecolor{FillWithDottedLinesColor}{gray}{0.7}
\unframedsolutions
\renewcommand{\solutiontitle}{\noindent\textbf{}\enspace}
\SolutionEmphasis{\itshape\small}
\SolutionEmphasis{\color{red}}

The exam settings in the preamble customize the document's layout and functionality. For example, \pointsinmargin places question point values in the margin for a cleaner look, while \colorfillwithdottedlines fills answer spaces with dotted lines to guide students. Solution formatting is also fully customizable: \unframedsolutions removes borders around solutions, and \SolutionEmphasis{\color{red}} highlights them in red. These options allow you to tailor the exam to your preferences and needs.

Question Types

The exam class provides various question types, making it highly versatile for creating exams. If compiled without the answers parameter, you get a clean, professional exam. With the answers parameter, the output includes solutions, perfect for creating a correction guide.

Check Options (Multiple Choice)

    

\question[2]
This question has one correct answer. Mark it.
\begin{checkboxes}
    \choice The correct answer is after the second wrong answer.
    \choice The correct answer is after this answer.
    \choice This is the correct answer.
    \CorrectChoice Previous answers are false.
\end{checkboxes}

\question[1]
Which of the following is not a Greek philosopher?\\
\begin{oneparcheckboxes}
    \choice Socrates
    \choice Plato
    \choice Pythagoras
    \CorrectChoice You
\end{oneparcheckboxes}

Fill in the Blank

    

\question[2] Fill in the blank using the following words:\\
\parbox{0.9\textwidth}{%
  \colorbox{gray!30}{\parbox{\dimexpr\linewidth-2\fboxsep}{%
      \centering
      \textbf{\textit{Helium $-$ Sir Isaac Newton $-$ Alpha Centuri $-$ Einstein}}
  }}
}\\[1ex]
\fillin[Helium] is the second element of the periodic table.\\
\fillin[Sir Isaac Newton][2in] discovered the first gravitational law.\\
The answer to \fillin[life, the universe and everything][3in] is 42

Direct Question with Space for Answers

    

\question[5]
In no more than one paragraph, explain why the earth is round.
\begin{solutionordottedlines}[1.5in]
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac,
adipiscing vitae, felis. Curabitur dictum gravida mauris.
\end{solutionordottedlines}

These examples illustrate how to design and format exams with ease. By toggling the answers parameter, you can switch between a student-ready exam and a solution-rich correction sheet.

The Exam




% Typeset exams with solutions in LaTeX
\documentclass[addpoints, 12pt, a4paper]{exam}
\usepackage[left=1.5cm,right=0.5cm,top=0cm,bottom=1cm]{geometry}   % Set page margins
%\usepackage[french]{babel}
\usepackage{calligra} % For calligraphy font
\usepackage[T1]{fontenc}
\usepackage{amsmath, amssymb}
\usepackage{tikz} % For drawing the vertical line
\usepackage{xcolor}

\pointname{}
\pointformat{\textbf{\textit{(\thepoints)}}}

% Exam settings
\pointsinmargin
%\colorfillwithlines
%\definecolor{FillWithLinesColor}{gray}{0.8}
\colorfillwithdottedlines
\definecolor{FillWithDottedLinesColor}{gray}{0.7}
\unframedsolutions
\renewcommand{\solutiontitle}{\noindent\textbf{}\enspace}
\SolutionEmphasis{\itshape\small}
\SolutionEmphasis{\color{red}}

% Redefine the points display format in margin
\newcommand{\borders}{%
  \tikz[remember picture, overlay, xshift=-0.5cm]{
    \draw[gray, thick] (0,-1.2) -- (0,-27);
    \draw[gray, thick] (0,-1.2) -- (\textwidth,-1.2);
    \node[] at (0.5,-0.25) {\textbf{1\textsuperscript{er} bac S.E}};
    \node[magenta] at (1.1,-0.6) {\textbf{www.mosaid.xyz}};
    \node[xshift=-2cm] at (\textwidth,-0.25) {\textbf{\today}};
    \node[xshift=-5.5cm] (A) at (\textwidth,-0.9)  {\textbf{Name :}};
    \node[xshift=-0.5cm] at (0.5\textwidth,-0.5) {\textbf{English Test n$^\circ$1 /2h}};
    \draw[gray, thick] (A.south west) -- ++(0,0.7) -- ++(6.4,0) ;
    \node[magenta] at (0.9\textwidth,-1.4) {\textbf{www.mosaid.xyz}};
  }%
}


% Redefine \exo command to avoid spacing issues
\newcommand{\exo}[1]{%
    \begin{tikzpicture}
        % Node for the text
        \node[] (text) at (0,0) {\textbf{#1}};
        % Shadow (calculated based on the text width)
        \fill[black] ([xshift=0.1cm, yshift=-0.1cm]text.south west)
                     rectangle ([xshift=0.1cm, yshift=-0.1cm]text.north east);
        % Main box (calculated based on the text width)
        \draw[fill=white] (text.south west) rectangle (text.north east);
        % Text inside the box
        \node[] at (text) {\textbf{#1}};
    \end{tikzpicture}%
}

\footer{}{Page \thepage\ of \numpages}{}

\begin{document}
\borders\\[1cm]

\noindent\hspace*{0.1cm}
\exo{Whatever Subjects English teachers teach \hspace{2mm} (10pts)}

\begin{questions}

\question[2]
This question has one correct answer. Mark it.
\begin{checkboxes}
    \choice The correct answer is after the second wrong answer.
    \choice The correct answer is after this answer.
    \choice This is the correct answer.
    \CorrectChoice Previous answers are false.
\end{checkboxes}

\question[1]
Which of the following is not a Greek philosopher?\\
\begin{oneparcheckboxes}
    \choice Socrates
    \choice Plato
    \choice Pythagoras
    \CorrectChoice You
\end{oneparcheckboxes}

\question[2] Fill in the blank using the following words:\\
\parbox{0.9\textwidth}{%
  \colorbox{gray!30}{\parbox{\dimexpr\linewidth-2\fboxsep}{%
      \centering
      \textbf{\textit{Helium ~$-$~ Sir Isaac Newton ~$-$~ Alpha Centuri ~$-$~ Einstein}}
  }}
}\\[1ex]
\fillin[Helium] is the second element of the periodic table.\\
\fillin[Sir Isaac Newton][2in] discovered the first gravitational law.\\
The answer to \fillin[life, the universe and everything][3in] is 42\\

\noindent \hspace*{-0.6cm}
\exo{Language, writing and other english stuff \hspace{2mm} (10pts)}
\setcounter{question}{0}
\question[5]
In no more than one paragraph, explain why the earth is round.
%\fillwithlines{1.5in}
%\fillwithdottedlines
\begin{solutionordottedlines}[1.5in]
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac,
adipiscing vitae, felis. Curabitur dictum gravida mauris. Nam arcu libero, nonummy eget, consectetuer
id, vulputate a, magna. Donec vehicula augue eu neque. Pellentesque habitant morbi tristique senectus
et netus et malesuada fames ac turpis egestas. Mauris ut leo. Cras viverra metus rhoncus sem. Nulla
et lectus vestibulum urna fringilla ultrices. Phasellus eu tellus sit amet tortor gravida placerat. Integer
sapien est, iaculis in, pretium quis, viverra ac, nunc.
\end{solutionordottedlines}
\question
\begin{parts}
\part[2]
What changes to the van Allen radiation belt are needed to make
the earth into a regular icosahedron?
\begin{solutionordottedlines}[1in]
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac,
adipiscing vitae, felis. Curabitur dictum gravida mauris. Nam arcu libero, nonummy eget, consectetuer
id, vulputate a, magna. Donec vehicula augue eu neque.
\end{solutionordottedlines}
\part[3]
Where should the field generator be constructed if you want one of
the vertices to be located at the Royal Observatory at Greenwich?
\begin{solutionordottedlines}[1in]
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac,
adipiscing vitae, felis. Curabitur dictum gravida mauris. Nam arcu libero, nonummy eget, consectetuer
id, vulputate a, magna. Donec vehicula augue eu neque. Pellentesque habitant morbi tristique senectus
et netus et malesuada fames ac turpis egestas. Mauris ut leo.
\end{solutionordottedlines}
\end{parts}
\end{questions}

%\begin{center}
%\hsword{text}
%\gradetable[h][questions]
%\end{center}

\begin{center}
        {\scalebox{3}{\textbf{\textcolor{blue}{\calligra Good Luck!}}}}
\end{center}

\end{document}

Exam compiled with XeLatex without solutions

And to have your solutions document, all you have to do is compile it using the parameter in the documentclass like this:



\documentclass[answers,addpoints, 12pt, a4paper]{exam}

Exam compiled with XeLatex with solutions

Conclusion

LaTeX is a powerful tool for creating professional exams, offering flexibility in formatting, question types, and solutions. With the exam class, you can easily design multiple-choice, fill-in-the-blank, and direct-answer questions, all while maintaining a clean layout. By toggling the answers parameter, you can switch between student-ready exams and detailed solution sheets for distribution after the test. Whether you're preparing an exam for your class or a correction guide, LaTeX provides the tools you need to create polished, customizable documents with ease.

New School Year Resolutions: Tips for a Successful Start

2024-09-16T19:08:48+00:00

New School Year Resolutions: A Fresh Start for Success

As the new school year begins, it's a perfect opportunity to hit the reset button, set fresh goals, and embrace new challenges. Whether you're a student, a teacher, or even a parent, the start of a new academic year is like a blank canvas—full of potential and possibilities. Making resolutions at the start of the school year can help you stay focused, motivated, and ready to make the most of the months ahead.

Why Make New School Year Resolutions?

Just like New Year's resolutions, setting new goals for the school year provides direction and purpose. It helps you identify what you want to achieve, whether it's academic success, personal growth, or better relationships. Unlike the general resolutions we make in January, school year resolutions are closely tied to the academic calendar, making them more relevant and actionable for students and educators alike.

Popular School Year Resolutions

Improve Academic Performance

One of the most common resolutions is to do better academically. This might mean aiming for higher grades, dedicating more time to studying, or seeking help in subjects where you struggle. Setting specific and measurable goals, like spending an extra hour on homework each day or visiting a tutor weekly, can make this resolution more achievable.
Develop Better Study Habits

Many students resolve to improve their study habits. This could involve organizing study materials more efficiently, avoiding procrastination, or breaking large projects into manageable tasks. Creating a realistic study schedule that incorporates regular breaks and sticking to it can help you make steady progress throughout the year.
Get Involved in Extracurricular Activities

Participating in clubs, sports, or other activities outside of class is a great way to meet new people, learn new skills, and take a break from academic pressures. A resolution to try something new—like joining a debate team, playing a musical instrument, or volunteering—can lead to discovering passions you never knew you had.
Improve Time Management Skills

Time management is a valuable skill that can make a huge difference in both academic and personal life. Setting goals like waking up earlier, using planners or digital tools to track assignments and deadlines, or breaking tasks into smaller, more manageable parts can help you stay on top of things and reduce stress.
Enhance Physical and Mental Well-being

A resolution to prioritize health—both physical and mental—can significantly impact your school year. This might mean committing to regular exercise, eating healthier, or taking time for mindfulness or relaxation techniques. Remember, a healthy body and mind are the foundation for achieving all your other goals.
Build Positive Relationships

Creating a goal to make new friends, strengthen existing relationships, or build better connections with teachers can make the school year more enjoyable and fulfilling. Aim to be more open, communicative, and supportive to those around you. Remember, a good support network is crucial to overcoming the inevitable challenges of the academic year.
Stay Organized

Organization is key to a successful school year. Set a goal to keep your workspace tidy, organize your notes and files regularly, or use tools like planners and apps to keep track of assignments and commitments. Being organized can help you stay focused, reduce stress, and save time in the long run.

Tips for Sticking to Your Resolutions

Make Them Specific: Vague resolutions are easy to forget. Make sure your goals are specific, measurable, and time-bound. Instead of saying, "I want to study more," try "I will study for an extra hour every evening."
Break Them Down: Large goals can be intimidating. Break them down into smaller, manageable steps. Celebrate small victories along the way to stay motivated.
Stay Flexible: Life can be unpredictable, and sometimes your resolutions might need to adapt to new circumstances. Be open to adjusting your goals if necessary.
Track Your Progress: Keep a journal or use an app to monitor your progress. This will help you stay accountable and see how far you've come.
Seek Support: Share your resolutions with friends, family, or teachers who can encourage and support you. Sometimes, having someone to remind you of your goals can make all the difference.

Conclusion

As you embark on a new school year, take some time to reflect on what you want to achieve and set some meaningful resolutions. Remember, it's not just about setting goals but about creating a plan to achieve them. Embrace the new year with optimism and determination, and you'll find yourself not only achieving your resolutions but also growing in ways you never imagined. Here's to a successful and fulfilling school year ahead!

Debt as a Tool for Control: Implications for Developing Nations

2024-06-27T20:35:10+00:00

The Strategic Utility of Enormous Debts: A Tool for Control and Domination in International Relations

In the intricate landscape of international relations, the deliberate accumulation of substantial debts serves as a potent mechanism for exerting influence and control over developing nations. This strategy, meticulously employed by powerful states and international financial institutions, exemplifies a complex interplay of economic leverage and geopolitical maneuvering. As elucidated by John Perkins and other scholars, the process often unfolds through the provision of loans laden with stringent conditions and high interest rates, effectively ensnaring borrower countries in a cycle of dependency and vulnerability.

Unraveling the Dynamics of Debt Dependency

At its core, the strategy of indebting nations involves not only financial manipulation but also strategic manipulation of political and economic agendas. When governments in developing countries accept large loans under unfavorable terms, they face immense pressure to prioritize debt repayment over domestic developmental goals. This prioritization, often at the expense of social welfare and sustainable growth, perpetuates a cycle of economic stagnation and political instability.

The Dual Impact on Governance and Sovereignty

The ramifications of debt dependency extend beyond economic constraints to encompass profound implications for governance and sovereignty. Leaders, whether democratically elected or autocratic, confront heightened scrutiny and domestic dissent when loans intended for national development are mismanaged or misappropriated. Such instances undermine governmental legitimacy and weaken national sovereignty, as external creditors leverage financial leverage to dictate policy reforms and economic restructuring in their own favor.

The Calculated Role of External Actors

Donor countries and international financial institutions wield considerable influence in shaping the trajectories of debtor nations. By leveraging debt as a tool for conditional aid and financial assistance, external actors effectively steer domestic policy agendas towards market liberalization, privatization, and fiscal austerity measures. These reforms, while ostensibly aimed at debt relief and economic stability, often prioritize the interests of creditors and multinational corporations over local communities and social equity.

Resilience and Reform in the Face of Debt Burdens

Even in scenarios where competent and reform-minded leadership assumes power, the burden of unsustainable debts complicates efforts to implement substantive policy changes. Structural adjustment programs imposed by creditors, characterized by stringent austerity measures and privatization mandates, constrain governments' capacity to pursue inclusive development strategies and address pressing social challenges.

Insights from Critical Voices

John Perkins' seminal insights underscore the coercive nature of debt accumulation as a means of geopolitical control: "By enticing leaders with substantial loans destined for unsustainable projects or personal enrichment, creditor nations and financial institutions establish a cycle of dependency that transcends changes in leadership, effectively subjugating debtor nations to external agendas."

The Dark Side of Ad Targeting: Mind Manipulation in the Age of Social Media

2024-06-27T19:44:35+00:00

The Dark Side of Ad Targeting: Mind Manipulation in the Age of Social Media and IoT

In today's digital age, ad targeting has become a sophisticated tool, allowing companies to deliver personalized advertisements directly to users based on their online behavior, preferences, and demographic information. While this can enhance user experience by presenting relevant ads, it also raises concerns about privacy and mind manipulation. As the Internet of Things (IoT) continues to expand, these concerns are likely to grow, potentially exacerbating the effects of ad targeting on our thoughts and behaviors.

The Mechanisms of Ad Targeting

Ad targeting leverages vast amounts of data collected from users’ online activities. Social media platforms like Facebook, Instagram, and Twitter gather information about our likes, shares, and interactions, creating detailed profiles that advertisers can use to deliver tailored content. These platforms employ algorithms that analyze this data to predict our interests and behaviors, ensuring that the ads we see are highly relevant.

The Subtle Art of Mind Manipulation

While personalized advertising might seem benign, it can subtly influence our thoughts and decisions. By continuously exposing us to specific messages and content, social media platforms can shape our perceptions and behaviors. This phenomenon, often referred to as "nudging," can lead us to make choices that we might not have considered otherwise.

For example, during election cycles, targeted political ads can reinforce existing beliefs or sway undecided voters. Similarly, targeted ads for products can create a sense of need or desire, prompting us to make purchases we didn't initially intend to. This level of influence raises ethical concerns about the manipulation of our thoughts and decisions without our conscious awareness.

The Internet of Things: A New Frontier for Ad Targeting

As the Internet of Things (IoT) becomes mainstream, the potential for ad targeting to influence our minds grows exponentially. IoT devices, such as smart speakers, wearable technology, and connected home appliances, generate a wealth of data about our daily lives. This data includes not only our online behavior but also our physical activities, health metrics, and even our interactions with the physical world.

With access to such comprehensive data, advertisers can create even more precise profiles and deliver hyper-targeted ads. Imagine receiving ads based on your heart rate during a morning run, your sleep patterns, or your conversations with a smart assistant. The integration of IoT data with social media profiles can lead to an unprecedented level of personalization, making it increasingly difficult to distinguish between genuine choices and those influenced by targeted content.

Ethical Implications and the Need for Regulation

The potential for ad targeting to manipulate our minds highlights the urgent need for robust privacy regulations and ethical guidelines. Users should have greater control over their data and a clear understanding of how it is being used. Transparency from tech companies and advertisers is crucial to ensure that individuals can make informed decisions about their online activities.

Furthermore, the development and implementation of ethical AI practices are essential to prevent the misuse of ad targeting technologies. This includes setting boundaries on the extent of data collection, ensuring that targeted ads do not exploit vulnerable populations, and promoting fairness in algorithmic decision-making.

Conclusion

Ad targeting, while offering benefits in terms of personalized content and user experience, poses significant risks in terms of mind manipulation. As the Internet of Things becomes more integrated into our daily lives, these risks are likely to intensify. It is imperative for society to address these challenges through thoughtful regulation, ethical practices, and increased user awareness to ensure that the power of ad targeting is used responsibly and does not undermine our autonomy.

The Great Pyramid Mystery: How Were They Built?

2024-06-21T15:19:23+00:00

The Enduring Mystery of Pyramid Construction

The pyramids of Egypt, particularly the Great Pyramid of Giza, have fascinated historians, archaeologists, and tourists for centuries. Standing as testaments to ancient engineering prowess, these colossal structures continue to baffle modern scientists and researchers with the question: how were they built?

Ancient Engineering Marvels

Constructed during Egypt's Old Kingdom, around 2580-2560 BCE, the Great Pyramid of Giza is one of the most iconic symbols of ancient civilization. It was built as a tomb for the Pharaoh Khufu and originally stood at 146.6 meters (481 feet) tall. The precision and scale of its construction are astounding, especially considering the tools and technology available over 4,000 years ago.

Theories and Hypotheses

Over the years, numerous theories have been proposed to explain how the ancient Egyptians managed to construct these enormous structures. Some of the leading hypotheses include:

Ramp Systems: One of the most widely accepted theories is that the Egyptians used a series of ramps to transport the massive stone blocks into place. These ramps could have been straight, zigzagging, or circular, but each design presents its own set of logistical challenges.
Lever and Pulley Systems: Another theory suggests the use of levers and pulleys to lift and move the stones. While plausible, there is limited evidence to support the widespread use of such systems.
Water and Buoyancy: Some researchers propose that the Egyptians utilized water to move the stones, either by creating canals or using buoyancy to float the blocks into position. This idea, while intriguing, lacks substantial archaeological evidence.
Internal Spiral Ramps: A more recent theory suggests that the pyramids were built using internal spiral ramps. This would have allowed the builders to transport stones up the structure as it rose, without the need for massive external ramps.

Unanswered Questions

Despite these theories, many questions remain unanswered. For instance, how did the Egyptians achieve such precise alignments and measurements without modern tools? The Great Pyramid's sides are closely aligned to the cardinal points of the compass, and its construction exhibits a level of precision that rivals modern engineering standards.

Additionally, the logistics of quarrying, transporting, and assembling millions of limestone and granite blocks, some weighing up to 80 tons, continue to puzzle experts. The sheer manpower and organizational skills required for such an undertaking are difficult to comprehend.

Modern Research and Technology

In recent years, advancements in technology have allowed researchers to explore new avenues in solving the mystery. Ground-penetrating radar, 3D modeling, and other modern tools have provided new insights into the construction techniques and logistics of pyramid building. Yet, despite these advancements, a definitive explanation remains elusive.

The Legacy of the Pyramids

The pyramids stand as a symbol of human ingenuity and the enduring legacy of the ancient Egyptian civilization. They remind us of the incredible feats that can be achieved with determination, creativity, and a deep understanding of the natural world.

As we continue to explore and uncover the secrets of the past, the pyramids will undoubtedly remain one of history's greatest enigmas, inspiring wonder and curiosity for generations to come.

Doctor Who: The Longest-Running Sci-Fi Show Loved Worldwide

2024-06-19T17:20:22+00:00

Doctor Who: The Timeless Sci-Fi Saga That Continues to Captivate Millions

Since its debut in 1963, "Doctor Who" has stood the test of time, earning the title of the longest-running sci-fi TV show in history. Created by the BBC, this iconic series follows the adventures of the Doctor, a time-traveling alien with the ability to regenerate into a new form upon death. This unique concept has allowed the show to reinvent itself repeatedly, keeping it fresh and engaging for new generations of fans.

A Legacy of Innovation and Imagination

"Doctor Who" has always been at the forefront of innovation in television storytelling. The show's flexibility in its format has enabled it to explore a vast array of themes, from historical events to futuristic dystopias. The TARDIS, the Doctor's time-traveling spaceship, is as much a symbol of the show's limitless potential as it is a beloved icon in popular culture.

Over the decades, "Doctor Who" has introduced audiences to unforgettable characters, including the Doctor's many companions who provide a human perspective to the Doctor's alien adventures. Each incarnation of the Doctor, played by a different actor, brings a unique personality and style to the role, ensuring that the show remains dynamic and unpredictable.

Enduring Popularity Across Generations

What truly sets "Doctor Who" apart is its ability to maintain a devoted fanbase while continuously attracting new viewers. The show's blend of sci-fi, drama, and humor appeals to a wide audience, making it a cultural touchstone in the UK and around the world. From children to adults, "Doctor Who" has something for everyone, which explains its enduring popularity.

The Doctor's adventures have inspired a wide range of spin-offs, books, audio dramas, and merchandise, further expanding the Whovian universe. The show's influence can be seen in various aspects of popular culture, from references in other media to conventions dedicated entirely to celebrating all things "Doctor Who."

A Global Phenomenon

"Doctor Who" is not just a British phenomenon; it has a massive global following. The show's episodes are broadcast in numerous countries, and its international fanbase eagerly anticipates new episodes and special events. The Doctor's message of hope, resilience, and curiosity resonates universally, making the series a beloved part of global sci-fi culture.

Looking to the Future

As "Doctor Who" approaches its 60th anniversary, its legacy shows no signs of fading. The series continues to push boundaries, introducing new characters and exploring contemporary issues through the lens of sci-fi. With each regeneration, the Doctor brings fresh stories and perspectives, ensuring that "Doctor Who" remains relevant and exciting.

In a world where many TV shows come and go, "Doctor Who" stands out as a beacon of imaginative storytelling and enduring appeal. Loved by millions of fans across the globe, this timeless series continues to inspire and entertain, proving that in the vast expanse of time and space, the adventures of the Doctor are far from over.

Exploring Moroccan Mythology: From Aicha Kandicha to the Djinn

2024-06-19T16:52:30+00:00

Top 7 Moroccan Mythology, Folklore, Myths, and Legends

Morocco, a land of rich cultural heritage and history, boasts an array of captivating myths, legends, and folklore that have been passed down through generations. These stories reflect the diverse cultural tapestry of the country, blending Berber, Arab, and sub-Saharan African influences. Here are seven of the most intriguing Moroccan myths and legends:

1. Aicha Kandicha

Aicha Kandicha, also known as Lalla Aicha, is one of Morocco's most famous and feared supernatural figures. She is often described as a beautiful woman with long hair and an alluring appearance, but with the legs of a goat or camel. According to legend, Aicha Kandicha seduces men and leads them to their doom. Many stories tell of her taking revenge on those who have wronged her or her family. This myth serves as a cautionary tale, warning against the dangers of temptation and the unknown.

2. The Legend of Isli and Tislit

The story of Isli and Tislit is a Berber tale of two star-crossed lovers, often compared to Romeo and Juliet. Isli, a young man, and Tislit, a beautiful woman, fell deeply in love, but their families were sworn enemies. Unable to be together, they cried so much that their tears formed two lakes in the Atlas Mountains, named Isli and Tislit. This tragic love story symbolizes the power of love and the devastating impact of familial and societal conflict.

3. The Djinn of the Sahara

Djinn, supernatural beings made of smokeless fire, are a significant part of Islamic mythology and feature prominently in Moroccan folklore. In the vast and mysterious Sahara Desert, tales abound of djinn who can shape-shift, possess people, and create mirages to deceive travelers. These spirits are both feared and revered, often believed to inhabit deserted places and abandoned ruins. Stories of encounters with djinn serve to explain mysterious events and reinforce the belief in the unseen world.

4. The Treasure of the Red Mountain

In the Anti-Atlas region, there is a legend about a hidden treasure buried beneath a red mountain. According to the tale, a wealthy Berber king buried his immense treasure to protect it from invaders. The mountain is said to be guarded by spirits and can only be accessed by those who possess a pure heart and unwavering courage. Many have tried to find the treasure, but none have succeeded, making it a symbol of the elusive nature of wealth and the importance of virtue over material riches.

5. The Tale of Sidi Hmad Ou Moussa

Sidi Hmad Ou Moussa was a renowned Sufi saint and a respected healer in Morocco. He is often depicted as a wise and benevolent figure with miraculous powers. Legends tell of his ability to heal the sick, control the weather, and even communicate with animals. His shrine, located in the Souss region, is a pilgrimage site where people come to seek blessings and miracles. The tales of Sidi Hmad Ou Moussa highlight the deep spiritual and mystical traditions within Moroccan culture.

6. The Cemetery Mule

The legend of the Cemetery Mule, or "Boughirat al-Maqbarah," is a popular tale in Moroccan folklore. According to the story, this supernatural mule appears in cemeteries at night, terrifying those who dare to venture near. It is said to be the spirit of a person who committed grave sins during their lifetime and was transformed into a mule as punishment. The Cemetery Mule serves as a grim reminder of the consequences of immoral behavior and the importance of living a righteous life.

7. The Bought

The Bought is a mythological figure that represents a person who has made a pact with dark forces to gain supernatural abilities or wealth. These individuals are believed to possess extraordinary powers, but at a great cost, often involving the sacrifice of their soul or loved ones. The Bought is a cautionary tale about the dangers of greed and the moral compromises one might face in pursuit of power and riches.

Conclusion

These myths and legends are not just stories; they are a reflection of Moroccan culture, values, and the collective imagination of its people. They offer insights into the fears, hopes, and dreams of generations past and continue to be a source of fascination and inspiration for many. Whether cautionary tales, love stories, or accounts of supernatural beings, these narratives are an integral part of Morocco's rich cultural heritage.

Iconic Buffy the Vampire Slayer Moments You Must Know

2024-06-18T21:03:23+00:00

The 8 Buffy The Vampire Slayer Moments That Defined The Show

"Buffy the Vampire Slayer," created by Joss Whedon, remains one of the most iconic television series of the late '90s and early 2000s. With its unique blend of horror, humor, and heartfelt moments, the show has left an indelible mark on popular culture. Here are eight defining moments that encapsulated the essence of the series.

1. Buffy's Sacrifice in "The Gift" (Season 5, Episode 22)

Buffy's selfless act of jumping into the portal to save the world showcased her growth as a character and her unwavering dedication to her role as the Slayer. This poignant moment underscored the show's themes of sacrifice and heroism.

2. The Introduction of Spike (Season 2, Episode 3)

Spike's arrival in Sunnydale brought a new dynamic to the show. With his charisma and complexity, he quickly became a fan favorite. His relationship with Buffy, evolving from adversaries to allies to lovers, added depth and intrigue to the series.

3. Angel's Transformation into Angelus (Season 2, Episode 14)

When Angel loses his soul and becomes the evil Angelus, the stakes are raised dramatically. This twist not only deepened Buffy's personal struggle but also highlighted the show's ability to blend romance with horror seamlessly.

4. The Musical Episode "Once More, with Feeling" (Season 6, Episode 7)

This groundbreaking episode brought a unique twist to the series, using song and dance to explore the characters' inner emotions and unresolved issues. It remains a standout for its creativity and emotional resonance.

5. Willow's Descent into Darkness (Season 6, Episode 20)

Willow's transformation into Dark Willow after the tragic death of her girlfriend Tara showcased the show's willingness to tackle heavy themes such as grief, addiction, and the consequences of power. Her struggle and eventual redemption were pivotal to the series' narrative.

6. Buffy vs. The Master (Season 1, Episode 12)

Buffy's first major battle against the ancient vampire, The Master, set the tone for the series. Her initial defeat and subsequent resurrection symbolized her resilience and the beginning of her journey as the Slayer.

7. The Body (Season 5, Episode 16)

This critically acclaimed episode dealt with the sudden and natural death of Buffy's mother, Joyce. Its raw and unflinching portrayal of grief and loss was a departure from the show's usual supernatural themes, making it one of the most powerful episodes in television history.

8. Buffy's Empowerment Speech in "Chosen" (Season 7, Episode 22)

In the series finale, Buffy's decision to share her Slayer power with potentials around the world was a fitting conclusion to her journey. This moment of empowerment and unity reflected the show's enduring message of strength and solidarity.

These moments are just a glimpse into the rich tapestry of "Buffy the Vampire Slayer." Each one contributed to the show's legacy, making it a beloved and timeless part of television history.

How to Download Facebook and Instagram Videos with SnapTube

2024-06-14T21:07:23+00:00

How to Download Facebook and Instagram Videos and Reels Using SnapTube

Downloading videos and reels from social media platforms like Facebook and Instagram can be a convenient way to save content for offline viewing. SnapTube is a popular app that allows users to easily download videos from these platforms. Here’s a comprehensive guide on how to use SnapTube to download videos and reels from Facebook and Instagram.

Step-by-Step Guide

1. Download and Install SnapTube

For Android Users:

Visit the SnapTube official website or a trusted app store, as SnapTube is not available on Google Play due to Google’s policies.
Download the SnapTube APK file.
Navigate to your phone's settings and enable installations from unknown sources.
Install the APK file.

For iOS Users:

SnapTube is not available for iOS. iOS users might need to look for alternative apps or use web-based downloaders.

2. Set Up SnapTube

Open the SnapTube app after installation.
Grant the necessary permissions for the app to function correctly.

3. Downloading Videos from Facebook

Method 1: Using SnapTube's Built-In Browser

Open SnapTube and navigate to Facebook using the built-in browser.
Log in to your Facebook account.
Find the video you want to download.
Tap on the download button that appears on the video.
Choose the desired resolution and format, then tap to download.

Method 2: Copy and Paste URL

Open the Facebook app or website and find the video you want to download.
Copy the video URL.
Open SnapTube and paste the URL into the search bar.
Tap the download button, select the desired format and resolution, and download the video.

4. Downloading Videos and Reels from Instagram

Method 1: Using SnapTube's Built-In Browser

Open SnapTube and navigate to Instagram using the built-in browser.
Log in to your Instagram account.
Find the video or reel you want to download.
Tap on the download button that appears on the video.
Choose the desired resolution and format, then tap to download.

Method 2: Copy and Paste URL

Open the Instagram app or website and find the video or reel you want to download.
Copy the video or reel URL.
Open SnapTube and paste the URL into the search bar.
Tap the download button, select the desired format and resolution, and download the video or reel.

5. Accessing Downloaded Videos

After downloading, all videos and reels can be accessed directly from the SnapTube app.
Navigate to the “My Files” or “Downloads” section within SnapTube to view your downloaded content.
You can also find the downloaded videos in your phone’s gallery or file manager, depending on your device’s configuration.

Tips for Using SnapTube

Update Regularly: Ensure that SnapTube is regularly updated to enjoy new features and improvements.
Wi-Fi Connection: Use a Wi-Fi connection for downloading larger files to avoid excessive data usage.
Legal Considerations: Respect copyright laws and platform policies when downloading content. Download only for personal use unless you have permission from the content creator.

Conclusion

SnapTube provides a simple and effective solution for downloading videos and reels from Facebook and Instagram. By following the steps outlined above, users can easily save their favorite content for offline viewing. Always ensure you use the app responsibly and respect copyright laws when downloading and sharing videos.

Manual Order of References in LaTeX

2024-06-06T17:48:46+00:00

In LaTeX, managing the order of references can be crucial for certain types of documents. While BibTeX automates citation management, there are situations where you might want to manually control the order of your references. This article will guide you on how to manually order references in LaTeX.

Why Manual Ordering?

Manual ordering of references might be necessary when:

You have specific requirements from a publisher or institution.
You want to highlight certain references by placing them in a particular order.
You are preparing a simple document with only a few references.

Creating a Manually Ordered Bibliography

Instead of relying on BibTeX, you can manually list your references using the thebibliography environment. Here’s how:

Example LaTeX File (`main.tex`)

    

\documentclass{article}
\usepackage[utf8]{inputenc}

\begin{document}

\title{Sample Document with Manually Ordered References}
\author{Author Name}
\date{\today}

\maketitle

\section{Introduction}
This document cites multiple sources \cite{goossens97}, \cite{lamport94}, \cite{knuth84}, \cite{greenwade93}, \cite{patashnik88}.

\begin{thebibliography}{9}

\bibitem{goossens97}
Michel Goossens, Frank Mittelbach, and Alexander Samarin.
\textit{The \LaTeX\ Companion}.
Addison-Wesley, 1997.

\bibitem{lamport94}
Leslie Lamport.
\textit{\LaTeX: A Document Preparation System}.
Addison-Wesley, 1994.

\bibitem{knuth84}
Donald E. Knuth.
\textit{The \TeX book}.
Addison-Wesley, 1984.

\bibitem{greenwade93}
George D. Greenwade.
"The Comprehensive \TeX\ Archive Network (CTAN)."
\textit{TUGBoat}, 14(3):342--351, 1993.

\bibitem{patashnik88}
Oren Patashnik.
\textit{BibTeXing}.
Oren Patashnik, 1988.

\end{thebibliography}

\end{document}

Steps to Compile

Since this method does not use BibTeX, compiling the document is straightforward:

Run pdflatex main.tex to generate the PDF file directly.

Advantages and Disadvantages

Advantages:

Full control over the order of references.
No need to manage an additional BibTeX file.
Simpler for documents with few references.

Disadvantages:

Less automation, which can lead to more manual work and errors.
Not suitable for documents with many references.
More difficult to maintain if references need to be added or removed frequently.

Conclusion

Manually ordering references in LaTeX is a straightforward process that provides precise control over how references appear in your document. While this method is less automated than using BibTeX, it is beneficial for specific use cases where order and simplicity are important.

How to Use plain and unsrt Bibliography Styles in LaTeX

2024-06-06T17:38:17+00:00

LaTeX provides a powerful way to manage bibliographies using BibTeX. Two common bibliography styles are `plain` and `unsrt`. This article will demonstrate how to use both styles in your LaTeX documents.

Using the `plain` Style

The `plain` style sorts the references alphabetically by the author's last name. Here's an example:

LaTeX File (`main.tex`)

    

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage{cite}

\begin{document}

\title{Sample Document}
\author{Author Name}
\date{\today}

\maketitle

\section{Introduction}
This document cites multiple sources \cite{goossens97, lamport94, knuth84, greenwade93, patashnik88}.

\bibliographystyle{plain}
\bibliography{references}

\end{document}

BibTeX File (`references.bib`)

    

@book{patashnik88,
  author    = "Oren Patashnik",
  title     = "BibTeXing",
  year      = "1988",
  publisher = "Oren Patashnik",
  address   = "Stanford, California"
}

@book{lamport94,
  author    = "Leslie Lamport",
  title     = "LaTeX: A Document Preparation System",
  year      = "1994",
  publisher = "Addison-Wesley",
  address   = "Reading, Massachusetts"
}

@book{knuth84,
  author    = "Donald E. Knuth",
  title     = "The TeXbook",
  year      = "1984",
  publisher = "Addison-Wesley",
  address   = "Reading, Massachusetts"
}

@book{goossens97,
  author    = "Michel Goossens and Frank Mittelbach and Alexander Samarin",
  title     = "The LaTeX Companion",
  year      = "1997",
  publisher = "Addison-Wesley",
  address   = "Reading, Massachusetts"
}

@article{greenwade93,
  author    = "George D. Greenwade",
  title     = "The {C}omprehensive {T}e{X} {A}rchive {N}etwork ({CTAN})",
  year      = "1993",
  journal   = "TUGBoat",
  volume    = "14",
  number    = "3",
  pages     = "342--351"
}

In the document above, the bibliography will be sorted alphabetically by the authors' last names.

Latex Bibliography ordered alphabetically

Using the `unsrt` Style

The `unsrt` style lists references in the order they are cited in the document. Here's how to use it:

LaTeX File (`main.tex`)

    

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage{cite}

\begin{document}

\title{Sample Document}
\author{Author Name}
\date{\today}

\maketitle

\section{Introduction}
This document cites multiple sources \cite{goossens97, lamport94, knuth84, greenwade93, patashnik88}.

\bibliographystyle{unsrt}
\bibliography{references}

\end{document}

BibTeX File (`references.bib`)

    

@book{patashnik88,
  author    = "Oren Patashnik",
  title     = "BibTeXing",
  year      = "1988",
  publisher = "Oren Patashnik",
  address   = "Stanford, California"
}

@book{lamport94,
  author    = "Leslie Lamport",
  title     = "LaTeX: A Document Preparation System",
  year      = "1994",
  publisher = "Addison-Wesley",
  address   = "Reading, Massachusetts"
}

@book{knuth84,
  author    = "Donald E. Knuth",
  title     = "The TeXbook",
  year      = "1984",
  publisher = "Addison-Wesley",
  address   = "Reading, Massachusetts"
}

@book{goossens97,
  author    = "Michel Goossens and Frank Mittelbach and Alexander Samarin",
  title     = "The LaTeX Companion",
  year      = "1997",
  publisher = "Addison-Wesley",
  address   = "Reading, Massachusetts"
}

@article{greenwade93,
  author    = "George D. Greenwade",
  title     = "The {C}omprehensive {T}e{X} {A}rchive {N}etwork ({CTAN})",
  year      = "1993",
  journal   = "TUGBoat",
  volume    = "14",
  number    = "3",
  pages     = "342--351"
}

In the document above, the bibliography will be listed in the order the references are cited in the text.

Latex Bibliography ordered from bib file

Compiling the Document

To compile your LaTeX document with BibTeX, follow these steps:

Run pdflatex main.tex to generate an initial `.aux` file.
Run bibtex main.aux to generate the bibliography.
Run pdflatex main.tex twice more to update references and generate the final document.

By using these steps and styles, you can control the order of your bibliography entries in LaTeX documents. Choose `plain` for alphabetical order or `unsrt` for citation order.

Why You Should Switch to Linux

2024-06-05T19:10:12+00:00

In the three decades since its inception, Linux has steadily grown from an obscure operating system used by a niche group of enthusiasts to a dominant force in the realm of servers and mobile devices. Today, Linux powers over 70% of the world's smartphones and servers, showcasing its robustness and reliability. However, its adoption on desktop computers remains relatively modest, with a market share of around 4%. Despite this, recent years have witnessed a resurgence in interest and development within the Linux ecosystem, making it more user-friendly and accessible than ever before.

Linux Today: A Mature and Versatile Ecosystem

Gone are the days when setting up wireless, Bluetooth, and printer devices on Linux was a frustrating ordeal. Today, most hardware works seamlessly with Linux, often requiring no more than a simple plug-and-play setup. The software landscape has also evolved significantly. Many popular applications now have native Linux versions, and where they don’t, robust alternatives or compatibility layers, such as Wine and Proton, fill the gap. Gaming on Linux, once a major hurdle, has seen substantial improvements thanks to platforms like Steam Play, which allow many Windows games to run on Linux with minimal hassle.

The Dark Cloud Over Windows

While Linux is on an upward trajectory, the future of Windows raises serious privacy concerns. Microsoft recently announced its “Copilot+ PC” initiative, a suite of powerful laptops designed to leverage the latest advancements in artificial intelligence, particularly the GPT-4o model from OpenAI. This model boasts impressive vision and audio capabilities, enabling real-time interactions that are deeply integrated into the operating system.

One of the most alarming features introduced with this update is “Recall,” which takes periodic screenshots of your screen, ostensibly to help you retrieve information and activities from your past sessions. This feature records all your digital interactions, from typing passwords to browsing family photos, watching movies, and managing anonymous online accounts. Essentially, it captures a comprehensive log of your digital life.

The Privacy Nightmare

The implications of such pervasive monitoring are profound. Even if Microsoft assures users that this feature is opt-in and that privacy protections are in place, the potential for misuse and security breaches is immense. Imagine a world where every keystroke, every private moment spent on your computer, is recorded and stored. This isn't just a hypothetical scenario; it's a looming reality that Microsoft seems eager to normalize.

Why You Should Consider Linux

In light of these developments, the case for switching to Linux becomes compelling not just from a feature standpoint, but from a privacy perspective as well. Linux, with its open-source nature, offers transparency and control over your operating system that proprietary software simply cannot match. You decide what gets installed, what gets tracked, and how your data is handled. This level of control is crucial in an era where privacy is increasingly under threat.

Switching to Linux might seem daunting if you're accustomed to the Windows ecosystem, but the transition is easier than you might think. Modern Linux distributions like Ubuntu, Fedora, and Manjaro provide user-friendly interfaces and extensive online support communities. Additionally, many of the tools and applications you rely on are either available on Linux or have suitable alternatives.

Conclusion

The technological landscape is evolving rapidly, and with it, the norms and expectations around privacy and user control. Microsoft's latest moves with Windows highlight a future where convenience and AI integration come at the cost of personal privacy. By contrast, Linux offers a path that prioritizes user autonomy and security. As the digital world becomes more intrusive, embracing Linux isn't just a choice of operating system—it's a stand for privacy and control in an increasingly monitored world.

How to Create an ISO from a Directory in Linux

2024-06-03T23:13:29+00:00

Creating an ISO image from a directory in Linux can be done using the mkisofs or genisoimage command. Follow these steps:

1. Install mkisofs or genisoimage

If you don't have mkisofs or genisoimage installed, you can install it using your package manager. For most Linux distributions, the package is named genisoimage.

For Debian-based distributions (like Ubuntu):



sudo apt-get install genisoimage

For Red Hat-based distributions (like Fedora):



sudo yum install genisoimage

2. Create the ISO

Use the mkisofs or genisoimage command to create the ISO. The basic syntax is:



mkisofs -o output.iso /path/to/directory



genisoimage -o output.iso /path/to/directory

Example:



mkisofs -o mydisk.iso /home/user/myfolder



genisoimage -o mydisk.iso /home/user/myfolder

3. Additional Options

You can use various options with mkisofs or genisoimage to customize the ISO creation process. Some common options include:

-V "Volume Label": Sets the volume label.
-R: Enables Rock Ridge extensions, which are useful for retaining file permissions and longer filenames.
-J: Enables Joliet extensions, which allow the ISO to be read by Windows systems.

Example with additional options:



mkisofs -o mydisk.iso -V "MY_DISK" -R -J /home/user/myfolder



genisoimage -o mydisk.iso -V "MY_DISK" -R -J /home/user/myfolder

After running the command, you will have an ISO file named output.iso (or mydisk.iso in the examples) that contains the contents of the specified directory.

The Impact of Capitalism on Marriage and Family Dynamics

2024-06-01T20:45:27+00:00

Women often believe that if they serve their family, they are failures, while if they serve strangers in revealing clothing, they are successful employees achieving their independence and freedom. They are willing to endure humiliation and degradation from their boss at work, but refuse to fulfill their husband's requests, considering them unacceptable control and domination.

Liberal thought, capitalist ideology, and radical feminism have successfully brainwashed women, stripping them of religious values, moral principles, and societal norms that contribute to family cohesion like a well-structured building. Instead, they have implanted individualism, selfishness, and narcissism.

An illustrative example of this shift in values is a conversation between a woman and her friend: the woman said, "I can't tolerate his demands every day." Her friend replied, "Divorce him; there are plenty of men like him." The woman responded, "No, my friend, he is my boss at work." The friend then said, "Be patient, that's your job." This example shows how the institution of marriage has become in the capitalist world, where work and loyalty to companies are valued over marital relationships. Patience and sacrifice at work are mandatory, while understanding and compromise in marriage are disregarded or undervalued.

This is primarily due to the dominance of market values that prioritize materialism over spirituality, transforming society from compassion to contracts. Nowadays, women view men merely as sperm donors rather than nurturers, as financial providers rather than guides and mentors, and as saviors from spinsterhood rather than companions.

Consequently, the pressure on men has become unimaginably intense in our modern era. To gain a woman's approval, a man cannot be ordinary, average, and simple like his contented ancestors and distinguished forefathers. Instead, he must be at the highest material and social levels in his environment, especially since the more a woman advances in her education and career, the higher her demands become. She does not want a man at her level, let alone a man beneath her.

What exacerbates the situation is the fierce competition among women and their cousins and friends over who will win the wealthiest and most prestigious man in their area. Women boast about the value of their dowry, the size of their wedding, the honeymoon location, the quality of purchases and gifts from the husband, the residence location, and the type of car, among other things. Unfortunately, this reality displeases many women.

In the end, it clearly shows how capitalism has affected familial relationships, highlighting the urgent need to reconsider these values and restore balance between work and family life to ensure family cohesion and societal stability.

How Small Daily Habits Lead to Big Changes Over Time

2024-05-31T20:39:56+00:00

Abstract

In the realm of personal development and fitness, the compounding effect of small, consistent actions over time is often underestimated. Using the mathematical principles illustrated by the expressions 1^365 = 1 and 1.01^365 ≈ 37.78, this article elucidates the substantial long-term benefits that can arise from seemingly insignificant daily improvements. This principle can be applied to various aspects of life, including physical fitness, skill acquisition, and overall personal growth.

Introduction

The mathematical expressions 1^365 = 1 and 1.01^365 ≈ 37.78 serve as powerful metaphors for understanding the cumulative effect of incremental progress. The number 1 represents a constant, indicating no change, while 1.01 signifies a 1% improvement. Over the course of a year, these small daily enhancements compound, resulting in a dramatic difference in the outcome.

Mathematical Foundation

To understand the profound impact of small improvements, consider the mathematical function of exponential growth. The formula
A = P(1 + r)^t
describes the future value (A) of an initial quantity (P) subjected to a growth rate (r) over time (t). In the context of personal improvement:

P = 1
r = 0.01 (1% daily improvement)
t = 365 days

Applying these values:

1.01^{365} ≈ 37.78

This indicates that a 1% daily improvement results in a factor of approximately 37.78 over one year. Conversely, maintaining the status quo with no improvement (1^365 = 1) yields no change.

Practical Implications

Physical Fitness

Daily Exercise: Engaging in a small amount of physical activity, such as a 10-minute walk or a few push-ups each day, can lead to significant health benefits over time. A 1% daily improvement in physical activity could substantially enhance cardiovascular health, muscle strength, and overall fitness by the end of the year.

Skill Acquisition

Learning and Development: Allocating just a few minutes each day to learn a new skill or improve an existing one can lead to mastery over time. For instance, practicing a musical instrument for 15 minutes daily or dedicating time to language learning can result in significant proficiency due to the cumulative effect of consistent practice.

Personal Growth

Habits and Behaviors: Small daily changes in habits, such as reading a few pages of a book, practicing mindfulness, or improving diet choices, can lead to substantial personal growth. Over a year, these minor adjustments can transform one's lifestyle and overall well-being.

Conclusion

The principle of compounding improvements, exemplified by the expressions 1^365 = 1 and 1.01^365 ≈ 37.78, underscores the importance of small, consistent actions. By embracing incremental progress, individuals can achieve remarkable transformations in various aspects of their lives. The key lies in the commitment to daily improvement, no matter how trivial it may seem. Over time, these small changes accumulate, leading to significant and lasting benefits.

MiXplorer for Android: The Best Free, Ad-Free File Manager

2024-05-31T11:48:52+00:00

In the vast world of Android file management, MiXplorer stands out as a powerful, feature-rich file explorer that caters to both casual users and advanced enthusiasts. Developed by HootanParsa, MiXplorer offers a comprehensive suite of tools that make file management seamless and efficient. In this article, we will explore MiXplorer's best features and how they enhance the user experience.

MiXplorer is a completely free file manager for Android that offers a premium experience without any ads whatsoever. This means you can enjoy all its powerful features without interruptions, making it a top choice for users who value a clean and ad-free interface.

1. User-Friendly Interface

MiXplorer user interface menu

MiXplorer boasts an intuitive and customizable interface that makes navigating through files a breeze. Users can choose from various themes, icon sets, and layout options to tailor the app's appearance to their liking. The interface is clean and clutter-free, allowing users to focus on their tasks without unnecessary distractions.

2. Powerful File Management Tools

Multi-Tab Browsing

One of MiXplorer’s standout features is its multi-tab browsing capability. Similar to a web browser, users can open multiple tabs and switch between different directories seamlessly. This feature is especially useful for multitasking and comparing files across different folders.

Drag and Drop

MiXplorer supports drag-and-drop functionality, making it easy to move or copy files between folders. This feature simplifies file organization and speeds up workflow, particularly when handling large amounts of data.

Advanced Search Function

Finding specific files in a sea of data can be challenging. MiXplorer’s advanced search function allows users to locate files quickly by specifying criteria such as file type, size, date modified, and more. This precision saves time and enhances productivity.

3. Comprehensive File Support

MiXplorer supports a wide range of file types, including common formats like ZIP, RAR, and 7z. It also integrates with various cloud storage services such as Google Drive, Dropbox, and OneDrive, allowing users to manage local and cloud files from a single interface.

Built-in Media Player and Text Editor

For added convenience, MiXplorer includes a built-in media player and text editor. Users can play videos, listen to music, and edit text files without needing to switch to other apps. This integration streamlines the user experience and reduces the need for multiple applications.

4. Enhanced Security Features

MiXplorer takes file security seriously. It offers robust encryption options to protect sensitive data. Users can encrypt individual files or entire folders, ensuring that their information remains secure. Additionally, MiXplorer supports fingerprint authentication, adding an extra layer of security to prevent unauthorized access.

5. Customization and Add-ons

Customizable Toolbars and Buttons

Users can customize MiXplorer's toolbars and buttons to fit their workflow. This flexibility allows for a more personalized experience, making it easier to access frequently used functions.

MiXplorer is Highly Customizable

Add-ons and Extensions

MiXplorer supports various add-ons and extensions that extend its functionality. Whether you need additional codec support for media files or integration with other apps, MiXplorer’s add-ons can enhance its capabilities to meet specific needs.

6. Batch Operations and Automation

Batch File Management

Handling multiple files at once can be tedious, but MiXplorer’s batch operations simplify this process. Users can select multiple files and perform actions such as moving, copying, deleting, or renaming them simultaneously. This feature is a time-saver for those who manage large datasets regularly.

Task Automation

MiXplorer also supports task automation through scripting. Users can create scripts to automate repetitive tasks, further enhancing efficiency and productivity.

7. Root Access and Advanced Options

For advanced users, MiXplorer provides root access, allowing for deeper system file management. This feature is particularly useful for those who want to modify system files or perform advanced operations. Additionally, MiXplorer offers a range of advanced settings and options, giving users full control over their file management experience.

Conclusion

MiXplorer is more than just a file manager; it's a comprehensive tool that caters to the diverse needs of Android users. With its user-friendly interface, powerful file management tools, extensive file support, and advanced features, MiXplorer sets a high standard in the realm of file explorers. Whether you are a casual user looking for a reliable file manager or a power user in need of advanced functionalities, MiXplorer is an excellent choice that won't disappoint.

Explore MiXplorer today and experience the difference a well-designed file manager can make in your daily Android usage.

How to Use setfacl and getfacl: A Step-by-Step Guide

2024-05-25T15:33:25+00:00

Introduction to ACLs

Access Control Lists (ACLs) are used to provide more fine-grained permissions for files and directories than the traditional Unix permissions (read, write, execute). They allow you to specify permissions for individual users or groups.

setfacl and getfacl

setfacl is used to set ACLs on files and directories.
getfacl is used to retrieve ACLs from files and directories.

Basic Syntax

setfacl



setfacl [options] acl_spec file...

getfacl



getfacl [options] file...

Setting ACLs with setfacl

Basic Usage

To add an ACL entry:



setfacl -m u:username:permissions file

-m: Modify the ACL.
u:username:permissions: Specify the user (u), the username, and the permissions (r, w, x).

Example:



setfacl -m u:john:rwx myfile

This grants user john read, write, and execute permissions on myfile.

Setting ACLs for Groups



setfacl -m g:groupname:permissions file

Example:



setfacl -m g:admins:rw myfile

This grants the group admins read and write permissions on myfile.

Setting Default ACLs on Directories



setfacl -d -m u:username:permissions directory

Example:



setfacl -d -m u:john:rwx mydir

This sets default permissions for john on the directory mydir.

Removing ACL Entries

To remove an ACL entry:



setfacl -x u:username file

Example:



setfacl -x u:john myfile

This removes the ACL entry for user john on myfile.

To remove all ACL entries:



setfacl -b file

Example:



setfacl -b myfile

This removes all ACL entries from myfile.

Viewing ACLs with getfacl

To view the ACLs on a file or directory:



getfacl file

Example:



getfacl myfile

This outputs the ACLs for myfile.

Example Output



# file: myfile
# owner: root
# group: root
user::rw-
user:john:rwx
group::r--
mask::rwx
other::r--

user::rw- - Permissions for the file owner.
user:john:rwx - Specific permissions for user john.
group::r-- - Permissions for the owning group.
mask::rwx - The effective rights mask.
other::r-- - Permissions for others.

Recursive ACLs

To apply ACLs recursively to all files and directories within a directory:



setfacl -R -m u:username:permissions directory

Example:



setfacl -R -m u:john:rwx mydir

This applies the ACL for john recursively within mydir.

Preserving Existing ACLs

To add or modify ACL entries without affecting existing ones, use the -n option with setfacl.



setfacl -n -m u:username:permissions file

Example:



setfacl -n -m u:john:rwx myfile

Conclusion

ACLs provide a powerful way to manage permissions on a more granular level than standard Unix permissions. Using setfacl, you can set and modify ACLs, while getfacl allows you to view them. This capability is especially useful in environments where multiple users or groups need specific access to files and directories.

How to Be Cautious Without Isolation: Lessons from the Quran and Hadith

2024-05-24T10:06:01+00:00

Praise be to the Prudent for their Astuteness

Avoiding evils and being cautious of them is among the finest qualities, and it is something all creatures are naturally inclined to do. This is an undeniable fact. However, the evils that many people may not pay attention to are those of the future, because they do not know the unseen that the days and nights hold. This is also natural. But Allah Almighty has placed signs in this universe that guide to the path of goodness and the path leading to other than it. He then called us to pursue goodness and avoid evil. He commanded caution, saying:

"O you who have believed, take your precaution"

And also said:

"O you who have believed, protect yourselves and your families from a Fire whose fuel is people and stones"

Hudhayfah ibn al-Yaman, may Allah be pleased with him, said: "People used to ask the Messenger of Allah about good, and I used to ask him about evil for fear that it might overtake me."

Caution should not be understood as fleeing from reality, as this is the worst state a person can fall into. The Prophet, peace be upon him, said:

"The believer who mixes with people and endures their harm is better than the believer who does not mix with people and does not endure their harm."

Anatole France said: "It is not the pure hearts that avoid the rain, but those that carry umbrellas." This is the intended meaning of caution, not withdrawal and isolation, or shunning and seclusion, as these are merely psychological complexes. True caution is to participate while being alert and vigilant. Sulayman ibn Wahb said: "Associate with people as you would with fire; take its benefit and beware of being burned." Abd al-Qadir al-Maghribi said: "He who stays away from water does not get wet."

Avoidance and caution signify a person's intelligence, acumen, alertness, and awareness. If it were not so, people would think all are pure angels, not knowing that among them are wolves in sheep's clothing. The poet encourages caution and avoidance, saying:

"If you avoid a matter from where it should be avoided
And see what you do, then you are wise."

One should not exceed the limit in caution, as that would be reprehensible fear, not stemming from wisdom. The best course is moderation, without underestimating or exaggerating. Aristotle said: "Excessive caution is the first resource of fear." Florian said: "Caution is good in itself, but overdoing it is a mirage." Moreover, caution should not lead one to abandon reliance on and trust in Allah in doing and abstaining from actions. Praise be to al-Sharif al-Radi who said:

"If you fear a matter, then hurry
Return to a Lord who protects you from fears."

When appropriate to one’s circumstances, caution has numerous benefits, such as avoiding falling into the traps of deceivers. Mazzini said: "When we are cautious, we may err, but we do not get deceived."
The ultimate caution a person should have is not to fall prey to the cunning and deceitful. The way to escape them is through vigilance and caution. As the saying goes: "An ounce of prevention is worth a pound of cure." Luqman the Wise said: "The most prudent of those who are prudent is the one who knows the matter before it happens and takes precautions."

One should not remain neutral in the face of clear evil and evident harm, as this is a trait of the hypocrites. If they imagine that they are safe from the clutches of evil and its stings, they are indeed deluded in their thinking.
To be continued.
Abd al-Razzaq al-Sadiqi

The Ten Strategies for Controlling Populations by Noam Chomsky

2024-05-22T18:54:55+00:00

The Ten Strategies for Controlling the Masses

- Professor Noam Chomsky

In January 2011, Chomsky compiled a list of methods used by global media to control the masses through ten basic strategies:

1. Distraction Strategy

This strategy is a key element in controlling societies. It involves diverting public attention from important issues and changes decided by the political and economic elites through a continuous flood of distractions and trivial information. The distraction strategy is also essential to prevent the public from gaining important knowledge in fields like science, economics, psychology, neurobiology, and computer science. "Keep the public's attention distracted away from the real social issues, directed towards topics with no real importance. Keep the public busy, busy, busy, without any time to think, until they return to the farm with the other animals." (Excerpt from the book "Silent Weapons for Quiet Wars")

2. Create Problems, Then Offer Solutions

This method is also known as "problem - reaction - solution". First, a problem or "situation" is created to elicit a specific reaction from the public, so that they will demand the measures you want them to accept. For example: allowing urban violence to escalate, or organizing bloody bombings, so that the public demands security laws at the expense of their freedom; or creating a financial crisis to make the public accept the degradation of social rights and the deterioration of public services as a necessary evil.

3. Gradual Strategy

To get an unacceptable measure accepted, it is enough to apply it gradually, in degrees, over a period of 10 years. This method was adopted to impose new socio-economic conditions between the 1980s and 1990s: widespread unemployment, precariousness, flexibility, outsourcing, and wages that do not guarantee a decent living. These changes would have led to a revolution if applied all at once.

4. Deferred Strategy

Another way to gain acceptance for unpopular decisions is to present them as "painful but necessary" and to get public consent for future sacrifices. Acceptance of a future sacrifice is always easier than an immediate one. First, because the effort will not be made immediately, and second, because the public always tends to hope naively that "everything will be better tomorrow" and that the sacrifice required may be avoided in the future. Finally, this gives the public time to get used to the idea of change and accept it with resignation when the time comes.

5. Treat the Public Like Children

Most advertising aimed at the general public uses arguments, characters, and tones that are childish, often approaching the level of mental retardation, as if the viewer were a small child or mentally disabled. The more we try to deceive the viewer, the more we adopt that tone. Why? "If we address a person as if they were 12 years old, then, due to suggestion, they will have a reaction or response that is as devoid of critical sense as that of a 12-year-old." (Excerpt from the book "Silent Weapons for Quiet Wars")

6. Appeal to Emotion Rather than Thought

A classic technique to disable logical analysis and critical thinking. The use of emotional vocabulary allows the passage to the subconscious to implant ideas, desires, fears, impulses, or behaviors.

7. Keep the Public in Ignorance and Mediocrity

Making the public incapable of understanding the technologies and methods used to control and enslave them. "The quality of education provided to the lower classes must be the poorest, so that the knowledge gap that isolates the lower classes from the upper classes remains incomprehensible to the lower classes." (Excerpt from the book "Silent Weapons for Quiet Wars")

8. Encourage the Public to Accept Mediocrity

Encouraging the public to believe that it is fashionable to be stupid, vulgar, and uneducated.

9. Replace Rebellion with Guilt

Making individuals believe that they are solely responsible for their misfortune, due to the inadequacy of their intelligence, abilities, or efforts. Thus, instead of rebelling against the economic system, individuals blame themselves, feel guilty, and become depressed, which leads to a state of passivity and lack of action. Without action, there is no revolution!

10. Know Individuals Better Than They Know Themselves

Over the past 50 years, scientific advances have created a widening gap between public knowledge and the knowledge possessed and used by the ruling elites. With the help of biology, neurobiology, and applied psychology, the "system" has reached an advanced understanding of human beings, both physically and psychologically. This means that the system, in most cases, has more control over individuals than individuals have over themselves.

Best Tools for SSD Health Monitoring on Windows

2024-05-21T20:33:18+00:00

How to Check SSD Health and Information in Windows

Solid State Drives (SSDs) are essential for modern computers, providing faster data access and improved performance over traditional Hard Disk Drives (HDDs). Regular monitoring of SSD health is crucial to ensure longevity and optimal performance. This article will guide you through the best tools available for checking SSD health and retrieving relevant information on a Windows system.

Prerequisites

Before you begin, ensure you have administrative privileges on your Windows system. The tools mentioned here are compatible with most SSDs and provide comprehensive health information.

Using CrystalDiskInfo

CrystalDiskInfo is a popular, free tool that provides detailed information about your SSD, including health status, temperature, and SMART attributes.

1. Install CrystalDiskInfo

Download CrystalDiskInfo from the official website: CrystalDiskInfo Download.

Run the installer and follow the on-screen instructions to complete the installation.

2. Check SSD Health

Open CrystalDiskInfo after installation. The main window will display a summary of your SSD’s health, including temperature, health status (Good, Caution, Bad), and various SMART attributes.

3. Detailed SSD Information

CrystalDiskInfo provides a detailed overview of your SSD’s SMART attributes. These attributes include metrics such as the total bytes written, power-on hours, and error rates. Reviewing these details can help you understand the overall condition of your SSD.

Using Samsung Magician (For Samsung SSDs)

If you have a Samsung SSD, Samsung Magician is a dedicated tool that offers advanced features for monitoring and managing your SSD.

1. Install Samsung Magician

<p>Download Samsung Magician from the official Samsung website: <a href="https://www.samsung.com/semiconductor/minisite/ssd/download/tools/" target="_blank">Samsung Magician Download</a>.</p>
<p>Run the installer and follow the on-screen instructions to complete the installation.</p>

2. Check SSD Health

Open Samsung Magician. The main dashboard provides an overview of your SSD’s health status, temperature, and used capacity.

3. Advanced Features

Samsung Magician offers additional features such as performance benchmarking, firmware updates, and over-provisioning settings. These tools help you maintain and optimize your Samsung SSD for better performance and longevity.

Using Intel SSD Toolbox (For Intel SSDs)

Intel SSD Toolbox is a specialized utility for Intel SSDs, providing detailed health information and management features.

1. Install Intel SSD Toolbox

Download Intel SSD Toolbox from the official Intel website: Intel SSD Toolbox Download.

Run the installer and follow the on-screen instructions to complete the installation.

2. Check SSD Health

Open Intel SSD Toolbox. The main window displays the SSD health status, estimated life remaining, and SMART attributes.

3. Diagnostic Scans and Firmware Updates

Intel SSD Toolbox includes diagnostic scans to test the SSD for potential issues and tools to update the firmware, ensuring your SSD runs with the latest improvements and fixes.

Using Windows Command Prompt

Windows also includes built-in tools for checking SSD health using the Command Prompt.

1. Check SMART Status

Open Command Prompt with administrative privileges. Type the following command and press Enter:


wmic diskdrive get status

This command displays the status of all connected drives. A status of “OK” indicates that the drives, including SSDs, are functioning properly.

2. Detailed Information with PowerShell

For more detailed information, use PowerShell. Open PowerShell with administrative privileges and run:


Get-PhysicalDisk

This command provides information about all physical disks, including their health status and operational status.

Conclusion

Monitoring the health and status of your SSD in Windows is straightforward with tools like CrystalDiskInfo, Samsung Magician, Intel SSD Toolbox, and built-in Windows utilities. Regular checks can help you identify potential issues early and maintain optimal performance. By following the steps outlined in this guide, you can ensure that your SSD remains in good health, prolonging its lifespan and reliability.

Stay proactive about your SSD's health, and you'll enjoy a more stable and efficient computing experience.

How to Check SSD Health in Linux: A Comprehensive Guide

2024-05-21T20:05:15+00:00

How to Check SSD Health and Information in Linux

Solid State Drives (SSDs) are crucial components in modern computers, offering faster data access speeds compared to traditional Hard Disk Drives (HDDs). To ensure optimal performance and longevity of your SSD, it is essential to regularly monitor its health and status. This article will guide you through the process of checking SSD health and retrieving relevant information on a Linux system.

Prerequisites

Before you begin, ensure you have access to a terminal and administrative privileges (root access or the ability to use sudo). The steps outlined here are applicable to most Linux distributions.

Using `smartctl` from the `smartmontools` Package

The smartctl tool, part of the smartmontools package, is widely used for monitoring and managing storage devices. It supports most SSDs and provides comprehensive health information.

1. Install `smartmontools`

First, install the smartmontools package. The installation command varies depending on your Linux distribution:

Debian/Ubuntu:


sudo apt-get update
sudo apt-get install smartmontools

Fedora:
```
sudo dnf install smartmontools
```
Arch Linux:
```
sudo pacman -S smartmontools
```

2. Check SSD Health

After installation, you can use smartctl to check the health status of your SSD. Replace /dev/sdX with your SSD's device identifier (e.g., /dev/sda, /dev/nvme0n1).

To view the overall health of the SSD, use the following command:


sudo smartctl -H /dev/sdX

3. Detailed SSD Information

For more detailed information, including SMART attributes, run:


sudo smartctl -a /dev/sdX

This command provides a comprehensive report, including the SSD model, firmware version, and various health indicators such as temperature, power-on hours, and error rates.

4. Running a Self-Test

You can also initiate self-tests to evaluate the SSD's condition. For a short self-test, use:


sudo smartctl -t short /dev/sdX

For a longer, more thorough test, use:


sudo smartctl -t long /dev/sdX

Check the test results with:


sudo smartctl -l selftest /dev/sdX

Using `nvme-cli` for NVMe SSDs

If your system uses NVMe SSDs, the nvme-cli tool provides specific commands to retrieve detailed information and health status.

1. Install `nvme-cli`

Install the nvme-cli package using the appropriate command for your distribution:

Debian/Ubuntu:


sudo apt-get update
sudo apt-get install nvme-cli

Fedora:
```
sudo dnf install nvme-cli
```
Arch Linux:
```
sudo pacman -S nvme-cli
```

2. Check NVMe SSD Health

To check the health of an NVMe SSD, use:


sudo nvme smart-log /dev/nvme0n1

This command provides detailed health information specific to NVMe drives, including temperature, available spare, data units read/written, and more.

3. Detailed NVMe Information

For detailed device information, use:


sudo nvme id-ctrl /dev/nvme0n1

This command will output the controller information, giving you a deeper insight into your NVMe SSD.

Conclusion

Monitoring the health and status of your SSD in Linux is straightforward with tools like smartctl and nvme-cli. Regular checks can help you preemptively identify potential issues and maintain optimal performance. By following the steps outlined in this guide, you can ensure that your SSD remains in good health, prolonging its lifespan and reliability.

Stay proactive about your SSD's health, and you'll enjoy a more stable and efficient computing experience.

The Evolution of Atomic Theory: Dalton to Schrödinger

2024-05-20T21:31:30+00:00

The journey to understand the atom, the fundamental building block of matter, has been a long and fascinating one, marked by significant milestones and groundbreaking discoveries. This article traces the history of atomic theory, highlighting the contributions of John Dalton, Ernest Rutherford, Niels Bohr, and Erwin Schrödinger.

John Dalton: The Revival of the Atomic Concept

In the early 19th century, John Dalton, an English chemist, and physicist, revitalized the ancient concept of the atom with his atomic theory. Dalton proposed that all matter is composed of tiny, indivisible particles called atoms. According to Dalton, atoms of a given element are identical in mass and properties, while atoms of different elements differ in these respects. He also introduced the idea that chemical reactions involve the rearrangement of atoms, which combine in fixed, whole-number ratios. Dalton's theory provided a systematic explanation for the laws of conservation of mass, definite proportions, and multiple proportions, laying the groundwork for modern chemistry.

Ernest Rutherford: The Nuclear Model of the Atom

At the dawn of the 20th century, the atomic model underwent a radical transformation thanks to the work of Ernest Rutherford, a New Zealand-born physicist. In 1909, Rutherford and his colleagues conducted the famous gold foil experiment, in which they bombarded a thin sheet of gold with alpha particles. They observed that most particles passed through the foil, but some were deflected at large angles. This unexpected result led Rutherford to propose a new atomic model in 1911. He suggested that the atom consists of a small, dense, positively charged nucleus surrounded by electrons. This nuclear model overturned the previous plum pudding model, which envisioned the atom as a diffuse cloud of positive charge with embedded electrons.

Niels Bohr: Quantum Jumps and Electron Orbits

While Rutherford's model introduced the nucleus, it did not fully explain how electrons are arranged around it. Danish physicist Niels Bohr addressed this issue in 1913 by incorporating quantum theory into his atomic model. Bohr proposed that electrons orbit the nucleus in specific, quantized energy levels and that they can transition between these levels by absorbing or emitting energy in discrete amounts, called quanta. This model explained the spectral lines of hydrogen and provided a foundation for understanding atomic structure. Bohr's theory marked a significant advancement in atomic physics, merging classical and quantum ideas.

Erwin Schrödinger: Wave Mechanics and the Quantum Model

The next major leap in atomic theory came from Austrian physicist Erwin Schrödinger in the mid-1920s. Schrödinger developed wave mechanics, a formulation of quantum mechanics that describes electrons as wave-like entities. His famous wave equation, the Schrödinger equation, provides a mathematical framework for predicting the behavior of electrons in atoms. Unlike Bohr's model, which depicted electrons in fixed orbits, Schrödinger's model treats electrons as existing in probabilistic clouds called orbitals. This approach offers a more accurate and comprehensive description of atomic and molecular systems.

Conclusion: A Continuing Journey

The development of atomic theory from Dalton to Schrödinger represents a remarkable evolution of scientific thought. Each scientist built upon the work of their predecessors, refining and expanding our understanding of the atom. Dalton's indivisible atoms, Rutherford's nucleus, Bohr's quantized orbits, and Schrödinger's wave mechanics collectively form the foundation of modern atomic physics. This journey is a testament to the power of scientific inquiry and the continual quest for knowledge, which drives us ever closer to unraveling the mysteries of the natural world.

cpp.sh: Your Ultimate Online C++ Compiler

2024-05-18T19:17:29+00:00

Explore cpp.sh: Your Go-To Online Platform for Running C++ Code

In the world of programming, C++ remains one of the most influential and powerful languages. Whether you’re a beginner learning the ropes or a seasoned developer working on complex projects, having a reliable and accessible platform to write, test, and run your C++ code is invaluable. Enter cpp.sh, an online compiler that simplifies the process of coding in C++ by offering a user-friendly interface and powerful features—all without the need to install any software on your local machine.

What is cpp.sh?

Cpp.sh is an online compiler and editor designed specifically for C++ programming. It allows users to write, compile, and run C++ code directly from their web browser. This web-based tool is especially useful for students, educators, and developers who need a quick and convenient way to test snippets of C++ code or share their work with others.

Key Features

Instant Compilation and Execution: One of the standout features of cpp.sh is its ability to compile and execute code instantly. This immediate feedback loop is crucial for learning and debugging, allowing users to see the results of their code in real-time.
User-Friendly Interface: The platform boasts a clean and intuitive interface. The code editor is designed with syntax highlighting and line numbering, making it easy to write and read code. Additionally, the interface is straightforward, ensuring that even beginners can navigate it with ease.
Cross-Platform Accessibility: Since cpp.sh is a web-based tool, it is accessible from any device with an internet connection. This cross-platform compatibility means you can code on the go, whether you're using a desktop, laptop, tablet, or smartphone.
Code Sharing and Collaboration: cpp.sh makes it easy to share code snippets. You can generate a unique URL for your code, allowing you to share it with peers, instructors, or collaborators quickly. This feature is particularly beneficial for collaborative projects or seeking help from the programming community.
Customization Options: Users can customize their coding environment to suit their preferences. This includes changing the theme of the editor, adjusting font sizes, and configuring other settings to create a comfortable coding experience.
No Installation Required: One of the primary advantages of cpp.sh is that it eliminates the need to install a local C++ development environment. This can save time and resources, particularly for those who may face difficulties installing software on their machines.

Getting Started with cpp.sh

Using cpp.sh is simple and straightforward. Here’s a quick guide to get you started:

Visit the Website: Go to cpp.sh in your web browser.
Write Your Code: Start typing your C++ code in the provided editor. The interface supports syntax highlighting, which helps in identifying various elements of the code.
Compile and Run: Once you’ve written your code, click the "Run" button. cpp.sh will compile and execute your code, displaying the output directly on the screen.
Save and Share: If you want to save your code or share it with others, use the "Share" button to generate a unique URL.

Why Choose cpp.sh?

Cpp.sh is a powerful tool for anyone interested in C++ programming. Its ease of use, instant feedback, and accessibility make it an excellent choice for both learning and professional development. Whether you’re debugging a tricky algorithm, learning the basics of C++, or working on a collaborative project, cpp.sh provides a seamless and efficient coding experience.

In a digital age where convenience and efficiency are paramount, cpp.sh stands out as a reliable and robust platform for running C++ code online. Give it a try and experience the benefits of this versatile online compiler.

Easy Firefox Profile Transfer: Quick Guide for Windows Users

2024-05-12T18:39:06+00:00

Effortless Firefox Migration: How to Seamlessly Transfer Your Profile to a New Windows Installation or Another Computer

Introduction: Moving to a new Windows installation or another computer can be overwhelming, especially when it comes to preserving your Firefox settings, bookmarks, and passwords. However, there's a simple solution: copying the Firefox profile folder. In this article, we'll explore how you can effortlessly transfer your Firefox profile to ensure a seamless browsing experience on your new system.

For Linux users, check out our guide on effortless Firefox migration . With easy-to-follow steps, you can seamlessly transfer your Firefox profile to a new Linux installation or another computer, ensuring all your settings, bookmarks, and passwords remain intact. Now, let's explore the Windows version of this guide.

Step 1: Locate Your Firefox Profile
Your Firefox profile contains all your personal settings, bookmarks, history, extensions, and saved passwords. By default, this profile is stored in a folder named "Profiles" within your Firefox installation directory. Navigate to "C:\Users\YourUsername\AppData\Roaming\Mozilla\Firefox\Profiles" to find it.

Step 2: Copy the Firefox Profile Folder
Once you've located your profile folder, simply copy it to an external storage device or transfer it over the network to your new Windows installation or another computer. You can do this using File Explorer.

Step 3: Paste the Firefox Profile Folder
After copying the Firefox profile folder, navigate to your new Windows installation or another computer and paste the folder into the same directory as before: "C:\Users\YourNewUsername\AppData\Roaming\Mozilla\Firefox\Profiles".

Step 4: Launch Firefox
Once you've pasted the profile folder into the correct directory, launch Firefox on your new system. Firefox will automatically detect the transferred profile and load all your settings, bookmarks, history, extensions, and saved passwords.

Step 5: Verify Your Settings
After launching Firefox, take a moment to verify that all your settings, bookmarks, passwords, and extensions have been successfully transferred. Everything should appear exactly as it was on your previous system.

Conclusion: Transferring your Firefox profile to a new Windows installation or another computer doesn't have to be complicated. By copying the Firefox profile folder, you can ensure that all your settings, bookmarks, passwords, and extensions are seamlessly transferred to your new system. Next time you're setting up a new Windows installation or migrating to another computer, remember this quick and easy method for preserving your Firefox profile.

Simplify Your Firefox Migration Process: Copy .mozilla Folder

2024-05-12T18:08:59+00:00

Effortless Firefox Migration: How to Seamlessly Transfer Your Profile to a New Linux Install or Another Computer

Introduction: Migrating to a new Linux installation or another computer can be a daunting task, especially when it comes to preserving your Firefox settings, bookmarks, and passwords. However, there's a simple solution that can save you time and effort: copying the .mozilla folder in your home directory. In this article, we'll explore how you can effortlessly transfer your Firefox profile to ensure a seamless browsing experience on your new system.

Step 1: Locate Your Firefox Profile
The Firefox profile contains all your personal settings, bookmarks, history, extensions, and saved passwords. By default, this profile is stored in a hidden folder named .mozilla in your home directory. To locate it, open your file manager and enable the option to show hidden files. You should see the .mozilla folder in your home directory.

Step 2: Copy the .mozilla Folder
Once you've located the .mozilla folder, simply copy it to an external storage device or transfer it over the network to your new Linux installation or another computer. You can do this using the command line or a graphical file manager, depending on your preference.

If you're using the command line, you can use the following command to copy the .mozilla folder to an external drive:

cp -r ~/.mozilla /path/to/external/drive

Replace "/path/to/external/drive" with the actual path to your external drive.

Step 3: Paste the .mozilla Folder
After copying the .mozilla folder, navigate to your new Linux installation or another computer and paste the folder into your home directory. Again, make sure to show hidden files in your file manager to see the .mozilla folder.

Step 4: Launch Firefox
Once you've pasted the .mozilla folder into your home directory, you're ready to launch Firefox. When you open Firefox on your new system, it will automatically detect the transferred profile and load all your settings, bookmarks, history, extensions, and saved passwords.

Step 5: Verify Your Settings
After launching Firefox, take a moment to verify that all your settings, bookmarks, passwords, and extensions have been successfully transferred. You should see everything exactly as it was on your previous system.

Conclusion: Transferring your Firefox profile to a new Linux installation or another computer doesn't have to be a complicated process. By simply copying the .mozilla folder from your home directory, you can ensure that all your settings, bookmarks, passwords, and extensions are seamlessly transferred to your new system. So the next time you're setting up a new Linux installation or migrating to another computer, remember this quick and easy method for preserving your Firefox profile.

The Top Linux Distros for College Students

2024-05-11T21:30:21+00:00

The Top Linux Distros for College Students: A Comprehensive Guide

Ubuntu

Ubuntu is often hailed as one of the most user-friendly Linux distributions, making it an excellent choice for students new to the Linux ecosystem. Its extensive software library, combined with a user-friendly interface, ensures that students can easily find and install the tools they need for their coursework. Ubuntu's LTS (Long Term Support) releases provide stability and reliability, making it a dependable companion throughout your college journey.

Fedora

For students who crave the latest software and technologies, Fedora is an ideal choice. Known for its focus on innovation, Fedora offers cutting-edge features while maintaining a high level of stability. With a vibrant community and extensive documentation, Fedora is well-suited for students who want to stay at the forefront of technology.

Debian

Debian prides itself on stability and reliability, making it a solid choice for college students seeking a dependable operating system. With its vast repository of software packages, Debian provides access to a wide range of tools and applications for academic and personal use. Ideal for students interested in exploring the inner workings of Linux systems, Debian offers a rich learning experience alongside its robust performance.

Linux Mint

Linux Mint is renowned for its user-friendly interface, reminiscent of traditional desktop environments like Windows. With a focus on simplicity and ease of use, Linux Mint provides a seamless transition for students migrating from other operating systems. Its stability, combined with a rich selection of pre-installed software, ensures that students can focus on their studies without worrying about technical hurdles.

Manjaro

Based on Arch Linux, Manjaro offers a balance between cutting-edge software and system stability. With access to the Arch User Repository (AUR), Manjaro provides a vast selection of software packages for students with diverse interests and needs. Its flexibility and customization options make it an attractive choice for students who want to tailor their operating system to suit their preferences.

Pop!_OS

Developed by System76, Pop!_OS is designed with developers and power users in mind. Featuring a minimalist design and productivity-focused features like tiling window management, Pop!_OS enhances efficiency and workflow management for college students. With enhanced gaming support, it caters to students looking to strike a balance between work and play.

Elementary OS

Combining elegance with simplicity, Elementary OS offers a visually stunning desktop environment that appeals to students with a penchant for design aesthetics. Its lightweight system requirements make it suitable for older hardware, ensuring smooth performance even on low-end laptops. With the AppCenter for easy software installation, Elementary OS provides a hassle-free experience for college students.

Conclusion

Choosing the right Linux distribution can significantly impact your college experience, empowering you with the tools and resources you need to succeed academically and professionally. Whether you prioritize stability, cutting-edge technology, or user-friendly design, there's a Linux distro tailored to meet your needs. Experiment with different distributions, explore their features, and discover the one that resonates with you. With Linux, the possibilities are endless, and your college journey awaits with open arms.

Free and Open-Source Alternatives to Proteus for Electronic Design

2024-05-07T22:38:16+00:00

In the realm of electronic design, software tools play a pivotal role in bringing ideas to life, from conceptualization to simulation and implementation. While commercial options like Proteus dominate the market, there exists a vibrant ecosystem of free and open-source alternatives that offer comparable features and flexibility. In this article, we'll delve into some of these alternatives, highlighting their key features and benefits.

KiCad

KiCad stands out as a powerful open-source EDA suite, providing a comprehensive set of tools for schematic capture, PCB layout, and 3D visualization. With a user-friendly interface and robust community support, KiCad is suitable for projects of all scales, from hobbyist endeavors to professional-grade designs. Its cross-platform compatibility ensures accessibility across different operating systems, making it a versatile choice for electronic designers worldwide.

KiCad

QUCS (Quite Universal Circuit Simulator)

QUCS offers a sophisticated simulation environment for electronic circuits, encompassing AC, DC, S-parameter, and transient analyses. As an open-source project, it provides users with the flexibility to customize and extend its capabilities according to their specific requirements. Its intuitive graphical interface simplifies the process of circuit simulation, making it an ideal choice for both beginners and experienced engineers seeking accurate and reliable results.

QUCS (Quite Universal Circuit Simulator)

LTspice

LTspice, developed by Analog Devices, is a high-performance SPICE simulator available free of charge. Renowned for its speed and accuracy, LTspice is widely utilized for simulating analog circuits and switching regulators. Its seamless integration with LTspice IV and XVII further enhances its usability, enabling users to efficiently design and analyze complex electronic systems with ease.

LTspice

Ngspice

Ngspice is an open-source SPICE simulator capable of handling various circuit types, including analog, digital, and mixed-signal circuits. While primarily a command-line tool, it offers compatibility with graphical interfaces like XSpice, facilitating user interaction and visualization. With its robust simulation engine and extensive library of device models, Ngspice empowers users to explore the behavior of electronic circuits with precision and accuracy.

Ngspice

GNU Circuit Analysis Package (Gnucap)

Gnucap distinguishes itself as a versatile circuit simulator designed for usability and extensibility. Despite being command-line driven, it offers interfaces like Gnucap-UI for graphical interaction, catering to users with varying preferences. With its emphasis on accuracy and flexibility, Gnucap serves as a valuable tool for engineers and researchers seeking to analyze and optimize electronic circuits for diverse applications.

OpenModelica

While not tailored specifically for electronic circuit design, OpenModelica provides a robust modeling and simulation environment for cyber-physical systems. Its support for multi-domain modeling enables users to simulate electrical systems alongside other components, facilitating comprehensive analysis and optimization. With its open-source nature and broad applicability, OpenModelica offers a unique perspective on system-level design and simulation.

In conclusion, the landscape of electronic design is enriched by the presence of free and open-source alternatives to commercial software like Proteus. Whether you're an enthusiast exploring circuitry as a hobby or a professional engineer tackling complex design challenges, these alternatives offer a wealth of features and capabilities to suit your needs. By embracing open-source tools like KiCad, QUCS, LTspice, Ngspice, Gnucap, and OpenModelica, designers can unlock new possibilities and drive innovation in the field of electronic design.

Creating Visually Stunning Banners for Websites with LaTeX

2024-05-06T16:55:02+00:00

Introduction

In the digital age, where websites compete for attention, visually appealing banners play a crucial role in capturing the interest of visitors. While graphic design software is commonly used for creating banners, LaTeX, a typesetting system primarily used for technical and scientific documents, offers a unique approach to banner design. In this article, we'll explore how to leverage LaTeX, along with the AddToShipoutPictureBG command and the tikz package, to craft visually stunning banners for websites.

The LaTeX Code:



\documentclass[a4paper]{article}
\usepackage[landscape,margin=1cm]{geometry}
\usepackage{tikz}
\usepackage{graphicx}
\usepackage{xcolor}
\usetikzlibrary{calc}
\usepackage{eso-pic}

\AddToShipoutPictureBG{\includegraphics[width=0.5\textwidth]{student.png}}


\begin{document}

\pagecolor{purple!70!red!40}
\thispagestyle{empty}

\begin{tikzpicture}[remember picture,overlay]
    \fill[purple!20,line width=3pt] ($(current page.south east) + (-0.57\paperwidth,0)$) arc (180:0:0.52\paperwidth);
    \draw[blue!50!cyan,line width=3pt] ($(current page.south east) + (-0.56\paperwidth,0)$) arc (180:0:0.51\paperwidth);
    \draw[blue!50!cyan,line width=3pt] ($(current page.south east) + (-0.57\paperwidth,0)$) arc (180:0:0.52\paperwidth);
    \node[blue!45, font=\fontsize{18}{22}\selectfont\bfseries] at ($(current page.south)+(1,0.75)$) {mosaid.xyz};
    \draw[blue!45, line width=2.5pt] ($(current page.south)+(-1,0.5)$) -- ($(current page.south)+(3,0.5)$) ;
\end{tikzpicture}

\vspace*{6.5cm}
\fontsize{38}{48}\selectfont\bfseries
\hspace*{18cm} How To Use\\
\hspace*{16.3cm} \LaTeX~ To Create\\
\hspace*{15cm} Visually Stunning\\
\hspace*{13.8cm} Banners For your\\
\hspace*{13.4cm}Website\\
\end{document}

Overview of the Code

The provided LaTeX code demonstrates the process of creating a banner. It utilizes the article document class with specific options for paper size and landscape orientation. Essential packages such as geometry, tikz, graphicx, and xcolor are included to facilitate layout design, drawing, image handling, and color customization, respectively.

Understanding AddToShipoutPictureBG

The AddToShipoutPictureBG command, employed with the eso-pic package, allows users to add a background image or graphic to every page of the document. In the context of banner creation, this command serves as the foundation for incorporating visual elements that span across the entire banner.

Using TikZ for Drawing

TikZ, a powerful package for creating graphics within LaTeX documents, is utilized to draw the visual elements of the banner. Through TikZ commands, users can design custom shapes, lines, and text, enabling precise control over the banner's appearance. This flexibility empowers designers to unleash their creativity and craft unique banners tailored to their preferences.

Creating the Banner

The banner is constructed using a combination of TikZ commands within the tikzpicture environment. Step-by-step, elements such as arcs, lines, and text are added to compose the banner's layout. Each TikZ command contributes to the overall design, with parameters adjusted to achieve desired sizes, positions, and styles.

Visual Effects and Styling

The code incorporates visual effects and styling techniques to enhance the banner's appeal. The pagecolor command is employed to set the background color of the page, while colors, line widths, and shapes are carefully chosen to create a visually engaging composition. By experimenting with different color schemes and design elements, users can customize the banner to suit various website themes and aesthetics.

Conclusion

In conclusion, LaTeX offers a unique and versatile platform for creating visually stunning banners for websites. By harnessing the power of the AddToShipoutPictureBG command and the tikz package, designers can unleash their creativity and produce banners that captivate audiences. Whether it's for personal blogs, professional portfolios, or corporate websites, LaTeX provides a compelling alternative for banner design that merges elegance with functionality.

References

TikZ and PGF Documentation: https://www.ctan.org/pkg/pgf
LaTeX Graphics Companion: https://www.ctan.org/pkg/latex-graphics-companion

Send Your Son to The University and Don't Look Back

2024-05-05T20:31:14+00:00

The prevailing sentiment in our educational culture is to achieve a high score in the baccalaureate exam, followed by enrollment in a prestigious university or private institute, which is commendable.

It is not praiseworthy to view the university solely as a fallback option for those rejected from higher education institutions or those with low baccalaureate scores. This misconception exists only in societies plagued by scientific backwardness. Fundamentally, the university serves as the authentic hub for nurturing researchers, scientists, and visionaries, a role it has historically played.

In modern times, advanced nations don't boast about their private schools or elite institutions; rather, they celebrate their universities and academic establishments like Harvard, Cambridge, Oxford, Chicago, Stanford, Toronto, Sorbonne, Berkeley... Even within our developing country, the brightest minds our society produces are largely shaped by public schools and universities.

Yes, the university can become a place of wasted time and energy if spent idly in cafes, laughing with friends at professors' quirks, chasing after phone numbers, playing football, or watching Netflix during lectures. In such cases, failure awaits, regardless of whether you attend a university or a top-ranked school, as the issue lies within oneself, one's mindset, thoughts, social circle, and environment.

However, if you perceive the university as a space to hone your intellectual tools, develop research skills, and take initiative in pursuing knowledge and scientific research, you will experience the richness of university life, akin to those who have dedicated themselves before you.

Another significant factor contributing to the university's decline and the negative perception among young people is the commercialization infiltrating the minds of parents, students, and educational institutions. Success is now equated with being an engineer who contributes to a company's success, earning a salary to afford an apartment, car, and summer vacation in a northern or Spanish city at best. Consequently, scientific progress has become associated with materialism and monthly income.

Our cultural stagnation, skewed priorities, and neglect of potential have all played a role in this phenomenon. Today, we hold up a corporate or commercial employee as the epitome of success and excellence for our children, while researchers, professors, writers, and thinkers represent the ideal models of perseverance, seeking assistance, and striving for success at the doors of educational institutions.

This is not to undermine the importance of corporate or commercial employees, but it should not overshadow the essence of scientific culture and its alignment with materialistic standards.

The university has been, still is, and will continue to be the sacred space and academic sanctuary that nurtures and will continue to nurture great minds, professors, and researchers. So, send your son to university without hesitation."

How to Create Circular Profile Pictures in LaTeX: A Step-by-Step Guide

2024-05-04T20:28:58+00:00

In today's digital age, presenting oneself professionally is paramount, whether it's for a CV, seminar poster, or professional profile. A key element of this presentation is the profile picture. While rectangular images are common, circular profile pictures can add a touch of elegance and professionalism to your documents. In this tutorial, we'll explore how to create circular profile pictures in LaTeX, a powerful typesetting system widely used for academic and professional documents.

Step 1: Preparing the LaTeX Environment

To begin, ensure you have LaTeX installed on your system. LaTeX distributions such as TeX Live and MiKTeX are freely available and easy to install on most operating systems.

Step 2: Writing the LaTeX Code

Below is a sample LaTeX code that creates circular profile pictures:



\documentclass{standalone}
\standaloneconfig{margin=2mm}
\usepackage{tikz}
\usepackage{graphicx}
\usepackage{ragged2e}

% Define the radius of the outer circle
\def\outerRadius{2.2cm}
% Define the radius of the inner circle
\def\innerRadius{2cm}

% Get the natural width of the image
\newlength{\imgwidth}

\newcommand\pic[2]{
    \begin{tikzpicture}
      \begin{scope}
        \draw[yellow] (0,0) circle (\outerRadius);
        \draw[yellow] (0,0) circle (\innerRadius);

        \fill[yellow] (0,0) circle (\outerRadius) -- (0,0) circle (\innerRadius);

        % Clip the image to the shape of the inner circle
        \clip (0,0) circle (\innerRadius);

        % Calculate the correct width to fit the image perfectly inside the inner circle
        \settowidth{\imgwidth}{\includegraphics{#1}}
        \pgfmathsetmacro{\scalefactor}{\innerRadius / (0.5 * \imgwidth)}

        % Include the image inside the inner circle with the calculated width
        \node at (0,0) {\includegraphics[scale=\scalefactor]{#1}};
      \end{scope}
      \node[blue,below, font=\Large\bfseries, align=center, inner sep=2pt, minimum width=2cm, minimum height=2cm, text width=3.5cm, text badly centered] at (0,-\outerRadius) {\Centering #2};
    \end{tikzpicture}
}


\begin{document}

\pic{outputimage.jpg}{Dr. Ethan Thompson}
\pic{female.png}{PhD. Sophia Rodriguez}
\pic{13mlw3.jpg}{Mia Anderson}
\pic{ef153.jpg}{Dr Mohamed Ali Soltan}

\end{document}

It will give this figure:

Profile pictures with LaTeX

Explanation

The LaTeX code utilizes the standalone document class to generate standalone images.
It makes use of the tikz package for drawing graphics and the graphicx package for including images.
The \pic command is defined to create circular profile pictures with names or titles below them.

Conclusion

In conclusion, by following the steps outlined in this tutorial, you can easily create circular profile pictures in LaTeX for use in CVs, seminar posters, and other professional documents. This simple yet effective technique adds a touch of professionalism to your presentations, helping you stand out in the competitive world of academia and beyond. Experiment with different styles and sizes to find the perfect look for your documents. Happy typesetting!

Rsync Command: The Ideal and Reliable Way to Copy Large Files

2024-05-04T18:37:45+00:00

Introduction

When transferring files to my Android phone or many of my external hard drives I never use the file manager nor do I use "cp" command, I noticed that with file managers the computer actually slows down and sometimes the file manager becomes non resposnive with large files. I always use rsync command.

And it has been a life saver and reliable, when copying files to a remote server over the network even with network interruptions and low netowrk connection

What is Rsync?

Rsync is a command-line utility that synchronizes files and directories between two locations while minimizing data transfer by only copying the differences between them. This mechanism makes Rsync incredibly efficient, particularly for large files where transferring the entire file each time is impractical. Its cross-platform support ensures seamless operation across Linux, macOS, and Windows systems.

Benefits of Using Rsync

Rsync offers several advantages for large file copying:

•Efficiency: Rsync's delta-transfer algorithm ensures that only the portions of files that have changed are transferred, reducing bandwidth usage.

•Reliability: Rsync's ability to resume interrupted transfers and handle network disruptions makes it a dependable choice for mission-critical operations.

•Versatility: Whether you're copying files over a network or to/from external devices, Rsync's adaptability shines through, providing consistent performance across various scenarios.

Real-World Examples Using Rsync

Example 1: Copying Large Files Over a Network:

Whenever I want to copy files to my website server I use the following command:



sshpass -p "mypassword" \
    rsync -avPh --bwlimit=1000 --timeout=120 \
    --exclude '__pycache__' \
    -e "ssh -oHostKeyAlgorithms=+ssh-dss  -p<portnumber> " "local/directory/or/file" myusername@myserver.com:/path/to/my/remote/directory

And it has been a life saver and reliable, even with network interruptions and low netowrk connection

Example 2: Copying Large Files to/from External Devices

Transferring media files to my Android phone via MTP or simply to an external drive can be unreliable with conventional methods. Rsync offers a robust solution, ensuring uninterrupted transfers even in the event of interruptions or connectivity issues.

•Basic Usage: Use the following syntax to copy files:

rsync [options] source destination

        

rsync -ahrS --progress /path/to/source/  /path/to/destination
# or simply navigate to destination and
rsync -ahrS --progress /path/to/source/  .  # notice the dot ie current directory

•Advanced Options: You can use additional options like '-avz' for archiving and compressing data, '-P' for progress updates, '--partial' for resuming interrupted transfers, --exclude '*.djvu' to exclude files with the .djvu extension, and '--max-size=53m' to limit the transfer of files smaller than 53 megabytes. the last two are especially usefull when synchronizing(copying=) a directory

Best Practices

•Optimize Performance: Experiment with compression and other options to maximize transfer speeds, especially over slower connections.

•Secure Transfers: Use SSH for secure data transfers, safeguarding your files during transit.

•Selective Copying: Leverage Rsync's options to exclude unnecessary files or directories, streamlining the copying process.

Conclusion

In the realm of large file copying, Rsync stands out as a beacon of reliability and efficiency. Whether you're synchronizing files over a network or transferring data to/from external devices, Rsync's prowess remains unmatched. By integrating Rsync into your workflow, you can streamline your file copying processes, ensuring swift and dependable transfers every time.

Discover Feh Image Viewer's Montage Mode: Effortlessly Create Stunning Image Collages

2024-05-03T17:46:48+00:00

Introduction:

Discover the power of Feh Image Viewer, a versatile and lightweight tool designed for seamless image viewing, management, and presentation. With its minimalist design and command-line interface, Feh offers a streamlined experience suitable for both casual users and professionals alike. In this comprehensive guide, we'll explore how to harness the full potential of Feh Image Viewer, including its standout feature: the robust montage mode for effortlessly creating visually captivating image collages. Additionally, we'll walk you through the installation process on various Linux distributions, enabling you to unlock Feh's powerful functionality with ease and efficiency.

Installation

    

# in Debian and Ubuntu based distros:
sudo apt install feh
# Arch linux:
sudo pacman -S feh
# fedora
sudo dnf install feh

Feh Image Viewer

Viewing Individual Images:
With Feh, viewing individual images is as simple as running the command feh /path/to/image. This straightforward command allows users to open and view images quickly without any unnecessary overhead. Feh's minimalist interface ensures that the focus remains on the image itself, providing a distraction-free viewing experience.

Browsing Image Directories:
Feh also excels at handling directories of images. By passing a directory path as an argument (feh /path/to/directory), Feh launches in a mode where it displays all images within that directory sequentially. Users can navigate through the images using keyboard shortcuts, allowing for efficient browsing of image collections without the need for a complex graphical user interface.

Montage Mode:
Feh's montage mode is a powerful feature that enables users to create visual collages or montages of images. By executing a command like this:

    

feh --index-info "%u\n" \       # Set format for image information
    -x -m -W 1920 -H 1080 \     # Display images in index mode with montage layout,
                        # set width and height of montage window
    -E 180 -y 180  \            # Set height and width of thumbnails
    -f "$image_list" \          # Specify file containing list of images
    -o "montage_output.png" \   # Save the generated montage as PNG
    2> /dev/null             # Redirect error messages to /dev/null

Feh Montage

Users can arrange images in a grid layout, specifying parameters such as width, height, and spacing. This mode is particularly useful for comparing multiple images side by side or creating thumbnails for image galleries.

Feh Desktop Backgrounder

Setting Desktop Background:
Feh offers seamless integration with desktop environments by allowing users to set images as desktop backgrounds directly from the command line. The command :



feh --image-bg bg_color --bg-max "/path/to/image"

sets the specified image as the desktop background, adjusting its size and position to fit the screen resolution. Users can also customize the background color (bg_color) and choose between different scaling options (--bg-max) to achieve the desired visual effect.

In summary, Feh Image Viewer offers a versatile set of features for both image viewing and desktop background management. Whether you need a lightweight and efficient tool for browsing images or a flexible solution for customizing your desktop environment, Feh provides the necessary tools to meet your needs with simplicity and reliability.

Lady Aicha's True Age at Marriage of Prophet Mohamed Peace Be Upon Him

2024-05-02T15:41:14+00:00

The Prophet's marriage to Aisha at the age of nine is a major falsehood in the Hadith literature. Biographical and authoritative Islamic sources refute the narrations of Bukhari, confirming that the daughter of Abu Bakr married the Prophet at the age of eighteen.

When the voices of the wise emerge to defend the Prophet, peace be upon him, confirming through history and authenticated narrations the inaccuracy of many of the narrations that some attribute to Islam, such as the narration of the Prophet's marriage, peace be upon him, to Lady Aisha when she was nine years old, they face that sacred obstacle which asserts the sanctity of ancient jurisprudential methodologies, the books of Bukhari and Muslim, sanctifying them from error, and rejecting any attempt to exert independent reasoning in correcting their narrations even if they are doubtful. For they are the sciences ahead of their time, unaccepting of renewal, addition, deletion, revision, commentary, or even criticism.

It is the same with the widely circulated narration known by almost every Muslim, found in Bukhari and Muslim, stating that the Prophet (peace be upon him), at the age of fifty, married the Mother of the Believers (Aisha) when she was six years old, consummating the marriage when she was almost nine. This narration, which gained the famous seal of immunity merely by its mention in Bukhari and Muslim, despite contradicting everything conceivable, contradicts the Quran, authentic Sunnah, reason, logic, custom, and the chronological sequence of events in the prophetic mission. The narration documented by Bukhari comes through five chains of transmission with one meaning for the text, and due to the length of the narration, we will mention its initial and final parts conveying the intended meaning (Bukhari - Chapter of the Prophet's Marriage to Aisha and Her Arrival in Medina and His Consummation with Her - 3894): Frooq ibn Abi al-Mughirah narrated to us: Ali ibn Mas'har narrated to us, from Hisham, from his father, from Aisha, may Allah be pleased with her, she said: "The Prophet married me when I was six years old, and we came to Medina... He consummated the marriage with me when I was nine years old."

Relying on the foundational texts of history and the authenticated biographies of the prophetic mission (such as al-Kamil, History of Damascus, Lives of the Nobles, History of al-Tabari, Al-Bidaya wa'l-Nihaya, History of Baghdad, and many others), they are almost unanimous regarding the chronological timeline of the events of the prophetic mission as follows:

- The Prophetic mission lasted for 13 years in Makkah.

- It continued for 10 years in Madinah.

- The Prophetic mission began in the year 610 CE (according to the Gregorian calendar).

- The migration (Hijrah) to Madinah occurred in the year 623 CE, which is 13 years after the start of the mission in Makkah.

- The Prophet passed away in the year 633 CE, which is 10 years after the migration to Madinah.

According to this agreed-upon timeline, it is assumed that the Prophet married Aisha three years before the Hijra to Medina, i.e., in the year 620 CE. This corresponds to the tenth year of revelation, and (According to Sahih Bukhari) Aisha was six years old at the time. He consummated the marriage with her at the end of the first year of migration, i.e., at the end of the year 623 CE, when she was nine years old. According to the Gregorian calendar, this means she was born in the year 614 CE, which corresponds to the fourth year of revelation according to Bukhari's narration.

This is a misconception and a significant error, as we will see in detail in this article.

Historical critique of the narration:

1. Calculating the age of Lady Aisha in relation to her sister, Asma bint Abi Bakr

All the aforementioned historical sources unanimously assert that Asma was ten years older than Aisha. These sources also agree that Asma was born 27 years before the Hijra to Medina, meaning she was 14 years old at the beginning of the prophetic mission in Mecca in 610 CE, deduced by subtracting her age before the migration (13 years of the prophetic call in Mecca) from her total age (27 - 13 = 14 years). All sources confirm that she was ten years older than Aisha, confirming that Aisha was four years old at the start of the prophetic mission in Mecca, meaning she was born in 606 CE. When the Prophet married her in Mecca in the tenth year of the prophetic mission, she was 14 years old (4 + 10 = 14 years). In other words, Aisha was born in 606 CE, and the Prophet married her in 620 CE when she was 14 years old. He consummated the marriage with her after three years and a few months, at the end of the first year of migration and the beginning of the second year, in 624 CE, making her age at that time 18 years (14 + 3 + 1 = 18 years), which is the actual age at which the noble Prophet married Aisha.

2. Calculating Aisha's age in relation to the death of her sister, Asma:

The aforementioned historical sources unanimously confirm that Asma died after a well-documented and established incident, the killing of her son, Abdullah ibn al-Zubayr, by the infamous tyrant, al-Hajjaj, in 73 AH. At the time of her death, Asma was 100 years old. If we subtract Asma's age at the time of her death (73 AH), when she was 100 years old, we get 27 years, which is her age at the time of the Prophet's migration, aligning perfectly with the age mentioned in historical sources. Subtracting the ten years by which Asma was older than Aisha, Aisha's age at the time of migration would be 17 years (27 - 10 = 17 years). If we consider the Prophet consummated the marriage with her at the end of the first year of migration, her age at that time would be 18 years (17 + 1 = 18 years), confirming the correct calculation of Lady Aisha's age at the time of her marriage to the Prophet. Additionally, Tabari asserts with certainty in his book "History of Nations" that all the children of Abu Bakr were born in the pre-Islamic era, which aligns with the correct timeline and exposes the weakness of Bukhari's narration, as Aisha was indeed born in the fourth year before the start of the prophetic mission.

3. Calculating Aisha's age compared to Fatimah al-Zahra, the daughter of the Prophet:

Ibn Hajar mentions in "al-Isabah" that Fatimah was born during the construction of the Kaaba when the Prophet was 35 years old. According to this narration by Ibn Hajar, though it's not considered strong, assuming its strength, Ibn Hajar, who is a commentator on Bukhari, indirectly refutes a narration within Bukhari. If Fatimah was born when the Prophet was 35 years old, then Aisha was born when the Prophet was 40 years old, which corresponds to the beginning of his prophethood. This means that Aisha's age at the time of migration was equivalent to the number of years of Islamic preaching in Mecca, which is 13 years, not 9 years. This narration is mentioned here only to illustrate the significant discrepancy in Bukhari's narration.

Critique of the narration from Hadith and Seerah books:

1. Ibn Kathir mentions in "Al-Bidaya wal-Nihaya" regarding those who embraced Islam early: "Among the women... Asma bint Abi Bakr and Aisha. Aisha was young, and these individuals embraced Islam within three years. The Messenger of Allah (peace be upon him) called secretly, and then Allah, the Almighty, commanded His Messenger to openly proclaim the call." Of course, this narration indicates that Aisha accepted Islam before the Prophet publicly announced his mission in the fourth year of prophethood, which corresponds to the year 614 CE. This means that she believed at least in the third year, which is equivalent to 613 CE. If we consider the narration from Al-Bukhari that Aisha was born in the fourth year of revelation, it implies that she was not present on Earth when the Prophet openly called to Islam in the fourth year of his mission. Alternatively, she would have been an infant. However, a proper calculation of her age confirms that she was born in the year 606 CE, which means that she was eight years old when the Prophet publicly called to Islam in 614 CE. This aligns with the correct timeline of events and contradicts the narration in Al-Bukhari.

2. Imam al-Bukhari himself narrates in the chapter "The Residence of Abu Bakr during the Time of the Prophet" that Aisha said: "I have never seen my parents embracing Islam except that they were already Muslims, and not a day passed except that the Messenger of Allah would come to our house both in the morning and in the evening. When the Muslims faced persecution, Abu Bakr migrated towards Abyssinia." I do not understand how al-Bukhari includes this narration because Aisha mentions that her parents embraced Islam before the migration to Abyssinia, as she stated. She also mentions that the Prophet used to visit their house every day, indicating that she was aware of these visits. It is universally agreed by historical sources that the migration to Abyssinia occurred in the fifth year of the prophetic mission, which corresponds to approximately 615 CE. If we assume the truth of Bukhari's narration that Aisha was born in the fourth year of the prophetic mission, which is 614 CE, it would mean that she was an infant during the migration to Abyssinia. How does this align with the statement "I have never seen my parents embracing Islam" when the word "seen" doesn't require clarification? However, according to the correct chronological timeline, Aisha would have been 4 years old before the start of the prophetic mission and 5 years old before the migration to Abyssinia, totaling 9 years, which is her actual age at that time.

3. Imam Ahmad narrates in "Musnad Aisha" that when Khadijah died, Khawlah bint Hakim, the wife of Uthman ibn Maz'un, came to the Prophet and said, "O Messenger of Allah, why don't you marry?" He asked, "Whom?" She replied, "If you wish, a virgin, and if you wish, a previously married woman." He asked, "Who is the virgin?" She said, "The one most beloved to you among Allah's creation, Aisha, the daughter of Abu Bakr." Here, it becomes evident that Khawlah bint Hakim presented both virgin and previously married (divorced or widowed) options to the Prophet. Was she presenting them based on their readiness for marriage, or was one of them a child whom the Prophet should wait to reach marriageable age? The context of the hadith indicates that she presented them as potential immediate spouses, as evidenced by her statement, "If you wish, a virgin, and if you wish, a previously married woman." Therefore, it is implausible that Aisha was a child at that time at the age of six, as presented by Khawlah as a potential marriage candidate ("a virgin").

4. Imam Ahmad also narrates a lengthy hadith from Khawlah bint Hakim about Aisha's engagement to the Prophet. The important part of it is as follows: "Umm Roman said: 'Indeed, Muta'im ibn 'Adi proposed to her for his son, and by Allah, Abu Bakr never promised something without fulfilling it... Perhaps you (the Prophet) will be his successor." The meaning here is simply that Muta'im ibn 'Adi, who was a disbeliever, had proposed to Aisha for his son Jabir ibn Muta'im before the noble Prophet. Abu Bakr wanted to fulfill his promise, so he visited him and found him saying, "Perhaps if I marry my son to Aisha, he will become a follower of your religion." Here, we pause with very important conclusions: Aisha could not have been engaged before the age of 6 to an older man who fought against the Muslims in Badr and Uhud, wanting to marry someone like Jabir. Also, it is impossible for Abu Bakr to have betrothed his daughter to one of the polytheists who were persecuting the Muslims in Mecca. This indicates that this was a promise of engagement made before the start of the prophetic mission when both parties were young, confirming that Aisha was indeed born before the start of the prophetic mission.

5. Al-Bukhari narrates in the chapter "The Statement of Allah: 'The Hour has drawn near, and the moon has split'": Aisha said, "Indeed, this verse was revealed to Muhammad [in Mecca], and I was a young girl playing, 'The Hour has drawn near, and the moon has split.'" It is universally agreed that Surah Al-Qamar was revealed four years after the start of the revelation, around 614 CE. If we believe Bukhari's narration, Aisha either had not been born yet or was a newborn baby when the Surah was revealed. However, Aisha says, "I was a young girl playing," indicating that she was a child playing. How could she not have been born yet? But the timeline consistent with the events confirms that she was 4 years old at the start of the revelation and 8 years old when the Surah was revealed, as we have repeatedly explained, which aligns with her statement "I was a young girl playing."

6. Al-Bukhari narrates in the chapter "A Virgin should not be married without her consent": The Messenger of Allah said, "A virgin should not be married until her permission is sought." They said, "O Messenger of Allah, how can her permission be sought?" He said, "By her silence." How can the noble Prophet say this and then act contrary to it? The hadith reported by Al-Bukhari from the age of the Mother of the Believers at her marriage attributes to her the statement that she used to play with dolls and that no one asked her permission for her marriage to the Prophet. How could she be asked while she was a very young child who did not understand the meaning of marriage? Even her consent at this age does not have any legal effect because it is consent given without being legally responsible, mature, or rational.

Critique of the Isnad (chain of narrators):

I will focus here on explaining the weaknesses in the chain of narrators in Al-Bukhari's narration only:

The hadith that mentioned the age of the Mother of the Believers came through five chains:

1.• Furwah ibn Abi al-Mughirah told us: Ali ibn Mas'har narrated to us, from Hisham, from his father, from Aisha.

2.• Ubaid ibn Isma'il told us: Abu Usamah narrated to us, from Hisham, from his father.

3.• Mua'la ibn Asad told us: Wahb narrated to us, from Hisham ibn Urwah, from Aisha.

4.• Muhammad ibn Yusuf told us: Sufyan narrated to us, from Hisham, from his father, from Aisha.

5.• Qubaysah ibn 'Uqbah told us: Sufyan narrated to us, from Hisham ibn Urwah, from Urwah.

And as we see, all the narrations trace back to one narrator, which is Urwah. He is the one who exclusively narrated from Aisha, and his son Hisham narrated exclusively from him. The problem lies in Hisham, as Ibn Hajar mentioned in "Hady al-Sari" and "Tahdhib," stating, "Abd al-Rahman ibn Yusuf ibn Kharash said: Malik did not approve of him. It reached me that Malik held a grudge against him for his narrations to the people of Iraq. He came to Kufa three times. The first time he used to say: 'My father told me, I heard Aisha.' The second time he used to say: 'My father informed me about Aisha.' The third time he used to say: 'My father about Aisha.'"

In simple terms, Hisham ibn Urwah was considered trustworthy in Al-Madinah. However, when he went to Iraq, his memory for Hadith deteriorated. He began fabricating or attributing Hadith to other narrators. Then he started saying "from my father" instead of "I heard" or "he told me." In the science of Hadith, the phrase "I heard" or "he told me" is stronger than "from so-and-so." The Hadith in Bukhari is reported as "Hisham from his father," not "I heard" or "he told me," which raises doubts about the authenticity of the chain. Furthermore, Imam Malik said that Hisham's narrations from Iraq are not accepted. Applying this to the Hadith reported by Al-Bukhari, we find it to be substantiated. None of the narrators were from Al-Madinah; they were all Iraqis, indicating that Hisham ibn Urwah narrated it in Iraq. It's implausible for Hisham to spend a long time in Al-Madinah without mentioning a Hadith like this even once. Therefore, we find no mention of Aisha's age at the time of her marriage to the Prophet in Imam Malik's book "Al-Muwatta," as he directly saw and heard Hisham ibn Urwah in Al-Madinah. These two reasons are sufficient to cast doubt on the authenticity of the narration in Bukhari, especially considering the confirmed corruption of its text through historical comparison.

As for the reliance of jurists and scholars, including Al-Bukhari, on this Hadith regarding the marriage of young girls, it represents a dark page in our heritage. We will postpone discussing it for now. It's strange to find Wahhabis promoting the idea that hot climates cause girls to mature early when the Arabian Peninsula, despite being hot, has only gotten hotter. Why then don't we find girls reaching puberty prematurely at six or even nine? This notion contradicts scientific facts, which affirm that climate plays no role in early puberty.

In conclusion, Lady Aisha married the Prophet at the age of 18, not 9, based on accurate estimation. This narration reported by Al-Bukhari is simply corrupt in its text and doubtful in its chain of transmission, as it contradicts Sharia, reason, authentic Hadiths, societal norms, and customs. Moreover, it extremely contradicts the timeline of the events of the Prophet's mission. We shouldn't hold Al-Bukhari and other scholars in higher regard than the Prophet himself. We are free to accept or reject what they have reported. Islam is not confined to the scholars and their time alone. Therefore, we can freely critique and reject much of what is contained in their books—these texts are ultimately human heritage, not divine scripture, and should never be sanctified or deified. We and the scholars of the past are - as humans- on equal footing, none of us superior to the other. They are just as prone to errors as they are capable of making accurate judgments.

Imam Ahmad ibn Hanbal's 10 Timeless Principles for Marital Harmony

2024-05-01T22:03:52+00:00

Imam Ahmad ibn Hanbal's advice to his son on his wedding day

Imam Ahmad ibn Hanbal shared invaluable advice with his son upon his marriage, offering ten timeless principles for marital harmony. These principles emphasize fostering tenderness, expressing love openly, and understanding differences between spouses. Imam Ahmad's wisdom provides profound insights into the complexities of married life, highlighting the importance of love, compassion, and understanding within the sacred bond of marriage.

• Be Generous with Affection and Express Your Love: Women appreciate tenderness and love to hear expressions of love. Don't hesitate to show affection to your wife. Being stingy with affection can create a barrier between you and her, affecting the bond of love.

• Balance Firmness and Gentleness: Women dislike overly strict or harsh men. At the same time, they appreciate a gentle and understanding approach. Find the right balance between being firm and being kind. It will lead to a more harmonious relationship.

• Pay Attention to Your Appearance and Manners: Women appreciate a husband who speaks kindly, dresses well, maintains personal hygiene, and smells pleasant. Cultivate these qualities to make your wife feel valued and respected.

• Respect Her Domain: Recognize that the home is the woman's domain. Allow her to feel like the queen of her castle. Avoid undermining her authority or trying to take control. A happy home is one where both partners respect each other's roles.

• Support Her Family: Women want to feel connected to their families. Don't force her to choose between you and her family. If she chooses you over them, she may carry resentment. Be understanding and supportive of her family ties.

• Embrace Her Imperfections: Remember that women are beautifully imperfect. Don't hold her mistakes against her. Instead of criticizing, be patient and understanding. Your acceptance will strengthen your relationship.

• Be Kind Even When She Is Unkind: Women may sometimes be unkind due to physical or emotional fatigue. Be compassionate during these moments. Just as Allah has eased some religious obligations for women during difficult times, ease your demands and commands when she is struggling.

• Forgive and Forget: If she praises you for a long time and then criticizes you once, don't let it affect your feelings. Don't hate her for this. If you dislike a particular trait in her, accept it and focus on her other positive qualities.

• Support Her During Weakness: Women experience physical and emotional weakness. Allah has exempted them from certain religious duties during these times. Be understanding and compassionate. Your kindness during her vulnerable moments will strengthen your bond.

• Remember She Is Your Companion: Treat her with kindness and overlook her weaknesses. She is your partner in this journey of life, and together you can build a beautiful relationship.

Remember, my son, a successful marriage requires effort, understanding, and love from both partners. May your marriage be filled with blessings and happiness!

Access Local Websites: Linux to Windows in VirtualBox

2024-04-30T20:56:51+00:00

How to Access a Local Website from a Linux Host Machine to a Windows Guest Machine in VirtualBox

If you're running a Windows virtual machine (VM) inside VirtualBox on your Linux host, you might want to access a local website or service hosted on the guest machine. In this guide, we'll walk through the steps to set up communication between your Linux host and Windows guest using a host-only network.

Prerequisites

VirtualBox: Ensure that you have VirtualBox installed on your Linux host machine.

Windows Guest VM: Set up a Windows virtual machine in VirtualBox.

Steps:

1. Create a Host-Only Network in VirtualBox:

• Open VirtualBox and go to File > Host Network Manager.

VirtualBox Network Manager

• In the Host-Only Networks tab, click Create. A host-only network will be created with the default name "vboxnet0".

Host-Only Network Creation

<p>&#8226; By default, it will have an IPv4 prefix of <code>192.168.56.1/24</code> and DHCP enabled.</p>

2. Configure the Virtual Machine Settings:

• Open the settings for your Windows guest virtual machine.

• Keep the first network adapter (usually NAT) as it is.

• Enable the second network adapter and select Attached to: "Host-Only Adapter".

• Choose the network name "vboxnet0" (the one you created in step 1).

Host-Only Network Adapter

3. Start Your Virtual Machine:

• Now, whenever you run your Windows guest virtual machine, it will be connected to the host-only network.

• On the host machine (Linux), you'll find a local network for communication between the host and guest machines. in my case I got something like this

    

$ ip a | grep -oP '(?<=inet |addr:)(?:\d+\.){3}\d+'
127.0.0.1   # loopback adress
192.168.1.5 # my machine local IP adress in my Local network
192.168.56.1    # this is the IP address of the host-only network
192.168.56.101  # my machine IP adress in the host-only network

If I have a website running in my Linux (host) machine on port 8081 then I can access it in the guest VM like this 192.168.56.1:8081 or 192.168.56.101:8081 or 192.168.1.5:8081 when I am connected to a local network

The Universal probability bound And The Infinite Monkey Theorem

2024-04-21T21:55:40+00:00

Introduction:

In the annals of scientific inquiry, one of the most intriguing questions pertains to the role of chance versus design in shaping the cosmos. At the heart of this discourse lies the concept of the universal probability bound, a theoretical construct proposed by William Dembski. This bound delineates the threshold beyond which events are deemed statistically improbable within the constraints of the universe's fundamental constants.

Let’s do some Maths:

the number of subatomic particles in the universe is estimated to be 10^80 particle

the smallest fraction of time is Planck time is (roughly) 10^-45 second. So we can say without doubt that the greatest number of interactions per second is 10^45 interaction.

The age of the universe is 13.7 x 10^9 years, so we can say that the longest period of time in which a number of events (interactions) can occur is 10^25 second.

10^80 x 10^45 x 10^25 = 10^150.

10^150 represents the maximum number of events occurring in the whole universe since the beginning of time and any probability smaller than 10^-150 is thusly considered equal to zero and its random event is considered impossible to happen.

Experience: The infinite Monkey Theorem:

10^80 monkeys typing in keyboards with a rate of 10^45 keystroke per second, and these monkeys keep typing for 10^25 seconds (more than 3.16 x 10^17 years) this period of time is greater than the age of the universe!

The number of keystrokes is 10^150.

Let’s calculate the probability to type a poem of 400 letters.

Let’s make it easier for these immortal monkeys and consider the keyboard consists of 26 keys (ignoring punctuation and spacing).

When events are independent, the probability of them all happening is the product of the individual probabilities multiplied together.

Think of it this way, to type the word “physics”

The probability to type “p” is 1 out of 26, the probability to type the next letter “h” is the same 1/26 and so on till the 7th letter in the word “physics”.

Therefore the probability to type the word “physics” is :

(1/26) x (1/26) x (1/26) x (1/26) x (1/26) x (1/26) x (1/26) or (1/26) ^7

the probability to type 400 letters is (1/26) ^400.

Which means that the monkeys need to type 26^400 letters to produce a single instance of this poem!!

For the sake of simplicity let’s make it only 10^400.

The probability, these monkeys succeed in producing the poem is:

(10^150) / (10^400) = 10^-250

which is largely smaller than the universal probability bound!

This example shows that it is impossible to randomly produce a small 400 letters poem (forget about a single DNA molecule that contains more than 140 Billion atoms). How can we say lightly that this universe is the result of chance, or is it the luckiest unverse where all parametters are just right for life to bloom. As we deepen our understanding of the universe, we realise that it is well designed by the Creator, God Almighty. If we forsake the western materialistic view of the universe, we will in no way hinder scientific inquiry, we will not deny the laws of physics. the only thing added to the mix is our faith.

Balancing Act: Prioritizing Teacher Well-being Amidst Student Challenges

2024-04-21T09:46:48+00:00

Reminder of Psychological and Social Balance

Dear teacher, remember not to burden yourself, not to burn your nerves, and always maintain a smile. Allocate time for yourself and your family, engage in your hobbies, and fill your time with activities beyond teaching and addressing students' issues.

Importance of Separating Personal and Professional Life

Colleagues, safeguard your health by maintaining a clear boundary between your personal and professional lives while fulfilling your responsibilities. The varying levels of student achievement may lead some of you to be overly critical of yourselves, which can have serious consequences for your mental and physical well-being. Therefore, approach your tasks professionally, delivering lessons with detachment and without emotional attachment, regardless of the students' proficiency levels. Students who possess the minimum competencies to keep pace with the lessons will benefit from your efforts. For those who lack even primary-level skills while being taught high school-level material, immediate educational intervention is necessary. Recognize that you have a limited and obligatory timeframe to complete the curriculum. Avoid succumbing to pressure or unrealistic expectations; you are not expected to possess miraculous abilities. Disregard criticisms blaming teachers for the educational system's shortcomings and focus on delivering your lessons professionally, promoting attendance, actively engaging students, and continually improving your performance. Ultimately, the responsibility lies with the students, their families, and the supervisory ministry.

Role of the Family and the Supervisory Ministry

Families, whose primary concern may be providing material needs, must understand the importance of actively monitoring, nurturing, and guiding their children. They are closest to the students and should not allow them to be neglected or exposed to negative influences from the streets or social media. Neglecting these duties renders the efforts of teachers futile. The supervisory ministry, meanwhile, is tasked with ensuring adequate infrastructure, reforming salary structures, compensation packages, promotions, and revising programs and curricula.

Avoiding Depression and Pressure

Dear colleagues, teachers often find themselves constrained by stereotypical views and prevailing judgments, leading to self-blame, accusations of negligence, and feelings of depression and pressure. Many teachers have succumbed to heart attacks or strokes, whether in the classroom or elsewhere. Remember not to overburden yourselves and safeguard your mental and physical well-being.

Automated Backup Solutions: Safeguarding Your Daily Work

2024-04-16T22:19:46+00:00

In the digital age, where the bulk of our work and personal documents exist in electronic format, ensuring their safety and accessibility is paramount. Imagine investing hours into crafting a crucial report, a research paper, or a personal project only to lose it due to technical glitches, accidental deletions, or hardware failures. To prevent such nightmares, it's essential to establish a robust backup system. In this guide, we'll explore how to backup your important documents, focusing particularly on files you interact with daily, such as ongoing projects or works-in-progress.

Understanding the Importance of Regular Backups

Before delving into the specifics of backup methods, let's underscore why regular backups are indispensable:

•Data Loss Prevention: Accidents happen. Whether it's a power outage, a software crash, or human error, the risk of losing valuable data is ever-present.

•Protection Against Hardware Failure: Hard drives can fail unexpectedly, resulting in permanent data loss. Backing up your files ensures that even if your primary storage device malfunctions, your data remains intact.

•Version Control: When working on documents that undergo frequent revisions, maintaining a history of changes allows you to revert to earlier versions if necessary.

Implementing a Backup Strategy

•Identify Critical Files: Begin by identifying the files and folders that are indispensable to you. This includes documents, presentations, spreadsheets, and any other data you interact with regularly.

•Select a Backup Method: There are various backup methods available, ranging from manual backups to automated solutions. Choose a method that aligns with your workflow and provides the level of redundancy you require.

•Automate the Process: Automating backups ensures consistency and minimizes the risk of human error. Utilize tools like cron jobs (for Unix-like systems) or task schedulers (for Windows) to schedule regular backups at convenient intervals.

•Utilize Versioning Systems: Version control systems such as Git are invaluable for managing projects involving code or text-based documents. They track changes over time, allowing you to revert to previous versions effortlessly.

Example Backup Script for Daily Use

If you're working on documents regularly and want a straightforward backup solution, consider implementing a script similar to the following:



#!/usr/bin/env bash

# Define backup directory
backup_dir="$HOME/backups"

# Create backup directory if it doesn't exist
mkdir -p "$backup_dir"

# Get current date and time
timestamp=$(date +%Y-%m-%d_%H-%M-%S)

# Get current directory name
current_dir=$(basename "$(pwd)")

# Create backup filename with directory name
backup_file="$backup_dir/${current_dir}_backup_$timestamp.tar.gz"

# Archive current directory and compress it
tar -czf "$backup_file" .

echo "Backup created: $backup_file"

This script creates a compressed archive of the current directory and saves it in a designated backup directory. You can then schedule it to run daily using a cron job, ensuring that your files are backed up regularly without manual intervention.

Conclusion

Protecting your important documents through regular backups is a simple yet crucial practice that can save you from potential disasters. By implementing a robust backup strategy and leveraging automation where possible, you can safeguard your work and enjoy peace of mind knowing that your data is secure and accessible whenever you need it. Remember, when it comes to backups, it's better to be safe than sorry.

Nmap: A Deep Dive into Network Security Auditing

2024-04-16T21:53:46+00:00

In today's interconnected digital landscape, understanding the intricacies of network security is paramount. Whether you're a seasoned cybersecurity professional or an enthusiastic novice, having the right tools at your disposal is crucial. Among these tools, Nmap stands out as a cornerstone for network exploration and security auditing. In this article, we'll delve into the depths of Nmap, exploring its features, applications, and best practices.

What is Nmap?

Nmap, short for Network Mapper, is an open-source tool designed for network exploration and security auditing. Developed by Gordon Lyon, commonly known by his pseudonym "Fyodor," Nmap has evolved over the years into a robust and versatile utility. It operates by sending packets to target hosts and analyzing their responses to provide valuable information about the network's topology, services, operating systems, and potential vulnerabilities.

Key Features of Nmap:

Port Scanning

One of Nmap's primary functions is port scanning. It allows users to discover open ports on target systems, providing insights into the services running on those ports and potential entry points for attackers.

nmap -p 1-100 192.168.1.1

Host Discovery

Nmap facilitates the discovery of hosts within a specified range of IP addresses. By sending ICMP echo requests, TCP SYN, ACK, or UDP probes, it identifies active hosts on the network.

nmap -sn 192.168.1.0/24

Service Version Detection

Nmap can determine the versions of services running on open ports, aiding in vulnerability assessment and patch management.

nmap -sV 192.168.1.1

OS Fingerprinting

Through a series of probing techniques, Nmap can attempt to identify the operating systems of target hosts based on their responses to network packets.

nmap -O 192.168.1.1

Scripting Engine

Nmap's scripting engine (NSE) allows users to automate and customize tasks, extending its functionality for specific purposes such as vulnerability scanning and network inventory.

Best Practices and Considerations:

Permission and Legality

Always ensure you have proper authorization before scanning networks. Unauthorized scanning could lead to legal repercussions.

Stealth and Discretion

Depending on the context, choose scan types that prioritize stealth to avoid detection by intrusion detection systems (IDS) or firewall logs.

Documentation

Document scan results meticulously, including dates, times, and specific configurations used. This information is invaluable for audits and future reference.

Regular Updates

Keep Nmap and its associated scripts updated to leverage the latest features and security enhancements.

Conclusion:

Nmap stands as a stalwart in the realm of network exploration and security auditing, empowering users with insights into network topology, services, and potential vulnerabilities. Its versatility, coupled with a rich set of features, makes it an indispensable tool for cybersecurity professionals worldwide. By understanding its capabilities and adhering to best practices, users can harness the power of Nmap to fortify their networks against potential threats and vulnerabilities.

Enhance LaTeX Efficiency: Divide and Conquer with input Command

2024-04-15T18:43:18+00:00

Writing in LaTeX offers unparalleled control and precision, but as projects grow in complexity, keeping everything organized becomes paramount. Breaking down your document into smaller, manageable files not only enhances clarity but also facilitates collaboration and maintenance. In this guide, we'll explore strategies for organizing LaTeX documents across multiple files and leveraging the \input command to merge them seamlessly into a cohesive whole. Additionally, we'll delve into optimizing your workflow with separate files for packages, definitions, commands, and shortcuts, ensuring efficiency and consistency throughout your LaTeX endeavors.

1. Divide and Conquer: Organizing Your Project

When embarking on a LaTeX project, resist the temptation to cram everything into a single file. Instead, adopt a modular approach by breaking down your document into logical sections. For instance, a research paper could consist of separate files for the introduction, literature review, methodology, results, and conclusion. Similarly, a thesis might comprise chapters stored in individual files.

Here's a basic project structure:



project/
│
├── main.tex
├── sections/
│   ├── introduction.tex
│   ├── literature.tex
│   ├── methodology.tex
│   ├── results.tex
│   └── conclusion.tex
├── packages.tex
├── definitions.tex
└── shortcuts.tex

2. Using `\input` command

The \input command in LaTeX allows you to incorporate the contents of one file into another. This feature proves invaluable for assembling a coherent document from multiple components. To include a file, simply use the \input command followed by the file's path relative to the main document.

In main.tex, you might have:



\documentclass{article}
\input{packages.tex}       % Include packages
\input{definitions.tex}    % Include definitions
\input{shortcuts.tex}      % Include shortcuts

\begin{document}
\input{sections/introduction.tex}   % Include sections
\input{sections/literature.tex}
\input{sections/methodology.tex}
\input{sections/results.tex}
\input{sections/conclusion.tex}
\end{document}

3. Streamlining Your Workflow with Separate Files

a. Packages:

Keep your document preamble clean by storing package imports in a separate file (packages.tex). This file should contain all necessary \usepackage commands.

b. Definitions:

Store custom commands and environments in definitions.tex. This centralizes your document's key definitions, enhancing readability and maintainability.

c. Shortcuts:

For frequently used commands, such as mathematical symbols or formatting macros, maintain a comprehensive shortcuts.tex file. This file should contain a collection of shortcuts tailored to your preferences and commonly used symbols. For example, you might define shortcuts like \cA to \cZ for \mathcal{A} through \mathcal{Z}, \sA to \sZ for \mathscr{A} through \mathscr{Z}, and so on.

By centralizing your shortcuts in one file, you can easily incorporate them into any LaTeX document by simply including \input{shortcuts.tex} in your preamble. This approach streamlines your workflow and ensures consistency across your documents.

4. Best Practices and Tips

•Naming Conventions: Adopt a consistent naming convention for your files and variables to avoid confusion.

•Version Control: Utilize version control systems like Git to track changes and collaborate effectively.

•Documentation: Include comments and documentation within your LaTeX files to aid understanding and future modifications.

5. Conclusion

Organizing LaTeX documents across multiple files offers numerous benefits, from improved clarity and maintainability to enhanced collaboration and efficiency. By dividing your project into modular components and leveraging the \input command, you can streamline your workflow and create polished, professional documents with ease.

Incorporate these strategies into your LaTeX workflow to unlock the full potential of this powerful typesetting system, and watch as your productivity soars.

The Ultimate Vim Setup (My 2024 vimrc ) : Essential Commands, Configurations, and Plugin Tips

2024-04-12T18:04:14+00:00

Are you ready to level up your text editing game? If you're a Linux or Windows user looking to harness the power of Vim, you're in the right place. Vim is a highly customizable text editor known for its efficiency and versatility. However, it can be intimidating for beginners. Fear not! In this guide, we'll walk you through the process of setting up Vim for the first time, catering to both Linux and Windows users.

Installing Vim
For Linux Users
For Windows Users
Essential Vim Commands
Configuring Vim
1: Vimrc File
2: Vim Plugins
4: History, Undo, Redo
5: More Settings
6: Color Highlighting
7: Search and Additional Settings
8: Custom Functions for File and Command History Management
Plugin Configurations
1: FZF Settings
2: Completion and YouCompleteMe
Filetype Specific Configurations
Conclusion

Installing Vim

For Linux Users:

Installing Vim on Linux is a breeze. Simply open your terminal and enter the following command:



# debian based distributions
sudo apt-get install vim

# Arch based distributions
sudo pacman -S vim

For Windows Users:

Windows users can download Vim from its official website (https://www.vim.org/download.php) or use package managers like Chocolatey (https://chocolatey.org/packages/vim).

Essential Vim Commands

One of the most distinctive features that sets Vim apart from other text editors is its powerful and efficient text manipulation capabilities, primarily driven by Vim motions. These commands streamline the editing process, allowing users to navigate, edit, and manipulate text with remarkable speed and precision.

i: Enter insert mode

Esc: Exit insert mode

:w: Save changes

:q: Quit Vim

:wq: Save and quit

h, j, k, l: Navigate left, down, up, right respectively

yy: Copy current line

dd: Delete current line

p: Paste copied/deleted text

Mastering these essential Vim commands is the first step towards becoming proficient with this powerful text editor. With practice, users can harness the efficiency and flexibility of Vim motions to edit text swiftly and effectively.

Configuring Vim

1: Vimrc File

The .vimrc file is a key component for configuring Vim according to your preferences. It contains settings, key mappings, and customizations to tailor Vim to your workflow.

On Linux systems, including Ubuntu, Debian, Fedora, and others, the .vimrc file is typically located in the user's home directory. You can access it using a text editor or via the command line. Here's the path:



/home/your_username/.vimrc

Replace your_username with your actual username.

For Windows users, the location of the .vimrc file may vary depending on the Vim installation method:

•If you installed Vim using the installer, the .vimrc file is usually located in the user's home directory:



C:\Users\YourUsername\_vimrc

•If you are using the Vim distribution called "Cream," the _vimrc file may be located in:



C:\Program Files\Vim\_vimrc

Remember to use a text editor or the command line to edit the .vimrc file and add your desired configurations.

2: Vim Plugins

Vim plugins enhance the functionality of the editor by adding features, customizations, and themes. They allow users to tailor Vim to their specific needs and preferences.

Vim-Plug is a popular plugin manager for Vim that simplifies the process of installing and managing plugins. Here's how to set it up:

Download Vim-Plug: Visit the Vim-Plug GitHub repository at https://github.com/junegunn/vim-plug.
Copy Vim-Plug: Depending on your operating system:

For Windows: Download the plug.vim file from the Vim-Plug GitHub repository. Then, copy the downloaded file to the %USERPROFILE%\vimfiles\autoload directory.
For Linux: Download the plug.vim file from the Vim-Plug GitHub repository. Then, copy the downloaded file to the ~/.vim/autoload directory.

With Vim-Plug installed, you're ready to start adding and managing plugins for your Vim editor.

Below is an example of configuring Vim plugins using Vim-Plug:



" enable syntax highlighting and filetype detection
syntax on
filetype plugin indent on

" Specify a directory for plugins.
call plug#begin('~/.vim/bundle')

" Gruvbox theme.
Plug 'gruvbox-community/gruvbox'

" fzf
Plug 'junegunn/fzf', { 'do': { -> fzf#install() } }
Plug 'junegunn/fzf.vim'

" Briefly highlight which text was yanked.
Plug 'machakann/vim-highlightedyank'

" Modify * to also work with visual selections.
Plug 'nelstrom/vim-visual-star-search'

" Better display unwanted whitespace.
Plug 'ntpeters/vim-better-whitespace'

" A bunch of useful language related snippets (ultisnips is the engine).
Plug 'SirVer/ultisnips' | Plug 'honza/vim-snippets'

"C family languages completion
Plug 'Valloric/YouCompleteMe'

" IDE-like bar
Plug 'bagrat/vim-buffet'

"
"Plug 'lervag/vimtex'

call plug#end()

In the example above, the Vim-Plug plugin manager is used to manage plugins. Each Plug command specifies a plugin to install or manage. After adding the desired plugins to your .vimrc file, save it and reload Vim to apply the changes. You can then install the plugins by running :PlugInstall command within Vim.

For Windows users, ensure that you name the bundle directory appropriately. In the example above, the directory is named bundle. However, on Windows systems, the directory separator is typically a backslash (\) instead of a forward slash (/). Therefore, you should name the directory bundle or bundle\ accordingly to avoid any path-related issues.

Experiment with different plugins to discover ones that best suit your workflow and enhance your Vim experience.

For the plugin "YouCompleteMe," additional steps are required for both Linux and Windows users. Firstly, ensure that Python is installed and added to the system's PATH environment variable. This step is necessary because YouCompleteMe relies on Python for its functionality. Additionally, Git should also be installed and added to the PATH, as YouCompleteMe requires Git for fetching and updating its dependencies.

After running :PlugInstall to install the plugins, users need to navigate to the YouCompleteMe plugin directory and execute the installation script manually. This is typically located in the .vim/bundle/YouCompleteMe directory. Follow the instructions provided in the plugin's documentation or README file to complete the installation process.

General settings in Vim allow users to customize various aspects of the editor's behavior and appearance to suit their preferences. These settings cover a wide range of functionalities, from enabling features like backspace navigation in insert mode and cursor line highlighting to configuring auto-reading of files changed outside of Vim. Users can also adjust settings related to cursor behavior, encoding, syntax highlighting, and more to create a personalized editing environment. Experimenting with these settings can significantly enhance productivity and streamline the editing experience in Vim.

In Vim, the "leader" key serves as a customizable prefix for creating custom key mappings. By default, the backslash (\) key is designated as the leader key, but users can redefine it to any other key of their choice. The leader key is often used in combination with other keys to create shortcuts for frequently used commands or custom functions. This allows users to streamline their workflow and increase efficiency by assigning intuitive and memorable key combinations for specific tasks. Utilizing the leader key effectively can significantly enhance productivity and make Vim usage more ergonomic and tailored to individual preferences.

    


" leader
" -----------------------------------------------------------------------------

let mapleader=";"
noremap cc :gg"+yG    " copy the entire document to system clipboard
noremap y yiW

" General Config
" -----------------------------------------------------------------------------

set backspace=indent,eol,start  "Allow backspace in insert mode
set showcmd                     "Show incomplete cmds down the bottom
set showmode                    "Show current mode down the bottom
set gcr=a:blinkon0              "Disable cursor blink
set visualbell                  "No sounds
set autoread                    "Reload files changed outside vim
set hidden
set cursorline
set modeline
set mouse=n
set encoding=utf-8
set isfname+=32
set showmatch                   "highlight matching [{{{()}}}]
set lazyredraw
set tw=100
set complete+=kspell
"set colorcolumn=100
set formatoptions=tcqrn1
set matchpairs+=<:>             " Use % to jump between pairs
set nocompatible
set noerrorbells visualbell t_vb=
set noshiftround
"set nospell
set nostartofline
set regexpengine=1
set ruler
set ttimeout
set whichwrap=b,s,<,>
set t_Co=256
set title titlestring=
set completeopt-=preview
set splitbelow
set splitright
set formatoptions-=tc       " turn off breaking long lines
set showtabline=0
set wildoptions=pum

4: History, Undo, Redo

In Vim, managing history, undo, and redo functionalities is crucial for efficient editing and reverting changes. By adjusting settings related to history, undo, and redo, users can customize Vim to suit their workflow and preferences.

Below are some settings commonly used to configure history, undo, and redo in Vim:




" history, undo, redo and backup
" -----------------------------------------------------------------------------
set history=10000
set undofile
set undodir=~/.vim/undo
set undolevels=1000
set undoreload=10000
set backupdir=~/.vim/backup
set directory=~/.vim/backup
set viminfo='1000000

"redo
nnoremap r <C-r>

In the provided configuration, Vim is set to maintain a history of 10,000 commands. Undo information is saved to a file using the undofile option, with the directory specified as ~/.vim/undo. Additionally, Vim is configured to maintain a high level of undo information with 1,000 levels and to reload undo files up to 10,000 bytes in size. Backup files are stored in ~/.vim/backup, and the viminfo option is set to a large value for storing various information about the editing session.

Furthermore, a mapping is created to allow for easy redoing of changes using the r key combined with Ctrl+r.

Customizing these settings enables users to effectively manage history, undo, and redo operations in Vim, enhancing productivity and providing greater control over the editing process. It's worth noting that Vim's history and undo/redo functionalities persist even after closing and reopening documents. With settings configured to retain thousands of history actions, users can seamlessly navigate through the editing history of their documents, ensuring a comprehensive and efficient editing experience.

5: More Settings

Additional settings in Vim allow users to further customize their editing environment and workflow. These settings can range from defining custom key mappings for specific tasks to configuring autocmds and functions to automate certain actions.

Below are some additional settings commonly used to enhance the Vim experience:




" more settings
" -----------------------------------------------------------------------------
"
nnoremap <silent><leader>l :set number! relativenumber!<CR>
autocmd FocusGained * !terminal_transparency set 90

function! EngType()
  " To switch back from Arabic
  set spell
  set spelllang=en_us
  set spellcapcheck
endfunction

function! FrType()
  set spell
  set spelllang=fr
  set spellfile+=~/.vim/spell/fr.utf-8.add
endfunction

" cycle through buffers
nnoremap <Tab> :bnext<CR>

"window mouvements
nnoremap <down>   <C-W><C-J>
nnoremap <up>     <C-W><C-K>
nnoremap <right>  <C-W><C-L>
nnoremap <left>   <C-W><C-H>

In the provided configuration, custom key mappings are defined to toggle line numbers and relative line numbers using <leader>l, and to cycle through buffers using <Tab>. Autocommands are utilized to adjust terminal transparency upon regaining focus, and functions are defined to switch between English and French spell checking modes. Additionally, custom mappings are set for window movements using <down>, <up>, <right>, and <left> keys.

These additional settings offer users greater flexibility and efficiency in their editing tasks, allowing for a more personalized and streamlined Vim experience.

6: Color Highlighting

Color highlighting in Vim plays a significant role in enhancing readability and visual appeal, making it easier for users to distinguish between different elements within the editor. By configuring color schemes and defining custom highlight groups, users can customize the appearance of various components such as the cursor, cursor line, status line, search results, and more.

Below are some settings commonly used to configure color highlighting in Vim:



" highlighting and cursor
" -----------------------------------------------------------------------------
"
colorscheme gruvbox

hi CursorLine       ctermbg=darkgrey  ctermfg=none    term=bold cterm=bold
hi CursorColumn     ctermbg=darkred   ctermfg=white    term=bold cterm=bold
hi StatusLine       ctermbg=darkred   ctermfg=white    term=bold cterm=bold
hi Normal           ctermbg=black     ctermfg=none     term=bold cterm=bold
hi Visual           ctermbg=lightred  ctermfg=black    term=bold cterm=bold
hi Folded           ctermbg=black     ctermfg=red      term=bold cterm=bold
hi FoldColumn       ctermbg=green     ctermfg=yellow   term=bold cterm=bold
hi Search           ctermbg=yellow    ctermfg=black    term=bold cterm=bold
hi Cursor           ctermbg=yellow    ctermfg=yellow   term=bold cterm=bold
hi iCursor          ctermbg=yellow    ctermfg=yellow   term=bold cterm=bold

hi SpellBad         cterm=underline   ctermfg=black    ctermbg=red
hi SpellLocal       cterm=underline   ctermfg=black    ctermbg=red
hi SpellRare        cterm=underline   ctermfg=black    ctermbg=red
hi SpellCap         cterm=underline   ctermfg=black    ctermbg=green

"make block cursor
let &t_ti.="\e[1 q"
let &t_SI.="\e[5 q"
let &t_EI.="\e[1 q"
let &t_te.="\e[0 q"

In the provided configuration, the Gruvbox color scheme is used to define various highlight groups for different elements such as the cursor line, cursor column, status line, search results, and more. Additionally, custom mappings are set to make the cursor block-shaped.

Customizing color highlighting settings allows users to create a visually appealing and personalized editing environment in Vim, enhancing readability and productivity.

7: Search and Additional Settings

Search functionality in Vim is essential for navigating through documents and finding specific text patterns efficiently. By configuring search settings, users can enhance their searching experience and streamline their workflow. Additionally, there are various other settings that can further customize Vim to suit individual preferences and automate certain tasks.

Below are some search-related settings and additional configurations commonly used in Vim:



" Search
set incsearch       " Find the next match as we type the search
set hlsearch        " Highlight searches by default
set ignorecase      " Ignore case when searching...
set smartcase       " ...unless we type a capital

" even more settings
" -----------------------------------------------------------------------------
"
" Automatically deletes all trailing whitespace on save.
autocmd BufWritePre * %s/\s\+$//e
" remember last position
if has("autocmd")
  au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
endif

" set current directory to the directory of the current file
autocmd BufEnter * if expand("%:p:h") !~ '^/tmp' | silent! lcd %:p:h | endif


" IDE BAR
nnoremap <silent><leader>k :execute 'set showtabline=' . (&showtabline ==# 2 ? 0 : 2)<CR>

" wordcount
function! WC()
    let filename = expand("%")
    let cmd = "detex " . filename . " | wc -w | tr -d '[:space:]'"
    let result = system(cmd)
    echo result . " words"
endfunction

command WC call WC()

In the provided configuration, search settings such as incsearch and hlsearch are enabled to enhance the search experience by highlighting matches and displaying search results as you type. Additionally, settings like ignorecase and smartcase are configured to ignore case when searching, except when typing capital letters.

Furthermore, additional settings are applied to automate tasks such as deleting trailing whitespace on save and remembering the last cursor position when reopening files.

Customizing these settings allows users to optimize their searching experience and tailor Vim to their specific preferences and workflow.

8: Custom Functions for File and Command History Management

In Vim, custom functions provide a powerful way to automate tasks and enhance productivity. Below are three custom functions designed to streamline file and command history management:

    

" this function is a great way to open old files
function! Output()
  enew | 0put =v:oldfiles| nnoremap <buffer> <CR> :e <C-r>=getline('.')<CR><CR>|normal gg<CR>
  setlocal buftype=nofile bufhidden=wipe noswapfile nowrap
  nnoremap <buffer> <down> j
  nnoremap <buffer> <up> k
endfunction
:command! Mm     call Output()
:command! MM     call Output()

function! OutputCommands()
  let history = []
  for i in range(histnr(':'), 1, -1)
    call add(history, histget(':', i))
  endfor
  enew
  call append(0, history)
  normal gg
  setlocal buftype=nofile bufhidden=wipe noswapfile nowrap
  "nnoremap <buffer> <CR> :call setreg('+', getline('.'))<CR>
  nnoremap <buffer> <CR> :let command = getline('.') | bnext | execute command<CR>
  nnoremap <buffer> <down> j
  nnoremap <buffer> <up> k
endfunction

:command! Cc     call OutputCommands()
:command! CC     call OutputCommands()

function! OutputRegs()
    " Create a new buffer
    enew
    setlocal buftype=nofile bufhidden=wipe noswapfile nowrap
    " Append content of non-empty registers a to z
    for reg in range(char2nr('a'), char2nr('z'))
        let reg_char = nr2char(reg)
        let reg_content = getreg(reg_char)
        if !empty(reg_content)
            call append(line('$'), [reg_char .":" , reg_content])
            call append(line('$'), "")
        endif
    endfor
    " Move the cursor to the beginning of the buffer
    normal gg
    " Output message
    echo "Contents of registers a to z "
endfunction

:command! Rr     call OutputRegs()
:command! RR     call OutputRegs()

•Output: This function opens a new buffer to display a list of old files, allowing easy navigation and reopening of previous documents.

•OutputCommands: This function creates a new buffer to display the command history, enabling users to review and execute previous commands.

•OutputRegs: This function generates a new buffer to display the contents of registers a to z, providing a convenient way to access and manage stored text snippets.

These custom functions offer efficient ways to handle file and command history, as well as manage text snippets stored in registers. For detailed explanations and usage examples of each function, refer to the following articles:

•Exploring the Output Function For a Better Vim Old Files

•Mastering OutputCommands for Command History Management

•Understanding Vim Registers and Advanced Usage

•Deep Dive into OutputRegs for Register Management

By incorporating these custom functions into your Vim workflow, you can optimize your editing experience and maximize efficiency.

Plugin Configurations

1: FZF Settings

FZF is a powerful command-line fuzzy finder that integrates seamlessly with Vim, providing quick and efficient file and buffer navigation. Below are some configurations commonly used to enhance the FZF experience:



" fzf settings
" -----------------------------------------------------------------------------
"
" Map a few common things to do with FZF.
nnoremap <silent> <Leader>, :Buffers<CR>
nnoremap <silent> <Leader>s :Files<CR>
nnoremap <silent> <Leader>j :Lines<CR>
nnoremap <silent> <Leader>h :Commands<CR>
nnoremap <silent> <Leader><leader> :History<CR>

" set filetypes

autocmd BufEnter,BufNew,BufNewFile,BufRead *.tex set ft=tex
autocmd BufEnter,BufNew,BufNewFile,BufRead *.cpp set ft=cpp
autocmd BufEnter,BufNew,BufNewFile,BufRead *.c set ft=c

In the provided configuration, key mappings are defined to quickly access FZF functionality for navigating buffers, files, lines, and command history. Additionally, filetypes are set automatically for specific file extensions to ensure proper syntax highlighting and formatting in Vim.

These configurations streamline the usage of FZF within Vim, enabling faster and more intuitive navigation through buffers and files.

2: Completion and YouCompleteMe

Completion in Vim is essential for enhancing productivity by providing suggestions and auto-completion for commands, keywords, and file paths. YouCompleteMe (YCM) is a popular plugin that offers intelligent code completion capabilities in Vim. Below are configurations commonly used to optimize completion settings and integrate YouCompleteMe:



" Completion
" .............................................................................

set wildmode=list:longest
set wildmenu                "enable ctrl-n and ctrl-p to scroll thru matches
set wildignore=*.o,*.obj,*~ "stuff to ignore when tab completing
set wildignore+=*vim/backups*
set wildignore+=*sass-cache*
set wildignore+=*DS_Store*
set wildignore+=vendor/rails/**
set wildignore+=vendor/cache/**
set wildignore+=*.gem
set wildignore+=log/**
set wildignore+=tmp/**
set wildignore+=*.png,*.jpg,*.gif

" YouCompleteMe
" .............................................................................

let g:ycm_global_ycm_extra_conf = '~/.vim/bundle/YouCompleteMe/.ycm_extra_conf.py'
let g:ycm_add_preview_to_completeopt = 0
"let g:ycm_autoclose_preview_window_after_insertion = 1
"let g:ycm_autoclose_preview_window_after_completion = 1
let g:ycm_collect_identifiers_from_tags_files = 1
"set tags+=~/.vim/tags/testtags

let g:ycm_key_list_select_completion = ['<Down>']
let g:ycm_key_list_previous_completion = ['<C-k>', '<Up>']
let g:ycm_key_list_accept_completion = ['<C-y>']

" Additional YouCompleteMe config.
let g:ycm_complete_in_comments = 1
let g:ycm_collect_identifiers_from_comments_and_strings = 1
let g:ycm_seed_identifiers_with_syntax = 1

let g:ycm_server_python_interpreter='python3'
map <leader>g :YcmCompleter GoToDefinitionElseDeclaration<CR>

In the provided configuration, completion settings such as wildmode and wildmenu are adjusted to enable enhanced tab completion behavior and ignore certain file patterns. YouCompleteMe integration settings are also defined to customize key mappings and enable additional completion features.

By configuring completion settings and integrating YouCompleteMe, Vim users can enjoy enhanced code completion capabilities and improved productivity in their editing workflows.

Filetype Specific Configurations

Filetype-specific configurations in Vim allow users to customize editor behavior and settings based on the type of file being edited. By organizing configurations into directories such as .vim/after/ftplugin and .vim/ftplugin, users can maintain clean and structured configuration files tailored to specific filetypes.

In the .vim/after/ftplugin directory, users can place configuration files that are sourced after the default filetype plugins. This allows for overriding or extending settings specific to certain filetypes, such as "C" and "C++". Similarly, the .vim/ftplugin directory contains filetype-specific configuration files that are sourced when editing files of corresponding types. For example, configuration files for filetypes like "tex", "php", "sh", "html", and others can be organized here.

Additionally, users can create a .vim/mysnippets folder to store filetype-specific code snippets. These snippets can be quickly inserted into files while editing, providing shortcuts for commonly used code patterns or structures.

If you're interested in delving deeper into each of these filetype-specific configurations, we invite you to keep an eye on this article. We'll continue updating it with more content and detailed explanations, ensuring you have access to the latest insights and configurations for optimizing your Vim experience.

•Exploring Vim Configuration for C and C++ Files (Pending)

•Mastering Vim Configuration for Tex Files (Pending)

•Advanced Vim Configuration for PHP Files (Pending)

•Customizing Vim Configuration for Shell Scripts (Pending)

•Optimizing Vim Configuration for HTML Files (Pending)

Conclusion

In conclusion, Vim is a powerful and versatile text editor that offers extensive customization options to suit individual preferences and workflows. By mastering essential commands, configuring plugins, and leveraging filetype-specific settings, users can optimize their Vim experience for maximum productivity.

Whether you're a seasoned Vim user or just getting started, exploring and experimenting with different configurations can help you tailor Vim to your specific needs and enhance your editing efficiency.

Remember, Vim is more than just a text editor—it's a customizable toolkit that adapts to your workflow and empowers you to edit text like a pro.

Thank you for joining us on this journey through Vim customization. Happy editing!

Mastering Cron Jobs: A Step-by-Step Guide from Beginner to Advanced

2024-04-11T10:51:10+00:00

Introduction:

Cron jobs are an essential part of Unix-based operating systems, allowing users to schedule repetitive tasks to be executed automatically. These tasks can range from simple commands to more complex scripts. In this guide, we'll explore the fundamentals of cron jobs and explain various scheduling options using real-world examples.

1. What is a Cron Job?

A cron job is a time-based job scheduler in Unix-like operating systems. It enables users to schedule tasks to run periodically at fixed times, dates, or intervals without manual intervention.

2. Components of a Cron Job:

Field	Values	Meaning	Examples
Minute	0-59	The minute of the hour	* (every minute), */2 (every 2 minutes)
Hour	0-23	The hour of the day	* (every hour), 18 (6 PM), 0-23/2 (every 2 hours)
Day of the month	1-31	The day of the month	* (every day), */2 (every 2 days), 5 (5th day of the month)
Month	1-12 (or names)	The month of the year	* (every month), 1 (January), */2 (every 2 months), 5 (May)
Day of the week	0-7 (0 and 7 represent Sunday, or use names)	The day of the week	* (every day of the week), 1 (Monday), 0,6 (Sunday and Saturday)

3. Basic Cron Job Syntax:

* * * * * /path/to/command

The syntax consists of five fields separated by spaces. Each field represents a unit of time and specifies when the command should be executed.

4. Explaining Cron Job Fields:

In a cron expression, there are five fields separated by spaces. Each field represents a different unit of time and determines when the command will be executed. Here's an explanation of each field:

Minute: Represents the minute of the hour (0-59). For example, if you specify `30` in this field, the command will run at the 30th minute of every hour.
Hour: Represents the hour of the day (0-23). If you specify `3` in this field, the command will run at 3:00 AM.
Day of Month: Represents the day of the month (1-31). If you specify `1`, the command will run on the 1st day of every month.
Month: Represents the month of the year (1-12 or names). If you specify `3` or `March`, the command will run in March.
Day of Week: Represents the day of the week (0-7 or names, where 0 and 7 represent Sunday). If you specify `5` or `Friday`, the command will run on Fridays.

By combining these fields with specific values or wildcards (*), you can create precise schedules for your cron jobs.

5. Examples of Common Cron Jobs:

    

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
# |  |  |  |  |
# *  *  *  *  *  /path/to/command to be executed
  0 18  *  *  *  /path/to/command    # every day at 18:00
 30 18  *  *  *  /path/to/command    # every day at 18:30
  0  0  1  *  *  /path/to/command    # every 1st of month (evey month)
  0  0  1  1  *  /path/to/command    # every 1 of month 1 (January) ie every year
  0  0  5  1  *  /path/to/command    # every 5th of month 1 (January) ie every year
  0  0  5  *  *  /path/to/command    # every 5th of every month

6. Other Symbols in Cron Expressions:

•Comma (,): Specifies a list of values within a field. Example: 0 0 1,15 * * /path/to/command (Runs on the 1st and 15th day of every month)

•Hyphen (-): Specifies a range of values within a field. Example: 0 9-17 * * * /path/to/command (Runs every hour from 9:00 AM to 5:00 PM)

•Slash (/): Specifies increments within a field. Example: */10 * * * * /path/to/command (Runs every 10 minutes)

7. More examples of Cron Jobs:

    

# More example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7)
# |  |  |  |  |
# *  *  *  *  *  /path/to/command to be executed
*/2  *  *  *  *  /path/to/command    # Every 2 Minutes
  5  0  *  *  *  $HOME/bin/daily.job >> $HOME/tmp/out 2>&1  # run five minutes after midnight, every day

 15 14  1  *  *     $HOME/bin/monthly   # run at 2:15pm on the first of every month
  0 22  *  * 1-5    /path/to/command  # run at 10 pm on weekdays, annoy Joe
23 0-23/2 * * *     echo "run 23 minutes after midn, 2am, 4am ..., everyday"
  5  4  *  * sun    echo "run at 5 after 4 every sunday"

  0  0  1  1  *   [[ $(date "+\%Y") == 2030 ]] &&/path/to/command1
  0  0  1  1  *   (( $(date "+\%Y") % 3 == 0  )) &&/path/to/command2
  0  0  1  1  *   (( $(date "+\%Y") % 3 == 1  )) &&/path/to/command3

command1 will run on the 2030-01-01T00:00:00
command2 will run every 3 years ( every year number multiple of 3) on the first of January at midnight, it will run on 2019, 2022, 2025, ... .
command3 does the same as command2 but has one year offset, i.e. 2020, 2023, 2026, ...

note: don't forget that you have to escape the -character (%) in your crontab file:

The "sixth" field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or a "%" character, will be executed by /bin/sh or by the shell specified in the SHELL variable of the cronfile. A "%" character in the command, unless escaped with a backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input.

— source: man 5 crontab

8. Adding Jobs with Crontab:

You can add new cron jobs using the crontab command. Follow these steps:

1 • Open the Crontab Editor: To edit your crontab file, enter the following command in your terminal:
crontab -e

2 • Add Your Cron Job: In the crontab editor, add a new line for your cron job. Each line represents a separate cron job.

3 • Save and Exit: After adding your cron job, save the changes and exit the crontab editor. The specific steps to save and exit depend on the text editor you're using.

4 • Once you've added your cron job, it will be saved and scheduled to run according to the specified schedule. You can verify that your cron job has been added by running crontab -l to list all cron jobs associated with your user account.

Remember to be cautious when editing the crontab file, as incorrect entries can lead to unexpected behavior or errors.

9. Conclusion:

In this guide, we've covered the fundamentals of cron jobs, including their purpose, syntax, and common scheduling options. Cron jobs are powerful tools for automating repetitive tasks in Unix-like operating systems, and understanding how to use them effectively can greatly enhance productivity.

By mastering the syntax and scheduling options of cron jobs, users can streamline their workflow and ensure that routine tasks are executed reliably and efficiently. With the examples provided in this guide, beginners can start leveraging cron jobs to automate tasks and save time.

Stay Tuned:

Stay tuned for more guides and tutorials.

Master Mobile Testing: Access Your Website on Local Network

2024-04-09T13:49:13+00:00

As web developers, ensuring that our websites function flawlessly across all devices is paramount. While testing on desktop browsers is relatively straightforward, mobile testing presents its own set of challenges. One effective approach is to open the website on mobile devices within the same network. In this guide, we'll explore the necessary steps to achieve this across various web development frameworks.

Understanding Ports and HTTP Servers

HTTP servers, such as Apache, Flask, Django, and Laravel, listen to specific ports for incoming connections. These ports need to be accessible within the local network for other devices to connect to the server. Let's take a closer look at how this is configured in some common setups:

1. Apache HTTP Server

Apache's configuration file (httpd.conf) contains directives specifying the ports it listens to. For example:

Listen 80
Listen 81
Listen 8081
...

This indicates that Apache is listening on ports 80, 81, 8081, and so on. Ensure that your firewall settings allow inbound connections to these ports.

2. Flask Application

For a Flask application, it's crucial to run the server in a way that makes it accessible to other devices on the network. This can be achieved using the --host and --port flags:

flask run --host=0.0.0.0 --port=5000

This command binds the Flask server to all network interfaces (0.0.0.0) and listens on port 5000.

3. Other Frameworks (Django, Laravel, etc.)

Similarly, other frameworks like Django and Laravel provide options to specify the host and port when running the development server. Consult the respective documentation for the exact commands, but typically, they follow a similar pattern to Flask.

Obtaining the Machine's IP Address

To access the website from mobile devices, you'll need to know the IP address of the machine hosting the server. You can obtain this information using various commands depending on your operating system:

• Using ifconfig:

ifconfig | grep inet | awk 'NR==1{print $2}'

• Using hostname:

hostname -I | cut -d ' ' -f 1

• Using ip:

ip addr show | grep inet | grep -v 'inet6' | awk '{print $2}' | cut -d '/' -f 1

Choose the appropriate command based on your Linux distribution. These commands will provide the IP address of your machine, necessary for accessing the website from mobile devices on the same network.

Accessing the Website on Mobile Devices

Once you have the machine's IP address and the port on which the server is running, you can access the website from any device on the same network. Simply open a mobile browser and enter the IP address followed by the port number, like so:

192.168.1.10:8085

Replace 192.168.1.10 with the actual IP address of your machine and 8085 with the port number your server is listening on.

Conclusion

Testing websites on mobile devices within the same network is essential for ensuring a seamless user experience across all platforms. By understanding how HTTP servers listen to ports and configuring them accordingly, along with obtaining the machine's IP address and accessing the website from mobile devices, developers can efficiently test and debug their web applications. With these techniques, you can confidently deploy mobile-friendly websites that cater to a diverse audience.

Enhancing Quranic Study with a Command-Line Quran Search and Display Script

2024-04-08T23:32:18+00:00

Your browser does not support the video tag.

In the modern digital age, technology plays a significant role in facilitating various aspects of religious study and practice. Among the numerous religious texts revered by millions worldwide, the Quran holds a central position in Islam. To aid in the exploration and comprehension of this sacred scripture, a novel approach emerges—a command-line Quran search and display script. This article delves into the functionality, usage, and significance of such a tool in the context of Quranic study.

Understanding the Script

    

script_dir=$(dirname "$0")
file1="$script_dir/quran-simple-clean.txt"
file2="$script_dir/quran-uthmani.txt"
file3="$script_dir/chapters-simple.txt"
quran_text="$(paste -d'|' "$file1" "$file2" )"

# the command-line arguments
number1=$1
number2=$2
number3=$3

print_lines() {
chapter_name=$(sed -n "$2"p "$file3" )
echo "$1" | awk -F '|' -v num1="$2" -v num2="$3" -v num3="$4" -v chap="$chapter_name" \
    '{
        if ((num3 != "") && ($1 == num1) && ($2 >= num2) && ($2 <= num3)) {
       printf("(\033[1;31m %d %s\033[1;0m) %s\n",$5,chap,$6);
        } else if ((num2 != "") && (num3 == "") && ($1 == num1) && ($2 == num2)) {
       printf("(\033[1;31m %d %s\033[1;0m) %s\n",$5,chap,$6);
        } else if ((num2 == "") && (num3 == "") && ($1 == num1)) {
       printf("(\033[1;31m %d %s\033[1;0m) %s\n",$5,chap,$6);
        }
    }'
}

if [[ $1 == h ]] ; then
    echo "Usage:
$(basename "$0")
$(basename "$0")  g   open with uthmani Quran in gedit
$(basename "$0")  [sourah/chapter] [num1] [num2]"
    exit
fi

if [[ $1 == g ]] ; then
    nohup gedit "$file2" </dev/null >/dev/null 2>&1 &
    exit
fi

number='^[0-9]+$'
if [[ "$1" =~ $number ]] ; then
    if [ -z "$number2" ]; then
        text=$(print_lines "$quran_text" "$number1")
    elif [[ -z "$number3" ]]; then
        text=$(print_lines "$quran_text" "$number1" "$number2")
    else
        text=$(print_lines "$quran_text" "$number1" "$number2" "$number3")
    fi
    if [[ $@ == *g* ]]
    then
        echo "$text" > /tmp/quran_result
        nohup gedit "/tmp/quran_result" </dev/null >/dev/null 2>&1 &
    else
        echo "$text"
    fi
else
    xkb-switch -s ara
    pkill -RTMIN+12 i3blocks
    pattern=$( zenity --entry --text="Search Holy Quran:" \
        --title="search Holy Quran" --width=500 --timeout=30)
    xkb-switch -s fr
    pkill -RTMIN+12 i3blocks

    if [[ -n $pattern ]] ; then
       results="$(echo "$quran_text" | grep --color=always "$pattern")"

       if [[ -n $results ]]
           then resuls_count=$(echo "$results" | wc -l)
           else resuls_count=0
       fi
       echo "searching : $pattern"
       echo "================================"
       echo "$resuls_count found"
       echo "================================"
       echo "$results" > /tmp/quran_result
       awk -F'|' '
        NR==FNR {chap[FNR]=$0; next}
        {printf("(\033[1;31m %d %s\033[1;0m) %s\n",$5,chap[$1],$6);}
       ' "$file3"  /tmp/quran_result
    fi
fi

The command-line Quran search and display script is a versatile tool designed to streamline the process of accessing and studying verses from the Quran. Written in the Bash scripting language, this script leverages a combination of Unix commands such as 'sed', 'awk', 'paste', 'zenity', and 'xkb-switch' to provide users with a seamless experience.

Features and Usage

Your browser does not support the video tag.

The script offers several features tailored to cater to the diverse needs of users engaging with the Quran:

• Interactive Search: Users can initiate an interactive search prompt, enabling them to search for specific keywords or phrases within the Quranic text.

• Verse Display: By providing chapter and verse numbers as command-line arguments, users can display specific verses from the Quran.

• Visual Enhancement: The script incorporates color-coded output for improved readability, enhancing the user experience during verse display.

• Integration with Text Editor: Users can seamlessly open the Uthmani version of the Quran in the 'gedit' text editor directly from the command line.

Significance in Quranic Study

The command-line Quran search and display script serves as a valuable tool for both scholars and enthusiasts alike:

• Accessibility: By offering a command-line interface, the script provides accessibility to users across various platforms without the need for complex software installations.

• Efficiency: With its streamlined search and display capabilities, the script enables users to quickly retrieve and study specific verses, enhancing the efficiency of Quranic study sessions.

• Customization: The script's modular design allows for easy customization and adaptation to specific study preferences or requirements, catering to the diverse needs of users.

GitHub Repository

The script along with the Quran text files can be found in the GitHub repository: https://github.com/neoMOSAID/quran-search. Users can access, contribute, and provide feedback on the script and its associated resources.

Conclusion

In the realm of Quranic study, the command-line Quran search and display script emerges as a versatile and efficient tool, empowering users to delve deeper into the sacred text with ease and convenience. Its integration of modern technology with traditional scholarship exemplifies the harmonious intersection of faith and innovation, facilitating a richer and more immersive Quranic study experience for all.

How to Use the date Command in Linux: Complete Guide and Examples

2024-04-07T20:03:26+00:00

The date command in Linux is a versatile tool used for displaying and formatting date and time information. Whether you need to display the current date and time, manipulate dates, or format them in a specific way, date has you covered. In this tutorial, we'll explore various use cases and formats of the date command to help you become proficient in its usage.

Displaying the Current Date and Time

To display the current date and time, simply run the date command without any arguments:



date

Output:

Wed Apr  6 22:05:24 UTC 2024

Formatting Date and Time

Basic Formatting

You can format the output of date using format specifiers. For example, to display the date in YYYY-MM-DD format:



date '+%Y-%m-%d'

Output:

2024-04-06

Customized Formats

You can customize the output further by combining different format specifiers. For instance:



date '+%A, %B %d, %Y - %H:%M:%S'

Output:

Wednesday, April 06, 2024 - 22:05:24

Manipulating Dates

Adding or Subtracting Days

To manipulate dates by adding or subtracting days, use the --date option:



# Add 1 day to the current date
date --date "+1 days"

Output:

Thu Apr  7 22:05:24 UTC 2024



# Subtract 307 days from the current date
date -d '-307 days'

Output:

Tue May  3 22:05:24 UTC 2023

Displaying Dates Relative to Today

You can display dates relative to today using expressions like "today" or "last Monday":



# Display the date of the last Monday
date -d 'last Monday'

Output:

Mon Apr  3 00:00:00 UTC 2024

Localization

The LC_ALL environment variable can be used to specify the locale for date formatting:



# Display date in Arabic locale
LC_ALL=ar_MA.utf8 date '+%A %d %h %Y, %H:%M'

Output:

الأربعاء 07 إبريل 2024, 22:05

Conclusion

The date command in Linux offers a wide range of functionalities for displaying, formatting, and manipulating dates and times. By mastering its various options and format specifiers, you can efficiently handle date-related tasks in your shell scripts and command-line operations. Experiment with different combinations of options and formats to suit your specific requirements.