This page is not for questions or problems about Emacs – see OpenQuestions for that.
Suggestions: If you have suggestions (not problems) for the Emacs Wiki (not Emacs), please contribute them at EmacsWikiSuggestions.
Note that this page is not about EmacsWikiMode.
Add your problem descriptions below this line
I thought there used to be an
‘Article’ link to take you back to the page that is being commented on. I find no link that does that now. (However, as a workaround, if you click the
‘Newest Revision’ link then you can find an
‘Article’ link.) – DrewAdams
SiteMap Search ElispArea HowTo Glossary RecentChanges News Problems Suggestions Add Translation Article Edit this page View other revisions Administration
This is what the page footer looks like on my iPhone with the traditional theme. Note the Article link at the beginning of the last row. – Alex
Sorry, I don’t know what I was seeing, or thought I was. I cannot even find a
‘Newest Revision’ link anywhere now. Unless that rings a bell, feel free to delete this problem report – sorry for the noise. – DrewAdams
– MichaelPaulukonis 2013-05-22 15:15 UTC
Yeah, I assume they all need
;bootstrap=0 or I should check for the presence of the CSS cookie. – AlexSchroeder
Thanks. This works now. – LeonidasTsampros
Out of curiosity: which one are you using? – Alex
I removed the entry for the double-TOC in ElispArea. But now I see one at HighlightLibrary. I suspect that something introduced the problem but perhaps if the page then gets edited and saved anew the problem goes away? – DrewAdams
Issues mentioned below:
Then again, I’m not sure whether all of these issues still persist. The only one that clearly still didn’t work was the
DiredPlus example. Anyway, what do you think? Switch away from Google?
Perhaps I should just offer both in order to allow easy testing. – AlexSchroeder
Using Chrome Version 24.0.1312.52 m and Windows 7 Pro Version 6.1 (Build 7601: Service Pack 1)
Works for me. Chrome Version 25.0.1364.97 m and Windows XP SP3. My guess is a temporary hickup by Google. – AlexSchroeder
Search for “apropos-fn+var.el”, or even just “apropos-fn+var”. You will not find most of the pages that link to page apropos-fn+var.el.
Now search for just “apropos-fn”, and you will find them – 4 pages of links.
Now try searching for “BrowseKillRing” – that page is not found. Now try “browse kill ring” or “browse-kill-ring”. After checking the 10 pages of links you discover that page BrowseKillRing appeards nowhere.
Now try to find this page: BufferMenuPlus. Now try clicking the title of page buff-menu+.el and looking through the search-hit links for page BufferMenuPlus. No luck. Same thing for DiredPlus from dired+.el. Try finding DiredSortMenu using “dired sort menu” or by clicking the title of dired-sort-menu+.el. You get the idea.
What’s wrong? – DrewAdams
Google. I am noticing similar issues with global google search more and more often. E.g. it seems google treats “-” as whitespace and then looks for the resulting separate words. It’s becoming harder and harder to “google” documentation of lisp symbol. The same happens for camelCase and file/paths, or at least I am getting that impression.
Edit: In case of apropos-fn or org-something it gets worse: fn? that’s not a word let’s just ignore it. org? that’s certainly organisation.
Edit 2: We cannot rename every page that google cannot find like done for the below issue. Maybe we should switch to another search engine instead.
Edit 3: Or maybe google just/additionally penalizes the emacswiki for offering N different urls for the same content. I think it would be worth while using just a single url and redirect all the others even if it wasn’t for the google issue.
But I don’t see how that would help with the problem of finding the page that documents a library, by clicking the Elisp page’s title. E.g., clicking the title of page wide-n.el to find the page MultipleNarrowings as one of the pages that link to it.
BTW, I notice that short things like
‘hl’ in `hl-line+.el’ ARE being used by the google search. So Jonas’s hypothesis that
‘fn’ not being a word is a problem does not seem to be a problem.
And even searching for a full page title sometimes does not find it. It seems that titles themselves are not being included in the text that is indexed/searched. Perhaps that is the real problem (or one of them). – DrewAdams
I think it must be a bug in Google’s code. Without the quotes returns more results that seem to be missing in the search with quotes. At this point I feel that maybe Jonas is right: “Maybe we should switch to another search engine instead.” when I last looked at ylucene it seemed like a pain to setup and I think I felt it didn’t handle a multi-lingual corpus very well. Does anybody feel like writing something? With the remote repositories it should be possible to write an external indexing and searching service that we could just integrate. – Alex
I can’t speak to most of what you wrote last, Alex. But wrt the quotes: Isn’t it the case that if you enclose something in (double-)quotes then it is looked for literally, rather than being decomposed into indexed substrings? If so then I would expect that with the quotes there would be fewere hits, because the hits would only be hits for the whole string, not for its component substrings.
AFAIK, Google generally uses full-text search, which means indexing, stop words etc. But since we see that it finds hits on components such as
‘hl’ perhaps it is not doing that kind of search on a site, at least with the way we are using it. (If so, that is actually better.)
As I mentioned earlier, one guess I have is that the page titles are simply not being included among the text that is searched. That alone might explain a lot. Perhaps there is some way to make Google include that text. (E.g., even artificially add it to each page as text, maybe in a hidden way.)
I know nothing about this stuff. Just talking off the top of my head. If it doesn’t help, please ignore. – DrewAdams
Visit highlight.el. Click the title to google-search for references to that page. There are 5 pages of hits, but none of them are HighLight, which is the main page documenting Lisp:highlight.el. There is even a link
Lisp:highlight.el on page HighLight, so it can’t just be a problem of using
<tt>[[highlight.el]]</tt> instead of
Lisp:. Maybe the problem has something to do with case-sensitivity in the page name “
HighLight”? – DrewAdams
I think that’s because when serving the page, the wiki tries to split page names based on CamelCase → Camel Case – this is what Google picks up (in addition to the h1 header). Thus, if you search for “highlight” you won’t find HighLight because it registers as “High Light”. If you search for “high light” instead, you’ll find the correct page. Perhaps we should create a new page called Highlight, move the HighLight content there, and have HighLight redirect to Highlight? – AlexSchroeder
Thanks for the explanation. Still, I don’t quite understand. I thought that explicit links to the target page (highlight.el in this case) were taken into account, i.e. by picking up the link sources (sort of like Google does in general, when trying to rank a page). How does a search for the text
highlight come into the picture? Is the search only for the text
highlight.el, or are links taken into account?
Wrt your suggestion, I don’t think that’s the solution here, but I might rename the page to something a bit different – and less general sounding– anyway. Thx – DrewAdams
I can’t say I understand completely, either. Google ought to know that there is a page with Url bla/HighLight, title High Light and h1 HighLight – why doesn’t a search for “highlight” find it? I don’t know. :(
Just mentioning in case it indicates a bug: Search for
DiredPlus and you will not see the DiredPlus page in the list. But search for
GrepPlus and you will see the GrepPlus page. Wonder why. – DrewAdams
hmm searching for “sticky site:.emacswiki.org” google find thse page with the url: www.emacswiki.org/cgi-bin/emacs-en/StickyModifiers, maybe it’s just a problem of adding a couple more url in the custom search – PierreGaston
http://www.emacswiki.org/cgi-bin/emacs-* to the list of sites. Previously the site list contained only
http://www.emacswiki.org/cgi-bin/wiki/*. I think the real problem is that I would want all the URLs matching
http://www.emacswiki.org/cgi-bin/emacs-* to be registered as
http://www.emacswiki.org/cgi-bin/wiki. Ah the joys of fiddling with search engines. :) – AlexSchroeder
Thanks! – LennartBorgman
I set my search languages to Chinese in google search preferences, so when I search in emacswiki.org, only a few pages can be found, can I just search all languages in emacswiki.org without change my google preferences? Or in the page of search result provides a radio button to select language. – Ye Wenbin
(this issue is actually different from the above)
No idea how much control you have over the search. However, currently searches often are useless to me, because they show only source code files. Try searching for “defmacro”, for instance; maybe that is because it isn’t discussed anywhere on the wiki, but I have no way of finding out. Please allow to exclude sources from the search results. – OlafB?
I’m not sure what to do. Fiddling with the search engine configuration might work, but how would we search for code examples, then? Add a second search box for code only? Yuck. There\s not much configuration going on because we are using Google Search. I don’t see a way to add checkboxes and other options to influence it.
Somebody could start working on a multi-lingual setup for Lucene or whatever the search engine of choice is for people who want to do it themselves. I remember looking at it and thinking that it looked like a lot of work for little gain.
For the example given, Google returns MacroBasics on third place. That’s not so bad, is it?
This might not be the best setup, Google-juice-wise. Permanently redirecting from one to the other seems like the way to go.
Additionally, even with a domain, pages lack a canonical URI;
/cgi-bin/wiki/foo all work. I suggest redirecting all of those to
Yeah, I think you’re right. I’m not comfortable enough with mod_alias, mod_rewrite, and all those and I don’t have an automated test suite that would point out how changes to .htaccess are affecting the site. That’s why I hesitate to fix these. – AlexSchroeder
emacswiki.org now redirects to www.emacswiki.org – AlexSchroeder
I edited page icicles-opt.el and saved. Later I tried to do the same thing. I got a lock message. I used the browser Back button to get to the editing again and saved again. I then got this:
This page was changed by somebody else 25 minutes ago. The changes conflict. Please check the page again. icicles-opt.el Download ;;; icicles-opt.el --- User options (variables) for Icicles ;; ;; Filename: icicles-opt.el ;; Description: User options (variables) for Icicles ;; Author: Drew Adams ;; Maintainer: Drew Adams ;; Copyright (C) 1996-2009, Drew Adams, all rights reserved. ;; Created: Mon Feb 27 09:22:14 2006 ;; Version: 22.0 <<<<<<< you ;; Last-Updated: Fri Jun 4 17:34:46 2010 (-0700) ||||||| ancestor ;; Last-Updated: Fri Jun 4 16:52:30 2010 (-0700) ======= ;; Last-Updated: Fri Jun 4 17:32:35 2010 (-0700) >>>>>>> other ;; By: dradams <<<<<<< you ;; Update #: 3700 ||||||| ancestor ;; Update #: 3698 ======= ;; Update #: 3699 >>>>>>> other
It’s telling me my two edits conflict, and it is not recognizing that I am me. ;-) – DrewAdams
That’s very strange indeed! I thought that once you’re using a username – which you clearly are – then that doesn’t happen anymore. I’ll have to look at that code again. – AlexSchroeder
It just happened that once. And I simply pasted and saved the file again, so there was no damage in the end. – DrewAdams
I tried yet again to get emacs-w3m to work as described above. I edited. It didn’t work. I edited the page with Safari. It worked. Then I followed the instructions again in emacs-w3m. The Safari edit did not show up in the compose edit box, even though the page did show it. Therefore, the text that the user edits is not the same as the text that is shown. Is this a cache issue? Thanks.
There’s some technical information available here, if you want to take a look at it: Oddmuse:Caching. As I’m currently in Costa Rica, I can’t help you. All I know is that it worked for me – and I went through all the trouble of downloading and compiling w3m and dependencies. – AlexSchroeder
I just edited and saved a reply someone posted at DrewsElispLibraries. I refrefreshed RecentChanges (with rollbacks and minor changes included), but my edit does not appear. That wiki page is listed, but still at the time and user of the previous edit. However, after clicking List only major changes it was listed. I had previously cleared my cache, so I don’t think that was the problem. I’m guessing it was a cache problem nevertheless, but thought I’d mention it, in case it’s not. – DrewAdams
Someone edited Emacsmirror months ago but the change is not visible on the page. When I edit the page I can see the added text. I haven’t tried yet what happens when I save the page. Maybe that would cause the old edit to become effective but I wanted to leave it as-is so you can see for yourself. – JonasBernoulli
Hm, I’m not sure. When using the cache=0 parameter the page doesn’t mention “solarized” so I think editing the page will not make a big change. I wonder where the diff comes from, however.
ain't -- it -- "nice"⇒ ain’t – it – “nice”
[EmacsWikiProblems ain't -- it -- "nice"]⇒ ain't -- it -- "nice"
The link text retains its crude ASCII formatting. – VegardOye
I tried to put braces in a url (because the stupid url required them), eg:
I tried a few different things, eg:
none of them worked. I think this should be ok.
Again though, I’m happy with it not being fixed because we’ll fix it with Elwiki.
If you read RFC 2396 you’ll note that curly braces are deemed “unwise” in section 2.4.3. Excluded US-ASCII Characters.
Takes me several minutes to load the Elisp Area page – or else it hangs altogether (times out). Likewise to get to one of the Lisp files there. Likewise, it takes a long time to preview (e.g. this edit). And yes, I tried closing the browser and deleting the cache. – DrewAdams
Is this happening to anybody else? What about the time? Whenever I use the site, it seems to be working just fine. – AlexSchroeder
I just got this error when trying to save a page after some simple (trivial) editing. No idea what caused it or what the problem is. I then clicked the browser
‘Back’ button and tried, successfully, to save again. – DrewAdams
Anybody else? I’ve never seen this before. – AlexSchroeder
Just an FYI that this problem has not disappeared, even if it is less frequent. – DrewAdams
In some cases the server might actually be at fault - still makes sense to group them like this.
This might be the same problem as EditingGetsOldPageText, below, but since that speaks specifically about emacs-w3m, I’m not sure.
This problem started several months ago. The browser cache does not get refreshed when pages are edited and saved. This happens for different browsers.
This problem has bitten several people, and the only workaround seems to be to remember to manually force a cache refresh when, say, you are looking at the editable page. And even that doesn’t work if you use the Download link.
This causes people to download the wrong version of a page (e.g. an Emacs Lisp library, using the Download link). And it causes people to accidentally overwrite a previous edit by someone else (since it doesn’t appear in the editable text unless they refresh that text).
I know that some people have thought that the problem was that pages were not being locked properly for edits, so that two people editing at the same time could accidentally overwrite each other’s edits. I don’t know if that problem also exists, but I do know that this cache problem has caused people to think there is a locking problem for edits. The cache problem occurs however, even for an edit that is long after (days after) the last edit has been saved, so it is not a lock problem.
Thanks for looking into this. – DrewAdams
This is still happening, but I still cannot give a recipe for why or when it happens – it happens sometimes. It just happened now. In the same browser session, I updated page DoReMi and saved. Then opened that page again from the link at RecentChanges, using browser’s Open Link in New Window. Then clicked Edit the page and got the old page source, before my edit and save. HTH – DrewAdams
Some more info on this, in case it helps. I was just bitten by this again – I had to redo a bunch of edits as a result.
If you look at the revisions of BookmarkPlus between Revision 53 and Revision 58, you’ll see that Revision 54 was a major edit, then 55 was a minor edit. Well, 55 did not use 54 as its starting point – it used 53 instead. So I ended up doing 55, 56, 57, and 58, before I realized that the major edit for 54 had been undone (i.e. lost).
I used to think this problem had something to do with the browser cache, but now I’m thinking it has something to do with major and minor edits. HTH. – DrewAdams
Dunno if this is strictly related to the browser cache problem that I’ve been assuming exists, but there is a fine example of losing page updates that just occurred. See the revisions of this very page, EmacsWikiProblems, today.
You’ll see that this sequence of events took place:
Vegard’s update wiped out my previous update. – DrewAdams
Hm, maybe this is unrelated. Possibly it just took him more than nine minutes to edit the page before he saved it? Perhaps diff3 will sometimes merge things and drop changes without marking them as a conflict? Or he used a raw client that interacts with the wiki text directly, didn’t post back the last modification date, thus diff3 was unable to determine the ancestor for conflict resolution, and he ended up overwriting what you had done. I think the caching problem you reported earlier is something else (and much trickier, apparently). – AlexSchroeder
Try this solution, been using it a while now --pft:
(define-key w3m-mode-map "\C-c\C-c" '(lambda () (interactive) (if (member 'w3m-href-anchor (text-properties-at (point))) (w3m-view-this-url) (w3m-submit-form))))
I’ve just opened at terminal and used w3m to browse and search the wiki and didn’t see anything wrong. The answer above makes me think that maybe it’s a w3m-mode question but I’m not sure. If it’s a w3m issue, can you elaborate? – AlexSchroeder
I haven’t figured out what the problem is yet, but I added http://www.emacswiki.org/emacs/?action=rss;rcidonly=IciclesDiscussion to Google Reader, and it didn’t get a “new item” notification when the page was changed. – EthanGlasserCamp?
When I look at the RSS feed, I get to see the latest revision of the page. I must therefore assume that it’s Google Reader’s fault. I can imagine two problems: 1. It takes very long for changes to be picked up by Google. That’s the explanation I currently favor because I have several of my own wikis in Google Reader and I often have the impression that Google Reader is up to a day late. 2. Google Reader thinks that you’re looking at an update to an existing page and will not show it anymore. I remember there was such an option for Blog Lines, but I can’t find anything like it for Google Reader. – AlexSchroeder
This has changed in the last day or so – since the spam attack.
On EmacsWiki, I can no longer right-click a link (any link) and choose Open in New Window. I use IE6, and I have Google Toolbar installed (since a long time ago). When I try to open a link in a new window, Google Toolbar treats the attempt as a pop-up and blocks it.
I am forced to duplicate the browser window (
‘C-n’) and then find and click the link. This is very slow, since the current page needs to be reloaded in the new window even though I’m going to move away from it.
I have this problem only for EmacsWiki pages, and I have changed nothing in my browser etc. Does this perhaps have something to do with the change to use reCAPTCHA?
This is really quite annoying. I can make the problem go away by choosing Popups okay for Google Toolbar (for EmacsWiki), but users shouldn’t need to do that. EmacsWiki appears unfriendly to people with this behavior. – DrewAdams
I believe you. Unfortunately I don’t know what to do about it. I’m sure your browsing environment will allow you to define exceptions to the popup blocker. – AlexSchroeder
Yes, as I said, I’ve done that. The point was that it’s a shame that users will now need to do that – some might become discouraged or not understand. What’s odd is that I’ve never seen this (treating Open in New Window as a popup) on any other site. Anyway, it’s not a biggee. And perhaps it affects only IE6 users who happen to use Google Toolbar – dunno. – DrewAdams
My understanding is that the TOC should be auto-generated.
This works fine on some pages (e.g. OddmuseMode )
But is missing completely on others (e.g. TrampMode (and this page, in fact))
I guess it worked most of the time, but at the same time it was very brittle and required constant attention and compatibility cross-checking. I feel it’s just not worth the effort. Perhaps we can improve the wiki for noscript users and add some explanatory text and instructions for how to selectively enable scripts.