-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vision for this package #57
Comments
Ping @davidshepherd7 |
So the short term one is done already right? Also I have a couple of questions not really related to what you've written: What sort of non-sql modes do you expect it to currently be useful in, and what do you expect it to do? I thought it was supposed to work inside strings in normal programming modes, and I had a quick go at writing tests and some tweaks but it turned out not to work how I had hoped, and I think it would be difficult to make reliable. Did you intentionally choose post-command-hook over post-self-insert-hook? If not I think post-self-insert could be better: 1. It would remove the need to check for commands to run after, 2. It plays nicely with keyboard macros (try recording a macro which types 'select ' and running it twice. I have to restart sqlup mode to get it capitalising things again). |
The short-term is there because we never want to lose sight of that. That's the primary job. Also, "well" is relative. #29 gets in the way, for instance. #38 probably does as well. For the medium-term, the answer is, I don't know. Literally, sqlup's only known goal is to upcase SQL keywords. I was surprised by the request for Redis keywords, but now I'm wondering how far the pattern will extend, what someone will want upcased next. Maybe Redis was the only one. Regarding post-command-hook, I think that was there because of pressing Enter, but now I'm not so sure. post-self-insert certainly SOUNDS like it's the hook we would like to be using. You'd be surprised how little I've had to write SQL directly in a code buffer; generally it gets written in an SQL buffer in some fashion and copied into the code buffer when I'm done, so I haven't run into that problem. Since the changes making sure we wouldn't upcase keywords in a string, I'm guessing writing inside a string in a code buffer works rather poorly. |
This package started out as a hack, because I'm lazy, and I wanted to show off, and I wanted to learn emacs-lisp. It got some success quickly, which surprised and delighted me.
For a long time I wanted to not depend on emacs at all. Then we added a dependency on
sql.el
and THAT went out the window.Then I wanted to only use emacs-lisp, and we added a dependency to
cl-lib
and THAT went out the window.Then I wanted to to stick strictly to SQL, and we added some code that checks for another packaged,
redis-mode
, and THAT went out the window.So right now I want to just upcase words... But someone rightly mentioned that there was here, fundamentally, the generic logic of "when something you're typing fits a particular rule, then do something".
So, given all this:
Short-term
Upcase SQL and redis keywords well.
Mid-term
Upcase keywords for anything that provides a list of keywords to match. (yes, this is already getting fuzzy, isn't it)
Long-term
Extract a generic transformer: "given this text and these rules, maybe apply these transformations" (This is REALLY fuzzy).
The text was updated successfully, but these errors were encountered: