dead airspace

Neovim Pastebin

Wed, 06 Mar 2024 17:49:05 +0530

Introduction

Recently, I have been sharing a lot code snippets and other textual 😏 files over the internet. So, currently I just run a curl command and then upload the file to https://0x0.st.

The command looks like this: curl -F'file=@/absolute/path/to/file' 0x0.st | xclip. We will be just transforming this command into a Neovim utility.

Other similar plugins.

So, before writing this I did try several other plugins. I did not like any but, maybe you will.

There is paperplanes.nvim but it is a bit too feature-rich. It supports multiple backends and other fringe features that I do not really need.
There is pastebin-vim which is also cumbersome to use as you’d need to generate API keys first.
Then there’s snips.nvim which is the best so far. But again I want something minimal.
Lastly, there is vim-pastebins which I have not tried.

Plenary

We will be using the well-known plenary.nvim library plugin. The only utilities we need from this are the Job and Path class. Which just basically spawns an async task in the background and calls an on_exit callback function when the task is done. And, the other is just the Lua version of Python’s pathlib.

The readme has examples of Job but here is an example anyway.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


local Job = require("plenary.job")
Job:new({
  command = "ls"
  args = { "--recursive" },
  on_exit = vim.schedule_wrap(function(self, code, _)
    if code ~= 0 then
      vim.notify(vim.inspect(self:stderr_result()))
      return
    end
    vim.notify(vim.inspect(self:result()))
  end),
})

Alternative APIs.

Following are alternative APIs to plenary’s Job 💀.

Following are alternative APIs to plenary’s Path 😢.

:help exists()
:help :glob()
:help readfile()
:help writefile()
:help delete()
:help uv.fs_unlink(): Delete file.
:help uv.fs_realpath(): Existence of a path.
:help uv.fs_read()
:help uv.fs_write()
:help uv.fs_open()

A nice little exercise would be to create your version of this script but by using these alternative APIs instead.

Procedure

Here’s a list of features that I primarily want.

Ability to upload a file.
Ability to upload specific lines from a file.
Ability to remove the uploaded item.
Ability to cache uploaded file into a JSON file.

As for going about implementing the upload feature for selected text, we would need to copy that selected text or, file and paste those contents into another temporary file and then upload that file to the pastebin website.

Configuration

We just need defaults for paths beforehand. We would need the following paths.

db_path: Path where all previously upload request responses will be saved.
tmp_path: This is only needed for selected text upload.
dump_path: Path to where all of the response headers will be written to by CURL.

1
2
3
4
5
6
7


local M = {}

M.config = {
  db_path = vim.fn.stdpath("state") .. "/paste.db.json",
  tmp_path = "/tmp/paste",
  dump_path = "/tmp/dump", -- needs to match with the scripts dump path (explained later)
}

As, for the setup function we now need to extend the default configuration table with the current one (the one i.e. passed in through the setup function). We do this because if we ever decide to change the configuration on the fly, then this will be useful and we won’t need to reload Neovim again.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


function M.setup(options)
  options = vim.F.if_nil(options, {})
  M.config = vim.tbl_deep_extend("keep", options, M.config)
  M._db = Path:new(M.config.db_path)
  M._dump = Path:new(M.config.dump_path)
  M._path = Path:new(M.config.tmp_path)
  M._responses = {}
  -- load db entries (persist)
  if M._db:exists() then M._responses = vim.json.decode(M._db:read()) end
end

After this, we initialize some private tables for several caching and file IO operations.

M._response: This table is used for storing responses. For instance a response from https://0x0.st might look like the following.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


HTTP/2 200 
server: nginx
date: Mon, 11 Mar 2024 16:06:07 GMT
content-type: text/html; charset=utf-8
content-length: 24
x-expires: 1741668317786
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-frame-options: sameorigin
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
referrer-policy: no-referrer, strict-origin-when-cross-origin
...

We would then parse this to a key: value pair value and then encode these into a JSON format. See: M.pretty().

M._dump: Path instance of M.config.dump_path where responses from CURL will be written to (by CURL itself) before parsing into a key: value. Again, we will be reading and writing to it a lot so, it’s better to make it a pair value.
M._db: Path instance of M.config.db_path.
M.tmp_path: The path where currently selected buffer contents will be copied to.

Upload

So for this we just need to follow the following steps.

Prepare the file M._path for upload by writing all the buffer contents to it.
Then upload the newly updated file to https://0x0.st using a job API.
Save the returned link into the clipboard.
Save the response dumped into M._dump to the M._responses table.
Clean M._path and M._dump.
Save all recorded M._responses upto this point to M._db path.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


function M.paste(contents)
  M._path:write(table.concat(contents, "\n"), "w")
  Job:new({
    command = "curl",
    args = { -- read the manpage - I can't be fucked.
      "--silent",
     "--show-error",
     "--location",
     "--dump-header",
      M._dump.filename,
     "--compressed",
     "--request",
     "POST",
     "--form",
      string.format("file=@%s", M._path.filename),
     "https://0x0.st",
    },
    on_exit = vim.schedule_wrap(function(self, code, _)
      if code ~= 0 then return end
      local body = self:result()[1] -- [1] because it only returns a link
      local pretty = M.pretty(M._dump:read()) -- defined below
      M._responses[body] = {
        body = body,
        headers = pretty.headers,
        code = pretty.code
      }
      -- clean used paths (optional)
      M._path:rm()
      M._dump:rm()
      vim.fn.setreg("+", body)
      vim.api.nvim_notify("+pastebin: " .. body, vim.log.levels.INFO, {
        title = "pastebin",
        icon = " "
      })
      M._db:write(vim.json.encode(M._responses), "w")
    end),
  }):start()
end

CURL returns results in a weird format, so next we will be writing a M.pretty function that will convert these values into a Lua table. Which then can be encoded to a JSON format.

You could define M.pretty as a local function if you want.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


function M.pretty(data)
  local lines = vim.split(data, "\r\n", { plain = true })
  local headers = {}
  local heading = vim.split(lines[1], " ", { plain = true })
  local code = heading[2]
  table.remove(lines, 1)
  for _, line in ipairs(lines) do
    local _line = vim.split(line, ": ", { plain = true })
    if #_line > 1 then
      local _colon_items = vim.split(_line[2], "; ", { plain = true })
      if #_colon_items == 1 then
        headers[_line[1]] = _colon_items[1]
      elseif #_colon_items > 1 then
        headers[_line[1]] = _colon_items
      end
    end
  end
  return { code = code, headers = headers }
end

Delete

For deleting a link form https://0x0.st, we just need to send the link, that we want to delete and its token that was given to us when we uploaded the file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


function M.delete(response)
  if not response then return end
  -- 0x0 will not allow deletion if we are unable to supply the token
  if not response.headers["x-token"] then
    M._responses[response.body] = nil -- rm from cache? This depends on your preference.
    M._db:write(vim.json.encode(M._responses), "w") -- useless if you chose to rm previous line
    return
  end
  Job:new({
    command = "curl",
    args = {
      "--form",
      string.format("token=%s", response.headers["x-token"]),
      "--form",
      "delete=",
      response.body, -- file link to delete example: https://0x0.st/HkmZ.lua
    },
    on_exit = vim.schedule_wrap(function(self, code, _)
      if code ~= 0 then return end
      -- I use https://github.com/rcarriga/nvim-notify
      -- if you don't then just use print("Deleted" .. response.body)
      vim.api.nvim_notify("Deleted " .. response.body, vim.log.levels.INFO, {
        title = "pastebin",
        icon = " "
      })
      M._responses[response.body] = nil
      M._db:write(vim.json.encode(M._responses), "w") -- save cache (persist)
    end),
  }):start()
end

Debloat. Rewrite.

Why though?

Will you only ever upload code files?
Won’t you want to upload a file without opening Neovim?
Wouldn’t it be better if there were a nice shell utility that can be used everywhere?
Minimalism.

So, we write a shell script that does just that. (Maybe we’ll write completions for it as well!)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


#!/usr/bin/env bash

dump="/tmp/dump"

