This page needs attention!


This page is for recording (or discussion) of current apparent Problems with the EmacsWiki Web site. The purpose is to point out problems to the site maintainers.

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 (ie, newest on top, oldest on bottom)

Text overflow in translated languages

The navigation menus on the left of the site overflow into the page content in some languages such as a Russian. This can probably be fixed with a minor change in css. – Thanks for your attention -- 2017-04-25

Can we shorten the text? Perhaps just use ЕмаксЛиспа? Or Территория Е. Л.? – Alex Schroeder

Revisioning Problems

editing does not get most recent version

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.

I don’t think I’ve ever run into this. Anybody else? – AlexSchroeder

RecentChanges doesn't reflect recent changes

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

Markup/Generation Issues

Need for canonical syntax for keyboard input

For example, on GetHelp, I count at least 4, slightly differing syntaxes used to markup keyboard input.

It would be helpful if there were one official syntax.

And it would be helpful if it rendered in HTML using <kbd></kbd> tags, which tend to look distinct in current browsers.

What do you suggest we do? Some regular expression to specify how to recognise the markup would be great. Perhaps simply highlight any sequence of (<[A-Z]>|\b[SMF]-(\S|f[0-9]))\b) and don’t rely on weird quotes? – Alex Schroeder

I’d suggest a dedicated syntax for keyboard input, probably <kbd></kbd>. Simple, explicit, already an HTML tag. No magic or edge cases.

This question has also been raised on emacs.StackExchange.

I disagree with a proposal to use something like <kbd> for Emacs key sequences. (I said the same thing in that emacs.SE thread.)

<kbd> (e.g. as rendered on Stack Exchange) is OK for indicating physical keyboard keys, such as ‘Alt’, ‘Ctrl’ (or ‘Control’) and ‘Enter’ (or ‘Return’).

It is not great for indicating Emacs key sequences, which are logical.

In the printed versions, the Emacs manuals make a similar distinction (physical vs logical keys).

We should generally use the same notation that Emacs itself uses for key sequences: ‘C-x’.

I say “we should generally use…”, but more importantly, we should let people use whatever they prefer, as long as it gets the message across clearly.

I think the distinction between physical keys and logical key sequences isn’t important enough, in the context of EmacsWiki, to discard the idea of using <kbd></kbd> syntax in wiki pages, because there are very few instances of writing out a full key name (like ‘Control’)--almost every case is a key sequence. The benefit, of having a consistent syntax to represent input, would remain.

As Alex has written in the MissionStatement, etc, EmacsWiki is not the Emacs manual, and it serves a different purpose, so it need not match the same standards, especially when doing so would have a significant drawback.

In this case, I think the drawback is indeed significant. As someone who has used Emacs for years but not contributed to this wiki often, when I wanted to make some contributions recently, it was a chore to do something that ought to be very straightforward: look up the correct syntax to represent keyboard input. Looking at, e.g. the source of GetHelp, as I mentioned, there were 4 different syntaxes used within the space of a few paragraphs, and it was not clear which one was correct or preferred. Looking at TextFormattingRules, it was also not helpful at all (no hits searching for ‘keyboard’ or ‘input’).

From a reader’s perspective, having several different syntaxes used to represent input makes it difficult to learn. How is the reader to know if there is a meaningful distinction between these syntaxes?

  • `C-h C-h`
  • ‘C-h C-h’
  • ‘C-h C-h’
  • C-h C-h

I can easily imagine a new user wondering if some of those quotes around the key sequences are also supposed to be input, because why else would they be displayed sometimes and not others?

And as a contributor, which syntax should I use? Why are some so much more cumbersome to type?

Fundamentally, what is the point of not having a canonical syntax for this? All it does it make the task harder for readers and contributors. Marking up keyboard input/key sequences/whatever is a fundamental part of writing Emacs documentation, and there is currently far too much friction to doing so here. Issues like this definitely deter potential contributors. It’s one of the reasons I’ve preferred publishing my own documentation, like this, rather than contributing here.

So, FWIW, I request that a simple, consistent syntax be designated for marking up keyboard input, one that renders nicely and is easy to read and input as markup. Whether it’s <kbd></kbd> or something else, what matters most is that there is one syntax that is designated as correct, documented clearly as such, and renders cleanly. I can only speak for myself, but I will be much more interested in contributing here if this issue is solved.

