March 31, 2023

A guide to simple and stupid usage of computers for writers (anyone who writes really)

You are free to: share — copy and redistribute the material in any medium or format for any purpose, even commercially. The licensor cannot revoke these freedoms as long as you follow the license terms.

Under the following terms:

Attribution - You must give appropriate credit , provide a link to the license, and indicate if changes were made . You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
NoDerivatives - If you remix, transform, or build upon the material, you may not distribute the modified material.
No additional restrictions - You may not apply legal terms or technological measures (e.g. no DRM) that legally restrict others from doing anything the license permits.

Notices:

You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable exception or limitation .

No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you use the material.

Who should not use this guide
Who may find this guide useful
Introduction
How to read this guide?
The command-line interface a.k.a cli
Use a text editor
Write in plain text with Markdown
Produce your document layout with Pandoc
Merge multiple pdf files
View your files with the programme “less”
Track versions of your work with git
Collaborate with others using git
Back up your work
Final note
About the author
Use Vim

Who should not use this guide

You might not want to use this guide if you:

prefer to use a computer with a mouse (or a trackpad) rather than using shortcuts (the keyboard)
think that, in computing, you can get things your way as long as you pay (money) for software
value convenience over agency

Who might find this guide useful

You might find this guide useful if you:

would like to keep your fingers on the keyboard (rather than fidgeting with the mouse)
are okay spending a bit of time understanding how you can do things if it means you can do things quickly afterwards
are curious about the terminal, a.k.a. the shell.

Introduction

The sheer number of features of word processors have made writing and collaborating with others unnecessarily complicated, slow, or cumbersome. Some feel they no longer work to write, but, work to manage the word processor - and the intertwinement of its constantly-evolving number functionalities - so they can get work done.

All-in-one tools (like word processors) average at everything but get nothing done well.

Do one thing, do it well.

In gardening, we know that purveyors of all-in-one tools which claim do everything are cumbersome to use. We like to use tool which to one thing, and do it well.

This guide offers writers to learn how to use programmes that do one single thing: edit plain text, track versions of your work, integrate modifications, produce the layout your document, et cetera - so you can focus on writing.

This is inspired by the Unix philosophy (emphasis mine):

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs that work together. Write programs to handle text streams, because that is a universal interface. –Doug Mcllroy¹

In other words, instead of having one programme (a word processor) which attempts to do everything, we will take the approach of adopting multiple programmes which each do one thing well, and work together.

Copyleft.

Most programmes in this guide are copyleft licensed (e.g. GPL licensed); others are Free Software (e.g. MIT licensed).

You already have all the programmes we will use on your computer.

All programmes we discuss in this guide are on your computer (even on a Mac), for example Vim, grep, find, less - or available in a remote repository (more about this later).

You should not have to switch programme anytime soon.

According to the Lindy effect², the remaining life expectancy of a non-perishable item is equal to time passed since its inception. For example, a technology that has existed for 20 years is expected to survive for another 20.

No programme presented in this guide are novelties (most novelties vanish). For example: the utility find was published in 1971; grep in 1973; less in 1985; Vim in 1991; Git in 2005; Pandoc in 2006; Markdown was written in 2004. The most recent, Back In Time, was published in 2008 (which is based on rsync released in 1996). Based on the Lindy effect, we can expect these programmes to be ‘around’ for another 15 to 50 years.

My point is that you should not have to switch programme anytime soon.

End of introduction

Note: this guide is meant to evolve. Feedback welcomed at yctct dot yctct dot com

How to read this guide?

If you came to this guide because you want to learn how to collaborate with others using git, jump to the first git section.

You might not want to learn git (yet); still you are interested in applying the Unix philosophy and/or want to quit using word processors. In that case you want to make yourself familiar with the command line (if you are not), read the section on Vim (or pick the text editor of your liking - not a word processor), and then read the sections on Markdown and Pandoc, at minima. Using a text editor, Markdown and Pandoc can replace usage of a word processor³.

If your main motivation is to control your computer from the keyboard exclusively (i.e. to free yourself from using the mouse), the whole guide is about that. However, you might not be interested in all programmes discussed. Feel free to skip parts; each section can be read independently.

