package-lint VS expand-region.el

Exactly! This is also why I like Compat. I have to read through the Emacs NEWS anyway, then I can just as well add the functions directly to Compat. The small downside however is that Compat pretends that some function is available in your Emacs. If you write a package you must look twice where a function is coming from. This should not be a problem if you use package-lint, which you should! But see also https://github.com/purcell/package-lint/issues/227.

Thank you for reading that far. If you have feedback, questions or improvement proposals, please let me know. I hope that Compat is useful for you. If you miss some important functionality, feel free to open an issue on the issue tracker. Any help in adding missing functionality is welcome. In case you are interested in upstream development, you may want to help with scanning through years of the Emacs Git log for added functionality. A laborious process, but the Emacs library diffs from package-lint are useful. Unfortunately package-lint does not yet support Compat and warns if you use compatibility functions. Also package-lint does not yet track argument number changes. Help with those package-lint issues would be greatly appreciated.

I would suggest using the checkdoc command in each of your package buffers. It will point out stylistic errors. flymake-mode will help catch byte-compilation errors as well. You should also install https://github.com/purcell/package-lint and M-x package-lint-current-buffer to get these up to par for MELPA.

(Note that the current minimum requirement for Emacs is set to 27.2, I'm pretty sure this can be lowered but I'm waiting on this issue for confirmation. Until then, if you have an older version, you should probably be able to install with quelpa just fine).

Also consider using checkdoc and package-lint before you publish stuff, it is really annoying to get warning pop-up for docs wider than 80 chars. Those are so easy to catch up. Generally, it is good to follow Melpa guidelines even if you don't plan to publish your package in Melpa.

I strongly suggest you to use package-lint when writing packages. It will point out all version mismatches, and some other things.

I don't use Meow, so this may be wildly off the mark (no pun) here. But I use and really like expand-region for selection and marking. With modal editing, I imagine it would be extremely fast and intuitive.

I think the following packages would fit your wishlist, as it is very similar to mine. As mentioned in the replies, there is (https://github.com/magnars/expand-region.el) and (https://github.com/mickeynp/combobulate). I regularly use (https://github.com/Fuco1/smartparens).

Paredit, Speed-of-thought lisp, Helm, perhaps Lispy but I am not using it myself. I found expand-region to work really well when writing and modifying elisp. lisp-extra-font-lock if you want some more blink (and font-lock-studio). Helpful is very good to have instead of built-in help, it displays the source code by default as well as symbol properties. It is a very informative learning experience to see how built-in stuff is implemented. I am quite lazy to press extra in built-in help to see the source code, but with Helpful, you get it auto in the same window, whicih is great for learning. Seeing symbol properties is sometimes a time saver so you don't have to M-: and type an Elisp function to see the symbol properties when debugging. Learn Edebug, it is very useful built-in application for Emacs Lisp development.

Exactly. Consider you have point in a table definition. You can programmatically find which org element you are in, at least for org-mode. Or in a defun for elisp-mode, a sentence or paragraf in plain text and so on. You could just press a shortcut, and based on major-mode you could find boundaries of the element and put it in hidden-list. It would be really fast to work that way. I don't know if it already exists in some package. Or you could go for somewhat easier version, and just check if a region is active, and if it is, hide region, and if not, hide current line, or based on mode, hide element at point. That way we can easily expand/contract region with er/expand-region and press a key to temporary hide/unhide it. It is not difficult to write a function to do that based on text properties. Thing-at-point might be useful here too.

https://github.com/magnars/expand-region.el is your friend. I use the built-in equivalent of it in IntelliJ all the time. it's a bit like a vi text objects in the simplest possible way.

Thanks, I will give paredit a shot.

I'm a regular emacs user, but I normally use expand-region[1] and cut/paste to edit lisp code. Expand-region usually knows what I want to move around after just one or two calls, only requires one key binding, and has visual feedback. And it works great in every language I have used.

https://github.com/magnars/expand-region.el

One thing that I always missed is the ability to select a whole function in C#, but I thought I just didn't know the right package or it was something trivial to do ad-hoc. Surprisingly, up to these days I still couldn't find anything. I bumped into the expand-region package at some point, which is awesome, but still something was missing. After going through the Emacs Lisp Intro tutorial, I learned a bit how to search things in a buffer, and I was also editing csharp files every day, so I decided to try to implement the functions myself. Fast forward some weeks, here I am, with a smile on my face :)

The package for growing the selection is the excellent expand-region by Magnar Sveen

If you want to try out some third-party packages in the beginning, I think the most "bang-for-your-buck" you'll get is with Avy. Also, expand-region. And specifically for writing: olivetti-mode, flyspell, dictionary, and Nicolas Rougier's Nano and Elegant Emacs setups.

You will probably like expand-region.el. It is fantastic for selecting inside brackets, quotes, etc.