function help_message() {
  echo 'usage: paste [[--upload|-u]|[--delete|-d]|[--clean|-c]|[--help|-h]]'
  echo
  echo 'script to upload files to a pastebin website'
  echo
  echo 'options:'
  echo '  -h, --help                                    show this help message and exit'
  echo '  -c, --clean                                   remove db'
  echo '  -u , --upload                     upload a file to 0x0.st'
  echo '  -d  , --delete      delete an uploaded file'
  echo 
  echo 'Source: https://github.com/dharmx'
}

function _upload() {
  [[ "$1" == "" ]] && echo Needs '' && help_message && return 1
  curl                      \
    --silent                \
    --show-error            \
    --location              \
    --dump-header "$dump"   \
    --compressed            \
    --request POST          \
    --form file=@"$1"       \
      https://0x0.st
}

function _delete() {
  [[ "$1" == "" || "$2" == "" ]] && echo Needs ' ' && help_message && return 1
  curl --form token="$1" --form delete= "$2"
}

case "$1" in
  --upload|-u) _upload "$2" ;;
  --delete|-d) _delete "$2" "$3" ;;
  --clean|-c) rm -rf "$dump" ;;
  --help|-h) help_message ;;
  *) echo -e Needs arguments! "\n" && help_message && exit 1 ;;
esac

We then place this into $PATH. I recommend ~/.local/bin. Now, you can use 0x0 -u file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#compdef 0x0

# Sing with me. WE 👏. LOVE 👏. COMPLETIONS 👏!
function _0x0() {
  _arguments                                                    \
    '-h[show this help message and exit]'                       \
    '--help[show this help message and exit]'                   \
    '-c[remove db]'                                             \
    '--clean[remove db]'                                        \
    '-u[upload a file to 0x0.st]:upload:_files'                 \
    '--upload[upload a file to 0x0.st]:upload:_files'           \
    '-d[delete an uploaded file]'                               \
    '--delete[delete an uploaded file]'
}

We then place this into $FPATH. I recommend ~/.local/share/zsh/completions. Name the file 0x0 or, something 🤷.

Rewritten

Only the M.paste and M.delete functions need to be re-written with new arguments. See below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


-- ...
function M.paste(contents)
  M._path:write(table.concat(contents, "\n"), "w")
  Job:new({
    command = "0x0", -- the script's name
    args = { "--upload", M._path.filename },
    on_exit = vim.schedule_wrap(function(self, code, _)
      if code ~= 0 then return end
      local body = self:result()[1]
      local pretty = M.pretty(M._dump:read())
      M._responses[body] = { body = body, headers = pretty.headers, code = pretty.code }
      M._path:rm()
      M._dump:rm()
      vim.fn.setreg("+", body)
      vim.api.nvim_notify(body, vim.log.levels.INFO, { title = "0x0", icon = " " })
      M._db:write(vim.json.encode(M._responses), "w")
    end),
  }):start()
end

function M.delete(response)
  if not response then return end
  if not response.headers["x-token"] then
    M._responses[response.body] = nil
    M._db:write(vim.json.encode(M._responses), "w")
    return
  end
  Job:new({
    command = "0x0",
    args = { "--delete", response.headers["x-token"], response.body },
    on_exit = vim.schedule_wrap(function(self, code, _)
      if code ~= 0 then return end
      vim.api.nvim_notify(vim.inspect(self:result()), vim.log.levels.INFO, { title = "0x0", icon = " " })
      M._responses[response.body] = nil
      M._db:write(vim.json.encode(M._responses), "w")
    end),
  }):start()
end
-- ...

Command

There are a few rules we’ll follow.

should not allow an file path arguments.
Without allow file path arguments.
If no or, any arguments are supplied, then use current buffer. And, only allow ranges in this case.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


-- at the very end of your paste.lua
function M.command(args)
  if args.bang and args.fargs[1] then
    M.delete(M._responses[args.fargs[1]])
  elseif args.fargs[1] then
    M.paste(vim.fn.readfile(file))
  else
    args.line1 = (args.range == 2 and args.line1 or 1) - 1
    args.line2 = args.range == 2 and args.line2 or -1
    M.paste(vim.api.nvim_buf_get_lines(0, args.line1, args.line2, false))
  end
end

Now, you’d just import the paste module and call the command function and pass in the args parameter.

