fragbot2

I'd start with traditional emacs key bindings and a rudimentary initialization file. As you get more comfortable, increase the complexity of your initialization file to solve a current need. I'd advise not thinking about learning emacs but think about using emacs instead. If you're persistent, you'll use it to solve a set of different problems (using myself as an example, I've started using emacs as a replacement for two usecases--text generation and automated search and replacement on a large number of files--that I typically solved with shell scripts).

Not wasting a huge amount of time screwing around with emacs requires discipline as it's easy to screw around on things with little value (e.g. trying every theme you can find or searching for the perfect fix to something that only happens on startup) because it's interesting. I'd plan on a little time for fun but avoid going overboard.

Not just you and it's not just /r/emacs or /r/org-mode, I've seen them in other places as well. While the guy in /r/org-mode wasn't one, most of them write so poorly that they must be ESL people and argue about minute things that well-adjusted (genuine?) people wouldn't argue about.

The other thing I'm seeing is an increase in duplicated posts to multiple forums asking fragmentary, barely coherent questions. Writing this, I just had the obvious epiphany that my assumption--there's a person at the other end--might be wrong.

Several comments:

• based on the CPU utilization, I'm guessing there's an error condition that causes a spin that continually tries to allocate memory.
• in my experience, things like this are often visible if you trace the executable. Unfortunately, OSX makes this unpleasant: https://www.shogan.co.uk/devops/dtrace-dtruss-an-alternative-to-strace-on-macos/.
• if you send a kill -11 to the process, you should get a corefile of the running process. Running something like strings or hexdump against the resulting image (you'll want to remove it when you're complete) might make the problem obvious. There should be a way to start the process with limited memory to avoid generating a 30GB core file.

Things I'd recommend checking out:

• start using dired as a file manager.
• get comfortable with macros.
• hyperbole as a bookmark manager on steroids (specifically explicit buttons).
• find a templating system for standard document/code generation (I use yasnippet after failing to make sense of srecode).
• write an interactive emacs lisp function to solve a text editing problem; extra credit for clever use of temporary buffers.

My general thought:

(defun zzz (elt)
   (let ((file (car elt))
            (repo (cadr elt))
             (st (caddr elt))
             (is (cadddr elt))
       (progn (find-file file)
         (search-forward repo)
         (switch-me-to-interactive-node-until-i hit-a-hotkey st is)
         (save-buffer)
         (kill-buffer))))

It's the switch-me function that I'm not sure how to approach.

What kind of URL and what version of hyperbole? I've seen something similar where certain types of URLs (notably ones that looked like a Jira id) broke hyperbole's implicit button recognition code...but only for URLs in that format.

Why are you working so hard to avoid source control? It solves the following:

• assuming you use github, gitlab or chiselapp (fossil hosting), it provides a practically free way to keep multiple machines in sync. You could also just use something like dropbox or an S3 bucket.
• if I wanted wanted to see commit history (what you're calling logs) in the file I'm working on, I'd create a src block that ran a command against the source control system and formatted the results appropriately. While I haven't done this with commit messages, I have done it on export to record the exported version.

I avoid git (work) or fossil (home) with literate org files as I don't want a full repository for a single file so I'll use rcs or sccs with emacs vc-mode.