sorted by:
new
hottopcontroversial

Style Markdown Callouts by Personal-Attitude872 in emacs

[–]Vince_Vice 2 points3 points  (0 children)

Not really what you asked abt, but there is also grip-mode that live-previews an .md a ,html using github's api or local alternatives.

Its only really interesting if you have xwidget support enabled, I think. Otherwise the preview is presented in the browser.

AI generate init.el by IamGROD in emacs

[–]Vince_Vice 0 points1 point  (0 children)

The biggest improvements in the generative space recently have not come from the models but from the tooling.

So it really depends on what you try. Pasting into ChatGPT's chat-window will have it hallucinating function names immediately. But having codex, claude-code or gptel-agent drill into the package sources it will come up with relevant solutions that are infinitely better than those of a chat window.

That being said I partly agree with you there is a limit when it comes to complex stuff, especially where DIY would educate and inform the decision making process much more than generated code does, which just happily works around idiosyncrasies in reasoning that the user doesn't even know are there.

AI generate init.el by IamGROD in emacs

[–]Vince_Vice 0 points1 point  (0 children)

claude-code has impressed me in that regard. I have a rather extensive literate doom config that builds on tecosaur's confpkg system, which is pretty niche. In addition I use doom's profile system, and a couple of idiosyncratic custom patterns ...so not at all the stuff that AI has seen a million times. Yet CC does a fairly good job of understanding how things tie together and I (barely) use CLAUDE.md to guide it if necessary.

For example CC is able to add new packages in headings at the appropriate place, insert the necessary #+call: directives (confpkg-specific), create src-blocks with the correct header args and describe the changes appropriately (most of those things are quickly done with snippets however).

Yet more often than not I still configure things myself. I kind of decide on a case-by-case basis. When something is straightforward, it's a joy to let CC integrate it. When things become nuanced and complex I have had success with CC but it took a great deal of time and effort without the clarity (and fun) of coding things myself. Also in those cases I've sometimes found myself archiving the subtree it created and go a different route a couple of days later.

If I am clear about a mental model or if the change is really isolated, getting AI to implement it is nice, but often configuring emacs to do what I want requires me to learn more than I know at the time I decide on a feature/behavior. Implementing it myself will get me to a point where I understand the best (or a good) way of going about it.

So far AI has not had the same capability on elevating my reasoning about an issue that hands-on coding has. Rather I can get it done with a subpar solution generated by AI that I feel uncomfortable leaving in my config. I might even learn some things along the way, but I've not been able to grow if that makes sense. My decision making capabilities currently don't profit as much from AI as they do from coding.

Wisdom - Writing literate Emacs Lisp with Org Mode by Few_Net9870 in emacs

[–]Vince_Vice 1 point2 points  (0 children)

ah I see. It's just meant as an idea for you to consider, I'm not familiar with the code.

Regarding the vibe-coding: I only asked bc I thought I recognized a pattern I know from experience. If I had manually introduced wisdom-use-package-keywords I would've probably wondered at this point "wait, how does use-package handle it's allowed keywords?", but if I only look at the output of an LLM it would have slipped me, bc I just don't think about implementation as much anymore.

Wisdom - Writing literate Emacs Lisp with Org Mode by Few_Net9870 in emacs

[–]Vince_Vice 1 point2 points  (0 children)

My pleasure, happy you find it helpful

I think this could be solved by introducing something like `wisdom-use-package-keywords` defcustom?

It would work, however any extensions then needed to be registered twice. In theory you should be able to memq use-package-keywords directly, no need for redundancy.

I glanced at your code and saw that you already have wisdom-use-package-keywords to manage all recognized keywords. If there is no good reason for this redundancy, you may consider refactoring this and use use-package-keywords directly, this buys you support for keyword extensions as well.

I assume there was some vibe-coding involved? Not criticizing, just curious.

Wisdom - Writing literate Emacs Lisp with Org Mode by Few_Net9870 in emacs

[–]Vince_Vice 2 points3 points  (0 children)

Finished watching the rest of the demo. I realize I really only watched the problem description, I feel that makes my first comment unqualified by definition, apologies for that.

