<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://shiraz-ahmad.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://shiraz-ahmad.com/" rel="alternate" type="text/html" /><updated>2026-05-06T13:57:02+00:00</updated><id>https://shiraz-ahmad.com/feed.xml</id><title type="html">Shiraz Ahmad</title><subtitle>Muhammad Shiraz Ahmad - Researcher, educator, programmer, and entrepreneur</subtitle><author><name>Muhammad Shiraz Ahmad</name></author><entry><title type="html">Protecting Research Time with a GPS-Aware MacBook Guard</title><link href="https://shiraz-ahmad.com/projects/productivity/gps-research-time-guard-for-macbook/" rel="alternate" type="text/html" title="Protecting Research Time with a GPS-Aware MacBook Guard" /><published>2026-04-17T00:00:00+00:00</published><updated>2026-04-17T00:00:00+00:00</updated><id>https://shiraz-ahmad.com/projects/productivity/gps-research-time-guard-for-macbook</id><content type="html" xml:base="https://shiraz-ahmad.com/projects/productivity/gps-research-time-guard-for-macbook/"><![CDATA[<p>I have been documenting a small but very practical Hammerspoon project for protecting research time on a MacBook.</p>

<p>GitHub links:</p>

<ul>
  <li>Project repository: <a href="https://github.com/MShirazAhmad/HammerspoonWorkMode">HammerspoonWorkMode</a></li>
  <li>Post source: <a href="https://github.com/MShirazAhmad/NoteBook/blob/master/_posts/2026-04-17-gps-research-time-guard-for-macbook.md">2026-04-17-gps-research-time-guard-for-macbook.md</a></li>
</ul>

<p>The idea is simple:</p>

<ul>
  <li>choose one approved location where real research work happens</li>
  <li>when you are physically sitting in that place, the system stays out of your way</li>
  <li>when you leave that place, the Mac starts enforcing stricter behavior rules</li>
</ul>

<p>That makes the approved place a freedom zone for research, and other places become guarded zones.</p>

<h2 id="what-problem-it-solves">What problem it solves</h2>

<p>The biggest problem was not lack of tools. It was context drift.</p>

<p>At the right location, I may genuinely need everything:</p>

<ul>
  <li>Terminal</li>
  <li>browser tabs</li>
  <li>PDFs</li>
  <li>Overleaf</li>
  <li>coding tools</li>
  <li>research notes</li>
</ul>

<p>But outside that location, the same laptop can easily slide into distraction, low-value browsing, or tool use that looks productive but is really avoidance.</p>

<p>So instead of blocking everything all the time, this project flips the model:</p>

<ul>
  <li>full freedom in the place where serious work happens</li>
  <li>stronger control everywhere else</li>
</ul>

<h2 id="how-it-works">How it works</h2>

<p>The project is built around two modes:</p>

<h3 id="allow"><code class="language-plaintext highlighter-rouge">ALLOW</code></h3>

<p>This mode is active when the machine detects that it is inside one approved GPS area, such as a lab.</p>

<p>In <code class="language-plaintext highlighter-rouge">ALLOW</code> mode:</p>

<ul>
  <li>the system relaxes blocking</li>
  <li>research tools stay usable</li>
  <li>the MacBook can be used freely for writing, reading, coding, analysis, or command-line work</li>
</ul>

<h3 id="block"><code class="language-plaintext highlighter-rouge">BLOCK</code></h3>

<p>This mode is active when the machine is outside the approved location.</p>

<p>In <code class="language-plaintext highlighter-rouge">BLOCK</code> mode:</p>

<ul>
  <li>blocked apps can be closed automatically</li>
  <li>distracting browser tabs can trigger interventions</li>
  <li>full-screen overlays can appear</li>
  <li>activity is logged for later review</li>
  <li>even tools like Terminal can be restricted if they are listed as blocked outside the approved place</li>
</ul>

<h2 id="why-this-framing-matters">Why this framing matters</h2>

<p>I wanted the project documentation to be honest about the intended behavior.</p>

<p>This is not just a generic productivity dashboard.</p>

<p>It is a research-time protection system with one strong promise:</p>

<ul>
  <li>if you are in the place where you truly work, it should not fight you</li>
  <li>if you are outside that place, it should help control how you use the MacBook</li>
</ul>

<p>That includes app behavior, browser behavior, and optional command-line restrictions.</p>

<h2 id="project-structure">Project structure</h2>

