unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: monnier@iro.umontreal.ca, 33796@debbugs.gnu.org
Subject: bug#33796: 27.0.50; Use utf-8 is all our Elisp files
Date: Fri, 21 Dec 2018 09:29:36 +0200	[thread overview]
Message-ID: <83va3nban3.fsf@gnu.org> (raw)
In-Reply-To: <5f113128-36c9-30c6-3413-8dc36051e058@cs.ucla.edu> (message from Paul Eggert on Thu, 20 Dec 2018 13:49:44 -0800)

> Cc: monnier@iro.umontreal.ca, 33796@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 20 Dec 2018 13:49:44 -0800
> 
> On 12/20/18 8:06 AM, Eli Zaretskii wrote:
> 
>  > my opinion should also count, right?
> 
> Of course, although my impression was that you weren't expressing an 
> opinion and were soliciting opinions.

Same as Stefan, actually: he asked whether there were objections.

>  > we need the opinion of people
>  > who might be actually affected by the proposed change,
> 
> I assume you mean that we need the opinion of people who would be 
> affected _negatively_.

Not necessarily.  I would actually like to hear opinions from people
who read CJK scripts who think the distinction no longer matters, not
these days.

>  > All 3 of us simply don't care,
> 
> No, actually I do care. Non-UTF-8 source files are a real annoyance for 
> me

This is a misunderstanding: by "don't care" I meant we don't care
which font is used to display a particular Unicode codepoint in the
Han area.

> I do think we should cut down on the unnecessary markup 
> in that file.

Agreed.

> The markup should be used only when it helps. Text like 
> "<x-charset><param>mule-unicode-0100-24ff</param> </x-charset>" is not 
> helping anybody; the file should just contain " " there.

There are only 2 such occurrences, so this isn't a grave problem.  I
will take a look when I have time.

> Most of the markup in that file is not necessary for proper display,
> and just gets in the way when using tools other than Emacs.

Which markup is not necessary for display, in your opinion?  I'm
surprised to hear that "most of it" is unnecessary, but maybe I'm
missing something.

>  >  . By the above reasoning, if Emacs is enhanced to interpret HTML/XML
>  >    and show typefaces instead of markup, you will see that as a
>  >    regression and complain that raw HTML files are "gibberish"?
> 
> I hope Emacs doesn't do any such thing by default.

Really?  Quite a few Emacs users think that it should, and that the
fact it doesn't is one of the significant deficiencies in Emacs, as
compared to other popular editors.

> </x-charset><x-charset><param>greek-iso8859-7</param>Greek (ελληνικά)   
> Γειά σας
> 
> It would be better to remove this particular markup, so that git etc. 
> would show this:
> 
> Greek (ελληνικά)    Γειά σας
> 
> which is what Emacs ordinarily shows.

That markup is precisely what keeps the charset properties on the
corresponding greetings.  Removing it would be losing information that
HELLO is trying to preserve.

> I don't use that menu, but I took your hint and just now 
> tried it, by selecting the abovementioned word "ελληνικά" and menuing to 
> Edit > Text Properties > Describe Properties, but all it said was 'Text 
> content at position 1530: There are text properties here: unknown 
> ("x-charset")'. This missed the point that the word's character set is 
> greek-iso8859-7

I cannot reproduce this.  That menu item invokes the command
describe-text-properties, which pops up the *Help* buffer, and the
text there says:

  Text content at position 1530:


  There are text properties here:
    charset              greek-iso8859-7

I wonder why you don't see that.  Is it possible that you are looking
at a file/buffer that was modified from its original contents?

> which is a special hack that hints to Emacs (and nobody else, I
> guess? I couldn't find documentation for this stuff even in the 
> Emacs manuals) that the text should be displayed with a Greek font 
> instead of the same Greek font that Emacs would be using anyway.

The charset property allows us to have a fontset that directs Emacs to
use specific fonts for specific character ranges.  See set-fontset-font.
I do agree that these issues are notoriously under-documented.





  reply	other threads:[~2018-12-21  7:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18 18:46 bug#33796: 27.0.50; Use utf-8 is all our Elisp files Stefan Monnier
2018-12-18 19:22 ` Eli Zaretskii
2018-12-18 19:46   ` Stefan Monnier
2018-12-19 17:54 ` Paul Eggert
2018-12-19 18:11   ` Eli Zaretskii
2018-12-19 22:13     ` Paul Eggert
2018-12-20 16:06       ` Eli Zaretskii
2018-12-20 21:49         ` Paul Eggert
2018-12-21  7:29           ` Eli Zaretskii [this message]
2018-12-21 13:46             ` Stefan Monnier
2018-12-21 15:54               ` Eli Zaretskii
2018-12-21 13:55             ` Eli Zaretskii
2018-12-19 21:16   ` Stefan Monnier
2019-01-08  2:20 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83va3nban3.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=33796@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).