IwoHerka

Naming guidelines

1. Syntax

1.1 Be consistent

Consistency in naming makes reading and memory retrieval much, much easier. Conversely, changing rules and mixing conventions are very confusing and significantly increase cognitive load. Follow language, company, and project conventions for names, even if you don't like them.

1.2 Follow conventions

martinchapman

# Visualise a latex document git history

# loop through commits, create a PDF from your main file for each
# translate the pages of that PDF to a single image
# create GIF/mp4 from the folder of images created

# run within your local repository
# prerequisites: ImageMagick and FFmpeg

# create output folder

sinbad

#!/bin/bash

# `gitea dump` doesn't currently back up LFS data as well, only git repos
# It primarily backs up the SQL DB, and also the config / logs
# We'll backup like this:
#   * "gitea dump" to backup the DB and config etc
#   * tar / bzip all the repos since they will be skipped
#     * Not rotated because git data is immutable (normally) so has all data
#   * rsync LFS data directly from /volume/docker/gitea/git/lfs
#     * No need for rotation since all files are immutable

fpom

                   GNU LESSER GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007

 Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.


  This version of the GNU Lesser General Public License incorporates
the terms and conditions of version 3 of the GNU General Public

dfeich

;;; ** Hydras
;;; *** context launcher for hydras
(defun dfeich/context-hydra-launcher ()
  "A launcher for hydras based on the current context."
  (interactive)
  (cl-case major-mode
    ('org-mode (let* ((elem (org-element-context))
		      (etype (car elem))
		      (type (org-element-property :type elem)))
		 (cl-case etype

egmontkob

Hyperlinks (a.k.a. HTML-like anchors) in terminal emulators

[ Update 2025-03-24: Commenting is disabled permanently. Previous comments are archived at web.archive.org. ]

---

Most of the terminal emulators auto-detect when a URL appears onscreen and allow to conveniently open them (e.g. via Ctrl+click or Cmd+click, or the right click menu).

It was, however, not possible until now for arbitrary text to point to URLs, just as on webpages.

philippeback

Basic abstractions behind Athens.

Since Athens is about drawing graphics, we need a media where all drawing operations will appear. We call that media a surface. The surface is abstract. It can have set dimensions, or don't. We don't define if it representing some kind of physical surface (like part of the display screen), or how it storing the data inside. We leaving an introduction of such details to concrete surface implementation. All that matters is that surface is a final target of all our drawing operations. Therefore, in Athens, a surface is usually a starting point where all begins from, and you doing so by creating a specific surface. It is surface's responsibility then, to provide user a means how he can draw on it, and therefore there is a number of factory methods, that allowing you to create a canvas, paints and shapes. All those three are specific implementation of AthensCanvas, AthensPaint and AthensShape protocols, suitable to be used with specific surface implementation that you using.

peteruhnak

"Based on Uko's script https://gist.github.com/Uko/6898022"

"Get reference to the source repository"
source := MCSmalltalkhubRepository allInstances detect: [ :each |
	each location includesSubstring: 'StName/project-name'
].

"Get reference to the target repository"
destination := MCFileTreeGitRepository allInstances detect: [ :each |
	each location includesSubstring: 'project-name/repository'

simonmichael

"
prototype ledger file parser in squeak
Simon Michael

test scripts:

s1 := LedgerParserTests sample1 readStream
PositionableStream
2007/10/7 the fairmont sonoma mission inn & spa
    expenses:food:dining  $11

dalehenrich

1. I assume that by moving to a disk-based structure, we are expecting folks to edit and modify directory structure on disk using the shell and standard editors. This means that all information is going to be stored in plain test files. No binary files. Binary files may be stored in the project structure for use by developers, but the mechanisms for loading code into an image from disk must not involve binary files.

2. I assume that we will preserve package structure on disk. This means that at a minimum we must be able to preserve the collection of class and method definitions that make up a Monticello package. This includes traits and any other standard definitions that are currently present in a Monticello package. In practice "preserving the package structure" means that one can load a package from disk and then save the package to disk in another location and the directory structure is "identical". The package loader must be respectful of files and directories that are not part of the official package