<p>The work was split into a modular Hammerspoon layout:</p>

<ul>
  <li><code class="language-plaintext highlighter-rouge">init.lua</code> as the entry point</li>
  <li><code class="language-plaintext highlighter-rouge">location_mode.lua</code> for GPS-based <code class="language-plaintext highlighter-rouge">ALLOW</code> / <code class="language-plaintext highlighter-rouge">BLOCK</code></li>
  <li><code class="language-plaintext highlighter-rouge">schedule.lua</code> for work-hour rules</li>
  <li><code class="language-plaintext highlighter-rouge">app_blocker.lua</code> for non-research app enforcement</li>
  <li><code class="language-plaintext highlighter-rouge">browser_filter.lua</code> for distracting URLs and titles</li>
  <li><code class="language-plaintext highlighter-rouge">activity_classifier.lua</code> for research vs off-task heuristics</li>
  <li><code class="language-plaintext highlighter-rouge">overlay.lua</code> for full-screen warnings and lockouts</li>
  <li><code class="language-plaintext highlighter-rouge">logger.lua</code> for activity and marker logs</li>
  <li><code class="language-plaintext highlighter-rouge">config/default.lua</code> for user-editable settings</li>
</ul>

<p>The documentation was also expanded quite a bit so a non-programmer can follow the setup more easily:</p>

<ul>
  <li>a main setup guide</li>
  <li>a beginner-friendly getting-started guide</li>
  <li>a “fill in these 5 values only” onboarding page</li>
  <li>helper docs for GPS coordinates and app names</li>
  <li>module-by-module plain-English guides</li>
</ul>

<h2 id="the-practical-use-case">The practical use case</h2>

<p>The clearest example is a lab workflow:</p>

<ul>
  <li>choose the lab as the approved GPS location</li>
  <li>when sitting in the lab, use the MacBook however needed for research</li>
  <li>when leaving the lab, let the system become stricter</li>
</ul>

<p>That means the laptop is not permanently locked down. It changes behavior based on where work is actually happening.</p>

<h2 id="why-i-like-this-approach">Why I like this approach</h2>

<p>I like this model because it does not pretend every context is the same.</p>

<p>A browser is not always a distraction.
Terminal is not always a distraction.
Even coding tools are not always productive.</p>

<p>The important question is not just <strong>what app is open</strong>, but also <strong>where am I and what kind of work context am I in</strong>.</p>

<p>That makes location a surprisingly strong signal for protecting research time without making the machine unbearable to use.</p>

<p>If you want to browse the code or setup guides directly, the full project lives on GitHub here: <a href="https://github.com/MShirazAhmad/HammerspoonWorkMode">MShirazAhmad/HammerspoonWorkMode</a>.</p>]]></content><author><name>Muhammad Shiraz Ahmad</name></author><category term="Projects" /><category term="Productivity" /><category term="Hammerspoon" /><category term="macOS" /><category term="Research" /><category term="Productivity" /><category term="Automation" /><summary type="html"><![CDATA[A write-up of a Hammerspoon-based project that gives full freedom in one approved research location and tighter behavior control everywhere else.]]></summary></entry><entry><title type="html">Publisher-Style Tracked Revisions with latexdiff</title><link href="https://shiraz-ahmad.com/latex/publishing/latexdiff-publisher-style-tracked-revisions/" rel="alternate" type="text/html" title="Publisher-Style Tracked Revisions with latexdiff" /><published>2026-04-16T00:00:00+00:00</published><updated>2026-04-16T00:00:00+00:00</updated><id>https://shiraz-ahmad.com/latex/publishing/latexdiff-publisher-style-tracked-revisions</id><content type="html" xml:base="https://shiraz-ahmad.com/latex/publishing/latexdiff-publisher-style-tracked-revisions/"><![CDATA[<p>When journals ask for a “tracked changes” version of a manuscript, LaTeX authors usually reach for <code class="language-plaintext highlighter-rouge">latexdiff</code>. The output can look a little mysterious at first because the generated file is full of commands such as <code class="language-plaintext highlighter-rouge">\DIFadd</code>, <code class="language-plaintext highlighter-rouge">\DIFdel</code>, <code class="language-plaintext highlighter-rouge">\DIFaddFL</code>, and <code class="language-plaintext highlighter-rouge">\DIFdelbeginFL</code>. This post explains what those commands are doing, why they exist, and how to think about them in a revision workflow.</p>