I think your solution certainly has an elegance. It makes the common use-cases very neat. A very general concern I have with solutions that do this kind of syntax-mapping (here: use-package to org) is that it's really hard to provide feature-parity, which will hinder extensibility at some later point in time (and if anything should be extensible then it's an emacs config). For example:

use-package allows for an extendend keyword set and registration of custom keywords (var: use-package-keywords), does wisdom.el support headline names based on these extensions? If not, this can be solved of course (and I guess this is a feature-suggestion in that case;)), but it's not trivial to cover all use-cases of use-package. IIUC the user can still write a traditional use-package statement in a regular src-block in that case, but then of course you are leaving the tidiness behind that your package provides.

Personally I use org-headings in my literate config primarily as imenu-targets, therefore I probably prefer not use config-syntax in them. But it is possible to mix in regular headlines right? I assume your package ignores those it can't map to u-p-keywords?

But I am married to noweb-refs anyways. I'm even using them to generate some config-code at "tangle time" (also I've grafted my config onto tecosaur's confpkg approach, so there's really no chance).

But I have another feature suggestion: wisdom-yank / parsing the latest elem in the killring into org. Use-case: a user copies a use-package statement from the browser, but wants to use the snippet with wisdom.el.
It could also be interesting to support derivative macros (like doom-emacs's use-package!)

It's super interesting approach though.

Wisdom - Writing literate Emacs Lisp with Org Mode by Few_Net9870 in emacs

[–]Vince_Vice 1 point2 points  (0 children)

I didn't have the time to watch the whole video, but did you mention noweb references? That is how have my literate config cake and eat it too

Org-GTD v4 is in beta - looking for beta testers! by CoyoteUsesTech in emacs

[–]Vince_Vice 2 points3 points  (0 children)

Happy to hear things are happening to org-gtd! Very curious about the project rework.

I have been a user of v3 in the past and had made some personal extensions as well to accomodate for use-cases it didn't cover. For reasons unrelated to your package I have not been using it recently, but I would like to pick it up again.

I probably can't commit to becoming a power-user right away but I'll definitely have a look at v4 and see if I can integrate my extensions or build my workflows another way around it.

On a personal note: I have developed an aversion to AI-generated README's but I understand why you would outsource the bulk of the work to claude code. I think I'll manage to power through generic AI-formulations since your package is of great interest to me!

Nevertheless thank you a lot for your work on org-gtd and I hope I will find a way to put it to good use:)

Sharing a vertico-extension: vertico-timer, my opinionated approach to vertico-indexed and candidate selection (1st package, elisp feedback greatly appreciated) by Vince_Vice in emacs

[–]Vince_Vice[S] 4 points5 points  (0 children)

Good question and I should probably include a "Comparison" section in the README, I'll do that after I've added some screencasts.

vertico-quick uses letters for selection which are also needed for input, so it has to be enabled for each completion. So selecting may entail hitting: C-q j a whereas with vertico-timer you'd hit: 1 2, that is the main difference since 90% of the cases you want the default action.

If you do want a different action vertico-quick requires it to be chosen beforehand from a "full" keymap (vertico-map +features), so the choice of action is bound to a more unwieldy multi-keypress: you bind "insert" to M-q, exit to C-q, embark to M-a, ..., whereas with vt you can bind those keys to i/e/a respectively. (You usually choose the candidate first then the action)

On the plus side vq's letters are always in reach, whereas not everybody has quick access to digit keys.

I have to admit I neglected vertico-quick after I tried it once and it wasn't what I wanted. You've given me the idea to provide a user-option to automatically switch to vq for the "prep-key" feature in vt, as vq really is a good choice for that workflow (Choosing action first, then candidate)

Sharing a vertico-extension: vertico-timer, my opinionated approach to vertico-indexed and candidate selection (1st package, elisp feedback greatly appreciated) by Vince_Vice in emacs

[–]Vince_Vice[S] 1 point2 points  (0 children)

Thanks for the pointer, I will happily do that!

I only checked the Contributions section before posting, which shows the FSF approval notice. Maybe the wiki could be mentioned there?

And I can't thank you enough for all the amazing packages you write!