See: :help nvim_create_user_command

I have it in ~/.config/nvim/lua/scratch/paste.lua so, I’d need to call require("scratch.paste"). If you have it in say, ~/.config/nvim/lua/paste.lua then you’d just need to do require("paste").

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


-- in your init.lua
vim.api.nvim_create_user_command("Paste", function(args)
  require("scratch.paste").command(args)
end, {
  desc = "Upload/delete files/snippets to a pastebin site.",
  range = true,
  bang = true,
  nargs = "?",
  complete = function(arg, name, _)
    if name:match("^'<,'>Paste") then return {} end
    if name:match("^Paste!") then
      return vim.tbl_keys(require("scratch.paste")._responses)
    end
    return vim.fn.getcompletion(arg, "file")
  end,
})

The custom command completion function is not complicated at all. We just check

If the dumbass is using ranges. If yes then do not supply any completions.
If the restarted individual is using i.e. :Paste!. If they are, then supply all response bodies list, which the user would want to delete.
Else supply with file paths.

Conclusion

Please read TOS

Also, please do not forget to read the TOS. Like the maximum file size you’re allowed to upload. Try not to upload furry porn to it. You can use mega.io for that. And, please no gore or, propaganda videos.

Just go and read it before you do anything stupid.

I hope you enjoyed reading this meme 💀. If you did then comment “Sex” for 25 Robux.

Bspwm Basics

Wed, 24 Aug 2022 17:29:27 +0530

Introduction

BSPWM is a neat window manager with some neat features. In this article we will be briefly looking at how BSPWM functions and what some of its features are.

Maybe analyze a bit of its source code, IPC commands and some other possible extensions.

Before We Begin

This is a fairly intermediate article which may seem easy to follow at first but, will get relatively difficult to follow as it progresses further. You would need to have the following things to progress smoothly.

Maybe a tiny amount of BST data structure.
Experience with window managers and X11.
Programming experience is preferred.

All right! Let us begin.

About BSPWM

BSPWM is a tiling window manager that represents windows as the leaves of a full binary tree. It uses an IPC application that invokes X events and changes BSPWM' internal states.

Unlike most other window managers it does not have a dedicated configuration file. You use the IPC client (bspc) for everything. Be it setting window gaps, border colors, layouts, monitors, etc. For BSPWM a configuration file is just a shell script that needs to be stored in $HOME/.config/bspwm/bspwmrc. It is a shell script that should have commands that starts a keyboard daemon, notification daemon, monitor configurations, border, gaps and other stuff as bspc calls. You may also have commands that will start some startup applications like discord, bars, etc.

This is preferred because when BSPWM is first launched, it does not have any state at all. You need to execute some bspc commands which will set an initial state then you would be able to spawn windows and whatnot.

Display Structure

It should be noted that BSPWM is a window manager, which means it manages windows. And it does so by representing the window tree as leaves of a full BST.

For application windows to be able to spawn, BSPWM first needs to define a root window. Which in WM lingo is called a workspace. And, after said workspace(s) are defined, one can now finally open an application window which will be managed by BSPWM.

Add on top of this information it is to be noted that BSPWM was originally designed for a computer with only one monitor. If you are curious then yes, the author has already added multi-monitor support. Monitors are also treated the same as roots i.e. a list.

If you are still confused then the following illustration will help ease that.

How BSPWM defines the relation between monitors and workspaces.

In this construct, the monitors stay at the topmost level. These monitors are the parents of workspaces.

Monitors

If we analyze the source then we will see that monitors are not represented as a multi-branched tree rather, as a single-branched one i.e. a linked list. Where the current monitor has links to the previous and next monitors.

288typedef struct monitor_t monitor_t;
289struct monitor_t {
290    char name[SMALEN];
291    uint32_t id;
292    xcb_randr_output_t randr_id;
293    xcb_window_t root;
294    bool wired;
295    padding_t padding;
296    unsigned int sticky_count;
297    int window_gap;
298    unsigned int border_width;
299    xcb_rectangle_t rectangle;
300    desktop_t *desk;
301    desktop_t *desk_head;
302    desktop_t *desk_tail;
303    monitor_t *prev;
304    monitor_t *next;
305};

