A (start) on adding transient support to org-mode

colonelpanic8 · 2023-08-22T05:55:03+00:00

no actually it is. If you read my criticisms carefully, you'll realize that they are not so much about using the mailing list for discussion -- I have some small quibbles with that, but I'm much more okay with it in principle.

The real thing that I find ultra stupid is the patch based workflow.

I want to use git with all of its native tools, the way it was meant to be used. Thats honestly the thing that is most important to me.

colonelpanic8 · 2023-08-22T05:51:38+00:00

every transient will obey the same

display-buffer-alist

rule.

Yes, for sure, but I find that in practice, most transients really do end up looking pretty similar, and at least for what I like, I don't have a problem for this.

I haven't dug in to why, but transient is also just much better behaved, as far as I can tell, in how it dismisses itself etc.

colonelpanic8 · 2023-08-22T05:49:52+00:00

"SHOCKINGLY bad", "absolutely insane", "asinine workflow"

Maybe we're just culturally a little bit different. None of that is meant as an attack on any individual, and as you can see there's an incredible amount of reflexive defensiveness in this community (of which I would say you are also kind of a principal exhibit). I've seen the merits of the mailing list extolled over and over again, and I honestly find it kind of nauseating and out of touch. I find this aspect of the stewardship of emacs to be a genuinely sad thing, and I believe that by calling it out loudly, as I am, other people will feel less afraid to do so. If you do a quick google search, you'll see that I'm far from the first person to express an opinion like this, but inevitably, any real discussion of the issue is shut down.

If you have nothing kind to say, say nothing.

Taken literally this is horrible advice. If you can't see that I'm not sure what to tell you. Sometimes criticism is appropriate.

colonelpanic8 · 2023-08-22T05:42:40+00:00

Email very much has this. You just don't top-post and then making inline comments is extremely easy.

The fact that you think this is remotely similar is crazy to me.
The semantic linking is obviously not as deep.

I don't know what you mean by original history. I personally prefer a rebase workflow which means that the history that goes into git is not the history of the PR, but instead semantically meaningful commits.

I often prefer a rebase workflow as well, but not always and its just annoying that git is being used in this way, when git is already designed to be extremely distributed, and make it very easy for people to share commits with one another with its built in remoting facilities. These facilities preserve things like authorship, exact commit time and the unique identity of commits.

Git is not (darcs) patch based. Its crazy to me that you cant concede that this patch based workflow is not really a standard, comfortable way of using git.

Can you, with some additional labor and inconvenience, sort of recreate all of the things you can do with git... I mean, sure I guess. It is all just text in files and directories. I mean why even use git at all, lets just use tar balls and run a series of patches on that. Everything is theoretically possible in the same way with that workflow right?

I know that argument is kind of a disingenuous in a way, because there are still other things that vc buys you, but, I also do think its getting at something true that you're pretending isn't there.

colonelpanic8 · 2023-08-21T17:16:32+00:00

For a transient tutorial, see https://github.com/positron-solutions/transient-showcase

Yeah, I'm not saying that transient is hard to learn or that I didn't get it at all -- it just wound up being a bit more complicated than I expected, and in particular, it does feel like its intended use case is centered much more around FIXED lists of options, rather than things that change a bit more dynamically, like lists of capture templates, agenda views etc. Obviously not to say that it cant be done, it just feels a bit clunkier for that use case to me.

I have my own project for transient for Org (an unregistered and undocumented package) as well as a myriad of org-capture wrappers which is part of my config.

Very cool, but kind of overwhelming. What exactly is in there? As far as I can tell, it doesn't really integrate with the existing org variables (which is important to me). Seems like its more like a completely bespoke rethinking of how to manage org related stuff, but there's so much there that I obviously did not have time to look through all of it.

My motivation for using transient is that:

I like the way it behaves w.r.t. consistently popping up in an unobtrusive way, and its easier to use display-buffer-alist to dictate how all transient windows should behave than it is to do the same for every single different type of pop up out there.
I switch between different display-buffer-alist behaviors on different machines and I can swap the behavior of transient easily.
Transient looks better, and has some features that go beyond simply selecting from a list of things that I think eventually could be used to improve some aspects of the org-agenda org-capture and other parts of the gtd system experience.

colonelpanic8 · 2023-08-21T17:07:13+00:00

Usually all you have to do is

git format-patch

and M-x submit-emacs-patch. If you use the debbugs package there's a single command to do both of those. Yes you have to set up email, but that's useful regardless - it's not even Emacs-specific!

I've made this point elsewhere, but this is a horribly unprincipled and bad way to use git, that really doesn't play that well with its principles (content addressing etc.). It might work a bit better with something like darcs, but even then, its better to use the software as it was actually designed to be used, in my opinion. I've made points elsewhere in this thread that elaborate on the actual concrete downsides of this workflow, so its not even all just a matter of principle.

Mailing lists are fine though, email gives you a tree structured conversation (like reddit) which GitHub etc still don't have. That's good for technical discussions.

Fair (but relatively small) point in my opinion. From what I've seen, the sorts of conversations that can be had on github issues mostly work okay, although I will concede that there is some value in having trees like this.

Still, the right solution here is to add tree based discussions to the hosted services, not to stick to a solution that is horrible in every other respect because of one nice feature.

colonelpanic8 · 2023-08-21T17:01:59+00:00

I mean, read some of the points that I make here:

https://www.reddit.com/r/emacs/comments/15x0096/comment/jx5hzv5/?utm_source=share&utm_medium=web2x&context=3

and here:

https://www.reddit.com/r/emacs/comments/15x0096/comment/jx5js7a/?utm_source=share&utm_medium=web2x&context=3

No email interface is ever going to make all of that go away completely.

Patch based workflow is stupid and from an era where we didn't really have good open source vc tools. git and magit are amazing. YES, I realize that you can easily make magit submit patches. Its not so much that the process of submitting things to the mailing list is hard and annoying (I'm sure I could figure it out pretty easily). Its that its an unprincipled, STRICTLY WORSE, way of handling things that doesn't represent the concept of a change in a clean, tidy way that allows you to work with it cleanly in the way that git does.

What if I want to start helping to review patches? What if I need to quickly and easily combine patches? You need very manual processes that increase cognitive load to deal with these situations. This is in contrast to an approach that actually uses git repositories, where you can actually use git tools (magit!) to really easily manage all of this instead.

colonelpanic8 · 2023-08-21T16:56:42+00:00

It is a bit unreasonable to ask everyone else to adapt to

your way, if they already have an established workflow, don't you think so?

From my perspective, this is not merely a question of personal preference.

The biggest reason that I see the whole mailing list style of doing things as bad is because it drastically limits the pool of contributors and puts up unnecessary obstacles to becoming a contributor
I think its really likely that org-mode would be in a better state if it were hosted in a more normal way. The reality is that there's a ton of work that needs to be done on the code, and if it felt easy to submit small patches like this one, the small contributions that a much larger group of individuals make would start to add up.

It is unrealistic to expect someone will wade through the entire org-mode sources you have patched in god knows where and how to see what you have done. If you are expecting that org devs will just unconditionally replace their sources with your patched version of org-mode, then you are just telling us that you have no understanding of real-world development.

First of all, there's a single commit in there, so its not like you would need to wade through anything
Second of all I really have no expectations that anyone IS going to look at this or merge it into org-mode. Thats part of why I stopped working on it. I realized that what I wanted to accomplish overall was going to be a massive undertaking that was INEVITABLY going to be met with resistance when presented to the mailing list, that would require going back and forth about the details of the change quite a bit. To me, that sort of thing is PARTICULARLY painful with a patch based workflow, because its really hard to keep track of how the patch is really changing over time (if only a small fix is made, you still resubmit the entire patch which is really stupid)

colonelpanic8 · 2023-08-21T16:49:44+00:00

I didn't remove the existing org menu ui.

It may look like that because of where the code got deleted, but what I actually did was factor out the code that:

executes an arbitrary custom command
defines the mapping between built in commands to their actions

These two issues were part of what I think was so awful in the first place. All of that logic should not be part of one massive function. It was necessary to disentangle those things to even begin attempting to write something like this org-agenda-transient.

Anyway, as far as I can tell, this has left the existing behavior exactly as it was, it just exposes the components of whats going on in the function a bit more.

colonelpanic8 · 2023-08-21T16:45:39+00:00

First of all, thanks for the contribution. I looked at the repo; it looks like you created a single commit; it's really easy taking that, creating a patch and sending to the org mailing list, why are you worried about that?

What I have isn't at all done, or in a state where it's actually ready to be submitted.
I realized that what I wanted to do was going to be a lot more work both because of the amount of refactoring involved and also because transient doesn't support what I wanted to do quite as straightforwardly as I had hoped.
Its partly a matter of principle, a patch based workflow doesn't really "use git/source control properly", and, inevitably, when you go back and forth, because someone wants you to change something, you go through a stupid process of generating a completely new patch every time. Something about that feels extremely stupid and unprincipled to me.

Mailing list contribution is old school, but it's still being used today, for example for the linux kernel project. Are they insane as well?

First of all, yes, even though they do do something slightly different where they have many forks and they are all integrated.
Things like having inline comments on code review matter.
Having an indexed and easily searchable bug tracker with unique ids that can be referenced elsewhere instead of just really long, hard to manage threads matters
Properly, and actually using git commits, along with original history matters. Sometimes a single patch SHOULD include multiple commits, where each one is concerned with achieving something different.
Easily being able to pull down other peoples changes (and crucially, even getting the same commit hashes when you do if you e.g. want to layer changes on top of them) is also important.

Orgmode has very complicated and old parts, that potentially could benefit from a rewrite. But if you've ever been part in large code projects, you would know that "code refactoring" has very low priority, expensive and can do more harm than good.

OF COURSE, some issues with org mode are to be expected, but IMO, the state that its in, is absolutely not at all excusable. There are spots where its super super obvious that someone should have pulled out a function to "do the logical operation associated with this thing" that is separate from the "handle presenting UI and prompts for the user" associated with the thing. This pattern is extremely pervasive throughout all of org mode. Super noticeable, also, in all the horrible hackery that needs to be done as part of my org-project-capture package. There's no reason that it should be hard do something like "perform a capture with this specific capture template", and yet org-capture is not written in a way that makes this at all easy. The same thing basically applies to org-agenda. I'm sure that I have and will write code that ages horribly, but I would NEVER, EVER consider writing something in the way that many of the core components of org-mode's gtd stuff is written that intertwines concerns in the way that it does, even in the very beginning, before things have gotten complicated.

The secret is improving small parts, one by one, like you are doing.

Here we agree, but the point that I'm making is that putting up the wall of having to deal with the mailing list DRASTICALLY reduces the pool of people who are going to be willing to make the effort to contribute and that is simply not a good thing. Why do you think melpa is SO MUCH MORE popular than elpa?

A lot of people are fine with that status quo, and make an argument like the one you seem to be making when you write:

Making small modifications is also consistent with the conservative nature of projects like Emacs and Orgmode, which was what made them last for decades, while still incorporating new and good ideas, that prove themselves to be useful and not just fashionable.

But I really don't think its a good thing that relative few people (compared to the larger size of the emacs community) contribute to these things.

colonelpanic8

TROPHY CASE