Sounds reasonable to me. I see no harm in adding it: <kbd>C-x C-s</kbd>C-x C-s – Alex Schroeder

Thanks, Alex. Based on your addition, I added this mention to TextFormattingRules:

  • To represent keyboard input, use <kbd></kbd> tags, like:
    • <kbd>C-x C-s</kbd> → C-x C-s

However, Drew then changed it, advocating a different syntax:

  • To represent keyboard input, you can wrap the key sequence with <kbd></kbd> tags or with backquote and apostrophe, like this (You can also use just ####):
    • <kbd>C-x C-s</kbd> → C-x C-s
    • `C-x C-s' → ‘C-x C-s’

So instead of one recommended syntax, three different ones are presented, with no guidance to users, and no apparent benefit to using one over the other.

Now I’m not a zealous practitioner of the Zen of Python, but neither am I an uncritical follower of TMTOWTDI. Even if multiple syntaxes are allowed, for historical reasons if nothing else, there is no reason to recommend three different ways of doing it. There’s no reason to make users, who are searching for simple reference information about how to do the simple task of marking up keyboard input, wonder about which of 3 apparently equally valid choices to use.

Of course, this is your wiki, and Drew’s put a lot of work into this over the years as well, so I’m not trying to disrespect either of you or usurp your authority.

What I am trying to do is reach a consensus about a consistent syntax, for all of the reasons I already stated. What benefit is there to advocating two slightly different syntaxes that are intended to mean the same thing? It doesn’t help readers or writers.

So I request that the two of you pick one syntax and document it as the recommended one, without also recommending unnecessary alternatives on the TextFormattingRules page, which is already very complicated. This may seem like a small issue, but I think it contributes to “death by a thousand papercuts” here.

I disagree that there is a Need for canonical syntax for keyboard input. I disagree that what matters most is that there is one syntax that is designated as correct. This yearning for one correct way sounds a bit OCD, to me. Why is it necessary?

The complaint is that I changed the Use this directive to You can use. The complaint is that now we’re recommending two, not one, syntax. I disagree that we’re recommending anything, here; we’re just saying what editing syntaxes you can use, to get what effects. It’s just a description of what the rendering system does.

I don’t have a problem with (Anonymous?) preferring <kbd>. I have a problem with our seeming to impose a single editing syntax – as opposed to just telling users how different syntaxes get rendered, and then letting them do whatever they want to get whatever effect they want. But I’ve said all of this before.

And it’s not just key bindings. The same goes for representation of input and output, file names, and other things. And in fact a single editing syntax is not sufficient here for all uses. Consider, for instance, a linked file name, such as apu.el. For that, I need to use <tt>.

Let users use what they want to do what they want. The argument that newbies will wonder whether they should input the quotes too, as part of a key sequence (or file name or command name or…) when they see ‘C-x e’ is hardly convincing.

Users see ‘C-x e’ when they interact with Emacs help. Are they thus confused also by Emacs help? Even if they were, we’re better off with a representation that reflects what users see in Emacs help. After all, we’re also teaching Emacs here.

And ideally, editing to produce such rendering should be just as easy as with Emacs - just type quote marks.

And there’s a reason that Emacs itself uses quotes, even beyond the obvious one that the default font is typically the same one used for key sequences and the like (a fixed-width font): When you have a key sequence such as C-x n a a a reader can mistake the sequence limits. Quotes set the thing that is quoted off from the surrounding text.

Typing quote marks doesn’t suffice on the wiki, however, for some key sequences and other fixed-width font renderings. Which means that we resort to something slightly different (usually involving using both (1) quote marks, to get the quote-mark representation, and (2) `##’, to get the code font.

Let me be more clear. I’m not a fan of inventing N different ways to get rendering that looks more or less like Emacs help. And I do think it’s a bit unfortunate that in some cases (e.g. some key sequences) the only thing we can get, that approximates Emacs help, involves a different form of single-quote chars.

On emacs.StackExchange there is a single editing syntax for getting a code font: wrapping with backquote chars. And that suffices for 99.9% of our needs for Emacs. It’s only a bit hairy when it comes to embedding/rendering backquote chars themselves.

(The main drawback to using that SE convention with Emacs stuff is that it’s not sufficient to just paste text from Emacs, e.g. Emacs help. If you want quoted stuff, e.g., ‘something’, to be rendered in a code font then you have to change the apostrophe to a backquote char.)

Unfortunately, we don’t have such a simple, single editing syntax here (AFAIK). Hence the resort to multiple ones. It’s not as if people wanted to invent multiple such. It’s that the simple ones of using ##, or backquote followed by apostrophe (like Emacs), or <code> or <tt> each have their drawbacks in some contexts (including for some key sequences).

If you haven’t actually tried to represent lots of different keys or code sequences here then it might be easy to suppose that a single editing syntax is an obvious approach.

AFAIK, we don’t have such a thing. I first try `…’ everywhere (often I copy+paste from commentary in Lisp files). Then I preview, to see which things didn’t render well. Then I fix those up using quote chars plus `##’, or whatever. Yes, it’s a bit of a pain, and somewhat error prone (you need to check well), but that’s what it takes. I certainly don’t use a combination of different editing syntaxes gratuitously – I do so only when I see that I have to.

And even if <kbd> were now such a cure-all thing (which I doubt, but haven’t tested), it’s certainly a verbose way of editing (a minor pain). And it means that when copy+pasting from Emacs itself, you need to change `something' to <kbd>something</kbd> everywhere – a royal pain. And the editing syntax is less readable. And the rendered result doesn’t show the quote marks that users see in Emacs help.

No one here disagrees with Occam’s razor: Don’t multiply things unnecessarily. I much prefer the simple approach used at emacs.SE, even if it means I have to change apostrophes in pasted code to backquotes. It’s a rare exception when I have to fiddle there (embedded backquote chars). It is uncommon, but not rare, that I have to fiddle here.

Another consideration is the zillions of existing occurrences here. I’d disagree with an attempt to, e.g., change existing pages to substitute <kbd>.

I’m pretty sure, based on what’s happened with other blanket editing-syntax changes made here, that doing that systematically would break rendering here & there, and I wouldn’t even discover that things had broken until much later. (Five consecutive apostrophes used to produce bold italic, for example. Now it can sometimes do crazy things, depending on where it occurs.)

Drew, I appreciate your taking the time to write that response, but it doesn’t address the arguments I’ve made since I started this discussion. I explained them clearly in my comments above.

My points remain, as does my request: That there be a single recommended keyboard-input markup; that it be clearly presented in TextFormattingRules as the recommended markup; that alternative markup not be equally recommended. Note that I have not requested that support for alternative markups be eliminated, nor that uses of them be replaced across the wiki.

The bottom line is that having four different markups to represent the same thing is unhelpful for readers and contributors. Choice overload and ambiguity have real costs. It may be technically impractical to enforce a single markup now, but we can at least recommend consistency and simplify the documentation, to start inching toward improvements.

I read TextFormattingRules again and it seems pretty good to me. Of all the thousands of words on that page, the point of contention is that the sentence «To represent keyboard input, you can wrap the key sequence with tags or with backquote and apostrophe, like this (You can also use just )» should be shortened to «To represent keyboard input, you can wrap the key sequence with tags» – that sounds like a simple change to make. All the other formatting rules are still explained on the page, after all. – AlexSchroeder

I disagree that we should recommend that users use <kbd> to represent key sequences. Just one opinion.

And if all <kbd> does is exactly what ## does (dunno whether that’s the case) then it’s a lot easier for users to use the latter. If they’re the same then why recommend the one that’s much harder to type?

A user can usually just copy+paste key sequences from Emacs Help, which uses backquote+apostrophe, or from Info, which uses curly quotes. In most cases that works fine for the wiki. But now we’re telling them that they should convert each such quoted key sequence (obtained from Emacs) to <kbd>-embedded sequences (for the wiki). What’s gained by such a recommendation?

I think that if people are reading through that page, that’s not the message they’re getting. They’ll see multiple ways to do things, and if they want to specifically highlight keypresses, then they can do it. If they don’t actually care about markup, then they can stop reading as soon as they’re happy. And if it turns out that nobody ever uses the kbd element, then we can remove it again. – Alex

tt does the Wrong Thing with Double-Quote Chars

This: <tt>"<2>"</tt> gets rendered with two closing curly double-quotes, not with straight double-quotes: ”<2>”. But ##"<2>"## renders correctly: "<2>".

Yeah, tt simply changes the font to teletype, it doesn’t mean “code” and thus I think the result is correct. <code>"<2>"</code> might do what you want: "<2>". – Alex Schroeder

Colon line prefix does not indent correctly

See UnicodeEncoding#ucs-cmds.el. No matter how many colons are used for the last paragraph, it does not indent more. We should be able to have :: align more or less with ** etc. This is a regression. – DrewAdams

I think the problem is that the HTML being generated right now is invalid: <dl class="quote"><dl class="quote"><dt /><dd>indent 2</dd></dl></dl> – I don’t think this ever worked as you intended it to. Right now you need to use : before you can use ::. – AlexSchroeder

I’m pretty sure it used to work. I guess you’re saying that a workaround is to do this?

* A bullet entry


:: Some text indented to be under the bullet.

That does seem to work. (You need to put some spaces after the `:’.)

  • A bullet entry