1
2
3


// code representation.
const int MON_LEN = 2;
monitor_t monitors[MON_LEN];

See those prev and next variables? Here the prev variable points to the previous monitor_t structure and next, next. And, if either of those pointer variables has NULL then it is to be assumed that the focused monitor is either at the end or at the beginning of the monitor list.

Workspaces

For desktops, the structure is pretty much the same as monitors. That is, both desktops and monitors are represented as doubly linked lists with links to previous and next desktops.

Workspaces are called desktops in BSPWM. They are used interchangeably. You will see both of them appear in this article.

See the following code snippet.

273typedef struct desktop_t desktop_t;
274struct desktop_t {
275    char name[SMALEN];
276    uint32_t id;
277    layout_t layout;
278    layout_t user_layout;
279    node_t *root;
280    node_t *focus;
281    desktop_t *prev;
282    desktop_t *next;
283    padding_t padding;
284    int window_gap;
285    unsigned int border_width;
286};

Monitor-Workspace Relation

The following figure attempts to briefly define the monitor-workspace relation in BSPWM that takes the above monitor_t and desktop_t definitions into account.

Representing monitor-workspace in the form of linked lists.

The first monitor (marked in green) has three desktops where the label of the first desktop is identified by (+), second by (-) and lastly third by (=).

It should be worth noting that having duplicate labels are possible because the window manager does not identify workspaces from labels rather they use the ID of that desktop/workspace. You can check what the current IDs with a simple query to BSPWM via the bspc IPC client.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


$ bspc query --desktops # IDs
0x00400004
0x00400005
0x00400006

$ bspc query --names --desktops # Labels
(+)
(-)
(=)

# change primary monitor number of desktops and labels
$ bspc monitor primary --reset-desktops 1 2 3

The BST data structure

The Binary Tree data structure is a way of representing data in the form of a tree. A BST is a special case of a tree that only has two children. As with all trees (both natural and pragmatic), this one also has leaves and branches. The leaves are called nodes which is the term we will use from now on.

A brief descriptive illustration of a binary tree.

You may also notice that the nodes are colored differently. The colors signify levels. For instance, the root level node is colored with green . The second level nodes are colored with blue and lastly the third level nodes are colored with red .

A BST node would look like the following in C.

1
2
3
4
5


struct node {
    int some_data;
    node_t *left_child;
    node_t *right_child;
};

This node will contain a pointer to the left child and another to the right child. Left and right child are siblings as illustrated in the diagram. And, some_data which is the data that the node will be carrying. Now, consider the following code to get a clearer visualization of how the node is being initialized and how some basic components work.

Minimal BST implementation in C

EWW Powermenu

Thu, 18 Aug 2022 18:08:53 +0530

Introduction

Hello there. Hope you are doing well. Lately, I have been playing with a neat piece of software called EWW. Making some aesthetic UI, widgets and whatnot.

Note that, this has a very steep learning curve. This is because tutorials, demo and examples about this are quite scarce. And the examples are either too complex or, very poorly documented and not to mention most of them are not even documented.

Prerequisites

Some requirements about what you’d need to get started like what OS will this work on, what languages you’d need to know, etc.

Familiarity with Linux is required. This is for Linux users only.
I will be using Archlinux for this. Debian users may need to translate some commands. But, for the most part equivalent commands will be provided.
A bit of programming experience will be preferred.
A xorg based window manager. Like bspwm, qtile, xmonad, etc. A display environment will work as well.

Does EWW work on Wayland?

This tutorial is designed for running EWW on a xorg-based window manager, but minimal changes should be able to make it run on wayland. See build flags and widget definitions.

Dependencies

Packages that are needed for this to work correctly.

Efficiently look for packages for any distro.

You may use command-not-found if you do not know what a package is called for your distro (Arch’s and Debian’s package naming conventions are quite different).

First and foremost you will need EWW. Head over to their website and follow their instructions.
And you would also need sudo which you already might have installed.
Fonts used in this widget are Poiret One, Koulen and Phosphor.
nmcli tool that comes with Network Manager which you already might have installed.

Copy and Paste