#Elisp

[mirqmarq428]

How do we directory in common lisp? Missing f.el rn

[laejoh]

having fun with the tumblr api, looking for conversations!

This elisp function in emacs lets me retrieve conversations from tumblr! The api doesn't have any documentation about /conversations.

The sid cookie was edited of course. I don't want my private conversations to show up here.

(let ((url-request-method "GET") (url-request-extra-headers `(("authorization" . "bearer") ("cookie" . "sid=aWX8ldphBKnKvrnStFz0jHRttkdfmvNhlfKHJnrdyxgl.a"))) (url-request-data "fields%5Bblogs%5D=avatar%2Cname%2Cseconds_since_last_activity%2Curl%2Cblog_view_url%2Cuuid%2Ctheme%2Cdescription_npf%2Cis_adult%2C%3Fprimary&participant=t%3Y-T8aKdASPs_51V8TQ")) (with-current-buffer (url-retrieve-synchronously "https://www.tumblr.com/api/v2/conversations") (buffer-string)))

Have fun exploring!

[unixbhaskar]

Emacs Elisp If Else Construct To Decide Running Mode 2024_07_06_02:57:09

[thirst2]

(defmacro id3--v2-generate-write (name args docstring &rest body) "" (declare (indent 3) (debug t)) (let* ((id&verions (seq-partition (car (assoc (intern (upcase (symbol-name name))) id3---v2-frame-id-lookup #'plist-get) 2)) (firstArg (car args)) (process (lambda (var) (,var (if ,(cadr args) ,var (alist-get ',(intern (seq-reduce (lambda (result word) (replace-regexp-in-string (concat "\\(-\\|^\\)" (capitalize word) "\\(-\\|$\\)") (concat "\\1" word "\\2") result)) '("on" "per" "ID") (capitalize (symbol-name var)))) ,firstArg)))))) `(defun ,(intern (concat "id3-v2-frame-write-" (symbol-name name))) (,firstArg &optional ,@(cdr args) discard-on-tag-alter? discard-on-file-alter? read-only? compressed? encryption-method grouping-identity) ,(concat docstring " While all arguments – other than the first – are set to optional, this is for internal implementation reasons; this function will not operate correctly or as desired if the above arguments are not provided for, sans any which have been explicitly described as optional. The remaining arguments are truly optional and need not be provided unless you wish for them to be used. DISCARD-ON-TAG-ALTER? will set the Tag Alter Preservation flag, in the frame's header, to true. DISCARD-ON-FILE-ALTER? will set the File Alter Preservation flag, in the frame's header, to true. READ-ONLY? will set the Read Only flag, in the frame's header, to true. COMPRESSED? will set the Compression flag, in the frame's header, to true and apply compression, with zlib, to the frame's body; this feature is not, yet, currently implemented and will be ignored. ENCRYPTION-METHOD will set the Encryption flag, in the frame's header, to true and be used to specify the symbol that will match an ENCR frame in the tag; you should make sure to proide an ENCR frame to the tag with a matching symbol. However, this feature is not, yet,currently implemented and, at this time, will be ignored. GROUPING-IDENTITY will set the Grouping Identity flag, in the frame's header, to true and be used to specify the symbol that will match a GRID frame in the tag; you should make sure to provide a GRID frame to the tag with a matching symbol. Failure to do so won't be the end of the world but it will unclear as to what you were trying to group this frame with.")

. (let ,(append (mapcar process args) `(,(funcall process 'discard-on-tag-alter? `(,(funcall process 'discard-on-file-alter?) `(,(funcall process 'read-only?) `(,(funcall process 'grouping-identity))) (lambda (version) (if (not (member version ',(flatten-list (mapcar #'cadr (id&versions)))) "" (let* ((nonheader (progn ,@body)) (id (symbol-name (car (seq-find (lambda (i&v) (member version (cadr i&v))) ',id&versions)))) (tagAlter (if discard-on-tag-alter? "1" "0")) (fileAlter (if discard-on-file-alter? "1" "0")) (readOnly (if read-only? "1" "0")) (compress "0") ;implement later? (encrypt "0") ;implement later? (unsynch (if (id3--v2-synchronized-p nonheader) "1" "0")) (groupID (if grouping-identity "1" "0")) (dataLenID "0")) (concat id (id3--v2-nat-int-to-synch-safe-string (string-bytes nonheader)) (pcase version (3 (unibyte-string (string-to-number (concat tagAlter fileAlter readOnly "00000") 2) (string-to-number (concat compress encrypt groupID "00000") 2))) (4 (unibyte-string (string-to-number (concat "0" tagAlter fileAlter readOnly "0000") 2) (string-to-number (concat "0" groupID "0" "0" compress encrypt unsynch dataLenID) 2)))) (if (and (= version 4) (string= unsynch "1")) (id3--v2-unsynchronize nonheader) nonheader)))))))))

Welp; it won't be winning any beauty competitions, any time soon, but I won't have to rewrite the header generation for ID3 frames whenever I make a write function for a new one.

And it lets me pass in the structure of frames which have been read from an existing tag and assigns the bits of it to all the expected variables so I don't have to do it myself.

Meh; unwieldy but I'm pleased.

[pillowspace]

dunno if you've answered this before or get asked a thousand times now. Do you have any tips on drawing Sun's rays? also how many to draw? I'd see ppl do usually 7 (3 each side and 1 on top)

It's easier to figure out the placements of the rays after drawing the face first. You may see me doing that here

If you're drawing the rays at an angle, it can be good to draw lines within the rays that show the sides of them. The edges. You can be neat with this, oooor just messy and it'll still look fine

Also, again. If there's an angle, the rays on the further side of the face can be drawn much smaller, and more disconnected from each other. Disconnected, because you cannot see the base of the rays from the angle you are seeing from.

I personally prefer 7 rays. It's up to whatever's more comfortable for you. It's a stylistic choise, but I like to draw the bottom rays slightly smaller than the rest

[tokinanpa]

what do you like about emacs?

a lot of things, really! I will refer you to the documentation for Doom Emacs for a short answer to this question that I agree with, or you can keep reading for my much, much longer answer. :)

as a software that predates modern text editors and IDEs, emacs breaks the mold when it comes to the established design patterns of these tools. in some cases this can be a problem: emacs is notoriously slow (though somehow still faster than modern IDEs on my machine lol), and its default keybindings are horrendous. but it is also emacs's greatest strength: the sheer versatility and extensability of its design is unmatched by any other tool in existence.

the first thing you need to know about emacs is that.. it's not really a text editor. I mean, that may be the mission statement on the website, and that's certainly what it was when it started out, but as it's developed it's become more than that. emacs is a software platform for text-based applications.

the entirety of emacs is designed to function as one big interpreter for the language Emacs Lisp (elisp for short). when you press a key on your keyboard in emacs, say the Enter key, that keypress is sent to emacs's standard library code written in elisp. the code looks up that key in a keymap, which associates it to a particular elisp subroutine to run (specifically "newline-and-indent"), which accesses the file you're currently editing and makes the corresponding change.

every aspect of that process is configurable directly through the elisp language. you can rebind the key to a different action, of course, but you can also edit the "newline-and-indent" subroutine to do something else, or edit any other elisp function. you can switch between multiple keymaps (a keymap is just a lisp object) on some condition, such as opening a particular file. you can even tell emacs to display text that isn't linked to any file and alter the keymap when the user is interacting with that text to contain your own custom bindings. in effect, you can create any text-based interface you want.

here is a non-exhaustive list of all of the things that I have used emacs as:

IDE

Prose editor

File manager

Calculator

Productivity tool

Email client

Calendar

Web browser

Tetris

all of these tools use, to varying degrees, the techniques I mentioned above to directly modify how emacs functions through elisp. with a little knowledge of the language, you can modify these tools to your liking just as easily as you can modify emacs itself. emacs becomes a unified interface for a hundred different applications, all of which are fully configurable and self-documenting. (yeah I didn't even mention that emacs is self-documenting within its code until now).

.. so it's not even really that I "prefer" emacs, because that framing implies that there are alternatives that are equal in scope or utility. I use emacs because it is the only thing that does what emacs does.

Emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish.

- Neil Stepheson, In the Beginning was the Command Line (1998)

[piratesexmachine420]

Experience with rust thus far

Rust is great! I've been working with it off and on for around a year and change now, and I have no complaints.

It's a very... sane language. At no point have I looked at a language feature and thought "wow that's a hack", which has been my experience with almost every other imperative language to that point. (Java, C, C#, JavaScript, Python, etc.) There are a few features I think it's currently lacking, but most of them are present in the nightly branch. (I'm a big fan of let_chains and const_fn_floating_point_arithmetic, among others.)

Library support via Cargo is great, no complaints, and I love how easy doc comments are to write, it makes for an almost Elisp level of good documentation.

I've written a few non-trivial applications, like a breakout clone and a flappy bird-esque thing, and while I ditched good practices for the sake of implementation efficiency (both projects were more about learning libraries than the final product) Rust's nature makes it really easy to refactor from copy-paste spaghetti hell into clean, encapsulated, maintainable code.

I also love how anal-retentive the compiler is. Again, Rust is a very sane language. I do not want to be writing Raku, where there are a thousand "basically correct" ways to do the same thing. I want constraints, and I want them strict. I want to be able to express to the compiler not just what I want a piece of code to do, but what I don't want it to do as well. We're all human! We're gonna mess up! I want it to be easy to tell that I've messed up! (Looking at you, python, with your assignment equals declaration bullshit. Typoing a variable name should not be permitted.)

Overall it's just great. When it comes to writing applications I'd pick no other language. (Except maybe D. Too bad nobody supports D...)

[neotriobrainrot-reborn]

Was practicing elispes and circles, and I ended up trying to draw Molly’s eyes a few times while practicing. I think I need to work on the shading when it comes to her eyes

[48787]

I'm too deep in my Church of Emacs infiltration

In order to blend in I've had to condition my brain to release positive chemicals whenever I hear the words "Org Mode"

I learned how to use org babel to gain power through their trust in my familiarity and now I'm further down the Holy path than some of the acolytes, even some priests.

I've had to commit so much to my cover that I've convinced others to plunge themselves deeper into faith and put all their source code into .org files, sometimes to the point of absurdity or even singularity. And those people go on to do the same to others as well!

Will the Cult even recognize me anymore? I haven't touched my Neovim config in weeks, maybe even months now. Will I even recognize my editor once the eternal war is over?

It doesn't matter. I will win this never ending war. The Cultists of Vi's victory has been assured for years. I just need to keep reminding myself "Emacs Makes Any Computer Slow" before I sleep, or else I'll start having dreams in elisp again...

[liliallowed]

this gives me killer vibes.

specially cuz he's constantly "crying" black tears.

"you're all on your own and you lost all your friends, you told yourself that it's not you(sans) it's them(chara)"

"you're one of a kind and no one understands but those crybaby tears keep coming back again."

"someone's turning the handle, to the faucet in your eyes, you pour it out where everyone can see."

"your 🎯 to big for your body. it's why it won't fit inside. you pour it out where everyone can see"

"tears fall to the ground we'll just let them drown=)"

[mirqmarq428]

You into programming? Any languages of choice? Any projects you are willing to talk about?

Yes, i program for fun and efficiency. im addicted to Emacs, so elisp is sort of my default language at the moment. I keep trying to get into Common Lisp, and if i got a chance to sit down with StumpWM again that would be great.

I'm also quite fond of PowerShell. Imo it's about as close to lisp as you can get with sh-like syntax, and on windows it's completely overpowered (iv written briefly about this a while back, search my #powershell tag).

Projects? I tend to get just far enough in on something to use it okay for myself, then it never get polished. For example i made an Emacs plugin to change and view GNOME settings, but you have to touch the files first or it won't do anything - and i use it like twice a year so the pressure to fix that "bug" is essentially zero. Same sort of thing with the hyprland-esque wallpaper generator - i got a third of the way thru porting it to Windows/Mac and just kinda haven't picked it up since. Also with that one i had the brilliant idea of writing the git branch and remote names in kanji, so there might be even weirder bugs outside of UTF-8 Linux. Lol

[laejoh]

Use GNU Emacs - The Plain Text Computing Environment

Use GNU Emacs - The Plain Text Computing Environment (With a number of lovely quotes at the beginning:

Using Emacs is kind of like making a piece of art. You start with a big block and you slowly chip away, bringing it closer and closer to what you want. —Mary Rose Cook

[Emacs is] a Lisp Machine with several compatible user interface modalities. Which is just amazingly helpful to [blind] people like me […] who are typically forgotten about these days. […] Emacs is a shining beacon in a dark age of canvases and decorative user interface design. —Mario Lang

It wouldn’t make sense to start out with anything other than Emacs. I don’t think there has been a piece of software which has had a larger impact on my life. I began using this about fifteen years ago, and it has followed me across operating systems, jobs, roles (I used it to manage my teams), languages, and needs. Every time I start something new, Emacs has been there to make it just a little easier, and the more I do in it, the easier everything gets. I believe this power comes from Emacs being the closest thing we have to a working Lisp Machine. —Katherine Cox-Buday

Emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. —Neal Stephenson

Emacs is the King of Editors because it’s a Lisp interpreter. Each and every key you tap runs some Emacs Lisp code snippet, and since Emacs Lisp is an interpreted language, that means that you can configure any key to run any arbitrary code. You just, like, do it. —Lars Magne Ingebrigtsen

I’m using Linux. A library that Emacs uses to communicate with Intel hardware. —Erwin, #emacs, Freenode

OSs and GUIs come and go, only Emacs has lasting power. —Per Abrahamsen

I am large, I contain multitudes. —Walt Whitman) (🔁) (mapcar #'emacsomancer objs) (@emacsomancer@types.pl) 2023-03-03 09:57:02

[mentalisttraceur-software]

histdir

So I've started a stupid-simple shell/REPL history mechanism that's more friendly to Syncthing-style cloud sync than a history file (like basically every shell and REPL do now) or a SQLite database (which is probably appropriate, and it's what Atuin does while almost single-handedly dragging CLI history UX into the 21st century):

You have a history directory.

Every history entry gets its own file.

The file name of a history entry is a hash of that history entry.

The contents of a history entry file is the history entry itself.

So that's the simple core concept around which I'm building the rest. If you just want a searchable, syncable record of everything you ever executed, well there you go. This was the smallest MVP, and I implemented that last night - a little shell script to actually create the histdir entries (entry either passed as an argument or read on stdin if there's no entry argument), and some Elisp code in my Emacs to replace Eshell's built-in history file save and load. Naturally my loaded history stopped remembering order of commands reliably, as expected, which would've been a deal-breaker problem in the long term. But the fact that it instantly plugged into Syncthing with no issues was downright blissful.

(I hate to throw shade on Atuin... Atuin is the best project in the space, I recommend checking it out, and it significantly inspired the featureset and UX of my current setup. But it's important for understanding the design choices of histdir: Atuin has multiple issues related to syncing - histdir will never have any sync issues. And that's part of what made it so blissful. I added the folder to Syncthing - no separate account, no separate keys, nothing I must never lose. In most ways, Atuin's design choice of a SQLite database is just better. That's real, proper engineering. Serious software developers all know that this is exactly the kind of thing where a database is better than a bunch of files. But one benefit you get from this file-oriented granularity is that if you just design the naming scheme right, history entries never collide/conflict in the same file. So we get robust sync, even with concurrent use, on multiple devices - basically for free, or at least amortized with the setup effort for whatever solution you're using to sync your other files (none of which could handle updates from two different devices to a single SQLite database). Deleting a history entry in histdir is an "rm"/"unlink" - in Atuin it's a whole clever engineering puzzle.)

So onto preserving order. In principle, the modification time of these files is enough for ordering: the OS already records when they were last written to, so if you sort on that, you preserve history order. I was initially going to go with this, but: it's moderately inconvenient in some programming languages, it can only handle a 1-to-1 mapping (one last-modified timestamp) even though many uses of history might prefer an n-to-1 (an entry for every time the command was called), and it requires worrying about questions like "does {sync,copy,restore-from-backup,this-programmatic-manipulation-I-quickly-scripted} preserve the timestamp correctly?"

So tonight I did what any self-respecting drank-too-much-UNIX-philosophy-coolaid developer would do: more files. In particular:

Each call of a history entry gets its own file.

The file name of a call is a timestamp.

The contents of a call file is the hash of the history entry file.

The hash is mainly serving the purpose of being a deterministic, realistically-will-never-collide-with-another-history-entry (literally other causes of collision like hackers getting into your box and overwriting your memory are certain and inevitable by comparison) identifier - in a proper database, this would just be the primary key of a table, or some internal pointer.

The timestamp files allow a simple lexical sort, which is a default provided by most languages, most libraries, and built in by default in almost everything that lists/iterates a directory. That's what I do in my latest Elisp code in my Emacs: directory-files does a lexical sort by default - it's not pretty from an algorithmic efficiency standpoint, but it makes the simplest implementation super simple. Of course, you could get reasonably more efficient if you really wanted to.

I went with the hash as contents, rather than using hardlinks or symlinks, because of programmatic introspection simplicity and portability. I'm not entirely sure if the programmatic introspection benefits are actually worth anything in practice. The biggest portability case against symlinks/hardlinks/etc is Windows (technically can do symlinks, but it's a privileged operation unless you go fiddle with OS settings), Android (can't do hardlinks at all, and symlinks can't exist in shared storage), and if you ever want to have your histdir on something like a USB stick or whatever.

Depending on the size of the hash, given that the typical lengths of history entries might be rather short, it might be better for deduplication and storage to just drop the hash files entirely, and leave only the timestamp files. But it's not necessarily so clear-cut.

Sure, the average shell command is probably shorter by a wide margin than a good hash. The stuff I type into something like a Node or Python REPL will trend a little longer than the shell commands. But now what about, say, URLs? That's also history, it's not even that different conceptually from shell/REPL history, and I haven't yet ruled out it making sense for me to reuse histdir for that.

And moreover, conceptually they achieve different goals. The entry files are things that have been in your history (and that you've decided to keep). They're more of a toolbox or repertoire - when you do a fuzzy search on history to re-run a command, duplicates just get in the way. Meanwhile, call files are a "here's what I did", more of a log than a toolbox.

And obviously this whole histdir thing is very expandable - you could have other files containing metadata. Some metadata might be the kind of thing we'd want to associate with a command run (exit status, error output, relevant state like working directory or environment variables, and so on), but other stuff might make more sense for commands themselves (for example: this command is only useful/valid on [list of hosts], so don't use it in auto-complete and fuzzy search anywhere else).

So... I think it makes sense to have history entries and calls to those entries "normalized" into their own separate files like that. But it might be overkill in practice, and the value might not materialize in practice, so that's more in the TBD I guess.

So that's where I'm at now. A very expandable template, but for now I've just replicated basic shell/REPL history, in an a very high-overhead way. A big win is great history sync almost for free, without a lot of the technical downsides or complexity (and with a little effort to set up inotify/etc watches on a histdir, I can have newly sync'ed entries go directly into my running shells/REPLs... I mean, within Emacs at least, where that kind of across-the-board malleability is accessible with a reasonably low amount of effort). Another big win is that in principle, it should be really easy to build on existing stuff in almost any language to do anything I might want to do. And the biggest win is that I can now compose those other wins with every REPL I use, so long as I can either wrap that REPL a little bit (that's how I'll start, with Emacs' comint mode), or patch the common libraries like readline to do histdir, or just write some code to translate between a traditional history file and my histdir approach.

At every step of the way, I've optimized first and foremost for easiest-to-implement and most-accessible-to-work-with decision. So far I don't regret it, and I think it'll help a lot with iteratively trying different things, and with all sorts of integration and composition that I haven't even thought of yet. But I'll undoubtedly start seeing problems as my histdirs grow - it's just a question of how soon and how bad, and if it'll be tractable to fix without totally abandoning the approach. But it's also possible that we're just at the point where personal computers and phones are powerful enough, and OS and FS optimizations are advanced enough, that the overhead will never be perceptible to me for as long as I live - after all, its history for an interface with a live human.

So... happy so far. It seems promising. Tentatively speaking, I have a better daily-driver shell history UX than I've ever had, because I now have great reliable and fast history sync across my devices, without regressions to my shell history UX (and that's saying something, since I was already very happy with zsh's vi mode, and then I was even more happy with Eshell+Eat+Consult+Evil), but I've only just implemented it and given it basic testing. And I remain very optimistic that I could trivially layer this onto basically any other REPL with minimal effort thanks to Emacs' comint mode.

[prodigalbutch]

what if over break i learn elisp And some webdev stuff,,, at the same times,,,,,

[pillowspace]

what’s the best way to draw the dca’s head for you? just free drawing it or using an elispe tool?

need to know for “research purposes”

Sometimes I'll use a shape tool. But like 95% of the time, I free draw it on its own. Here, have a Sun doodle in under 5 minutes for fun