The command-line interface a.k.a. cli

You should be familiar with the command-line interface (a.k.a. the terminal or the shell) before you go through this guide.

If cd, cd .., cd /, ls, mv, mkdir, rm look familiar to you, you are good to go. Otherwise you might want read https://yctct.com/cli where I put a few ideas to get the basics.

Use text editor

Why using a (plain) text editor?

The point is to quit using word processors. It starts with picking a text editor, a programme that does work one thing well: edit plain text (as opposed to rich text processed by word processors). Writing in plain text means that you don’t have to worry about formatting: the layout, the font, the table of contents, et cetera. Just write.

I use Vim but you are free to pick the text editor of your choice. If you’d like to pick up Vim, read the appendix at the end of this document (or https://yctct.com/use-vim).

What’s next?

If you write in plain text, you will need a couple more tools to format your text, e.g. create title, italicise etc. That is what Markdown and Pandoc are for. Keep reading.

Write in plain text with Markdown

What is Markdown?

Markdown is a markup language for creating formatted text using a plain-text editor⁴.

Why use Markdown?

I am assuming the reader has been using word processors (e.g. Word, LibreOffice) so far.

Word processors are what some call WYSIWYG (What You See Is What You Get), meaning that the activity of writing text, that is actually typing your text, and the activity of formatting text, that is editing your text in the form of a letter, a C.V. or whatever you want your text to look like, are done in one single programme. What you see is what you get.

Another way to produce a document is first to write plain text, and then, format the text using another programme. That is where Markdown comes into use. You can write using Markdown’s syntax in plain text, then, use Pandoc to convert your Markdown document into a pdf or else. That is it. No more word processor.

The authors of the markup language write that “Markdown allows you to write using an easy-to-read, easy-to-write plain text format”⁵, and add that, “readability is emphasized above all else. You don’t necessarily need to convert a text written using Markdown to share it with other. A Markdown-formatted document should be publishable as-is, as plain text”.

What does Markdown syntax look like?

Markdown syntax

# That is a H1 title 

## That is a H2 title 

### That is a H3 title

Also a H1 title
==============

A a H2 title
-----------

*Use asterisks to italicize text.*

Use asterisks to italicize text.

_Underscores also work to italicize text._

Underscores also work to italicize text.

**Use two asterisks to in bold.**

Use two asterisks to write in bold.

~~User tildes to strikethrough text.~~

~~User tildes to strikethrough text.~~

You can comment out text by framming it between <code><!--</code> 
and <code>--></code>, like this: <!-- N.B. commented text will not 
appear once you convert out from Markdown!-->.

You can comment out text by framing it between <!– and –>, like this: .

This sentence terminates in the footnote^[here.]

This sentence terminates in the footnote⁶

You can also use numbers to write footnotes^[2].
[2]: second footnote

You can also use numbers to write footnotes⁷.

Numbered list:

1. first bullet point
1. second bullet point (notice: it is still number 1)
1. third bullet  point
    * indent bullet point

first bullet point
second bullet point (notice: it is still number 1)
third bullet point
- indent bullet point

Unnumbered list:

* one 
* two 
* three

one
two
three

You can also use hyphens:

- one 
- two 
- three

one
two
three

``` Use at least three backtick marks for code blocks on multiple lines. ```

Use at least three backtick marks
for code blocks
on multiple lines.

Use one tab or four spaces for single-line code block.

    Use one tab or four spaces for single-line code block.

Use `backtick marks` to indicate `code` within a paragraph.

Use backtick marks to indicate code within a paragraph.

> a quote 
>
> > a nested quote
>
> a second paragraph within a quote

a quote

a nested quote

a second paragraph within a quote

[An hyperlink with a title - hoover on it](https://yctct.com/ "yctct")

A hyperlink with a title - hover on it

[An hyperlink with no title](https://yctct.com/)

A hyperlink with no title

To embed an image with a title:

![Alt text](/path/to/img.jpg "Title")

Without a title:

![Alt text](/path/to/img.jpg)

Produce a horizontal rule tag by placing three or more hyphens, asterisks, or underscores on a line with nothing else:

* * *
 
***
 
*****
 
- - -
 
---------------------------------------

You can find more information on the webpage the developers of Markdown, John Gruber and Aaron Swartz, published in 2004 when they released: https://daringfireball.net/projects/markdown/

Produce your document layout with Pandoc

What’s Pandoc?

Pandoc is tool to convert from one markup language to another using the command-line.

Using Pandoc

To convert from Markdown to pdf run:

$ pandoc -o file.pdf markdown.md

-o stands for “output”.

To add a table of contents to the output, append the command by --toc:

$ pandoc -o file.pdf markdown.md --toc

To learn more about Pandoc run:

$ man pandoc

Merge multiple pdf files

To merge multiple pdf files into a single pdf file with the utility pdfunite, open your terminal and run:

$ sudo apt install pdfunite
$ pdfunite pdf_sourcefile1 pdf_sourcefile2 pdf_output

pdf_sourcefile1 et cetera are the pdf files you want to merge.

pdf_output is the name of a pdf file that will be created with all pdf files merged once you have run the command.

To learn more about pdftunite run:

$ man pdfunite

pdfunite is copyleft-licensed and was first released in 1995. It was written, and is still developed, by Derek Noonburg⁸.

Before we talk about version control, that is how to keep track of different version of your file, let’s discuss less. A tool to display and navigate documents.

View your files with the programme “less”

Why less?

You don’t have to open files or documents to display them. You can use the programme called “less”.
Less is a pager. A pager is a program that displays text files⁹.

To view a file run:

$ less file

To quit less press q.

Navigating a file with `less`

To navigate the file viewed use keys:

j to scroll down
k to scroll up
f or space bar to scroll down one window size
b to scroll up one window size

The idea of using keys rather than the arrow-key pad (to the bottom right of your keyboard) is that it is faster since your right-hand fingers are already positioned on keys j and k. Once one gets use to scroll up and down with j and k it becomes inconvenient to use the arrow keys.

To return to the top of the page press g.

To jump to the bottom of the page press GG.

Searching for keywords

You can search for keywords by typing /some_keyword. Once the keyword is highlighted, press return (enter). Now you can move to the next occurrence by pressing the key n (small cap), and the previous occurrence by pressing the key N (large cap).

If you already scrolled down and think that the keyword you are looking for is towards the top of the page, use the “inverse” of /, that is: ?. For example ?some_keyword to search backwards.

Switch to a text editor to edit a file

If you want to edit the file you are previewing press v.

Display multiple files with less

You can preview multiple files running:

$ less file1 file2 file3

To navigate between files press:

:n to examine the next file
:p to examine the previous file

Use less to display the output of other commands

You can use less to display the output of other commands instead of having the output of a command printing in the shell (i.e., the terminal).

For example, to list all pdf files of a directory and pipe the output of ls to less run:

$ ls .*pdf | less

That way you can navigate the (supposedly long) list using the keys j and k or search for keywords using /.

| pipes the output of the command preceding | as input to the next.

* acts as wild card (a substitute) for one or many characters (“a string”, esoterically speaking). In that example above, that is all files ending in .pdf.

More about less

Less is was written by Mark Nudelman in 1983-85, released in 1984 and currently maintained by him¹⁰.

Less is released under GNU General Public License (GPL).

To learn more about less, run $ man less to view less’s manual (in less).

Track versions of your work with git

What is git?

Git a version control system, a programme to help you keep track of different versions of your work, revisions your make or changes. With git, you can also save all past changes, so in case you mess up, you can also reverse to a prior version.

Why would you want to use git as a writer?

As a sole writer:

stop duplicating files to keep track of modifications e.g. file_version_1.txt, file_version_yesterday.txt, etc.
do not hesitate to delete text; everything you commit (I will define later) can be retrieved. Delete with confidence, recover if needed.
edit, reorganise and more text without altering “the main” copy

As writers collaborating:

no more duplicates e.g., doc_alice_edits.txt, doc_bob_edits.txt, doc_john_edits.txt
no more waiting for other to send you the latest version or whatever
use git to check for “conflicts” (differences) when two or more persons have worked on same file
each writer can use their own text editor, their own system to write. Git is agnostic.

There are many more reasons. This is just to give the reader an idea of why a writer might want to use git.

Getting started using git: create a git repository, make changes to a file and merge your changes into master

In this example we will learn how to use git to keep track of revisions of a text file: file.txt. We will:

create a git repository in a directory
initiate tracking for a file
create a branch
edit a file without altering “the original” copy
commit (save) that change
merge the change with “the original” file
delete the branch to leave the repository clean

You should be familiar with using the command-line interface (i.e. the terminal, the shell). You can find more information on learning to the use the command line there: https://yctct.com/cli.

If you need to install git on Trisquel GNU/Linux run:

$ sudo apt install git

Start by creating a directory (a folder) named book where we will create and keep track of a file:

$ mkdir book

Move into the directory book:

$ cd book

Create a file:

$ touch file.txt

Initiate a git repository in this directory:

$ git init

The shell (a.k.a. the terminal) should print:

Initialized empty Git repository in /home/user/book/.git/

We can check the status of our repository:

$ git status

The shell should print:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    file.txt

nothing added to commit but untracked files present (use "git add" to track)

Git tells us that it can see file.txt but does not track it (yet).

As suggested by git in the message above, to start tracking file.txt we run:

$ git add file.txt

We can run git status to check that file.txt is tracked by git. The shell should print:

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   file.txt

file.txt is now tracked but not recorded to the repository yet. To record a file to the repository we need to commit (save, in a way) that file. To commit file.txt we run:

$ git commit -m "Add file"

-m stands for “message”; a message appended to the commit. You can run $ man git-commit to learn more about commits.

The shell unexpectedly prints:

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'yourusername@computer.(none)')

Our commit did not go through. The repository does not know who we are. When we will collaborate with others on the same repository, and commit changes, git will need to know who commits come from.

We follow the above instruction to set the identity of our account, we run:

$ git config --global user.email "alice@yctct.com"
$ git config --global user.name "Alice A"

N.B. #1: do not forget to substitute the placeholders for your email address and name.

N.B. #2: This email address and name will show up in the commits for others to see.

Now that we created a repository, added file.txt and set our identity, we can commit file.txt to the repository (try Crtl+P to retrieve commands you’ve previously typed in the shell):

$ git commit -m "Add file"

The shell should print:

[master (root-commit) 954ea14] Add file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file.txt

We run git status to check where we are at. The shell should print:

On branch master
nothing to commit, working tree clean

Good.

We can also run git log to print our commit to the shell:

commit 954ea14e97ff2f2f690583bdb728d3fdab584376 (HEAD -> master)
Author: Alice A <alice@yctct.com>
Date:   Sun Mar 26 12:32:31 2023 +0100

    Add file

That is the commit we just made. You can see that our change was committed to the branch master.

Now we want to start working on file.txt. In this example, we will add a title. That is not much but the process will be the same for any future work you will want to keep track of.

The first thing we want to do before make any modification to our file is to create a branch (a sort of copy) of the directory where the repository lives. We do not need to create copy of file.txt e.g. file_version1.txt!

We create a branch named add-title:

$ git branch add-title

(You can run $ man git-branch to learn more about branching.)

We can check that the branch was created by running:

$ git branch

The shell should print:

  add-title
* master

We can see that the branch add-title was created.

We can also see that we are still on the branch master. The * indicates which branch we are on.

We want to add a title to file.txt so let’s switch to the branch add-title where we will be able to make changes to file.txt without altering file.txt on the branch master.

To switch to the branch add-title we run:

$ git switch add-title

We can check that we switched to the branch add-title by running:

$ git branch

The shell should print:

* add-title
  master

The * indicates that we are on the branch add-title.

Now we can start editing file.txt.

We can add a title to file.txt (using the programme echo) and check that the title was added (using the programme cat):

$ echo "# This is a title" > file.txt
$ cat file.txt 
# This is a title

Good. cat prints the content of file.txt to the shell.

Now we run git status to check where we are at.

The shell should print:

On branch add-title
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   file.txt

no changes added to commit (use "git add" and/or "git commit -a")

We are happy with the title we added to file.txt so we commit the modification.

First: we stage (that is, add) the file to the staging area by running:

$ git add file.txt

N.B.: you will make use of the staging area in the future. For now it makes no different. Just an extra step we have to take.

We can run git status to check that file.txt was staged. The shell should print:

On branch add-title
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   file.txt

Now we commit:

$ git commit -m "Add title"

The shell should print:

[add-title bc4803f] Add title
 1 file changed, 1 insertion(+)

We can run git log to prints our commits to the shell:

commit bc4803f1330c1febeaee3283ee858be079bd3665 (HEAD -> add-title)
Author: Alice A <alice@yctct.com>
Date:   Sun Mar 26 12:58:18 2023 +0100

    Add title

commit 954ea14e97ff2f2f690583bdb728d3fdab584376 (master)
Author: Alice A <alice@yctct.com>
Date:   Sun Mar 26 12:32:31 2023 +0100

    Add file

Those are the two commits we made so far: first adding file.txt to the repository, and then adding a title to file.txt. We can see that the first commit was made on the branch master and the second (the one at the top) to the branch add-title.

We can also run git status to check that the branch is “clean”, that file.txt was committed:

On branch add-title
nothing to commit, working tree clean

If we are happy with the modification we have just made i.e. adding a title, we can merge the changes into to branch master and delete the branch add-title.

First we switch back to the branch master:

$ git switch master

N.B.: we need to commit all changes to switch branch.

The shell should print:

Switched to branch 'master'

To see that changes made on the branch add-title did not affect the branch master we can print the content of file.txt:

$ cat file.txt

The shell should print nothing. (file.txt has no title on the branch master.)

We can check that the branch add-title was not merged yet:

$ git branch --no-merged

The shell should print branches that are not merged, in our case the branch add-title:

add-title

To merge changes made on the branch add-title into the branch master we run:

$ git merge add-title

(You can run $ man git-merge to learn more about merges.)

The shell should print:

Updating 954ea14..bc4803f
Fast-forward
 file.txt | 1 +
 1 file changed, 1 insertion(+)

We can check that changes of the branch add-title were merged onto the branch master:

$ git branch --merged

The shell should print branches that are merged (and indicates which branch we are on):

  add-title
* master

We can also check that file.txt was modified, again using the programme cat:

$ cat file.txt 
# This is a title

Now we can delete the branch add-title since its changes were merged into the branch master, we run:

$ git branch -d add-title

The shell should print:

Deleted branch add-title (was bc4803f).

We can run git status to check the status of our repository. The shell should print:

On branch master
nothing to commit, working tree clean

We are done learning the very basics of git. We:

created a repository in a directory with file.txt
set the identity of our git account
created a branch
made a change to file.txt
committed that changes to the newly created branch
merged the changes into the branch master
deleted the branch where we worked to keep the repository clean

I hope you can now use git to track versioning of your work. If not, you can run $ man git to learn more or drop me a line via email. I would be happy to help further by writing another blog post for example. Let me know.

Other git commands you might find useful

$ git diff

shows changes between commits in the shell.

$ git add .

stages all files. Also useful when you stage one single file so you don’t have to type the name of the file.

$ git ci --amend --no-edit

adds changes to the last commit. In other words, it is useful if you already committed and forgot to add something to a file (do not do if you already pushed, for those who use git to collaborate). You can commit a change without adding a new commit.

$ git ci --amend

same as above, but prompts you to also update the message of the commit.

$ git ci -am "Commit message"

stages (add) and commit at once. No need to run git add .

$ git branch -v

lists the last commit on each branch.

$ git grep keyword

to look for a keyword in the repository.

You might also want git to ignore .pdf files so they don’t show up when you run git status. To do so you can tell the .gitignore file to ignore files with extension .pdf. In the directory run:

$ echo "*.pdf" > .gitignore

to check that *.pdf was written to the hidden file .gitignore you can run:

$ cat .gitignore

which should print:

*.pdf

One more thing if you are unfamiliar with hidden files: to list hidden files run $ ls -a.

About git

Git is published under the copyleft license GNU General Public License (GPL). It was started by Linus Torvalds, released in 2005 and is currently maintained by Junio C Hamano et al..

Write & collaborate with others with Git on a server

You can use git to collaborate over a single document.

You have to host the main version of the document on a server which all contributor access to using git.

You can create a main repository using the copyleft-licensed Forgejo.

You don’t need to install Forgejo yourself, or to maintain a server yourself.

You can use an instance (i.e. a server where Forgejo is installed) of organisation maintaining such server.

For example, the non-profit organisation Codeberg e.V. based in Berlin maintains an instance of Forgejo at the address: https://www.codeberg.org.

Other instances of Forgejo exists.

If you would like to try to set up a repository, you can create an account on the instance ran by Codeberg e.V. and follow the step.

If you have questions, let me know. I will expand the section of this handbook.

Back up your work

Backing up?

Back up (save) your work locally, that is on an external drive, with the programme named “Back In Time” (BiT).

You can install BiT on a GNU/Linux distribution by running:

$ sudo apt install backintime-qt

Your first back up

To create your first back, do:

Open Back in Time
A prompt should pop up asking you if you want to restore, click No
A window titled Settings should pop up
To select the drive where you want to back up, click on the folder icon in Where to save snapshots > Computer > / > media > user > (make sure the drive is mounted)
To select /home/ folder to backup, in Settings go to the tab titled Include > Add folder > select the folder
/home/ should be listed in Include files and folders
Click OK
A window titled Back in Time should pop up
Click the Take a snapshot button to take the first snapshot.

To back up your /home/ directory from the command line run:

$ backintime backup

Restore from an existing back up

To restore from an existing backup, on a newly installed operating system for example, run:

Open Back in Time (root)
A prompt should pop up asking you if you want to restore, click Yes
A prompt should pop up asking you for user password
A window titled Restore Settings (as superuser) should pop up
Navigate to the snapshot you want to restore and select it
The path to the snapshot should show up in green at the bottom
Click Restore
A window titled Back in Time (as superuser) should pop up
Select the folder you want to restore
A window titled Question (as superuser) should pop up
Click Yes

Final note

This guide is meant to evolve.

Free free to email feedback and comments to yctct at yctct dot com.

About the author

As far as I can remember: I had my first encounter with the internet in the early 2000s; with Instant Messaging and peer-to-peer networks. Back then, I owned a computer running with Windows, for a couple of years or so, then nothing until I purchased a Macbook in 2010. I got my first smartphone in 2015, the year I started to work in the software industry.

In 2019 I stopped working for the development of proprietary software.

In 2020 I switched back to using a dumb phone.

In 2021 I traded my MacBook for a second-hand laptop running the operating system Trisquel GNU/Linux.

I now do research, mostly drawing from philosophical works, to try to figure out concepts, or a framework, to critique digital technologies; ‘to critique’ meaning to sieve through to improve how we use technologies (not to blame or reject). I plan to publish a book. You can read a summary of the prologue there: https://yctct.com.

Use Vim

If you have never used Vim you will be surprised at first. Vim doesn’t work like the lay text editor. You will find that you no longer need to use the mouse. You will only interact with the keyboard. Typing, editing, is very fast. I also find that keeping my hands on the keyboard, rather than to constantly have to reach out for the mouse, helps me focus.

It takes a bit of effort at first, but, I read that most people who try Vim do not switch back to a regular text editor.

To learn how to use Vim: start using it now.

Three things to make getting started easier though. Keep reading.

Vim Tutor

Complete the VIM Tutor. VIM Tutor is already installed on your computer, like Vim. To start Vim Tutor open the terminal and run:

$ vimtutor

You should see this:

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

=    W e l c o m e   t o   t h e   V I M   T u t o r    -    Version 1.7      =
===============================================================================

     Vim is a very powerful editor that has many commands, too many to
     explain in a tutor such as this.  This tutor is designed to describe
     enough of the commands that you will be able to easily use Vim as
     an all-purpose editor.

     The approximate time required to complete the tutor is 25-30 minutes,
     depending upon how much time is spent with experimentation.

     ATTENTION:
     The commands in the lessons will modify the text.  Make a copy of this
     file to practice on (if you started "vimtutor" this is already a copy).

     It is important to remember that this tutor is set up to teach by
     use.  That means that you need to execute the commands to learn them
     properly.  If you only read the text, you will forget the commands!

     Now, make sure that your Caps-Lock key is NOT depressed and press
     the   j   key enough times to move the cursor so that lesson 1.1
     completely fills the screen.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                        Lesson 1.1:  MOVING THE CURSOR


   ** To move the cursor, press the h,j,k,l keys as indicated. **
             ^
             k              Hint:  The h key is at the left and moves left.
       < h       l >               The l key is at the right and moves right.
             j                     The j key looks like a down arrow.

Make Vim your default text editor

Once you’ve completed Vim tutor, use vim.

:help.

When you need to figure how to do something: run :h to display the help files. For example, if you want to find out how to substitute some text run :h substitute.

:q.

Tip: to quit (exit) Vim run :q.

Brian Moolenaar’s blog post

Next, you want to get an idea of “how to think Vim” (rather than learning shortcuts and commands by heart without understanding why things are this way). Vim is like a language that has a grammar. Once you get how the grammar works, you can figure you own sentences (i.e. shortcuts).

To get an idea of how to think about using Vim, read https://www.moolenaar.net/habits.html written by Vim’s creator Bram Moolenaar.

A few tips though.

Show word count in Vim

You can show the number of words in Vim by writing a file, a paragraph, etc. to the programme wc.

To display word count of a file, write it to the programme wc:

:w !wc  -w

In Vim, ! calls an external programme.
-w is an option that prompt wc to only show word count.

You can run $ man wc in a terminal to see other options.

Change Vim color scheme

You can change Vim color scheme to your liking.

To display the name of the color scheme currently loaded run:

:colo

The name of the color scheme should be displayed at the bottom of your screen.

To display all color schemes run:

:colo [spacebar] [Crtl+D]

To flick through color schemes run:

:colo [spacebar] [tab]

To load a color scheme run:

:colo [name] [return]

For example :colo evening [return].

That’s it for Vim.

Generally, I’d suggest using no plugins at first.

Raymond, Eric S. (2004). “Basics of the Unix Philosophy”. The Art of Unix Programming. Addison-Wesley Professional (published 2003-09-23). ISBN 0-13-142901-9↩︎
Goldman, Mandelbrot, Taleb↩︎
and if you need to compare files, you can use the programme diff, e.g. in your terminal run $ diff file1 file2.↩︎
From Wikiless↩︎
John Gruber’s website↩︎
here.↩︎
2↩︎
xpdfreader’s website.↩︎
https://www.greenwoodsoftware.com/less/faq.html#what ↩︎
Less’s website↩︎

personal computing command-line interface (cli) vim markdown git pandoc text processing office applications wiki shell literacy offline blog post digital literacy

GPG fingerprint: 2E0F FB60 7FEF 11D0 FB45 4DDC E979 E52A 7036 7A88

A guide to simple and stupid usage of computers for writers (anyone who writes really)

Table of Contents

Who should not use this guide

Who might find this guide useful

Introduction

How to read this guide?

The command-line interface a.k.a. cli

Use text editor

Why using a (plain) text editor?

Write in plain text with Markdown

What is Markdown?

Why use Markdown?

Markdown syntax

Produce your document layout with Pandoc

What’s Pandoc?

Using Pandoc

Merge multiple pdf files

View your files with the programme “less”

Why less?

Navigating a file with less

Searching for keywords

Switch to a text editor to edit a file

Display multiple files with less

Use less to display the output of other commands

More about less

Track versions of your work with git

What is git?

Why would you want to use git as a writer?

Getting started using git: create a git repository, make changes to a file and merge your changes into master

Other git commands you might find useful

About git

Write & collaborate with others with Git on a server

Back up your work

Backing up?

Your first back up

Restore from an existing back up

Final note

About the author

Use Vim

Vim Tutor

Make Vim your default text editor

Brian Moolenaar’s blog post

Show word count in Vim

Change Vim color scheme

Navigating a file with `less`