Some text indented to be under the bullet.

I guess I’m OK with the workaround, though it indents too far and adds too much vertical whitespace. You can remove this problem unless you want to keep it as a reminder to look for a better solution.

I guess if the following two don’t line up exactly, we can use some CSS fix it:

  • bullet

I’m assuming that the exact indentation is determined by the browser defaults. On my iPad it looks as follows:

normal text

   • bullet

The variant you prefer would be this, correct?

normal text

 • bullet

– Alex

Can markup be used in headers? <code>I have failed to do so.</code>

Is this documented somewhere?

Use-case: putting a category-tag like CategoryNeedsAttention into a header, without actually invoking it.

Interestingly, the markup in this particular header renders properly in the TOC

Markup cannot be nested by default. Very few markup elements can in fact be nested. This is not document anywhere, I think. Common sense stuff like list items and inline markup can be nested (bold list items, for example). Emphasis markup using apostrophes is the online inline markup that can be nested: ''italic '''bold''' and italic'' → italic bold and italic. – AlexSchroeder

The irony being that markup in headers is rendered in the (javascript-built) TOC – MichaelPaulukonis

Apostrophes etc. not prettified in links

The link text retains its crude ASCII formatting. – VegardOye

Server Issues

CGI Internal error: 400 Bad request (malformed multipart POST)

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

