4 ms·

NEWS: https://www.gnu.org/software/emacs/news/NEWS.26.3 https://www.gnu.org/software/emacs/news/NEWS.26.3

by michaelhoffman 7y ago

rhabarba 7y ago
So ... only two relevant changes this time?
- cheez 7y ago
  Looks that way.
- gnufied 7y ago
  for many of us this fixes a show stopper bug while downloading packages from MELPA/ELPA. I was just trying to setup on a new Fedora box (emacs-26.2) and my setup kept failing on "Failed to download archive...".
  - sambe 7y ago
    Which change fixes that?
    - rhabarba 7y ago
      The new certificate mentioned in the announcement, probably.
      - sambe 7y ago
        Am I blind? I can’t see a certificate mentioned in the link or the parent’s NEWS link...
        rhabarba 7y ago
        Right from the link: > This release is mainly a maintenance release, which contains a new GPG key for GNU ELPA packages.
- na85 7y ago
  The release notes explicitly stated this is a maintenance release
abdullahkhalids 7y ago
This page is being rendered as DejaVu Sans Mono on my Debian Firefox. This font apparently does not have the Form Feed character [1], so I am getting a bunch of nonrendered characters, once before every * heading (but not before ). Incidentally, my emacs font face is also the same, so I am also getting a bunch of ^L in emacs C-h n. [1] https://unicode-table.com/en/000C/ https://unicode-table.com/en/000C/
- anyfoo 7y ago
  Is Form Feed ever a character that a font renders? It’s whitespace, after all. And (hard to be certain on the phone) this “website” is likely just a text file. Maybe Firefox just does not like form feed in general. That emacs displays form feeds as the Control character ^L (which it is) is also normal, and if you just curled the file confirms that it’s just a plain old text file.
  - majewsky 7y ago
    You're correct: FF is not a printable character. But I'm seeing the same issue with Firefox on Windows (with some monospace font). I suspect that the issue is what Firefox complains about in the developer console: The file does not have a defined encoding. In fact, the Content-Type header is completely missing. I guess that those replacement glyphs are just Firefox playing it safe in the face of uncertainty regarding the character encoding.
  - sambe 7y ago
    I use the page-break-lines package to show these a bit more nicely (IMO).

NEWS: https://www.gnu.org/software/emacs/news/NEWS.26.3 https://www.gnu.org/software/emacs/news/NEWS.26.3

rhabarba 7y ago

So ... only two relevant changes this time?

cheez 7y ago
Looks that way.
gnufied 7y ago
for many of us this fixes a show stopper bug while downloading packages from MELPA/ELPA. I was just trying to setup on a new Fedora box (emacs-26.2) and my setup kept failing on "Failed to download archive...".
- sambe 7y ago
  Which change fixes that?
  - rhabarba 7y ago
    The new certificate mentioned in the announcement, probably.
    - sambe 7y ago
      Am I blind? I can’t see a certificate mentioned in the link or the parent’s NEWS link...
      - rhabarba 7y ago
        Right from the link: > This release is mainly a maintenance release, which contains a new GPG key for GNU ELPA packages.
na85 7y ago
The release notes explicitly stated this is a maintenance release

abdullahkhalids 7y ago

This page is being rendered as DejaVu Sans Mono on my Debian Firefox. This font apparently does not have the Form Feed character [1], so I am getting a bunch of nonrendered characters, once before every * heading (but not before ). Incidentally, my emacs font face is also the same, so I am also getting a bunch of ^L in emacs C-h n. [1] https://unicode-table.com/en/000C/ https://unicode-table.com/en/000C/

anyfoo 7y ago
Is Form Feed ever a character that a font renders? It’s whitespace, after all. And (hard to be certain on the phone) this “website” is likely just a text file. Maybe Firefox just does not like form feed in general. That emacs displays form feeds as the Control character ^L (which it is) is also normal, and if you just curled the file confirms that it’s just a plain old text file.
- majewsky 7y ago
  You're correct: FF is not a printable character. But I'm seeing the same issue with Firefox on Windows (with some monospace font). I suspect that the issue is what Firefox complains about in the developer console: The file does not have a defined encoding. In fact, the Content-Type header is completely missing. I guess that those replacement glyphs are just Firefox playing it safe in the face of uncertainty regarding the character encoding.
- sambe 7y ago
  I use the page-break-lines package to show these a bit more nicely (IMO).