Skip to content
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

Open
Trevoke opened this issue Aug 30, 2016 · 3 comments
Open

Vision for this package #57

Trevoke opened this issue Aug 30, 2016 · 3 comments

Comments

@Trevoke
Copy link
Owner

Trevoke commented Aug 30, 2016

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).

@Trevoke
Copy link
Owner Author

Trevoke commented Aug 30, 2016

Ping @davidshepherd7

@davidshepherd7
Copy link
Contributor

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).

@Trevoke
Copy link
Owner Author

Trevoke commented Aug 30, 2016

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.
If this is desired behavior, it's likely worth opening an issue and then, probably, creating a new code path differentiating between SQL-related major modes and other major modes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants