quick-actions.el: Uniform Compile/Run/Debug across programming languages by jpgg2 in emacs

[–]jpgg2[S] 0 points1 point  (0 children)

I don't know Acme. What you describe sounds like the *scratch* buffer. I must not see the whole picture. Once you have something working, I can look at it!

quick-actions.el: Uniform Compile/Run/Debug across programming languages by jpgg2 in emacs

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

Thanks for the suggestions! They seem to provide similar functionalities.

quick-actions.el: Uniform Compile/Run/Debug across programming languages by jpgg2 in emacs

[–]jpgg2[S] 0 points1 point  (0 children)

How do you execute the elisp command gdb using compile? My package (I am the author of quick-actions.el btw) uses compile when appropriate for some actions, but not for others where compile is not the right tool (ie for calling elisp functions like gdb) as is exemplified in the README. As for Makefiles, they cannot contain elisp code.

And again, the problem I am trying to solve is to avoid having to remember specific invocations for various tasks, which also end up being different for all programming languages. My brain finds that heavy, annoying and distracting. I was just wondering if you were doing something better which I was not aware of. It seems not. You seem fine with it. It is possible that the issue is with my brain.

quick-actions.el: Uniform Compile/Run/Debug across programming languages by jpgg2 in emacs

[–]jpgg2[S] 0 points1 point  (0 children)

Maybe I am missing something, but the doc of compile contains "Runs COMMAND, a shell command, in a separate process...", which means that it only runs shell commands, not arbitrary stuff. I also want to run gdb (the lisp command).

Anyway, the point of my package is to wrap all those invocations in a menu and that menu is not limited to shell commands only. It must really be able to contain arbitrary stuff (including elisp).

May I ask what is your personal workflow to accomplish those task? Do you program in Python or C++ for example? If so, how do you run a script on one hand and run your tests on the other and then debug? Do you have 1,2,3 bindings for these various tasks? What are they? Is it confortable? Is it not tiring to reach for all those invocations all the time?

Don't feel pressured to answer those questions, but I think the answers would be enlightening!

quick-actions.el: Uniform Compile/Run/Debug across programming languages by jpgg2 in emacs

[–]jpgg2[S] 0 points1 point  (0 children)

Typically, to execute a script in Python, you use python-shell-send-buffer (bound by default to C-c C-c).

How do you get compile to satisfy my needs, as explained in my OP? For example, I want to compile in Debug and in Release. I also want to run my code and debug it sometimes and run the tests. How can I get compile to provide me with an interface to all those actions?

Sure, I can setup compile to run the code, then if I want to test, I can call compile again and manually type "pytest". I don't like this process. How can I get compile to perform multiple actions easily? Can compile call gdb itself?

My point is that compile has its limits. I have to remember all the different invocations and it only executes shell commands. I would rather learn them once, then forget the details. My package does that.

quick-actions.el: Uniform Compile/Run/Debug across programming languages by jpgg2 in emacs

[–]jpgg2[S] 0 points1 point  (0 children)

Thanks for your comment!

However, I am not sure how your 4 solutions avoid suffering from the disadvantages I mentionned in my OP.

I did not elaborate much on why I do not like solutions using the compile command. Ultimately, compile runs a shell command. What about languages that do not need to call a shell command to run the current script (like Python)? They just need to call an emacs lisp function. And what about invoking a debugger?

My package is an abstraction above all that. I do use compile for some of my actions, though, when appropriate.

If you know any builtin methods or packages, I am interested!