<p>GitHub links:</p>

<ul>
  <li>Post source: <a href="https://github.com/MShirazAhmad/NoteBook/blob/master/_posts/2026-04-16-latexdiff-publisher-style-tracked-revisions.md">2026-04-16-latexdiff-publisher-style-tracked-revisions.md</a></li>
  <li>Site repository: <a href="https://github.com/MShirazAhmad/NoteBook">MShirazAhmad/NoteBook</a></li>
</ul>

<h2 id="the-core-idea">The core idea</h2>

<p>These commands are not meant for everyday writing. They are revision-markup commands.</p>

<p>Their job is to turn the difference between an older manuscript and a revised manuscript into a PDF that behaves like tracked changes in a word processor:</p>

<ul>
  <li>added text is visibly marked</li>
  <li>deleted text stays visible long enough for review</li>
  <li>larger inserted or removed regions can be grouped as blocks</li>
  <li>the resulting PDF stays readable and submission-friendly</li>
</ul>

<p>In that sense, they are the LaTeX implementation layer behind a publisher-style marked revision.</p>

<h2 id="a-minimal-setup">A minimal setup</h2>

<p>Here is a compact version of the command definitions:</p>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFadd</span><span class="p">}</span>[1]<span class="p">{{</span><span class="k">\color</span><span class="p">{</span>blue<span class="p">}</span>#1<span class="p">}}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdel</span><span class="p">}</span>[1]<span class="p">{{</span><span class="k">\color</span><span class="p">{</span>red<span class="p">}</span><span class="k">\sout</span><span class="p">{</span>#1<span class="p">}}}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddbegin</span><span class="p">}{</span><span class="k">\begingroup\color</span><span class="p">{</span>blue<span class="p">}}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddend</span><span class="p">}{</span><span class="k">\endgroup</span><span class="p">}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelbegin</span><span class="p">}{</span><span class="nt">\begin{DIFdelblockbox}</span><span class="k">\color</span><span class="p">{</span>red<span class="p">}}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelend</span><span class="p">}{</span><span class="nt">\end{DIFdelblockbox}</span><span class="p">}</span>

<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddFL</span><span class="p">}</span>[1]<span class="p">{</span><span class="k">\DIFadd</span><span class="p">{</span>#1<span class="p">}}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelFL</span><span class="p">}</span>[1]<span class="p">{</span><span class="k">\DIFdel</span><span class="p">{</span>#1<span class="p">}}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddbeginFL</span><span class="p">}{</span><span class="k">\DIFaddbegin</span><span class="p">}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddendFL</span><span class="p">}{</span><span class="k">\DIFaddend</span><span class="p">}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelbeginFL</span><span class="p">}{</span><span class="k">\DIFdelbegin</span><span class="p">}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelendFL</span><span class="p">}{</span><span class="k">\DIFdelend</span><span class="p">}</span>
</code></pre></div></div>

<p>The important distinction is:</p>

<ul>
  <li><code class="language-plaintext highlighter-rouge">\DIFadd{...}</code> and <code class="language-plaintext highlighter-rouge">\DIFdel{...}</code> are inline markup</li>
  <li><code class="language-plaintext highlighter-rouge">\DIFaddbegin ... \DIFaddend</code> and <code class="language-plaintext highlighter-rouge">\DIFdelbegin ... \DIFdelend</code> are block markup</li>
  <li>the <code class="language-plaintext highlighter-rouge">FL</code> variants are float-safe or float-oriented wrappers used by <code class="language-plaintext highlighter-rouge">latexdiff</code></li>
</ul>

<h2 id="inline-additions-and-deletions">Inline additions and deletions</h2>

<p>For small changes inside ordinary prose, the base commands are the clearest.</p>

<h3 id="added-text">Added text</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code>The experiment showed <span class="k">\DIFadd</span><span class="p">{</span>clear evidence of pore coarsening<span class="p">}</span>.
</code></pre></div></div>

<p>This reads naturally in the diff PDF: the sentence remains intact, and the inserted phrase is highlighted inline.</p>

<h3 id="deleted-text">Deleted text</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code>This method is <span class="k">\DIFdel</span><span class="p">{</span>probably<span class="p">}</span> sufficient for preliminary screening.
</code></pre></div></div>

<p>This works best when the deleted phrase is short and meaningful on its own. For deletion examples, plain text is safer than embedding raw math syntax inside <code class="language-plaintext highlighter-rouge">\DIFdel{...}</code>.</p>

<h2 id="what-the-fl-commands-are-for">What the FL commands are for</h2>

<p>The <code class="language-plaintext highlighter-rouge">FL</code> variants exist because not every LaTeX context tolerates ordinary markup equally well. Floats, captions, and some moving arguments can be fragile. So <code class="language-plaintext highlighter-rouge">latexdiff</code> sometimes replaces the standard commands with:</p>

<ul>
  <li><code class="language-plaintext highlighter-rouge">\DIFaddFL{...}</code></li>
  <li><code class="language-plaintext highlighter-rouge">\DIFdelFL{...}</code></li>
  <li><code class="language-plaintext highlighter-rouge">\DIFaddbeginFL ... \DIFaddendFL</code></li>
  <li><code class="language-plaintext highlighter-rouge">\DIFdelbeginFL ... \DIFdelendFL</code></li>
</ul>

<p>In many cases, you can read them the same way as the non-<code class="language-plaintext highlighter-rouge">FL</code> versions. The difference is mostly about where <code class="language-plaintext highlighter-rouge">latexdiff</code> decided it needed a safer wrapper.</p>

<h2 id="why-difdelbeginfl-may-appear-to-do-nothing">Why <code class="language-plaintext highlighter-rouge">\DIFdelbeginFL</code> may appear to “do nothing”</h2>

<p>This is one of the biggest sources of confusion.</p>

<p>By default, <code class="language-plaintext highlighter-rouge">latexdiff</code> often uses a float style called <code class="language-plaintext highlighter-rouge">FLOATSAFE</code>. In that style, the block-level <code class="language-plaintext highlighter-rouge">FL</code> commands can be empty:</p>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddbeginFL</span><span class="p">}{}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddendFL</span><span class="p">}{}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelbeginFL</span><span class="p">}{}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelendFL</span><span class="p">}{}</span>
</code></pre></div></div>

