Hi, I wrote my message in a hurry. Let me clarify it. > > I'm only talking about built-in tooling. I don't mind if a user have the > feature you're proposing, of course, as it is not wrong per se. > > However, I believe that's not the best solution for the problem we're > trying to solve. I think there's an opportunity to provide something > smarter, and less intrusive, to handle emphasis, which doesn't involve > messing with `post-command-hook'. >
I agree with you that my solution is somewhat intrusive. Ideally, I would have preferred that my solution could leverage advice functions or some Org hook, so that I wouldn't have to modify org.el, but it doesn't seem like there is a straightforward way to do that. The modification of `post-command-hook', similar to one used for `prettify-symbols-mode', only occurs if `org-auto-emphasis-mode' is active > Like in a word processor, you don't need to see the markers to operate > on them. I don't think the usual "toggle" model is appropriate, however. > I suggest to use two commands: one for deleting the markers around point > or within active region, and one for inserting markers or extending > existing ones. > So in your system, in order to interact with emphasis markers, the user would have to learn two different commands? That doesn't seem to be in line with the dwim philosophy used in modern emacs packages. In my opinion, one of the strengths of Org is that the interface is multimodal. One can (in principle) edit documents in much the same way as word processors and rich text editors. However since everything underneath is implemented with just text, one can also directly access and manipulate this text. The ability to switch between these two modalities is extremely powerful and is what sets Org apart from other document editing systems. > Allow me to polish up my draft a bit, so we can compare the benefits of > each system. > I look forward to seeing your proposed system more concretely. Shankar Rao
