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

Add the current mode to the API #43

Closed
defunkt opened this issue Mar 17, 2011 · 13 comments
Closed

Add the current mode to the API #43

defunkt opened this issue Mar 17, 2011 · 13 comments

Comments

@defunkt
Copy link

defunkt commented Mar 17, 2011

It'd be nice if a CodeMirror object had an API method / property containing the current mode. Or does it and I'm missing it?

@marijnh
Copy link
Member

marijnh commented Mar 17, 2011

I think getOption("mode") will do what you want.

@defunkt
Copy link
Author

defunkt commented Mar 17, 2011

Unfortunately not.

>> editor.getOption("mode")
"rb"

That's the mode I set, but not the mode in use as shown by the warning I see:

No mode rb found, falling back to plain text.

@marijnh
Copy link
Member

marijnh commented Mar 17, 2011

Right, when trying to use a mode that wasn't loaded, it'll fall back to the null mode. Why do you need to detect this? Wouldn't it suffice to just ensure you only use modes that are loaded?

I am planning to add something that'll list loaded modes. That might help here.

@defunkt
Copy link
Author

defunkt commented Mar 17, 2011

Why not load all the modes and let CodeMirror figure out which mode to use?

That's how it works right now if you load all modes and pass an extension, with a few special cases.

The only problem is there's no way to figure out which mode CodeMirror picked.

@marijnh
Copy link
Member

marijnh commented Mar 17, 2011

Mode names are not extensions. If you want something 'clever' like this, use MIME types. Again, why do you need to find out which mode was picked?

@defunkt
Copy link
Author

defunkt commented Mar 17, 2011

You're already calling console.warn in the exact case I'm asking about. Why not set a flag or variable?

@marijnh
Copy link
Member

marijnh commented Mar 17, 2011

Yeah, I can, but I'm trying to figure out your use case. I try to be a bit conservative in adding API functions, to keep things tidy.

@defunkt
Copy link
Author

defunkt commented Mar 17, 2011

I guess I'm a bit confused.

When you ask CodeMirror to use a mode, and it cannot find that mode, it falls back to the plain text mode.

However there is absolutely no way in JavaScript to know if CodeMirror found the mode you asked for.

@marijnh
Copy link
Member

marijnh commented Mar 17, 2011

Because you're not expected to ask for any old random mode. You have control over the modes you load, so you should know whether the mode you're trying to use is present.

@defunkt
Copy link
Author

defunkt commented Mar 17, 2011

So not only does CodeMirror let me give it a String mode name with no way to verify I was correct, it also stores a dictionary of modes internally as well as the current mode internally but refuses to surface this data to plugin developers.

@marijnh
Copy link
Member

marijnh commented Mar 17, 2011

Firstly, I talked about adding a way to list the loaded modes, and in fact have already added that (see the the current HEAD commit).

Secondly, if your tone is going to be like this, forget about it—go bother the maintainer of some other project.

@defunkt
Copy link
Author

defunkt commented Mar 17, 2011

All I want is for the mode variable you use internally to be available to plugins so I can use your sweet library on my project. And you're telling me I'm doing it wrong (even though your library does it this way) and to fuck off?

Okay, I will (and I've closed this issue), but I still vote that CodeMirror2 should let you know whether the mode you want is available or not :) Especially when writing plugins.

@michaelficarra
Copy link

@marijnh: I still think it would be useful to be able to get this option. It may be possible to figure it out, but it could be a lot more convenient.

@defunkt: Listing a use case is a must for feature additions like this. He wouldn't have told you to fuck off if you would have just provided reasons why this feature should exist instead of being so stubborn. You may have thought it was implicit, but reasons why it is superior to the provided methods (given they are valid) would surely be enough to convince the maintainer to comply.

alltom pushed a commit to alltom/CodeMirror that referenced this issue Aug 23, 2012
explicitly handle indent for unknownScript in htmlMixed mode
This issue was closed.
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

3 participants