<p>That means block markup inside floats may not show a visible enclosing effect, even though inline changes like <code class="language-plaintext highlighter-rouge">\DIFdelFL{...}</code> still render.</p>

<p>If you want the <code class="language-plaintext highlighter-rouge">FL</code> block commands to behave like the regular block commands, the conceptual model is <code class="language-plaintext highlighter-rouge">IDENTICAL</code> float style:</p>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddbeginFL</span><span class="p">}{</span><span class="k">\DIFaddbegin</span><span class="p">}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFaddendFL</span><span class="p">}{</span><span class="k">\DIFaddend</span><span class="p">}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelbeginFL</span><span class="p">}{</span><span class="k">\DIFdelbegin</span><span class="p">}</span>
<span class="k">\providecommand</span><span class="p">{</span><span class="k">\DIFdelendFL</span><span class="p">}{</span><span class="k">\DIFdelend</span><span class="p">}</span>
</code></pre></div></div>

<p>With that approach, <code class="language-plaintext highlighter-rouge">\DIFdelbeginFL ... \DIFdelendFL</code> inherits the same block-level revision behavior as <code class="language-plaintext highlighter-rouge">\DIFdelbegin ... \DIFdelend</code>.</p>

<h2 id="block-revisions">Block revisions</h2>

<p>Sometimes a whole sentence or paragraph has changed enough that treating it as a block is clearer.</p>

<h3 id="added-block">Added block</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">\DIFaddbeginFL</span>
This paragraph introduces a new interpretation of the densification pathway.
It emphasizes that transport limitation may emerge only after reaction
completion is independently verified.
<span class="k">\DIFaddendFL</span>
</code></pre></div></div>

<p>This is useful when the revision is conceptual rather than just lexical.</p>

<h3 id="deleted-block">Deleted block</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">\DIFdelbeginFL</span>
The previous draft referred to fully uniform reaction completion
without discussing spatial resolution limits.
<span class="k">\DIFdelendFL</span>
</code></pre></div></div>

<p>For robust rendering, I prefer a boxed deleted-block presentation for paragraph-scale deletions rather than trying to force paragraph-wide strikeout through every LaTeX context. Inline deletions can still use strikeout, while block deletions get a stable visual container.</p>

<h2 id="citations-inside-revised-prose">Citations inside revised prose</h2>

<p>Citations are common in revised text, and the best pattern is usually to mark only the changed words, not the citation command.</p>

<h3 id="addition-near-a-citation">Addition near a citation</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Recent work supports <span class="k">\DIFadd</span><span class="p">{</span>pressure-sensitive pore evolution<span class="p">}</span>
in reactive carbide systems~<span class="k">\cite</span><span class="p">{</span>exampleRefA<span class="p">}</span>.
</code></pre></div></div>

<h3 id="deletion-near-a-citation">Deletion near a citation</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code>This mechanism is <span class="k">\DIFdel</span><span class="p">{</span>probably<span class="p">}</span> dominant at early times~<span class="k">\cite</span><span class="p">{</span>exampleRefB<span class="p">}</span>.
</code></pre></div></div>

<p>That keeps the claim and its reference together while making the actual wording change obvious.</p>

<h3 id="compiled-output">Compiled output</h3>

<p><img src="/assets/images/latexdiff/latexdiff-full-example-1.png" alt="Compiled page showing the introduction and base latexdiff command explanations." />
<em>The compiled PDF begins by framing these macros as publisher-style tracked revisions rather than normal writing commands.</em></p>

<h2 id="captions">Captions</h2>

<p>Captions are real prose, so <code class="language-plaintext highlighter-rouge">latexdiff</code> often marks them word by word.</p>

<h3 id="added-caption-wording">Added caption wording</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">\caption</span><span class="p">{</span>Cross-sectional micrograph showing
<span class="k">\DIFadd</span><span class="p">{</span>enhanced pore rounding at higher pressure<span class="p">}</span>.<span class="p">}</span>
</code></pre></div></div>

<h3 id="deleted-caption-wording">Deleted caption wording</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">\caption</span><span class="p">{</span>Time-resolved image of the pellet
<span class="k">\DIFdel</span><span class="p">{</span>under fully uniform conversion conditions<span class="p">}</span>.<span class="p">}</span>
</code></pre></div></div>

<p>This is usually exactly what you want in a review PDF, because it lets a reviewer see whether the interpretation of the figure changed.</p>

<p><img src="/assets/images/latexdiff/latexdiff-full-example-3.png" alt="Compiled page showing inline add/delete examples and the start of FL command coverage." />
<em>Inline additions and deletions are easy to scan in the rendered PDF, which is why they work well for submission-ready revision markup.</em></p>

<h2 id="figure-environments-and-fl-commands">Figure environments and FL commands</h2>

<p>Inside floats, <code class="language-plaintext highlighter-rouge">latexdiff</code> may switch to the <code class="language-plaintext highlighter-rouge">FL</code> variants automatically.</p>

<h3 id="addition-inside-a-figure">Addition inside a figure</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt">\begin{figure}</span>[ht]
  <span class="k">\centering</span>
  <span class="k">\fbox</span><span class="p">{</span><span class="k">\rule</span><span class="p">{</span>0pt<span class="p">}{</span>1.2in<span class="p">}</span><span class="k">\rule</span><span class="p">{</span>0.65<span class="k">\linewidth</span><span class="p">}{</span>0pt<span class="p">}}</span>
  <span class="k">\DIFaddbeginFL</span>
  <span class="k">\caption</span><span class="p">{</span>Revised workflow including
  <span class="k">\DIFaddFL</span><span class="p">{</span>a verification step after synthesis<span class="p">}</span>.<span class="p">}</span>
  <span class="k">\DIFaddendFL</span>
<span class="nt">\end{figure}</span>
</code></pre></div></div>

<h3 id="deletion-inside-a-figure">Deletion inside a figure</h3>

<div class="language-tex highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nt">\begin{figure}</span>[ht]
  <span class="k">\centering</span>
  <span class="k">\fbox</span><span class="p">{</span><span class="k">\rule</span><span class="p">{</span>0pt<span class="p">}{</span>1.2in<span class="p">}</span><span class="k">\rule</span><span class="p">{</span>0.65<span class="k">\linewidth</span><span class="p">}{</span>0pt<span class="p">}}</span>
  <span class="k">\caption</span><span class="p">{</span>Pressure-dependent morphology map with
  <span class="k">\DIFdelFL</span><span class="p">{</span>a fully uniform conversion assumption<span class="p">}</span>.<span class="p">}</span>
<span class="nt">\end{figure}</span>
</code></pre></div></div>

<p>That second pattern is especially useful because it avoids fragile nested block deletion inside a caption while still making the deleted wording visible.</p>