Client Issues

In some cases the server might actually be at fault - still makes sense to group them like this.

Browser Cache Not Refreshed - Stale Pages Served

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:

  1. I updated the page to reply to SteveTaylor about the mistaken rollback: revision 608.
  2. VegardOye updated the page to add a new item: revision 609.

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

Missing table of contents

The table of contents is generated by Javascript. On some pages that haven’t been edited in years, you can still find a table of contents that doesn’t use Javascript, but as soon as such a page is edited, the table of contents will require Javascript. The old code 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. The DuckDuckGo search also uses JavaScript to quietly add to the search terms. Without JavaScript, this will also look weird. – AlexSchroeder

Captcha problems

If javascript is disabled, the captcha used on EmacsWiki, is virtually impossible for normal humans to solve on the first, second, or tenth attempt. reCaptcha might pretend to work without js, but it’s too frustrating to bother. You may as well just disable anonymous edits for non-js users (like those using Emacs, say).

I can offer two solutions: 1. if you are using a browser that stores cookies, you can provide a “secret” URL parameter that tells Emacs Wiki that you have already answered the CAPTCHA: uihnscuskc=1. 2. Switch to one of the Oddmuse modes listed on CategoryOddmuse. I recommend OddmuseCurl because that’s what I use. It also serves as an example of how to use the wiki using curl.

Gists, Portraits

Yeah. Thanks for the heads up. I fixed Gists. The server now fetches them and includes them in the HTML (slowing things down). I don’t think the server should fetch and cache portraits from elsewhere, though. So I think I’m just going to remove that functionality. Right now I feel that all that we need to keep is the [new] element, what do you think? – Alex Schroeder