EmacsWikiProblems

Thanks for reporting this. I’ve removed the offending lines from my banned user agent config. See my blog for more info. – Alex

The easiest solution for me would be for you to make changes to this file via git and send the patch via mail to alex@gnu.org:

git clone https://alexschroeder.ch/cgit/oddmuse

Alternatively, editing on GitHub should also work.

Or just download the plain text from swedish-utf8.pl, edit it, and send it to me via mail.

Optionally also add your name and email address to the file header so that you also get credit.

A few words are also from the config file; the German translations, for example, are in config-de, where as the Swedish ones are in config-se. To changes these, just send me an email.

In any case, thanks! 😊

– Alex

Fixed: ircs://irc.libera.chat:6697/#emacs – Alex

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 icicles-install.el 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. – Alex Schroeder

Thanks for the help, it solved my problem! Feel free to remove the entry. — AnonymousCoward

There is a 2000 character limit, unfortunately. If you check the config file and search for “elisp_formatting” you’ll find the code in question. – Alex

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. – Alex Schroeder

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

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

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

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.

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

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.)

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 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

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

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 guess if the following two don’t line up exactly, we can use some CSS fix it:

• bullet

indent

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

normal text

   • bullet
   indent

The variant you prefer would be this, correct?

normal text

 • bullet
   indent

– Alex

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

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: ‘default’ (to compute a value according to ‘url-privacy-level’). I wonder what that means, exactly. Apparently our url-privacy-level differs? The value of that is (email) for me. What about you?

I just tried the following:

(let* ((url-privacy-level 'paranoid)
       (url-user-agent 'default))
  (with-current-buffer
      (url-retrieve-synchronously
       "https://www.emacswiki.org/emacs/eww")
    (buffer-substring 1 13)))

Still works…

– Alex

Done! I simply removed that line. A copy for the curious is on this blog post of mine: 2020-12-22 Apache config file to block user agents – Alex

Anybody else? I’ve never seen this before. – AlexSchroeder

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

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

No idea. The certs are installed from Let’s Encrypt automatically. – AlexSchroeder