<p><img src="/assets/images/latexdiff/latexdiff-full-example-5.png" alt="Compiled page showing deleted-block and citation-aware revision examples." />
<em>Block-level deletions and citation-containing prose can still be presented cleanly in a review copy when the markup is structured carefully.</em></p>

<p><img src="/assets/images/latexdiff/latexdiff-full-example-7.png" alt="Compiled page showing figure-environment examples using FL commands." />
<em>Inside figure environments, the FL variants show how <code>latexdiff</code> preserves visible revision markup in float-related contexts.</em></p>

<h2 id="practical-advice">Practical advice</h2>

<ul>
  <li>Use <code class="language-plaintext highlighter-rouge">\DIFadd{...}</code> and <code class="language-plaintext highlighter-rouge">\DIFdel{...}</code> for small inline edits.</li>
  <li>Use block begin/end pairs when a whole passage was inserted or removed.</li>
  <li>Treat <code class="language-plaintext highlighter-rouge">FL</code> commands as <code class="language-plaintext highlighter-rouge">latexdiff</code>’s context-safe wrappers, especially inside floats.</li>
  <li>Avoid nested delete markup inside a block that is already being treated as a deleted block.</li>
  <li>Prefer robust block presentation for deleted paragraphs instead of forcing paragraph-wide strikeout everywhere.</li>
</ul>

<h2 id="final-takeaway">Final takeaway</h2>

<p>The purpose of these commands is simple: they let LaTeX authors produce the kind of tracked-revision PDF that editors, reviewers, and publishers expect.</p>

<p>If you think of them as “submission-time revision markup” rather than “normal writing commands,” their design becomes much easier to understand:</p>

<ul>
  <li>inline commands show word-level edits</li>
  <li>block commands show passage-level edits</li>
  <li><code class="language-plaintext highlighter-rouge">FL</code> variants help the markup survive in fragile LaTeX contexts</li>
</ul>

<p>That is the real role of <code class="language-plaintext highlighter-rouge">latexdiff</code>: not just comparing two <code class="language-plaintext highlighter-rouge">.tex</code> files, but turning those differences into a review-ready manuscript.</p>]]></content><author><name>Muhammad Shiraz Ahmad</name></author><category term="LaTeX" /><category term="Publishing" /><category term="LaTeX" /><category term="latexdiff" /><category term="Publishing" /><category term="Revisions" /><category term="GitHub Pages" /><summary type="html"><![CDATA[A practical guide to \DIFadd, \DIFdel, and the FL variants used by latexdiff to generate tracked-change PDFs for reviewers and publishers.]]></summary></entry><entry><title type="html">LaTeX Diff from Git Timeline VS Code Extension</title><link href="https://shiraz-ahmad.com/projects/releases/latex-diff-from-git-timeline/" rel="alternate" type="text/html" title="LaTeX Diff from Git Timeline VS Code Extension" /><published>2025-12-11T00:00:00+00:00</published><updated>2025-12-11T00:00:00+00:00</updated><id>https://shiraz-ahmad.com/projects/releases/latex-diff-from-git-timeline</id><content type="html" xml:base="https://shiraz-ahmad.com/projects/releases/latex-diff-from-git-timeline/"><![CDATA[<p>I just published a new VS Code extension: <strong><a href="https://github.com/MShirazAhmad/latex-diff-from-git-timeline">LaTeX Diff from Git Timeline</a></strong>. It lets you visualize how your LaTeX documents evolve by building diffs straight from the git commit history.</p>

<h3 id="what-it-does">What it does</h3>
<ul>
  <li>Shows a commit-by-commit view of your LaTeX files so you can track changes visually.</li>
  <li>Generates diffs using your repository history, making it easy to review edits before merging or sharing PDFs.</li>
  <li>Runs directly inside VS Code—no separate scripts or manual commands needed once configured.</li>
</ul>

<h3 id="why-i-built-it">Why I built it</h3>
<p>Keeping track of LaTeX edits across branches can be tedious. This extension keeps everything inside VS Code, so you can stay focused on writing while still having a clear audit trail of how a document changes over time.</p>

<h3 id="try-it-out">Try it out</h3>
<p>Clone the repository and install the extension locally to give it a spin:</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>git clone https://github.com/MShirazAhmad/latex-diff-from-git-timeline.git
<span class="nb">cd </span>latex-diff-from-git-timeline
npm <span class="nb">install
</span>npm run compile
</code></pre></div></div>

