177 lines
51 KiB
HTML
177 lines
51 KiB
HTML
<!DOCTYPE html>
|
||
<html><head><title>EmacsWiki: Emacs Wiki Problems</title><link rel="alternate" type="application/wiki" title="Edit this page" href="https://www.emacswiki.org/emacs?action=edit;id=EmacsWikiProblems" /><link type="text/css" rel="stylesheet" href="https://www.emacswiki.org/light.css" /><meta name="robots" content="INDEX,FOLLOW" /><link rel="alternate" type="application/rss+xml" title="EmacsWiki" href="https://www.emacswiki.org/emacs?action=rss" /><link rel="alternate" type="application/rss+xml" title="EmacsWiki: EmacsWikiProblems" href="https://www.emacswiki.org/emacs?action=rss;rcidonly=EmacsWikiProblems" />
|
||
<link rel="alternate" type="application/rss+xml"
|
||
title="Emacs Wiki with page content"
|
||
href="https://www.emacswiki.org/full.rss" />
|
||
<link rel="alternate" type="application/rss+xml"
|
||
title="Emacs Wiki with page content and diff"
|
||
href="https://www.emacswiki.org/full-diff.rss" />
|
||
<link rel="alternate" type="application/rss+xml"
|
||
title="Emacs Wiki including minor differences"
|
||
href="https://www.emacswiki.org/minor-edits.rss" />
|
||
<link rel="alternate" type="application/rss+xml"
|
||
title="Changes for EmacsWikiProblems only"
|
||
href="https://www.emacswiki.org/emacs?action=rss;rcidonly=EmacsWikiProblems" /><meta content="width=device-width" name="viewport" />
|
||
<script type="text/javascript" src="/outliner-toc.js"></script>
|
||
<script type="text/javascript">
|
||
|
||
function addOnloadEvent(fnc) {
|
||
if ( typeof window.addEventListener != "undefined" )
|
||
window.addEventListener( "load", fnc, false );
|
||
else if ( typeof window.attachEvent != "undefined" ) {
|
||
window.attachEvent( "onload", fnc );
|
||
}
|
||
else {
|
||
if ( window.onload != null ) {
|
||
var oldOnload = window.onload;
|
||
window.onload = function ( e ) {
|
||
oldOnload( e );
|
||
window[fnc]();
|
||
};
|
||
}
|
||
else
|
||
window.onload = fnc;
|
||
}
|
||
}
|
||
|
||
// https://stackoverflow.com/questions/280634/endswith-in-javascript
|
||
if (typeof String.prototype.endsWith !== 'function') {
|
||
String.prototype.endsWith = function(suffix) {
|
||
return this.indexOf(suffix, this.length - suffix.length) !== -1;
|
||
};
|
||
}
|
||
|
||
var initToc=function() {
|
||
|
||
var outline = HTML5Outline(document.body);
|
||
if (outline.sections.length == 1) {
|
||
outline.sections = outline.sections[0].sections;
|
||
}
|
||
|
||
if (outline.sections.length > 1
|
||
|| outline.sections.length == 1
|
||
&& outline.sections[0].sections.length > 0) {
|
||
|
||
var toc = document.getElementById('toc');
|
||
|
||
if (!toc) {
|
||
var divs = document.getElementsByTagName('div');
|
||
for (var i = 0; i < divs.length; i++) {
|
||
if (divs[i].getAttribute('class') == 'toc') {
|
||
toc = divs[i];
|
||
break;
|
||
}
|
||
}
|
||
}
|
||
|
||
if (!toc) {
|
||
var h2 = document.getElementsByTagName('h2')[0];
|
||
if (h2) {
|
||
toc = document.createElement('div');
|
||
toc.setAttribute('class', 'toc');
|
||
h2.parentNode.insertBefore(toc, h2);
|
||
}
|
||
}
|
||
|
||
if (toc) {
|
||
var html = outline.asHTML(true);
|
||
toc.innerHTML = html;
|
||
|
||
items = toc.getElementsByTagName('a');
|
||
for (var i = 0; i < items.length; i++) {
|
||
while (items[i].textContent.endsWith('✎')) {
|
||
var text = items[i].childNodes[0].nodeValue;
|
||
items[i].childNodes[0].nodeValue = text.substring(0, text.length - 1);
|
||
}
|
||
}
|
||
}
|
||
}
|
||
}
|
||
|
||
addOnloadEvent(initToc);
|
||
</script>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></head><body class="default" lang="en"><header><a class="logo" href="https://www.emacswiki.org/emacs/SiteMap"><img alt="[Home]" class="logo" src="https://www.emacswiki.org/images/logo218x38.png" /></a><nav><span class="gotobar bar"><a class="local" href="https://www.emacswiki.org/emacs/SiteMap">SiteMap</a> <a class="local" href="https://www.emacswiki.org/emacs/Search">Search</a> <a class="local" href="https://www.emacswiki.org/emacs/ElispArea">ElispArea</a> <a class="local" href="https://www.emacswiki.org/emacs/HowTo">HowTo</a> <a class="local" href="https://www.emacswiki.org/emacs/Glossary">Glossary</a> <a class="local" href="https://www.emacswiki.org/emacs/RecentChanges">RecentChanges</a> <a class="local" href="https://www.emacswiki.org/emacs/News">News</a> <a class="local" href="https://www.emacswiki.org/emacs/Problems">Problems</a> <a class="local" href="https://www.emacswiki.org/emacs/Suggestions">Suggestions</a> <a href="https://www.emacswiki.org/emacs?action=random" rel="nofollow">Random</a></span><form method="get" action="https://www.emacswiki.org/emacs" enctype="multipart/form-data" accept-charset="utf-8" class="search"><p><label for="search">Search:</label> <input type="text" name="search" size="15" accesskey="f" id="search" /> <label for="searchlang">Language:</label> <input type="text" name="lang" size="5" id="searchlang" /> <input type="submit" name="dosearch" value="Go!" /></p></form></nav><div class="message"><p>This page needs attention!</p></div><h1><a href="https://www.emacswiki.org/emacs?search=%22EmacsWikiProblems%22" rel="nofollow" title="Click to search for references to this page"><span style="padding-right: 0.5ex;">Emacs</span><span style="padding-right: 0.5ex;">Wiki</span><span style="padding-right: 0.5ex;">Problems</span></a></h1></header><div class="wrapper"><div class="content browse" lang="en"><p>This page is for recording (or discussion) of current apparent <strong><a class="definition" href="https://www.emacswiki.org/emacs?search=%22Problems%22" name="Problems" rel="nofollow" title="Click to search for references to this permanent anchor">Problems</a></strong> with the <a class="local" href="https://www.emacswiki.org/emacs/EmacsWiki">EmacsWiki</a> <em>Web site</em>. The purpose is to point out problems to the site maintainers.</p><p>This page is <em>not</em> for questions or problems about Emacs – see <a class="local" href="https://www.emacswiki.org/emacs/OpenQuestions">OpenQuestions</a> for that.</p><p><strong>Suggestions:</strong> If you have <em>suggestions</em> (not problems) for the Emacs Wiki (not Emacs), please contribute them at <strong><a class="local" href="https://www.emacswiki.org/emacs/EmacsWikiSuggestions">EmacsWikiSuggestions</a></strong>.</p><p>Note that this page is not about <a class="local" href="https://www.emacswiki.org/emacs/EmacsWikiMode">EmacsWikiMode</a>.</p><p><strong>Add your problem descriptions below this line</strong> (ie, newest on top, oldest on bottom)</p><h2>Ampersands do not display correctly in grey boxes</h2><p>This can be seen for example on the page <a class="url https number" href="https://www.emacswiki.org/emacs/ReplaceRegexpWithLispExpressions#h5o-5"><span><span class="bracket">[</span>1<span class="bracket">]</span></span></a>. The token \& is displayed as \& amp; in the last line figuring in the grey box under the header Find files listed in a buffer.</p><h2>When downloading a file, emacs-wiki does not show the latest version</h2><p>I have updated the file at <a class="url https" href="https://www.emacswiki.org/emacs/orgfold-separate-file.el">https://www.emacswiki.org/emacs/orgfold-separate-file.el</a>. And the page correctly shows the latest code (e.g. it does not include `(require cl)`. However, when I try to download the file by clicking the `Download` button, then it shows the older (incorrect) version of the file (which does include `(require cl)`.</p><h2>Chrome 100 gives Forbidden error</h2><p>I’m running Chrome with the #force-major-version-to-100 flag enabled, which causes emacswiki.org to fail with “Forbidden”.</p><p>Please see <a class="url https" href="https://developer.chrome.com/blog/force-major-version-to-100/">https://developer.chrome.com/blog/force-major-version-to-100/</a> for more details on the experiment.</p><div class="color one level0"><p> Thanks for reporting this. I’ve removed the offending lines from my banned user agent config. See <a class="url https outside" href="https://alexschroeder.ch/wiki/2020-12-22_Apache_config_file_to_block_user_agents">my blog</a> for more info. – Alex</p></div><h2>Wrong translation on buttons</h2><p>Some buttons on the bottom of all pages have the wrong translation on the Swedish version of the site. For example the “Talk” button is labeld with “Ságastallan” which seems to be in the Sami language. I saw some other button with incorrect translation, but I can’t remember which page it was. Is there some page where I can fix the translation of the buttons?</p><p>– tfendin</p><div class="color one level0"><p> The easiest solution for me would be for you to make changes to this file via git and <a class="url https outside" href="https://git-send-email.io/">send the patch via mail</a> to alex@gnu.org: </p><pre>git clone https://alexschroeder.ch/cgit/oddmuse
|
||
</pre><p>Alternatively, <a class="url https outside" href="https://github.com/kensanata/oddmuse/blob/master/modules/translations/swedish-utf8.pl">editing on GitHub</a> should also work.</p><p>Or just download the plain text from <a class="url https outside" href="https://alexschroeder.ch/cgit/oddmuse/plain/modules/translations/swedish-utf8.pl">swedish-utf8.pl</a>, edit it, and send it to me via mail.</p><p>Optionally also add your name and email address to the file header so that you also get credit.</p><p>A few words are also from the <a class="url https outside" href="https://www.emacswiki.org/config">config</a> file; the German translations, for example, are in <a class="url https outside" href="https://www.emacswiki.org/config-de">config-de</a>, where as the Swedish ones are in <a class="url https outside" href="https://www.emacswiki.org/config-se">config-se</a>. To changes these, just send me an email.</p><p>In any case, thanks! 😊</p><p>– Alex</p></div><h2>Unable to make links using ircs:// protocol</h2><p>I can’t make links using the <code>ircs://</code> protocol, though the <code>irc://</code> protocol does work.</p><p>So, something like <code>ircs://irc.libera.chat:6697/#emacs</code> and <code>[ircs://irc.libera.chat:6697/#emacs #emacs]</code> doesn’t work; while <a class="url irc" href="irc://irc.libera.chat/#emacs">irc://irc.libera.chat/#emacs</a> and <a class="url irc outside" href="irc://irc.libera.chat/#emacs">#emacs</a> do.</p><p>—<a class="local" href="https://www.emacswiki.org/emacs/AnonymousCoward">AnonymousCoward</a></p><div class="color one level0"><p> Fixed: <a class="url ircs" href="ircs://irc.libera.chat:6697/#emacs">ircs://irc.libera.chat:6697/#emacs</a> – Alex</p></div><h2>icicle-download-wizard fails and afterwards www.emacswiki.org refuses connections</h2><p>I wanted to try icicles and followed the instructions from icicles-install.el. icicle-download-wizard downloads several files but eventually fails: </p><pre>Download the Icicle files? (y or n) y
|
||
Contacting host: www.emacswiki.org:80
|
||
Saving file ~/icicles/col-highlight.el...
|
||
Wrote /home/erik/icicles/col-highlight.el
|
||
...
|
||
Downloaded ‘icicles-cmd1.el’
|
||
Contacting host: www.emacswiki.org:80
|
||
error in process sentinel: open-network-stream: make client process failed: Connection refused, <span class="builtin">:name</span>, www.emacswiki.org, <span class="builtin">:buffer</span>, #<killed buffer>, <span class="builtin">:host</span>, www.emacswiki.org, <span class="builtin">:service</span>, 80, <span class="builtin">:nowait</span>, nil, <span class="builtin">:tls-parameters</span>, nil
|
||
error in process sentinel: make client process failed: Connection refused, <span class="builtin">:name</span>, www.emacswiki.org, <span class="builtin">:buffer</span>, #<killed buffer>, <span class="builtin">:host</span>, www.emacswiki.org, <span class="builtin">:service</span>, 80, <span class="builtin">:nowait</span>, nil, <span class="builtin">:tls-parameters</span>, nil
|
||
</pre><p>Afterwards, www.emacswiki.org refuses connections.</p><p>Running on: GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)</p><div class="color one level0"><p> The site runs on a very small virtual machine and I’m using fail2ban to monitor regular connections. If there are more than 20 connections in 40s, you get banned for 10min at the firewall level. If this happens three times, you get banned for a week. The problem is that <a class="local" href="https://www.emacswiki.org/emacs/icicles-install.el">icicles-install.el</a> waits for exactly 2s, but if you visit Emacs Wiki in another window, or otherwise prod the installer, it will trigger these protective measures. I’ve simply edited the icicles-install.el page and changed the sleeper from 2s to 5s. Perhaps that helps more people from banning themselves. – <a class="local" href="https://www.emacswiki.org/emacs/Alex_Schroeder">Alex Schroeder</a></p></div><div class="color two level0"><p> Thanks, Alex! – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p></div><div class="color one level0"><p> Thanks for the help, it solved my problem! Feel free to remove the entry. — <a class="local" href="https://www.emacswiki.org/emacs/AnonymousCoward">AnonymousCoward</a></p></div><h2>Source code blocks edited in recent days not being syntax highlighted</h2><p>Source code blocks I, and others, have edited in recent days are not being syntax highlighted. This is affecting the <a class="local" href="https://www.emacswiki.org/emacs/ElispArea">ElispArea</a> too, see e.g. <a class="inter Lisp" href="/emacs/bookmark+.el"><span class="site">Lisp</span><span class="separator">:</span><span class="interpage">bookmark+.el</span></a> by <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a>, or <a class="inter Lisp" href="/emacs/undecodify.el"><span class="site">Lisp</span><span class="separator">:</span><span class="interpage">undecodify.el</span></a>, also the “Make fullscreen work with posframe.el” section on the <a class="local" href="https://www.emacswiki.org/emacs/EmacsForMacOS">EmacsForMacOS</a> page. I have tried <code><pre></code> tags as well as the three curly braces <code>{{{</code>, both on their own lines before, and after the code block, but neither appear to be working at the moment.</p><p>—<a class="local" href="https://www.emacswiki.org/emacs/AnonymousCoward">AnonymousCoward</a></p><div class="color one level0"><p> There is a 2000 character limit, unfortunately. If you check the <a class="url https outside" href="https://www.emacswiki.org/config">config</a> file and search for “elisp_formatting” you’ll find the code in question. – Alex</p></div><div class="color two level0"><p> Oh, that makes sense, thanks, and thank you for all you do for the wiki and the community. <br />—<a class="local" href="https://www.emacswiki.org/emacs/AnonymousCoward">AnonymousCoward</a></p></div><h2>Failed to verify signature archive contents</h2><p>Text of error response to “package-list-packages” follows -</p><p>Failed to verify signature archive-contents.sig: No public key for 066DAFCB81E42C40 created at 2020-09-23T16:05:02-0500 using RSA Command output: gpg: Signature made Wed 23 Sep 2020 04:05:02 PM CDT gpg: using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40 gpg: Can’t check signature: No public key</p><p>Question: is this a problem at the melpa site or do I have to have gpg installed and operational to use melpa?</p><div class="color one level0"><p> I have no idea. This doesn’t look like a problem with the site (Emacs Wiki) but like a problem with how your package manager is set up. – <a class="local" href="https://www.emacswiki.org/emacs/Alex_Schroeder">Alex Schroeder</a></p></div><h2>Text overflow in translated languages</h2><p>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</p><div class="color one level0"><p> Can we shorten the text? Perhaps just use <a class="local" href="https://www.emacswiki.org/emacs/%d0%95%d0%bc%d0%b0%d0%ba%d1%81%d0%9b%d0%b8%d1%81%d0%bf%d0%b0">ЕмаксЛиспа</a>? Or Территория Е. Л.? – Alex Schroeder</p></div><h2>Revisioning Problems</h2><p><a class="anchor" name="EditingGetsOldPageText"></a> </p><h3>editing does not get most recent version</h3><p>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.</p><div class="color one level0"><p> I don’t think I’ve ever run into this. Anybody else? – <a class="local" href="https://www.emacswiki.org/emacs/AlexSchroeder">AlexSchroeder</a></p></div><h3>RecentChanges doesn't reflect recent changes</h3><p>I just edited and saved a reply someone posted at <a class="local" href="https://www.emacswiki.org/emacs/DrewsElispLibraries">DrewsElispLibraries</a>. I refrefreshed <a class="local" href="https://www.emacswiki.org/emacs/RecentChanges">RecentChanges</a> (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. – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p><h2>Markup/Generation Issues</h2><h3>Need for canonical syntax for keyboard input</h3><p>For example, on <a class="local" href="https://www.emacswiki.org/emacs/GetHelp">GetHelp</a>, I count at least 4, slightly differing syntaxes used to markup keyboard input.</p><p>It would be helpful if there were one official syntax.</p><p>And it would be helpful if it rendered in HTML using <code><kbd></kbd></code> tags, which tend to look distinct in current browsers.</p><div class="color one level0"><p> 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 <code>(<[A-Z]>|\b[SMF]-(\S|f[0-9]))\b)</code> and don’t rely on weird quotes? – <a class="local" href="https://www.emacswiki.org/emacs/Alex_Schroeder">Alex Schroeder</a></p></div><div class="color two level0"><p> I’d suggest a dedicated syntax for keyboard input, probably <code><kbd></kbd></code>. Simple, explicit, already an HTML tag. No magic or edge cases.</p></div><div class="color one level0"><p> This question has also been raised on <a class="url https outside" href="https://emacs.meta.stackexchange.com/q/15/105">emacs.StackExchange</a>.</p><p>I disagree with a proposal to use something like <code><kbd></code> for Emacs key sequences. (I <a class="url https outside" href="https://emacs.meta.stackexchange.com/a/31/105">said the same thing</a> in that emacs.SE thread.)</p><p><code><kbd></code> (e.g. as rendered on Stack Exchange) is OK for indicating <em>physical</em> keyboard keys, such as <code>‘Alt’</code>, <code>‘Ctrl’</code> (or <code>‘Control’</code>) and <code>‘Enter’</code> (or <code>‘Return’</code>).</p><p>It is not great for indicating Emacs <em>key sequences</em>, which are logical.</p><p>In the printed versions, the Emacs manuals make a similar distinction (physical vs logical keys).</p><p>We should generally use the same notation that Emacs itself uses for key sequences: <code>‘C-x’</code>.</p><p>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.</p></div><div class="color two level0"><p>I think the distinction between physical keys and logical key sequences isn’t important enough, in the context of <a class="local" href="https://www.emacswiki.org/emacs/EmacsWiki">EmacsWiki</a>, to discard the idea of using <code><kbd></kbd></code> syntax in wiki pages, because there are very few instances of writing out a full key name (like <code>‘Control’</code>)--almost every case is a key sequence. The benefit, of having a consistent syntax to represent input, would remain.</p><p>As Alex has written in the <a class="local" href="https://www.emacswiki.org/emacs/MissionStatement">MissionStatement</a>, etc, <a class="local" href="https://www.emacswiki.org/emacs/EmacsWiki">EmacsWiki</a> 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.</p><p>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 <a class="local" href="https://www.emacswiki.org/emacs/GetHelp">GetHelp</a>, 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 <a class="local" href="https://www.emacswiki.org/emacs/TextFormattingRules">TextFormattingRules</a>, it was also not helpful at all (no hits searching for <code>‘keyboard’</code> or <code>‘input’</code>).</p><p>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?</p><ul><li><strong>`<code>C-h C-h</code>`</strong></li><li><strong><code>‘C-h C-h’</code></strong></li><li><code>‘C-h C-h’</code></li><li><strong><code>C-h C-h</code></strong></li></ul><p>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?</p><p>And as a contributor, which syntax should I use? Why are some so much more cumbersome to type?</p><p>Fundamentally, what is the point of <b>not</b> 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 <a class="url https outside" href="https://github.com/alphapapa/emacs-package-dev-handbook">this</a>, rather than contributing here.</p><p>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 <code><kbd></kbd></code> 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.</p></div><div class="color one level0"><p> Sounds reasonable to me. I see no harm in adding it: <code><kbd>C-x C-s</kbd></code> → <kbd>C-x C-s</kbd> – Alex Schroeder</p></div><div class="color two level0"><p> Thanks, Alex. Based on your addition, I added this mention to <a class="local" href="https://www.emacswiki.org/emacs/TextFormattingRules">TextFormattingRules</a>:</p><blockquote><ul><li>To represent keyboard input, use <code><kbd></kbd></code> tags, like:<ul><li><code><kbd>C-x C-s</kbd></code> → <kbd>C-x C-s</kbd> </li></ul></li></ul></blockquote><p>However, Drew then changed it, advocating a different syntax:</p><blockquote><ul><li>To represent keyboard input, you can wrap the key sequence with <code><kbd></kbd></code> tags or with backquote and apostrophe, like this (You can also use just <kbd>##</kbd>…<kbd>##</kbd>):<ul><li><code><kbd>C-x C-s</kbd></code> → <kbd>C-x C-s</kbd></li><li><code>`C-x C-s'</code> → <code>‘C-x C-s’</code> </li></ul></li></ul></blockquote><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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 <a class="local" href="https://www.emacswiki.org/emacs/TextFormattingRules">TextFormattingRules</a> 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.</p></div><div class="color one level0"><p> I disagree that there is a <strong>Need</strong> <em>for canonical syntax for keyboard input</em>. I disagree that <strong>what matters most</strong> <em>is that there is one syntax that is designated as correct</em>. This yearning for one correct way sounds a bit OCD, to me. Why is it necessary?</p><p>The complaint is that I changed the <em>Use this</em> directive to <em>You can use</em>. 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.</p><p>I don’t have a problem with (Anonymous?) preferring <code><kbd></code>. I have a problem with our seeming to impose a single editing syntax – as opposed to just telling users <em>how different syntaxes get rendered</em>, and then letting them do whatever they want to get whatever effect they want. But I’ve said all of this before.</p><p>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 <tt><a class="local" href="https://www.emacswiki.org/emacs/apu.el">apu.el</a></tt>. For that, I need to use <code><tt></code>.</p><p>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 <code>‘C-x e’</code> is hardly convincing.</p><p>Users see <code>‘C-x e’</code> 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.</p><p>And ideally, editing to produce such rendering should be just as easy as with Emacs - just type quote marks.</p><p>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 <code>C-x n a a</code> a reader can mistake the sequence limits. Quotes set the thing that is quoted off from the surrounding text.</p><p>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.</p><p>Let me be more clear. I’m <em>not</em> a fan of inventing <em>N</em> 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.</p><p>On emacs.<a class="local" href="https://www.emacswiki.org/emacs/StackExchange">StackExchange</a> 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.</p><p>(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., <code>‘something’</code>, to be rendered in a code font then you have to change the apostrophe to a backquote char.)</p><p>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 <code>##</code>, or backquote followed by apostrophe (like Emacs), or <code><code></code> or <code><tt></code> each have their drawbacks in some contexts (including for some key sequences).</p><p>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.</p><p>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 <em>gratuitously</em> – I do so only when I see that I have to.</p><p>And even if <code><kbd></code> 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 <code>`something'</code> to <code><kbd>something</kbd></code> 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.</p><p>No one here disagrees with Occam’s razor: <em>Don’t multiply things unnecessarily.</em> 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.</p><p>Another consideration is the zillions of existing occurrences here. I’d disagree with an attempt to, e.g., change existing pages to substitute <code><kbd></code>.</p><p>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.)</p></div><div class="color two level0"><p> 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.</p><p>My points remain, as does my request: That there be a single recommended keyboard-input markup; that it be clearly presented in <a class="local" href="https://www.emacswiki.org/emacs/TextFormattingRules">TextFormattingRules</a> 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.</p><p>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.</p></div><div class="color one level0"><p> I read <a class="local" href="https://www.emacswiki.org/emacs/TextFormattingRules">TextFormattingRules</a> 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 <kbd></kbd> tags or with backquote and apostrophe, like this (You can also use just <code>…</code>)» should be shortened to «To represent keyboard input, you can wrap the key sequence with <kbd></kbd> tags» – that sounds like a simple change to make. All the other formatting rules are still explained on the page, after all. – <a class="local" href="https://www.emacswiki.org/emacs/AlexSchroeder">AlexSchroeder</a></p></div><div class="color two level0"><p> I disagree that we should <b>recommend</b> that users use <code><kbd></code> to represent key sequences. Just one opinion.</p><p>And if all <code><kbd></code> does is exactly what <span>##</span> 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?</p><p>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 <b>should</b> convert each such quoted key sequence (obtained from Emacs) to <code><kbd></code>-embedded sequences (for the wiki). What’s gained by such a recommendation?</p></div><div class="color one level0"><p> 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</p></div><h3>tt does the Wrong Thing with Double-Quote Chars</h3><p>This: <code><tt>"<2>"</tt></code> gets rendered with two closing curly double-quotes, not with straight double-quotes: <tt>”<2>”</tt>. But <span>##"<2>"##</span> renders correctly: <code>"<2>"</code>.</p><div class="color one level0"><p> Yeah, tt simply changes the font to teletype, it doesn’t mean “code” and thus I think the result is correct. <code><code>"<2>"</code></code> might do what you want: <code>"<2>"</code>. – <a class="local" href="https://www.emacswiki.org/emacs/Alex_Schroeder">Alex Schroeder</a></p></div><h3>Colon line prefix does not indent correctly</h3><p>See <a class="local anchor" href="https://www.emacswiki.org/emacs/UnicodeEncoding#ucs-cmds.el">UnicodeEncoding#ucs-cmds.el</a>. No matter how many colons are used for the last paragraph, it does not indent more. We should be able to have <code>::</code> align more or less with <code>**</code> etc. This is a regression. – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p><div class="color one level0"><p> I think the problem is that the HTML being generated right now is invalid: <code><dl class="quote"><dl class="quote"><dt /><dd>indent 2</dd></dl></dl></code> – I don’t think this ever worked as you intended it to. Right now you need to use <code>:</code> before you can use <code>::</code>. – <a class="local" href="https://www.emacswiki.org/emacs/AlexSchroeder">AlexSchroeder</a></p></div><div class="color two level0"><p> I’m pretty sure it used to work. I guess you’re saying that a workaround is to do this?</p><pre>* A bullet entry
|
||
|
||
:
|
||
|
||
:: Some text indented to be under the bullet.
|
||
</pre><p>That does seem to work. (You need to put some spaces after the `:’.)</p><ul><li>A bullet entry</li></ul><dl class="quote"><dt /><dd><dl class="quote"><dt /><dd>Some text indented to be under the bullet.</dd></dl></dd></dl><p>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.</p></div><div class="color one level0"><p> I guess if the following two don’t line up exactly, we can use some CSS fix it:</p><ul><li>bullet </li></ul><dl class="quote"><dt /><dd>indent</dd></dl><p>I’m assuming that the exact indentation is determined by the browser defaults. On my iPad it looks as follows:</p><pre>normal text
|
||
|
||
• bullet
|
||
indent
|
||
</pre><p>The variant you prefer would be this, correct?</p><pre>normal text
|
||
|
||
• bullet
|
||
indent
|
||
</pre><p>– Alex </p></div><h3>Can markup be used in headers? <code>I have failed to do so.</code></h3><p>Is this documented somewhere?</p><p>Use-case: putting a category-tag like <code>CategoryNeedsAttention</code> into a header, without actually invoking it.</p><p>Interestingly, the markup in this particular header renders properly in the TOC</p><div class="color one level0"><p> 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: <code>''italic '''bold''' and italic''</code> → <em>italic <strong>bold</strong> and italic</em>. – <a class="local" href="https://www.emacswiki.org/emacs/AlexSchroeder">AlexSchroeder</a></p></div><div class="color two level0"><p> The irony being that markup in headers <b>is</b> rendered in the (javascript-built) TOC – <a class="local" href="https://www.emacswiki.org/emacs/MichaelPaulukonis">MichaelPaulukonis</a></p></div><h3>Apostrophes etc. not prettified in links</h3><ul><li><code>ain't -- it -- "nice"</code> ⇒ ain’t – it – “nice”</li><li><code>[EmacsWikiProblems ain't -- it -- "nice"]</code> ⇒ <a class="local" href="https://www.emacswiki.org/emacs/EmacsWikiProblems">ain't -- it -- "nice"</a></li></ul><p>The link text retains its crude ASCII formatting. – <a class="local" href="https://www.emacswiki.org/emacs/VegardOye">VegardOye</a></p><h2>Server Issues</h2><h3>EWW gets 403 with default url-user-agent</h3><pre> (<span class="keyword elisp">let</span> ((url-user-agent 'default))
|
||
(<span class="keyword elisp">with-current-buffer</span>
|
||
(url-retrieve-synchronously
|
||
<span class="string">"https://www.emacswiki.org/emacs/eww"</span>)
|
||
(buffer-substring 1 13)))
|
||
=> <span class="string">"HTTP/1.1 403"</span></pre><pre> (<span class="keyword elisp">let</span> (url-user-agent)
|
||
(<span class="keyword elisp">with-current-buffer</span>
|
||
(url-retrieve-synchronously
|
||
<span class="string">"https://www.emacswiki.org/emacs/eww"</span>)
|
||
(buffer-substring 1 13)))
|
||
=> <span class="string">"HTTP/1.1 200"</span></pre><div class="color one level0"><p> Hm, eww works for me, and my url-user-agent is set to default. When I evaluate the first code snippet, I get “HTTP/1.1 200”. There are several hundred regular expressions banning user agents of various sorts, so what you’re saying could definitely happen. I’m just surprised that I cannot reproduce it. Now, the doc string explains: <code>‘default’</code> (to compute a value according to <code>‘url-privacy-level’</code>). I wonder what that means, exactly. Apparently our url-privacy-level differs? The value of that is (email) for me. What about you?</p><p>I just tried the following:</p><pre>(<span class="keyword elisp">let</span>* ((url-privacy-level 'paranoid)
|
||
(url-user-agent 'default))
|
||
(<span class="keyword elisp">with-current-buffer</span>
|
||
(url-retrieve-synchronously
|
||
<span class="string">"https://www.emacswiki.org/emacs/eww"</span>)
|
||
(buffer-substring 1 13)))
|
||
</pre><p>Still works…</p><p>– Alex</p></div><div class="color two level0"><p> Thanks. Knowing about the server regular expressions allowed me to narrow this down further. My default user agent string (as returned by (url-http--user-agent-default-string)) is “URL/Emacs Emacs/27.1.90 (X11; powerpc64le-unknown-linux-gnu)”. The “unknown” manufacturer field in the canonical system name is what the server is rejecting. If I change any character in “unknown”, I get a 200 response. Could the regular expressions checking for “unknown” be made more precise? Anyway, good to have an explanation.</p></div><div class="color one level0"><p> Done! I simply removed that line. A copy for the curious is on this blog post of mine: <a class="url https outside" href="https://alexschroeder.ch/wiki/2020-12-22_Apache_config_file_to_block_user_agents">2020-12-22 Apache config file to block user agents</a> – Alex</p></div><div class="color two level0"><p> That’s quite a list. I just retested and now loading emacswiki.org in EWW works with url-user-agent at its default value, ‘default. Thanks!</p></div><h3>CGI Internal error: 400 Bad request (malformed multipart POST)</h3><p>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 <code>‘Back’</code> button and tried, successfully, to save again. – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p><div class="color one level0"><p> Anybody else? I’ve never seen this before. – <a class="local" href="https://www.emacswiki.org/emacs/AlexSchroeder">AlexSchroeder</a></p></div><div class="color two level0"><p> Just an FYI that this problem has not disappeared, even if it is less frequent. – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p></div><h2>Client Issues</h2><p>In some cases the server might actually be at fault - still makes sense to group them like this.</p><p><a class="anchor" name="StalePagesServed"></a> </p><h3>Browser Cache Not Refreshed - Stale Pages Served</h3><p>This might be the same problem as <a class="local anchor" href="#EditingGetsOldPageText">EditingGetsOldPageText</a>, below, but since that speaks specifically about emacs-w3m, I’m not sure.</p><p>This problem started several months ago. The browser cache does not get refreshed when pages are edited and saved. This happens for different browsers.</p><p>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.</p><p>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).</p><p>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.</p><p>Thanks for looking into this. – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p><div class="color one level0"><p> 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 <a class="local" href="https://www.emacswiki.org/emacs/DoReMi">DoReMi</a> and saved. Then opened that page again from the link at <a class="local" href="https://www.emacswiki.org/emacs/RecentChanges">RecentChanges</a>, 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 – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p></div><div class="color two level0"><p> 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.</p><p>If you look at the revisions of <a class="local" href="https://www.emacswiki.org/emacs/BookmarkPlus">BookmarkPlus</a> 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).</p><p>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. – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p></div><div class="color one level0"><p> 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, <a class="local" href="https://www.emacswiki.org/emacs/EmacsWikiProblems">EmacsWikiProblems</a>, today.</p><p>You’ll see that this sequence of events took place:</p><ol><li>I updated the page to reply to <a class="local" href="https://www.emacswiki.org/emacs/SteveTaylor">SteveTaylor</a> about the mistaken rollback: revision 608.</li><li><a class="local" href="https://www.emacswiki.org/emacs/VegardOye">VegardOye</a> updated the page to add a new item: revision 609.</li></ol><p>Vegard’s update wiped out my previous update. – <a class="local" href="https://www.emacswiki.org/emacs/DrewAdams">DrewAdams</a></p></div><div class="color two level0"><p> 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). – <a class="local" href="https://www.emacswiki.org/emacs/AlexSchroeder">AlexSchroeder</a></p></div><h2>Certificate Issues</h2><p>The SSL certificate was expired for most of this weekend? Someone fixed - new one in place now. Root cause addressed? – Lee 21Nov21.</p><div class="color one level0"><p> No idea. The certs are installed from Let’s Encrypt automatically. – <a class="local" href="https://www.emacswiki.org/emacs/AlexSchroeder">AlexSchroeder</a></p></div><hr /><p><a class="local" href="https://www.emacswiki.org/emacs/CategoryEmacsWikiSite">CategoryEmacsWikiSite</a></p></div><div class="wrapper close"></div></div><footer><hr /><span class="translation bar"><br /> <a class="translation new" href="https://www.emacswiki.org/emacs?action=translate;id=EmacsWikiProblems;missing=de_es_fr_it_ja_ko_pt_ru_se_uk_zh" rel="nofollow">Add Translation</a></span><div class="edit bar"><a accesskey="c" class="comment local" href="https://www.emacswiki.org/emacs/Comments_on_EmacsWikiProblems">Talk</a> <a accesskey="e" class="edit" href="https://www.emacswiki.org/emacs?action=edit;id=EmacsWikiProblems" rel="nofollow" title="Click to edit this page">Edit this page</a> <a class="history" href="https://www.emacswiki.org/emacs?action=history;id=EmacsWikiProblems" rel="nofollow">View other revisions</a> <a class="admin" href="https://www.emacswiki.org/emacs?action=admin;id=EmacsWikiProblems" rel="nofollow">Administration</a></div><div class="time">Last edited 2022-05-27 23:36 UTC by <span class="ip-code" title="Anonymous"><span class="orange">1</span><span class="blue">4</span><span class="violet">6</span><span class="orange">1</span></span> <a class="diff" href="https://www.emacswiki.org/emacs?action=browse;diff=2;id=EmacsWikiProblems" rel="nofollow">(diff)</a></div><div style="float:right; margin-left:1ex;">
|
||
<!-- Creative Commons License -->
|
||
<a class="licence" href="https://creativecommons.org/licenses/GPL/2.0/"><img alt="CC-GNU GPL" style="border:none" src="/pics/cc-GPL-a.png" /></a>
|
||
<!-- /Creative Commons License -->
|
||
</div>
|
||
|
||
<!--
|
||
<rdf:RDF xmlns="http://web.resource.org/cc/"
|
||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
|
||
<Work rdf:about="">
|
||
<license rdf:resource="https://creativecommons.org/licenses/GPL/2.0/" />
|
||
<dc:type rdf:resource="http://purl.org/dc/dcmitype/Software" />
|
||
</Work>
|
||
|
||
<License rdf:about="https://creativecommons.org/licenses/GPL/2.0/">
|
||
<permits rdf:resource="http://web.resource.org/cc/Reproduction" />
|
||
<permits rdf:resource="http://web.resource.org/cc/Distribution" />
|
||
<requires rdf:resource="http://web.resource.org/cc/Notice" />
|
||
<permits rdf:resource="http://web.resource.org/cc/DerivativeWorks" />
|
||
<requires rdf:resource="http://web.resource.org/cc/ShareAlike" />
|
||
<requires rdf:resource="http://web.resource.org/cc/SourceCode" />
|
||
</License>
|
||
</rdf:RDF>
|
||
-->
|
||
|
||
<p class="legal">
|
||
This work is licensed to you under version 2 of the
|
||
<a href="https://www.gnu.org/">GNU</a> <a href="/GPL">General Public License</a>.
|
||
Alternatively, you may choose to receive this work under any other
|
||
license that grants the right to use, copy, modify, and/or distribute
|
||
the work, as long as that license imposes the restriction that
|
||
derivative works have to grant the same rights and impose the same
|
||
restriction. For example, you may choose to receive this work under
|
||
the
|
||
<a href="https://www.gnu.org/">GNU</a>
|
||
<a href="/FDL">Free Documentation License</a>, the
|
||
<a href="https://creativecommons.org/">CreativeCommons</a>
|
||
<a href="https://creativecommons.org/licenses/sa/1.0/">ShareAlike</a>
|
||
License, the XEmacs manual license, or
|
||
<a href="/OLD">similar licenses</a>.
|
||
</p>
|
||
<p class="legal" style="padding-top: 0.5em">Please note our <a href="/emacs/Privacy">Privacy Statement</a>.</p>
|
||
</footer>
|
||
</body>
|
||
</html>
|