Win 7 Chrome. Ctrl-F search must work or this highlighter will never get out of the gate with me.
Topic on Extension talk:CodeMirror
Thanks for reporting this -- I've created a bug ticket at phab:T174510. I tried to reproduce myself, and ctrl-F search is working for me on Mac, Firefox and Chrome. This may be browser-specific; we'll check it out. Thanks!
Can you make sure you're on the latest Chrome version? Can you reproduce this problem with another browser?
I have had this problem on Firefox on Linux a couple of times. It seems to be related to scrolling in the edit area: searching for a word that is outside the visible edit area doesn't work... sometimes! It seems to be related to whether one hits ctrl-F and starts typing, or hits F3 to repeat the current search. Try opening a page (with CM already turned on) e.g. and searching for something further down the page e.g. 'External links'. It doesn't work, but if there's some part of the string you're typing in visible it'll jump to that, causing the edit box to scroll, which means more is visible... and so sometimes certain searches can seem to work correctly.
At least, this is what my pre-coffee brain is thinking this morning. :-)
Damn, you're right. It's not picking up words outside the view area. That is a serious problem; we'll figure out how to get this fixed.
Your pre-coffee brain is absolutely right, Sam. The library draws the area inside the textbox and a little bit outside of it (for performance reasons). So if your string lies in that region, it shows up. If it's in the area just outside, it causes the window to scroll and more area gets drawn and then Find has more text to search on and more words pop-up.
I'm wondering if we can trick the browser spell checking and Ctrl+F to work on the layer of text underneath CodeMirror, with CM only acting as the highlighting layer on top.
A similar problem afflicts the code editor which was, I guess got round by including a separate, and to my mind much better tool than the simple one provided by the browser: search, search and replace, regex, whole word, case sensitivity, search within selection. Adapt/adopt that and I'm all in for this highlighter
GitHub's code editor does a similar thing to the Wikimedia one: a in-editor find dialog that appears when you hit ctrl-f. It's not bad, but both of them are a bit slower than the native functions. I reckon it'd be worth considering, if the alternative is to syntax highlight the full page text and by doing so slow things down.
I read somewhere (and I can't find a citation for this atm) that GitHub uses CodeMirror too.
Yes! You're quite correct (judging by looking at the code of a GH edit page). So maybe the search plugin is stable enough for use.
I have the same problem with the firefox
Search does not work in Firefox for Mac. I see the passage, but the computer does not.
We're currently working on a fix for this; there's a search add-on that's used by GitHub on their installation of syntax highlighting which we can adapt for our version. This is a serious bug, and we want to get a fix out as soon as we can.
If folks are interested in following the bug ticket, it's phab:T174480.
Hi Folks, thank you for your marvellous work. I just interrupted my personal test Phase. Ctrl-F is a must-have. I will monitor this thread and hope you will find a solution. --~~~~his thread
Code Mirror does not render the whole document, only the visual part. Therefore the search does not work for the whole document. I looked in the Code Mirror User Manuel for a solution and found the option "viewportMargin". Does anyone know a way to change these options?
I tried it by addomg the line "CodeMirror.defaults.viewportMargin = 1000;" to my "global.js" script, but it does not work.
I have put it now in a Greasemonkey script, this works.
Hi @Trustable. See https://github.com/codemirror/CodeMirror/issues/4491#issuecomment-271615629
That option will work, but it'll be a performance tradeoff, sadly. We're looking into a search add-on for now.
Hi, here's an update on the progress on this issue. We were looking at using the search add-on that GitHub uses in their version of CodeMirror, and it's not an acceptable solution for us. It only works when you've got the cursor in the edit window -- if you're not inside the edit window, ctrl-F still gives you the browser search. That's not very discoverable -- for some people, it would just be broken sometimes. The add-on also uses a combination of ctrl-F to start the search and ctrl-G to move from one highlighted word to another, which is also not very discoverable. So that is a dead end for us.
We're now investigating a couple other options, including loading the page outside the edit window in the background, after the text in the edit window is displayed. This might slow things down, so we're testing the performance.
We're still focused on solving this issue; I'm sorry it's not fixed yet.
My Core-i5-2320 is from 2011, still I don't notice any delay when editing a large article with viewportMargin = 1000.
We've rolled out a fix to the problem (setting the viewportMargin to Infinity). This fixes the ctrl+f issues but it might show some lag when editing large articles. If this happens, please report it here along with:
- Link to the page/section you were editing
- Some detail about the machine you were editing on (for example: Dell, Windows, i5 processor)
Thanks.
Yeah, the new version is on this wiki now, and I copied a really long page into a sandbox to test this out: User:DannyH (WMF)/CodeMirror test. Ctrl-F works for me on this page -- I hope it works for everyone. :)
For the performance, I did notice one thing that I did that caused a noticeable delay, which is adding a magic word and not closing it. For me, it's a rare use case and the performance hit wasn't very significant.
I'd be interested to know if other people see any noticeable performance issues, and how bad you think the issue is.
I've just checked again now, and searching does not work properly using Firefox on Mac. For example, I edit [[Wikipedia:Articles for deletion/Holly Neher]] and search for "Boing". It finds matches outside of the edit box, but not inside it - and still the same if I first place the cursor inside the edit box. I then search for something else ("relevant" in this case), and it finds all occurrences both inside and outside the edit box. If I then search for "Boing" again, it finds them all. It looks like the first search doesn't work, but subsequent ones do - is there some initialization failure somewhere?
Yes, the problem was that syntax highlighting was only allowing you to search what's currently in the edit window, and a few lines directly under it. Searching for "relevant" scrolled you down to that line, and at that point, "Boing" was close enough to the edit window to be searchable.
There's a fix for this, that's live right now on this wiki and a lot of Wikipedia languages. It'll be live on English Wikipedia tomorrow. Sorry for the bug, it's very annoying.
Ah, thanks, I'll try again tomorrow. I've always loved syntax highlighting (can you tell I'm an old softie dev?), so my thanks go to those developing it - once the searching and the spellchecking are sorted, I'm sure I'll love it.
I have the same situation, Win 7 + Chrome.