Comment by olivierestsage | Hacker News Reader

Comment by olivierestsage | Hacker News Reader

Thanks for sharing this. My personal experience speaks to a lot of what the author mentions: I'm an academic with little programming experience to speak of (mainly some Java in high school), and it always seemed to my younger self like there was this insurmountable hurdle between the language-learning phase and the part when you can actually develop useful applications. Now, of course, I know that this is not necessarily true of programming, and that this discouraging feeling is something beginners experience in many fields--but that's how it seemed back then.

Flash forward to now: I picked up Emacs a year or so ago because of Org-mode and its promise of organizing my tasks. Gradually growing my init.el to fit with my way of thinking was my first encounter with programming with any kind of direct practical application, since (as the author mentions) a beginning user frequently pastes simple Lisp functions off StackExchange, and you can kind of puzzle out how they work with your own eyes, immediately, even if you lack significant training. It soon gave me the goal of using code that I could understand (at least somewhat) when I needed new Emacs functionality, rather than just downloading a big package off MELPA that would be far beyond my comprehension. And that was the point I started to learn Emacs Lisp.

Currently I've been working on a minor mode. Who knows how long it'll take me, but it's been a fun ride, and I credit this personal development to the lack of barriers in Emacs that the author describes.

Ironically I think org-mode is a great example of a non-malleable system. When I started using it I slowly tried to customize it to better suit my needs, but everything was quite brittle.

Posted a comment awhile back with some specific examples from my experience: https://news.ycombinator.com/item?id=20551598

I'd say it's very customizable, but requires (sometimes significant) time investements.

I'll respond here since can't reply to the original comment:

1. "leading stars" -- I think the solution is org-hide-leading-stars (and it is basically the hack you are describing)

2. "now it takes multiple seconds to refresh my agenda view" -- org-super-agenda is a pretty mature library handles groups well. As for performance, the most significant speedup for me was setting org-agenda-span to a lower value

3. "it's actually pretty hard to find good examples of a full org-mode workflow." -- agree. One reason is perhaps because it's quite hard to communicate your workflow to other people becaue it's too specific to your needs.

4. "But problematically I now have a lot of files with similar names" -- yep, refile-outline-path, but also uniquify helps a lot.

5. "Apparently org-mode deliberately prevents the end user from adding their own custom emphasis formats" -- don't know whether that's the case; but you can abuse org-add-link-type, then you could write [highlight:Some text to highligtht], and do whatever styling you want during the export. Hacky, but kinda does the job.

Finally, it's at least possible in theory to override any org-mode function and change the logic. Of course, you can do it with any other text editor, but it would be way less effort to hack Emacs (even if it's dirty and adhoc).

I can however understand the frustration. It took me several attempts to pick up Emacs and Org-mode specifically. And I'm still very often frustrated by it, but I personally find being able to bend your editor into doing exactly what you want worth the effort.

See [0] for for #5 (customized highlighting).

[0]: https://www.reddit.com/r/orgmode/comments/f7amq2/weekly_rorg...

> And I'm still very often frustrated by it, but I personally find being able to bend your editor into doing exactly what you want worth the effort.

I agree with this assessment. Emacs is frustrating and terrible and you'll never get things just right, but as a software developer, I've found its extensibility and programmability to be profoundly life-altering.

> I'd say it's very customizable, but requires (sometimes significant) time investements.

It seemed like with enough effort I could get emacs to mostly do what I wanted, but it never seemed like I could get it to do what I wanted well. Maybe I just gave up on it too soon.

Yes, it's quite brittle. Looking over your list, part of the problem is also that it was written to function as a WYSIWIG system in an environment meant for text buffers (rather than a generic MVC like framework where you could apply an arbitrary transformation on the on-disk data to present on the screen).

If you're a power user who would like a very malleable system, I can't imagine anything better than Scribble/Pollen. IME it felt very natural to use, and is infinitely flexible (fully-programmable in Racket).

[can't add comment to your old post]

1. org-bullets 2. it seems like a bug with performance for long lines in emacs (at least it was in my case) 3. there is no size fits all: my org file are header, code blocks -heavy lots of hierarchy, tags, properties; yours may be completely different 4. refilling works via narrowing the list of candidates using ivy (it the same interface used for switching to a project, opening a file, switching to a different buffer, running a command, etc)

5. https://emacs.stackexchange.com/questions/5889/how-to-highli...

> 5. https://emacs.stackexchange.com/questions/5889/how-to-highli...

This is a good example of my frustration. The solution you suggested allows you to change how an existing emphasis character appears in emacs, but does not allow you to add a new emphasis character. Not great if you still want to be able to use all the old emphasis characters.

To add highlighting without interfering with an existing emphasis character, you're stuck with some ugly hacks (of which I tried a few before giving up). Apparently the reason for this particular limitation is so that org-mode has a consistent syntax for parsing outside of emacs (https://lists.gnu.org/archive/html/emacs-orgmode/2013-02/msg...). I don't care about parsing outside of emacs (and even if I did, it doesn't seem too terrible to just have my custom emphasis character get printed to the screen without the appropriate formatting). A truly malleable system wouldn't make it so hard for me to modify it to my liking based on my particular needs.

I was able to consistently get emacs/org-mode to work sorta how I wanted it to, but it was _always_ hacky and clunky.

I’ve taken 3 semesters of OOP and 1 semester of functional and still have no idea how I would build a program if someone told me to

1. Write placeholder output, the equivalent of a Hello World for the task.

2. Start parameterizing parts of the program to generate the output, so that more and more of the output comes from a few source variables.

3. Eventually you want a user interface on this and have it load from disk instead of recompiling...and so you end up with a complete program.

You generally don't get there just by concentrating really hard on the architecture. You architect a bit and then try things to get empiric feedback.

I'm writing a script right now. So far I've got a constructor written, and comments written for what the "main method" equivalent part of it will be doing.

My next step is to implement the first comment: reading in my input file, at which point I'll add some temporary code to loop through and print out what got read in, so I know I did that right.

Then I'll move on to implementing the next main-method comment, which'll loop through records from my input file, open files it says to, find certain lines, and edit the text of em. So basically using the loop I already wrote above, I'll add in code for it to find the line number I want, and print that out so I know that bit works.

etc etc. It's all iterative. You start with bare bones, and add meat and tendons here and there, iteratively, throwing in test output as you go so you know the bit you just made works.

edit: and you don't have to go in order, either. Writing comments like I did that lay out what my "main method" will be doing, lets me know "okay, i've got a file-reading bit, a file-seeking, -interpreting, and -writing bit, I'll need a bit that outputs results as CSV..." and I wrote above about implementing the first step and a little of the second, but the constructor I have written is for the last step, my results-as-CSV step, because that's a thing that was easy to think about while I pondered the tougher bits. I'll add more to that constructor, probably, as I realize "oh yeah I wanna know about X aspect of each operation result, too!"

There'll be lots of TODO comments here and there as I bounce around, and it'll get built up in bits and pieces, like starting with a spooky skeleton and adding more and more meat to it til eventually you have the whole body

Reply on news.ycombinator.com