<p>Then load the extension into VS Code from the generated package (<code class="language-plaintext highlighter-rouge">Extensions</code> → <code class="language-plaintext highlighter-rouge">...</code> → <strong>Install from VSIX</strong>) and start diffing your LaTeX files against any commit in the timeline. Feedback and contributions are welcome!</p>

<h3 id="how-to-use-it">How to use it</h3>
<ul>
  <li>Open your LaTeX project in VS Code, and right-click a <code class="language-plaintext highlighter-rouge">.tex</code> file in <strong>Source Control</strong> (Changes/History) or <strong>Explorer</strong>.</li>
  <li>Select <strong>Generate LaTeX Diff</strong>, choose the OLD version, then pick the NEW version (a commit or your working directory).</li>
  <li>The extension writes a <code class="language-plaintext highlighter-rouge">diff_&lt;old&gt;_to_&lt;new&gt;_&lt;file&gt;.tex</code> next to your source file and offers to open it.</li>
  <li>Compile that diff file (<code class="language-plaintext highlighter-rouge">pdflatex diff_...tex</code>) to produce a PDF with tracked changes: additions in blue, deletions in red.</li>
  <li>If you want the PDF to mirror your journal template, compile with the same main document preamble (e.g., <code class="language-plaintext highlighter-rouge">pdflatex -jobname=tracked-change \input{diff_...tex}</code>) so fonts and spacing match.</li>
</ul>

<h3 id="in-editor-selection-flow-screenshots">In-editor selection flow (screenshots)</h3>

<p><img src="/assets/images/latex-diff-context-menu.jpg" alt="Simplified VS Code context menu with &quot;Generate LaTeX Diff&quot; highlighted." />
<em>Right-click any <code class="language-plaintext highlighter-rouge">.tex</code> file in Explorer or Source Control to start the diff workflow without leaving VS Code.</em></p>

<p><img src="/assets/images/latex-diff-select-old-commit.jpg" alt="Stylized VS Code quick pick for &quot;Select OLD commit&quot; highlighting the choice of a historical commit." />
<em>Anchor the older side of the diff by selecting the commit you want to compare against.</em></p>

<p><img src="/assets/images/latex-diff-select-new-commit.jpg" alt="Stylized VS Code quick pick showing the &quot;Select NEW commit&quot; prompt with working directory and recent commits." />
<em>Pick the newer side of the comparison—usually your working directory—to see the latest edits against an earlier commit.</em></p>

<p><img src="/assets/images/latex-diff-from-git-timeline-cover.png" alt="Compiled PDF output demonstrating the final tracked-changes document generated by the extension." />
<em>This is the compiled PDF produced from the generated <code>latexdiff</code> file, showing additions in blue and deletions in red just as journals require.</em></p>

<h3 id="share-or-submit-with-tracked-changes">Share or submit with tracked changes</h3>
<ul>
  <li><strong>Send to collaborators or advisors:</strong> Compile the generated diff file to PDF and share it so reviewers can see all edits in color. The PDF is fully standalone for quick comment rounds.</li>
  <li><strong>Submit to publishers with change markup:</strong> When responding to reviewer comments, generate a diff between the last published commit and your revised draft. The resulting PDF clearly marks insertions/deletions, so you can upload it as the “tracked changes” version many journals request.</li>
  <li><strong>Pre-merge validation:</strong> Before merging a branch, create a diff versus <code class="language-plaintext highlighter-rouge">main</code> to verify all manuscript edits are intentional. This also produces a ready-to-circulate tracked-changes PDF for sign-off.</li>
  <li><strong>Advisory revisions with context:</strong> Pair the diff PDF with your advisor’s comment IDs by generating diffs on specific branches (e.g., <code class="language-plaintext highlighter-rouge">advisor-notes</code> → <code class="language-plaintext highlighter-rouge">revision-v2</code>). Each colored change maps directly to a comment, speeding up approval.</li>
  <li><strong>Camera-ready confidence:</strong> Before final submission, regenerate the diff against the camera-ready branch to ensure no late-stage formatting tweaks slipped in unnoticed.</li>
</ul>]]></content><author><name>Muhammad Shiraz Ahmad</name></author><category term="Projects" /><category term="Releases" /><category term="VS Code" /><category term="LaTeX" /><category term="Git" /><category term="Extensions" /><summary type="html"><![CDATA[Publish announcement for a VS Code extension that visualizes LaTeX changes across git history.]]></summary></entry></feed>