GNU bug report logs -
#43866
26.3; italian postfix additions
Previous Next
Reported by: Francesco Potortì <pot <at> gnu.org>
Date: Thu, 8 Oct 2020 12:07:01 UTC
Severity: wishlist
Tags: moreinfo
Found in version 26.3
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43866 in the body.
You can then email your comments to 43866 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 12:07:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Francesco Potortì <pot <at> gnu.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 08 Oct 2020 12:07:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Since the inception of mule, amyyears ago, I have set up an environment
where I switch between italian-postfix and american input methods.
Now I realise that I have made long time ago an addition to italian that
has never gone into emacs.
The rationale is that in Italy latin-9 should be used insterad of
latin1, which does not contain the euro symbol. And that
italian-postfix should allow introducing the euro symbol.
Here is what I use in all machines where I have emacs:
================ start ================
;; Add the Euro symbol, use Latin-9 rather than Latin-1
(quail-define-package
"italian-postfix" "Latin-9" "IT<" t
"Italian (Italiano) input method with postfix modifiers
a` -> à A` -> À e' -> é << -> «
e` -> è E` -> È E' -> É >> -> »
i` -> ì I` -> Ì E= -> € o_ -> º
o` -> ò O` -> Ò a_ -> ª
u` -> ù U` -> Ù
Typewriter-style italian characters.
Doubling the postfix separates the letter and postfix: e.g. a`` -> a`
" nil t nil nil nil nil nil nil nil nil t)
(quail-define-rules
("A`" ?À) ("a`" ?à) ("E`" ?È) ("E'" ?É) ("E=" ?€) ("e`" ?è) ("e'" ?é)
("I`" ?Ì) ("i`" ?ì) ("O`" ?Ò) ("o`" ?ò) ("U`" ?Ù)
("u`" ?ù) ("<<" ?«) (">>" ?») ("o_" ?º) ("a_" ?ª)
("A``" ["A`"]) ("a``" ["a`"]) ("E``" ["E`"]) ("E''" ["E'"]) ("e``" ["e`"])
("e''" ["e'"]) ("I``" ["I`"]) ("i``" ["i`"]) ("O``" ["O`"]) ("o``" ["o`"])
("U``" ["U`"]) ("u``" ["u`"])
("<<<" ["<<"]) (">>>" [">>"]) ("o__" ["o_"]) ("a__" ["a_"])
)
================ end ================
In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2020-05-17, modified by Debian built on x86-csail-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid
Important settings:
value of $LC_COLLATE: it_IT.UTF-8
value of $LC_CTYPE: it_IT.UTF-8
value of $LC_NUMERIC: C
value of $LANG: C.UTF-8
locale-coding-system: utf-8-unix
Major mode: Mail
Minor modes in effect:
filladapt-mode: t
diff-auto-refine-mode: t
desktop-save-mode: t
epa-global-mail-mode: t
epa-mail-mode: t
shell-dirtrack-mode: t
openwith-mode: t
xterm-mouse-mode: t
display-time-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
abbrev-mode: t
Load-path shadows:
~/elisp/bhl hides /usr/share/emacs/site-lisp/bhl
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-autoloads hides /usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/debian-autoloads
/usr/share/emacs/site-lisp/elpa/csv-mode-1.12/csv-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.12/csv-mode-pkg
/usr/share/emacs/site-lisp/elpa/csv-mode-1.12/csv-mode hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.12/csv-mode
/usr/share/emacs/site-lisp/elpa/csv-mode-1.12/csv-mode-tests hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.12/csv-mode-tests
/usr/share/emacs/site-lisp/elpa/csv-mode-1.12/csv-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.12/csv-mode-autoloads
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-el hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-el
/usr/share/emacs/site-lisp/elpa/debian-el-37/gnus-BTS hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/gnus-BTS
/usr/share/emacs/site-lisp/elpa/debian-el-37/preseed hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/preseed
/usr/share/emacs/site-lisp/elpa/debian-el-37/deb-view hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/deb-view
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-el-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-el-autoloads
/usr/share/emacs/site-lisp/elpa/debian-el-37/apt-utils hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/apt-utils
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-bug hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-bug
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-el-pkg hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-el-pkg
/usr/share/emacs/site-lisp/elpa/debian-el-37/apt-sources hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/apt-sources
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-autoloads
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/dictionary hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/dictionary
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/link hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/link
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/dictionary-pkg hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/dictionary-pkg
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/dictionary-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/dictionary-autoloads
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/connection hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/connection
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot-mode-pkg
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/debian-autoloads
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot-context hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot-context
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot-gui hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot-gui
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot-mode-autoloads
/usr/share/emacs/site-lisp/elpa/markdown-mode-2.4/markdown-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/markdown-mode-2.4/markdown-mode-autoloads
/usr/share/emacs/site-lisp/elpa/markdown-mode-2.4/markdown-mode hides /usr/share/emacs/site-lisp/elpa-src/markdown-mode-2.4/markdown-mode
/usr/share/emacs/site-lisp/elpa/markdown-mode-2.4/markdown-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/markdown-mode-2.4/markdown-mode-pkg
/usr/share/emacs/site-lisp/flim/md4 hides /usr/share/emacs/26.3/lisp/md4
/usr/share/emacs/site-lisp/flim/hex-util hides /usr/share/emacs/26.3/lisp/hex-util
~/elisp/octave hides /usr/share/emacs/26.3/lisp/progmodes/octave
/usr/share/emacs/site-lisp/flim/ntlm hides /usr/share/emacs/26.3/lisp/net/ntlm
/usr/share/emacs/site-lisp/flim/hmac-md5 hides /usr/share/emacs/26.3/lisp/net/hmac-md5
/usr/share/emacs/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/26.3/lisp/net/sasl-ntlm
/usr/share/emacs/site-lisp/flim/sasl-digest hides /usr/share/emacs/26.3/lisp/net/sasl-digest
/usr/share/emacs/site-lisp/flim/sasl hides /usr/share/emacs/26.3/lisp/net/sasl
/usr/share/emacs/site-lisp/flim/sasl-cram hides /usr/share/emacs/26.3/lisp/net/sasl-cram
/usr/share/emacs/site-lisp/flim/hmac-def hides /usr/share/emacs/26.3/lisp/net/hmac-def
Features:
(shadow emacsbug apropos vc-bzr mode-local calccomp calc-map calc-alg
calc-vec calc-aent calc-menu calc-yank calc-ext reporter debian-bug
anything-config anything woman cl etags two-column iso-transl org-rmail
org-mhe org-irc org-info org-gnus nnir gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo
gnus-spec gnus-int gnus-range gnus-win gnus nnheader org-docview
org-bibtex org-bbdb org-w3m org-element avl-tree generator org org-macro
org-footnote org-pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp
ob-comint ob-core ob-eval org-compat org-macs org-loaddefs ispell xref
project eieio-opt speedbar sb-image ezimage dframe completion dos-w32
find-cmd grep find-dired find-func pp cl-print help-fns radix-tree
unrmail calc calc-loaddefs calc-macs deb-view network-stream starttls
url-http tls gnutls url-gw nsm url-cache url-auth url url-proxy
url-privacy url-expand url-methods url-history url-cookie w3m-filter
w3m-form w3m-cookie url-domsuf w3m-bookmark w3m-tabmenu w3m-session w3m
mailcap doc-view image-mode w3m-hist w3m-fb bookmark-w3m w3m-ems
wid-edit w3m-ccl ccl w3m-favicon w3m-image w3m-proc w3m-util cal-move
cal-x dabbrev arc-mode archive-mode macros locate edmacro kmacro rect
tabify man shr-color timezone rmailsort rmailedit url-util shr svg xml
browse-url add-log mailalias rmailout rmailkwd time-stamp cl-extra
dired-aux wdired misearch multi-isearch make-mode jka-compr vc-git
diff-mode markdown-mode subr-x noutline outline easy-mmode generic
sh-script executable tex-mode compile vc-dir ewoc vc vc-dispatcher
vc-svn json-mode rx bibtex-style vc-filewise vc-rcs octave texinfo pcase
bibtex mhtml-mode css-mode smie color js json map imenu cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
sgml-mode dom qp rmailmm message rmc puny rfc822 mml mml-sec gnus-util
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse
rfc2231 desktop frameset elec-pair cal-julian solar cal-dst pot skeleton
warnings rmailsum rmail rmail-loaddefs sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mime-compose epa-mail mail-utils epa
derived epg view holidays hol-loaddefs appt diary-lib diary-loaddefs
cal-menu calendar cal-loaddefs tramp tramp-compat tramp-loaddefs
trampver ucs-normalize shell pcomplete comint ring parse-time
format-spec advice bhl visual-fill-column switch-to-shell openwith
hi-lock xt-mouse time-date ffap thingatpt scroll-in-place filladapt
ansi-color time quail help-mode dired-x dired dired-loaddefs generic-x
disp-table finder-inf info debian-el package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib w3m-load mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 859419 104132)
(symbols 48 61004 1)
(miscs 40 1838 1970)
(strings 32 207996 12197)
(string-bytes 1 6110429)
(vectors 16 83287)
(vector-slots 8 2187469 111622)
(floats 8 914 1312)
(intervals 56 48134 1037)
(buffers 992 180))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 12:27:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Francesco Potortì <pot <at> gnu.org>
> Date: Thu, 08 Oct 2020 14:05:55 +0200
>
> Since the inception of mule, amyyears ago, I have set up an environment
> where I switch between italian-postfix and american input methods.
>
> Now I realise that I have made long time ago an addition to italian that
> has never gone into emacs.
>
> The rationale is that in Italy latin-9 should be used insterad of
> latin1, which does not contain the euro symbol. And that
> italian-postfix should allow introducing the euro symbol.
The Latin-1 vs Latin-9 part is not important nowadays, since Emacs
uses Unicode internally.
As for the Euro symbol, I guess we need to add it to all the Latin
input methods, not just the Italian one?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 12:35:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>> From: Francesco Potortì <pot <at> gnu.org>
>> Date: Thu, 08 Oct 2020 14:05:55 +0200
>>
>> Since the inception of mule, amyyears ago, I have set up an environment
>> where I switch between italian-postfix and american input methods.
>>
>> Now I realise that I have made long time ago an addition to italian that
>> has never gone into emacs.
>>
>> The rationale is that in Italy latin-9 should be used insterad of
>> latin1, which does not contain the euro symbol. And that
>> italian-postfix should allow introducing the euro symbol.
>
>The Latin-1 vs Latin-9 part is not important nowadays, since Emacs
>uses Unicode internally.
I don't know if that's ever used, maybe changing it is worth enyway.
>As for the Euro symbol, I guess we need to add it to all the Latin
>input methods, not just the Italian one?
I guess yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 12:40:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 08 Oct 2020 15:26:16 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Francesco Potortì <pot <at> gnu.org>
>> Date: Thu, 08 Oct 2020 14:05:55 +0200
>>
>> Since the inception of mule, amyyears ago, I have set up an environment
>> where I switch between italian-postfix and american input methods.
>>
>> Now I realise that I have made long time ago an addition to italian that
>> has never gone into emacs.
>>
>> The rationale is that in Italy latin-9 should be used insterad of
>> latin1, which does not contain the euro symbol. And that
>> italian-postfix should allow introducing the euro symbol.
Eli> The Latin-1 vs Latin-9 part is not important nowadays, since Emacs
Eli> uses Unicode internally.
Eli> As for the Euro symbol, I guess we need to add it to all the Latin
Eli> input methods, not just the Italian one?
Itʼs already in latin-postfix and on C-x 8 * E, is that really
necessary?
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 12:58:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Francesco Potortì <pot <at> gnu.org>, 43866 <at> debbugs.gnu.org
> Date: Thu, 08 Oct 2020 14:39:15 +0200
>
> Eli> As for the Euro symbol, I guess we need to add it to all the Latin
> Eli> input methods, not just the Italian one?
>
> Itʼs already in latin-postfix and on C-x 8 * E, is that really
> necessary?
You mean, do people (besides Francesco) still use italian-postfix? I
don't know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 13:27:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> >> The rationale is that in Italy latin-9 should be used insterad of
> >> latin1, which does not contain the euro symbol. And that
> >> italian-postfix should allow introducing the euro symbol.
>
> Eli> As for the Euro symbol, I guess we need to add it to all the Latin
> Eli> input methods, not just the Italian one?
>
>Itʼs already in latin-postfix and on C-x 8 * E, is that really
>necessary?
I don't use latin-postfix, because it gets in the way: there are many
more combinations than in italian postifix which change what I am
writing - this is an added burden for a minuscul added benefit.
This is why italian-postifix exists, in spite of the existence of
latin-postfix.
I don't use C-x 8 either, because I'd have to learn a lot of complex
bindings: when I need some exotic char I use the terminal or the X
combinations, which are easier and not specific to Emacs, unless I am
forced to.
This has little to do with italian-postfix, in fact.
All in all, I don't get your objection. What would be the drawback of
adding the E = keybinding?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 13:55:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 08 Oct 2020 15:57:14 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Francesco Potortì <pot <at> gnu.org>, 43866 <at> debbugs.gnu.org
>> Date: Thu, 08 Oct 2020 14:39:15 +0200
>>
Eli> As for the Euro symbol, I guess we need to add it to all the Latin
Eli> input methods, not just the Italian one?
>>
>> Itʼs already in latin-postfix and on C-x 8 * E, is that really
>> necessary?
Eli> You mean, do people (besides Francesco) still use italian-postfix? I
Eli> don't know.
What I meant is: everything is Unicode, and latin-postfix subsumes all
<language>-postfix, as far as I can tell, so people could just use latin-postfix.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 14:01:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 08 Oct 2020 15:26:07 +0200, Francesco Potortì <pot <at> gnu.org> said:
>> >> The rationale is that in Italy latin-9 should be used insterad of
>> >> latin1, which does not contain the euro symbol. And that
>> >> italian-postfix should allow introducing the euro symbol.
>>
Eli> As for the Euro symbol, I guess we need to add it to all the Latin
Eli> input methods, not just the Italian one?
>>
>> Itʼs already in latin-postfix and on C-x 8 * E, is that really
>> necessary?
Francesco> I don't use latin-postfix, because it gets in the way: there are many
Francesco> more combinations than in italian postifix which change what I am
Francesco> writing - this is an added burden for a minuscul added benefit.
OK
Francesco> This is why italian-postifix exists, in spite of the existence of
Francesco> latin-postfix.
Francesco> I don't use C-x 8 either, because I'd have to learn a lot of complex
Francesco> bindings: when I need some exotic char I use the terminal or the X
Francesco> combinations, which are easier and not specific to Emacs, unless I am
Francesco> forced to.
This would not be for you: you already have your modified
italian-postfix.
Francesco> This has little to do with italian-postfix, in fact.
Francesco> All in all, I don't get your objection. What would be the drawback of
Francesco> adding the E = keybinding?
Think of it more as 'do we really need to change X numbers of input
methods, is there a simpler way'.
And the answer appears to be 'no such way exists'
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 14:25:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 08 Oct 2020 15:54:37 +0200, Robert Pluim <rpluim <at> gmail.com> said:
>>>>> On Thu, 08 Oct 2020 15:57:14 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>>> From: Robert Pluim <rpluim <at> gmail.com>
>>> Cc: Francesco Potortì <pot <at> gnu.org>, 43866 <at> debbugs.gnu.org
>>> Date: Thu, 08 Oct 2020 14:39:15 +0200
>>>
Eli> As for the Euro symbol, I guess we need to add it to all the Latin
Eli> input methods, not just the Italian one?
>>>
>>> Itʼs already in latin-postfix and on C-x 8 * E, is that really
>>> necessary?
Eli> You mean, do people (besides Francesco) still use italian-postfix? I
Eli> don't know.
Robert> What I meant is: everything is Unicode, and latin-postfix subsumes all
Robert> <language>-postfix, as far as I can tell, so people could just use latin-postfix.
As a practical question, if we do decide to add the euro to a bunch of
latin input methods, where do we stop? Should we add it to all the
greek-* methods on the grounds that Greece uses the Euro, but not to
"british" since the UK uses the pound?
(this is why I use C-x 8 * E to type €)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 14:33:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 43866 <at> debbugs.gnu.org
> Date: Thu, 08 Oct 2020 16:24:05 +0200
>
> As a practical question, if we do decide to add the euro to a bunch of
> latin input methods, where do we stop? Should we add it to all the
> greek-* methods on the grounds that Greece uses the Euro, but not to
> "british" since the UK uses the pound?
I only thought about the Latin-N ones, mainly because all the legacy
encodings which didn't have a Euro sign at some point got upgraded to
newer Latin-N encodings which do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 15:24:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> E= -> €
>
> Typewriter-style italian characters.
If they really are typewriter-style, wouldn't C= make more sense? E overstruck with = would just be a smudgy mess even if typed on a beautiful Olivetti.
Both C= and E= seem to work as X11 compose pairs. We could include both.
That is, c=, C=, e=, E=, and c==, C==, e==, E== as the literal cases.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 15:36:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 8 Oct 2020 17:23:35 +0200, Mattias Engdegård <mattiase <at> acm.org> said:
>> E= -> €
>>
>> Typewriter-style italian characters.
Mattias> If they really are typewriter-style, wouldn't C= make more sense? E overstruck with = would just be a smudgy mess even if typed on a beautiful Olivetti.
Mattias> Both C= and E= seem to work as X11 compose pairs. We could include both.
Mattias> That is, c=, C=, e=, E=, and c==, C==, e==, E== as the literal cases.
C= would make more sense, but E= (and of course =E for prefix input
methods) is more mnemonic. I can never remember how to type € on a mac
because itʼs not on something obvious like Option-E.
Thereʼs precedence from C-x 8 * as well, which uses E (though perhaps
it should have 'e' as well).
And for total coverage, we *must* add 'C-x 8 2 0 a c' ;-)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 15:43:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Thu, 8 Oct 2020 17:23:35 +0200
> Cc: 43866 <at> debbugs.gnu.org
>
> Both C= and E= seem to work as X11 compose pairs. We could include both.
I think you are right.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 16:11:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>> E= -> €
>>
>> Typewriter-style italian characters.
>
>If they really are typewriter-style, wouldn't C= make more sense? E
>overstruck with = would just be a smudgy mess even if typed on a
>beautiful Olivetti.
The euro sign under E is on many Italian keyboards, so that sounds
natural to me. Never seen C= as a shortcut, my X understands e= and E=
but not c= or C=.
>
>Both C= and E= seem to work as X11 compose pairs. We could include both.
>That is, c=, C=, e=, E=, and c==, C==, e==, E== as the literal cases.
I would not include c= and C=. I would not include e= either. These
things are very annoying unless they are really useful, so better just
include what's really needed and nothing more.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 16:23:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>And for total coverage, we *must* add 'C-x 8 2 0 a c' ;-)
Wow! But I can't imagine what that could produce :)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 17:19:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 08 Oct 2020 18:10:34 +0200, Francesco Potortì <pot <at> gnu.org> said:
>> Both C= and E= seem to work as X11 compose pairs. We could include both.
>> That is, c=, C=, e=, E=, and c==, C==, e==, E== as the literal cases.
Francesco> I would not include c= and C=. I would not include e= either. These
Francesco> things are very annoying unless they are really useful, so better just
Francesco> include what's really needed and nothing more.
The advantage of e= is that (on a US-type keyboard at least) it
doesnʼt involve any modifiers. But then again adding it would increase
the chances of someone typing it by mistake.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 17:29:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>>> On Thu, 08 Oct 2020 18:10:34 +0200, Francesco Potortì <pot <at> gnu.org> said:
>
> >> Both C= and E= seem to work as X11 compose pairs. We could include both.
> >> That is, c=, C=, e=, E=, and c==, C==, e==, E== as the literal cases.
>
> Francesco> I would not include c= and C=. I would not include e= either. These
> Francesco> things are very annoying unless they are really useful, so better just
> Francesco> include what's really needed and nothing more.
>
>The advantage of e= is that (on a US-type keyboard at least) it
>doesnʼt involve any modifiers. But then again adding it would increase
>the chances of someone typing it by mistake.
Yes. That's exactly the point.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 18:01:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 43866 <at> debbugs.gnu.org (full text, mbox):
8 okt. 2020 kl. 19.18 skrev Robert Pluim <rpluim <at> gmail.com>:
> Francesco> I would not include c= and C=. I would not include e= either. These
> Francesco> things are very annoying unless they are really useful, so better just
> Francesco> include what's really needed and nothing more.
>
> The advantage of e= is that (on a US-type keyboard at least) it
> doesnʼt involve any modifiers. But then again adding it would increase
> the chances of someone typing it by mistake.
As you noted, e= is already in latin-postfix. It seems odd to require E= in one mode and e= in another. It makes more sense for italian-postfix to be a subset of latin-postfix, so that an Italian user who needs foreign letters can switch without relearning composition pairs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 08 Oct 2020 19:56:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 43866 <at> debbugs.gnu.org (full text, mbox):
Francesco> I would not include c= and C=. I would not include e= either. These
Francesco> things are very annoying unless they are really useful, so better just
Francesco> include what's really needed and nothing more.
Robert:
>> The advantage of e= is that (on a US-type keyboard at least) it
>> doesnʼt involve any modifiers. But then again adding it would increase
>> the chances of someone typing it by mistake.
Mattias:
>As you noted, e= is already in latin-postfix. It seems odd to require
>E= in one mode and e= in another. It makes more sense for
>italian-postfix to be a subset of latin-postfix, so that an Italian
>user who needs foreign letters can switch without relearning
>composition pairs.
I once tried using latin-postfix and I soon stopped, as it creates many
more artifacts that you don't want than ones you want. Having a lowcase
e for making the euro sign is just one more reason why I wouldn't use
latin-postfix.
If the agreed-upon solution is to put 'e =' on all European postfix
languages, I think that's better leaving them all as they are now.
If the only blocking issue here is inconsistency with latin-postfix,
then better use 'E =' in place of 'e =' on latin-postfix and adding the
same to all European languages. The only drawback would be for those
using latin-postfix, but after my experience using it, I don't think it
is really used in practice.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 04:43:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 43866 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> As you noted, e= is already in latin-postfix. It seems odd to require
> E= in one mode and e= in another. It makes more sense for
> italian-postfix to be a subset of latin-postfix, so that an Italian
> user who needs foreign letters can switch without relearning
> composition pairs.
I'm not sure I agree. An input method specialised to a specific
language doesn't have to be a superset of the larger group -- a
less-specific input method may be intended for users that have less
experience with the language, and therefore be "sloppier"; i.e., have
more input methods so that the user will find the character easier (but
have more false positives that then will have to be fixed manually).
So I think Francesco is right here -- just add E=, and do nothing else
here (for the Euro).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 11:27:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 43866 <at> debbugs.gnu.org (full text, mbox):
9 okt. 2020 kl. 06.42 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> I'm not sure I agree. An input method specialised to a specific
> language doesn't have to be a superset of the larger group -- a
> less-specific input method may be intended for users that have less
> experience with the language, and therefore be "sloppier"; i.e., have
> more input methods so that the user will find the character easier (but
> have more false positives that then will have to be fixed manually).
The choice of input method is not about proficiency in the language but rather that a more constrained method is more efficient for monolingual use. The many input sequences of 'latin-postfix' are not there to help the learner stumble upon the right one by luck, but to allow the entry of more characters.
However, Francesco is right in that latin-postfix is too heavily loaded for smooth use, and I certainly understand why he prefers italian-postfix. 'latin-alt-postfix' is somewhat more practical (and uses e=).
> So I think Francesco is right here -- just add E=, and do nothing else
> here (for the Euro).
I wouldn't mind, although we may be straying a bit into tailoring parts of Emacs to a single user.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 11:57:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 43866 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
() Mattias Engdegård <mattiase <at> acm.org>
() Fri, 9 Oct 2020 13:26:12 +0200
> So I think Francesco is right here -- just add E=, and do
> nothing else here (for the Euro).
I wouldn't mind, although we may be straying a bit into
tailoring parts of Emacs to a single user.
FWIW, i use italian-postfix, too, and would welcome this (E=
only) change.
--
Thien-Thi Nguyen -----------------------------------------------
(defun responsep (query) ; (2020) Software Libero
(pcase (context query) ; = Dissenso Etico
(`(technical ,ml) (correctp ml))
...)) 748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 12:46:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 09 Oct 2020 07:53:58 -0400, Thien-Thi Nguyen <ttn <at> gnuvola.org> said:
Thien-Thi> () Mattias Engdegård <mattiase <at> acm.org>
Thien-Thi> () Fri, 9 Oct 2020 13:26:12 +0200
>> So I think Francesco is right here -- just add E=, and do
>> nothing else here (for the Euro).
Thien-Thi> I wouldn't mind, although we may be straying a bit into
Thien-Thi> tailoring parts of Emacs to a single user.
Thien-Thi> FWIW, i use italian-postfix, too, and would welcome this (E=
Thien-Thi> only) change.
I guess Iʼm the weirdo here: I use latin-prefix :-)
(it has € on ~e, which is not a great choice: various other
latin-prefix methods use ~e and ~E for other codepoints. Perhaps we
should add =E (or =e) to latin-prefix and maybe the other
latin-N-prefix methods)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 14:32:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Fri, 09 Oct 2020 14:45:34 +0200
> Cc: Mattias Engdegård <mattiase <at> acm.org>,
> Lars Ingebrigtsen <larsi <at> gnus.org>, 43866 <at> debbugs.gnu.org
>
> Thien-Thi> FWIW, i use italian-postfix, too, and would welcome this (E=
> Thien-Thi> only) change.
>
> I guess Iʼm the weirdo here: I use latin-prefix :-)
>
> (it has € on ~e, which is not a great choice: various other
> latin-prefix methods use ~e and ~E for other codepoints. Perhaps we
> should add =E (or =e) to latin-prefix and maybe the other
> latin-N-prefix methods)
Based on the discussion, I've decided to make a minimal change, so I
added E= as a sequence for the Euro sign to Latin-1 language input
methods (on the master branch).
Any reason not to close this bug report now?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 14:49:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 09 Oct 2020 17:31:17 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
Eli> Based on the discussion, I've decided to make a minimal change, so I
Eli> added E= as a sequence for the Euro sign to Latin-1 language input
Eli> methods (on the master branch).
Eli> Any reason not to close this bug report now?
If you've decided that the prefix methods donʼt get a similar
treatment then we can close it.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 15:05:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: ttn <at> gnuvola.org, mattiase <at> acm.org, larsi <at> gnus.org, 43866 <at> debbugs.gnu.org
> Date: Fri, 09 Oct 2020 16:48:07 +0200
>
> Eli> Any reason not to close this bug report now?
>
> If you've decided that the prefix methods donʼt get a similar
> treatment then we can close it.
You mean, use =E for the Euro? I don't mind if there are no
objections.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 15:06:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 43866 <at> debbugs.gnu.org (full text, mbox):
9 okt. 2020 kl. 16.31 skrev Eli Zaretskii <eliz <at> gnu.org>:
> Based on the discussion, I've decided to make a minimal change, so I
> added E= as a sequence for the Euro sign to Latin-1 language input
> methods (on the master branch).
The minimal change would be to do it for italian-postfix only but perhaps it doesn't hurt too much elsewhere.
(I don't think prefix methods need it.)
> Any reason not to close this bug report now?
Maybe it merits a NEWS entry?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 15:10:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 9 Oct 2020 17:05:23 +0200, Mattias Engdegård <mattiase <at> acm.org> said:
Mattias> 9 okt. 2020 kl. 16.31 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> Based on the discussion, I've decided to make a minimal change, so I
>> added E= as a sequence for the Euro sign to Latin-1 language input
>> methods (on the master branch).
Mattias> The minimal change would be to do it for italian-postfix only but perhaps it doesn't hurt too much elsewhere.
Mattias> (I don't think prefix methods need it.)
Why? If eg french-postfix has it, why not french-prefix?
>> Any reason not to close this bug report now?
Mattias> Maybe it merits a NEWS entry?
Itʼs a user-visible change, so I guess so.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 15:11:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 9 Oct 2020 17:05:23 +0200
> Cc: Robert Pluim <rpluim <at> gmail.com>, ttn <at> gnuvola.org, larsi <at> gnus.org,
> 43866 <at> debbugs.gnu.org
>
> 9 okt. 2020 kl. 16.31 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> > Based on the discussion, I've decided to make a minimal change, so I
> > added E= as a sequence for the Euro sign to Latin-1 language input
> > methods (on the master branch).
>
> The minimal change would be to do it for italian-postfix only but perhaps it doesn't hurt too much elsewhere.
I couldn't explain to myself why Italian should have it, but, say,
German or French shouldn't.
> (I don't think prefix methods need it.)
OK.
> > Any reason not to close this bug report now?
>
> Maybe it merits a NEWS entry?
Sounds too small to announce, but if others think it should be in
NEWS, I won't object.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 15:23:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 09 Oct 2020 18:10:48 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
Eli> Sounds too small to announce, but if others think it should be in
Eli> NEWS, I won't object.
git never forgets :-)
commit 3409fe0362c52127c52f854a7300f4dde4b8fffe
Author: Eli Zaretskii <eliz <at> gnu.org>
Date: Thu Mar 29 19:45:13 2018 +0300
Support Capital sharp S in German input methods
* lisp/leim/quail/latin-post.el ("german-postfix"):
* lisp/leim/quail/latin-pre.el ("german-prefix"): Add Capital
sharp S. (Bug#30988)
* etc/NEWS: Mention the support of Capital sharp S.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Fri, 09 Oct 2020 15:29:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 43866 <at> debbugs.gnu.org (full text, mbox):
9 okt. 2020 kl. 17.08 skrev Robert Pluim <rpluim <at> gmail.com>:
> Why? If eg french-postfix has it, why not french-prefix?
We would have to be rather sure about what it should be; each new sequence will be a potential point of annoyance.
The prefix methods that define € use ~e, but our users apparently didn't want us to follow existing practice for the postfix methods (e=).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Sat, 10 Oct 2020 20:55:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 43866 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> If you've decided that the prefix methods donʼt get a similar
>> treatment then we can close it.
>
> You mean, use =E for the Euro? I don't mind if there are no
> objections.
I think it sounds logical, but I don't think we should make such a
change without it being requested by somebody using those input
methods. Perhaps =E would be annoying for them?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Mon, 12 Oct 2020 09:27:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 10 Oct 2020 22:54:14 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:
Lars> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> If you've decided that the prefix methods donʼt get a similar
>>> treatment then we can close it.
>>
>> You mean, use =E for the Euro? I don't mind if there are no
>> objections.
Lars> I think it sounds logical, but I don't think we should make such a
Lars> change without it being requested by somebody using those input
Lars> methods. Perhaps =E would be annoying for them?
I donʼt think it would be annoying, but I agree thereʼs probably no
need to start adding things people haven't requested (and ~e already
exists).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Tue, 13 Oct 2020 20:20:03 GMT)
Full text and
rfc822 format available.
Message #104 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> Itʼs already in latin-postfix and on C-x 8 * E, is that really
> necessary?
I wonder why C-x 8 provides key sequences that are not mnemonic
and so hard to remember?
Would it make sense to support exactly the same keys that are
provided by the X11 compose method? I mean that are in the file
/usr/share/X11/locale/en_US.UTF-8/Compose
also available at
https://help.ubuntu.com/community/ComposeKey
and
https://cgit.freedesktop.org/xorg/lib/libX11/plain/nls/en_US.UTF-8/Compose.pre
For example, for every such line:
<Multi_key> <equal> <E> : "€" EuroSign # EURO SIGN
replace <Multi_key> with C-x 8, and bind such key sequences:
C-x 8 = E => "€"
and for all other keys as well, e.g.
C-x 8 . . . => "…" (HORIZONTAL ELLIPSIS)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 14 Oct 2020 02:32:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 43866 <at> debbugs.gnu.org
> Date: Tue, 13 Oct 2020 23:07:13 +0300
>
> I wonder why C-x 8 provides key sequences that are not mnemonic
> and so hard to remember?
>
> Would it make sense to support exactly the same keys that are
> provided by the X11 compose method? I mean that are in the file
> /usr/share/X11/locale/en_US.UTF-8/Compose
> also available at
> https://help.ubuntu.com/community/ComposeKey
> and
> https://cgit.freedesktop.org/xorg/lib/libX11/plain/nls/en_US.UTF-8/Compose.pre
How about making a new input method for those? It seems to me that
C-x 8 is already too "fat".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 14 Oct 2020 04:39:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 43866 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Would it make sense to support exactly the same keys that are
> provided by the X11 compose method?
That might be a good idea.
Also, I wonder if we could make that command more self-documenting.
Maybe C-h in the argument for C-x 8 could display a buffer
which displays characters you can choose.
Each character would be followed by the sequence to type to choose that
character.
This should include all the characters Emacs supports, divided clearly
into Unicode code blocks, with their unicode names. Not just the ones
that have specific short C-x 8 sequences definied in Emacs.
It would be nice to have a prefix more mnemonic than C-x 8.
But I have nothing to suggest.
It would be good to shorten C-x 8 RET. That is my go-to method
of inserting characters for which I don't know a sequence.
Currently, 8 upper-case letters are valid after C-h 8, and 6
lower-case. Suppose we free up one case -- either the upper-case
letters or the lower-case letters. Then we could make typing
a letter of that case throw you into the minibuffer.
In this way, we could replace C-x 8 RET UNICODE-NAME RET with
C-x 8 UNICODE-NAME RET.
Also, why not change the Unicode character names to lower-case?
They would look nicer that way, I think.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 14 Oct 2020 08:37:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>> I wonder why C-x 8 provides key sequences that are not mnemonic
>> and so hard to remember?
>>
>> Would it make sense to support exactly the same keys that are
>> provided by the X11 compose method? I mean that are in the file
>> /usr/share/X11/locale/en_US.UTF-8/Compose
>> also available at
>> https://help.ubuntu.com/community/ComposeKey
>> and
>> https://cgit.freedesktop.org/xorg/lib/libX11/plain/nls/en_US.UTF-8/Compose.pre
>
> How about making a new input method for those? It seems to me that
> C-x 8 is already too "fat".
Yes, a new method might be useful as well. But since such method can't
be enabled all the time because such sequences as "= E" should be inserted
literally in normal circumstances. So such method needs to be enabled
temporarily, and it takes more time to enable/disable it, while it's
useful only to insert a single special character sometimes, it would be
much easier to type some prefix key before typing "= E" to insert €
when such a need arises occasionally.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 14 Oct 2020 08:37:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> > Would it make sense to support exactly the same keys that are
> > provided by the X11 compose method?
>
> That might be a good idea.
Do we have the rights to copy all key definitions from the X11 compose method?
I guess there are no licensing restrictions?
> Also, I wonder if we could make that command more self-documenting.
> Maybe C-h in the argument for C-x 8 could display a buffer
> which displays characters you can choose.
> Each character would be followed by the sequence to type to choose that
> character.
Yes, displaying a separate buffer would be useful. Then maybe
displaying these keys could be moved from the Help buffer of 'C-h b'
that currently displays a very long list of 'C-x 8' keys at the beginning
of the Help buffer, so it's very difficult to see the keys of the
current mode that are at the end of the long Help buffer.
> This should include all the characters Emacs supports, divided clearly
> into Unicode code blocks, with their unicode names. Not just the ones
> that have specific short C-x 8 sequences definied in Emacs.
Maybe also 'C-u C-x =' could suggest how to input characters
using C-x 8 mnemonics.
> It would be nice to have a prefix more mnemonic than C-x 8.
> But I have nothing to suggest.
Yes, to find a more mnemonic and shorter key would be useful.
Maybe this question could be asked on emacs-devel
where someone might have ideas for such a key.
> It would be good to shorten C-x 8 RET. That is my go-to method
> of inserting characters for which I don't know a sequence.
>
> Currently, 8 upper-case letters are valid after C-h 8, and 6
> lower-case. Suppose we free up one case -- either the upper-case
> letters or the lower-case letters. Then we could make typing
> a letter of that case throw you into the minibuffer.
Sorry, I don't understand. I tried to type 'C-h 8', and it's undefined.
> In this way, we could replace C-x 8 RET UNICODE-NAME RET with
> C-x 8 UNICODE-NAME RET.
>
> Also, why not change the Unicode character names to lower-case?
> They would look nicer that way, I think.
I don't know why the Unicode standard uses upper-case, but I see no problem
in Emacs with upper-case letters when case-fold is non-nil, so you can type
lower-case letters in completions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 14 Oct 2020 10:44:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 14 Oct 2020 00:38:48 -0400, Richard Stallman <rms <at> gnu.org> said:
>> Would it make sense to support exactly the same keys that are
>> provided by the X11 compose method?
Richard> That might be a good idea.
Could we provide this as an input method?
Richard> Also, I wonder if we could make that command more self-documenting.
Richard> Maybe C-h in the argument for C-x 8 could display a buffer
Richard> which displays characters you can choose.
Richard> Each character would be followed by the sequence to type to choose that
Richard> character.
The problem is that such a list is very long. 'C-h b' after 'C-x 8
RET' will display the bindings, but it does not currently contain the
character names, and TAB after 'C-x 8 RET' will list all the names but
not the sequences for entering them.
There are completion frameworks that have solved this, eg with helm
you can start typing right after 'C-x 8 RET' and it will narrow the
list down automatically. Iʼm sure we could do something similar.
Richard> This should include all the characters Emacs supports, divided clearly
Richard> into Unicode code blocks, with their unicode names. Not just the ones
Richard> that have specific short C-x 8 sequences definied in Emacs.
Why does it matter which code block a character is in?
Richard> It would be nice to have a prefix more mnemonic than C-x 8.
Richard> But I have nothing to suggest.
Richard> It would be good to shorten C-x 8 RET. That is my go-to method
Richard> of inserting characters for which I don't know a sequence.
Where would you put it? Note that if you do know the sequence you can
use Alt or a dead accent key instead of 'C-x 8' (someone did suggest
freeing up F2 recently)
Richard> Currently, 8 upper-case letters are valid after C-h 8, and 6
Richard> lower-case. Suppose we free up one case -- either the upper-case
Richard> letters or the lower-case letters. Then we could make typing
Richard> a letter of that case throw you into the minibuffer.
I think itʼs a tossup as to which of them would be easier to free
up. The lower case bindings have one fewer prefix key, so perhaps
lower case. Or perhaps a completely different binding.
Richard> In this way, we could replace C-x 8 RET UNICODE-NAME RET with
Richard> C-x 8 UNICODE-NAME RET.
Richard> Also, why not change the Unicode character names to lower-case?
Richard> They would look nicer that way, I think.
The Unicode character names are always described in upper case, but I
guess we could add a configuration option so that 'ucs-names'
downcased them (the completion in C-x 8 RET is case insensitive)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 14 Oct 2020 14:58:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Richard Stallman <rms <at> gnu.org>
> Date: Wed, 14 Oct 2020 00:38:48 -0400
> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
>
> Also, I wonder if we could make that command more self-documenting.
> Maybe C-h in the argument for C-x 8 could display a buffer
> which displays characters you can choose.
I don't understand: "C-x 8 C-h" already shows such a buffer.
> Also, why not change the Unicode character names to lower-case?
> They would look nicer that way, I think.
You can type in lower-case, then TAB will upcase them for you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 14 Oct 2020 15:08:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Wed, 14 Oct 2020 11:07:41 +0300
>
> > How about making a new input method for those? It seems to me that
> > C-x 8 is already too "fat".
>
> Yes, a new method might be useful as well. But since such method can't
> be enabled all the time because such sequences as "= E" should be inserted
> literally in normal circumstances. So such method needs to be enabled
> temporarily, and it takes more time to enable/disable it, while it's
> useful only to insert a single special character sometimes, it would be
> much easier to type some prefix key before typing "= E" to insert €
> when such a need arises occasionally.
But turning an input method on and off is just 1 key, C-\, whereas
C-x 8 is 2 keys, and not very convenient sequence to type, at least on
QWERTY keyboards. So it looks like a dedicated input method will
still be a win. I don't think it's right that the only Unicode input
method we have is TeX -- that is great for TeX users, but many people
don't use (La)TeX, and will find it unintuitive to type the TeX
sequences.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 14 Oct 2020 19:51:03 GMT)
Full text and
rfc822 format available.
Message #128 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>> > How about making a new input method for those? It seems to me that
>> > C-x 8 is already too "fat".
>>
>> Yes, a new method might be useful as well. But since such method can't
>> be enabled all the time because such sequences as "= E" should be inserted
>> literally in normal circumstances. So such method needs to be enabled
>> temporarily, and it takes more time to enable/disable it, while it's
>> useful only to insert a single special character sometimes, it would be
>> much easier to type some prefix key before typing "= E" to insert €
>> when such a need arises occasionally.
>
> But turning an input method on and off is just 1 key, C-\, whereas
1 key C-\ to enable, and 1 key C-\ to disable. Also might need to select
another input method name from 'C-u C-\' when also using other input methods.
> C-x 8 is 2 keys, and not very convenient sequence to type, at least on
> QWERTY keyboards.
I agree, C-x 8 is not easy to type.
> So it looks like a dedicated input method will still be a win.
A win for some users, not a win for other users, so adding both
(an input method and a prefix key) would be fine for all.
> I don't think it's right that the only Unicode input method we have is
> TeX -- that is great for TeX users, but many people don't use (La)TeX,
> and will find it unintuitive to type the TeX sequences.
It seems the TeX input method requires typing whole Unicode names,
or at least unambiguous parts of names, e.g. '\euro' inserts €,
'\smile' inserts ⌣, but can't type '\smiling face with sunglasses'.
Also I see a hex Unicode input method in uni-input.el that supports
e.g. U<hex> or u<hex>, RFC1345 mnemonics in rfc1345.el,
SGML entities in sgml-input.el. So adding a X11 Compose method would be handy.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 15 Oct 2020 02:35:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Wed, 14 Oct 2020 22:40:48 +0300
>
> >> Yes, a new method might be useful as well. But since such method can't
> >> be enabled all the time because such sequences as "= E" should be inserted
> >> literally in normal circumstances. So such method needs to be enabled
> >> temporarily, and it takes more time to enable/disable it, while it's
> >> useful only to insert a single special character sometimes, it would be
> >> much easier to type some prefix key before typing "= E" to insert €
> >> when such a need arises occasionally.
> >
> > But turning an input method on and off is just 1 key, C-\, whereas
>
> 1 key C-\ to enable, and 1 key C-\ to disable. Also might need to select
> another input method name from 'C-u C-\' when also using other input methods.
Btw, input methods that use =E or E= could (and in many cases do) have
==E and E== to insert just "=E" and "E=", so no toggling is needed.
> > I don't think it's right that the only Unicode input method we have is
> > TeX -- that is great for TeX users, but many people don't use (La)TeX,
> > and will find it unintuitive to type the TeX sequences.
>
> It seems the TeX input method requires typing whole Unicode names,
> or at least unambiguous parts of names, e.g. '\euro' inserts €,
> '\smile' inserts ⌣, but can't type '\smiling face with sunglasses'.
> Also I see a hex Unicode input method in uni-input.el that supports
> e.g. U<hex> or u<hex>, RFC1345 mnemonics in rfc1345.el,
> SGML entities in sgml-input.el. So adding a X11 Compose method would be handy.
Agreed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 15 Oct 2020 03:53:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 43866 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Would it make sense to support exactly the same keys that are
> > provided by the X11 compose method? I mean that are in the file
> > /usr/share/X11/locale/en_US.UTF-8/Compose
> > also available at
> > https://help.ubuntu.com/community/ComposeKey
> > and
> > https://cgit.freedesktop.org/xorg/lib/libX11/plain/nls/en_US.UTF-8/Compose.pre
> How about making a new input method for those? It seems to me that
> C-x 8 is already too "fat".
That may be useful, but it has a drawback compared with C-x 8.
It is inconvenient to change input methods just for one character and
then change back. C-x 8 avoids that inconvenience; you can use it to
enter one character, any one character, without changing the current
input method.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 15 Oct 2020 03:56:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 43866 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Richard> Maybe C-h in the argument for C-x 8 could display a buffer
> Richard> which displays characters you can choose.
> Richard> Each character would be followed by the sequence to type to choose that
> Richard> character.
> The problem is that such a list is very long. 'C-h b' after 'C-x 8
> RET' will display the bindings, but it does not currently contain the
> character names, and TAB after 'C-x 8 RET' will list all the names but
> not the sequences for entering them.
It would be a problem if they are displayed in an inconvenient
way, not designed specifically for this purpose. My idea is to display
them in a buffer which is divided into pages, so you could use C-x ]
and C-x [ to move around in it, as well as search commands.
> Why does it matter which code block a character is in?
Organizing the buffer by code blocks makes it feasible to navigate
through the long list of all the Unicode characters and find
the one you want, without knowing its name in advance.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Mon, 19 Oct 2020 20:53:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 43866 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> It seems the TeX input method requires typing whole Unicode names,
>> or at least unambiguous parts of names, e.g. '\euro' inserts €,
>> '\smile' inserts ⌣, but can't type '\smiling face with sunglasses'.
>> Also I see a hex Unicode input method in uni-input.el that supports
>> e.g. U<hex> or u<hex>, RFC1345 mnemonics in rfc1345.el,
>> SGML entities in sgml-input.el. So adding a X11 Compose method would be handy.
>
> Agreed.
Here's is a working implementation. It binds all key sequences to the key
'C-+' that has the mnemonics of adding a character. 'C-+' is free because
it can't be used to zoom text since its counterpart key 'C--' is already
taken to input numeric arguments. 'C-+ C-+' is bound to 'insert-char'
like the current longer key sequence 'C-x 8 RET' that is hard to type.
[x-compose.el (application/emacs-lisp, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Mon, 19 Oct 2020 23:13:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 43866 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Here's is a working implementation. It binds all key sequences to the key
> 'C-+' that has the mnemonics of adding a character. 'C-+' is free because
> it can't be used to zoom text since its counterpart key 'C--' is already
> taken to input numeric arguments.
Right, but the idea of using it still makes me feel a bit uneasy.
May I suggest that we use a different key for this?
A while back, RMS suggested that we could bind `C-+' to
text-scale-adjust even if we can't bind `C-'. I was not super
enthusiastic about this at the time, but perhaps that idea is the least
bad option.
One could imagine that in combination with, for example, optionally
binding the numerical prefix argument only to `M--'. We could perhaps
then consider enabling that in the "beginner friendly profile" we have
been discussing on emacs-devel (but that no one has yet seriously worked
on).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Tue, 20 Oct 2020 14:13:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Mon, 19 Oct 2020 23:45:48 +0300
>
> Here's is a working implementation. It binds all key sequences to the key
> 'C-+' that has the mnemonics of adding a character. 'C-+' is free because
> it can't be used to zoom text since its counterpart key 'C--' is already
> taken to input numeric arguments. 'C-+ C-+' is bound to 'insert-char'
> like the current longer key sequence 'C-x 8 RET' that is hard to type.
The implementation seems to rely on a file in the /usr/include tree
that might not be there. This is a significant disadvantage, IMO. It
means that, unlike all other similar facilities in Emacs, this one is
not self-contained.
Is it possible to lift this limitation?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Tue, 20 Oct 2020 14:48:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 20 Oct 2020 17:12:02 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
>> Date: Mon, 19 Oct 2020 23:45:48 +0300
>>
>> Here's is a working implementation. It binds all key sequences to the key
>> 'C-+' that has the mnemonics of adding a character. 'C-+' is free because
>> it can't be used to zoom text since its counterpart key 'C--' is already
>> taken to input numeric arguments. 'C-+ C-+' is bound to 'insert-char'
>> like the current longer key sequence 'C-x 8 RET' that is hard to type.
Eli> The implementation seems to rely on a file in the /usr/include tree
Eli> that might not be there. This is a significant disadvantage, IMO. It
Eli> means that, unlike all other similar facilities in Emacs, this one is
Eli> not self-contained.
Eli> Is it possible to lift this limitation?
Aren't all those definitions in lisp/term/x-win.el anyway?
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Tue, 20 Oct 2020 15:51:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Juri Linkov <juri <at> linkov.net>, 43866 <at> debbugs.gnu.org
> Date: Tue, 20 Oct 2020 16:47:12 +0200
>
> Eli> The implementation seems to rely on a file in the /usr/include tree
> Eli> that might not be there. This is a significant disadvantage, IMO. It
> Eli> means that, unlike all other similar facilities in Emacs, this one is
> Eli> not self-contained.
>
> Eli> Is it possible to lift this limitation?
>
> Aren't all those definitions in lisp/term/x-win.el anyway?
Probably. But even that is sub-optimal (though better than reading a
/usr/include file): it is only available on X. What about TTY
sessions, what about w32?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Tue, 20 Oct 2020 18:57:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> May I suggest that we use a different key for this?
>
> A while back, RMS suggested that we could bind `C-+' to
> text-scale-adjust even if we can't bind `C-'. I was not super
> enthusiastic about this at the time, but perhaps that idea is the least
> bad option.
>
> One could imagine that in combination with, for example, optionally
> binding the numerical prefix argument only to `M--'. We could perhaps
> then consider enabling that in the "beginner friendly profile" we have
> been discussing on emacs-devel (but that no one has yet seriously worked
> on).
Ah, C-+ could be suitable for a beginner profile indeed.
What key other programs use for a Compose-like Multi_key?
https://help.ubuntu.com/community/ComposeKey
says that the default Compose Multi_key is Shift+AltGr,
and the Unicode composition key is Shift+Ctrl+U.
And indeed Shift+Ctrl+U works in all applications and xterm,
but not in Emacs on X (in Emacs on tty Shift+Ctrl+U works).
And here is more information for different systems:
https://en.wikipedia.org/wiki/Compose_key
https://en.wikipedia.org/wiki/Unicode_input
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Tue, 20 Oct 2020 18:57:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> Eli> The implementation seems to rely on a file in the /usr/include tree
> Eli> that might not be there. This is a significant disadvantage, IMO. It
> Eli> means that, unlike all other similar facilities in Emacs, this one is
> Eli> not self-contained.
>
> Eli> Is it possible to lift this limitation?
>
> Aren't all those definitions in lisp/term/x-win.el anyway?
It seems the list in lisp/term/x-win.el is not needed at run-time,
since Eli want to pre-generate these keymappings, so at the time
of generation, keysymdef.h can be used because we need such mappings as
from XK_Aogonek to U+0104, not from 0x01a1 to U+0104 like in x-win.el.
The only remaining problem with keysymdef.h is how to process such
definitions in keysymdef.h:
#define XK_KP_Enter 0xff8d /* Enter */
There is no Unicode character, even in x-win.el.
I guess it should be hard-coded to map directly to [kp-enter].
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Tue, 20 Oct 2020 19:38:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> The implementation seems to rely on a file in the /usr/include tree
> that might not be there. This is a significant disadvantage, IMO. It
> means that, unlike all other similar facilities in Emacs, this one is
> not self-contained.
>
> Is it possible to lift this limitation?
Yes, this is easy to do. But I have one problem:
/usr/share/X11/locale/en_US.UTF-8/Compose contains 83 lines
where a key sequence maps to 2 characters, not to 1 character, e.g.
<Multi_key> <acute> <Cyrillic_u> : "у́" # CYRILLIC SMALL LETTER U WITH COMBINING ACUTE ACCENT
where "у́" is 2 characters: CYRILLIC SMALL LETTER U and COMBINING ACUTE ACCENT.
iso-transl.el maps a key sequence to a single character only using
(define-key map (apply 'vector '(?' ?у)) (vector ?у))
I don't know how to map a key sequence to 2 characters.
When trying to map to 2 characters ?у and ?́ :
(define-key map (apply 'vector '(?' ?у)) (vector ?у ?́ ))
typing 'y inserts only the last character ?́ , not both ?у and ?́ .
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Tue, 20 Oct 2020 20:20:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> The implementation seems to rely on a file in the /usr/include tree
> that might not be there. This is a significant disadvantage, IMO. It
> means that, unlike all other similar facilities in Emacs, this one is
> not self-contained.
>
> Is it possible to lift this limitation?
I tried to generate an output with a list of characters,
but can't find a print-related variable that would
print a number as a character.
For example, currently
(prin1 ?⌘ (current-buffer)) => 8984
prints the number 8984, but I need to print the character, i.e.
(prin1 ?⌘ (current-buffer)) => ?⌘
There is the variable 'float-output-format' that affects the output
of floating-point numbers, e.g.
(let ((float-output-format "%.2f")) (prin1 12.345 (current-buffer)))
but I can't find a variable to print characters instead of integers.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 08:13:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 20 Oct 2020 22:05:31 +0300, Juri Linkov <juri <at> linkov.net> said:
>> The implementation seems to rely on a file in the /usr/include tree
>> that might not be there. This is a significant disadvantage, IMO. It
>> means that, unlike all other similar facilities in Emacs, this one is
>> not self-contained.
>>
>> Is it possible to lift this limitation?
Juri> Yes, this is easy to do. But I have one problem:
Juri> /usr/share/X11/locale/en_US.UTF-8/Compose contains 83 lines
Juri> where a key sequence maps to 2 characters, not to 1 character, e.g.
Juri> <Multi_key> <acute> <Cyrillic_u> : "у́" # CYRILLIC SMALL LETTER U WITH COMBINING ACUTE ACCENT
Juri> where "у́" is 2 characters: CYRILLIC SMALL LETTER U and COMBINING ACUTE ACCENT.
Juri> iso-transl.el maps a key sequence to a single character only using
Juri> (define-key map (apply 'vector '(?' ?у)) (vector ?у))
Juri> I don't know how to map a key sequence to 2 characters.
Juri> When trying to map to 2 characters ?у and ?́ :
Juri> (define-key map (apply 'vector '(?' ?у)) (vector ?у ?́ ))
Juri> typing 'y inserts only the last character ?́ , not both ?у and ?́ .
Canʼt you pass a string containing ?y and ?́ as the last argument to
define-key? (although you might want to use the ?\N{NAME} or ?\uXXXX
syntax to stop Emacs combining that U+0301 with the question mark)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 14:03:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Tue, 20 Oct 2020 22:56:07 +0300
>
> I tried to generate an output with a list of characters,
> but can't find a print-related variable that would
> print a number as a character.
>
> For example, currently
>
> (prin1 ?⌘ (current-buffer)) => 8984
>
> prints the number 8984, but I need to print the character, i.e.
>
> (prin1 ?⌘ (current-buffer)) => ?⌘
I don't think I understand what you are looking for. Would using the
%c format in a call to 'format' be okay? If not, why not?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 14:30:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 43866 <at> debbugs.gnu.org
> Date: Wed, 21 Oct 2020 10:11:55 +0200
>
> Canʼt you pass a string containing ?y and ?́ as the last argument to
> define-key? (although you might want to use the ?\N{NAME} or ?\uXXXX
> syntax to stop Emacs combining that U+0301 with the question mark)
The character composition happens only on display, the buffer or
string still have two codepoints.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 14:41:01 GMT)
Full text and
rfc822 format available.
Message #176 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 21 Oct 2020 17:29:58 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 43866 <at> debbugs.gnu.org
>> Date: Wed, 21 Oct 2020 10:11:55 +0200
>>
>> Canʼt you pass a string containing ?y and ?́ as the last argument to
>> define-key? (although you might want to use the ?\N{NAME} or ?\uXXXX
>> syntax to stop Emacs combining that U+0301 with the question mark)
Eli> The character composition happens only on display, the buffer or
Eli> string still have two codepoints.
Yes. But when looking at the code it would look like a single glyph,
which would be confusing.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 15:24:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: juri <at> linkov.net, 43866 <at> debbugs.gnu.org
> Date: Wed, 21 Oct 2020 16:40:47 +0200
>
> Eli> The character composition happens only on display, the buffer or
> Eli> string still have two codepoints.
>
> Yes. But when looking at the code it would look like a single glyph,
> which would be confusing.
We could have a comment about that. IMO, using the ?\N{NAME} for that
is gross.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 17:47:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>> I tried to generate an output with a list of characters,
>> but can't find a print-related variable that would
>> print a number as a character.
>>
>> For example, currently
>>
>> (prin1 ?⌘ (current-buffer)) => 8984
>>
>> prints the number 8984, but I need to print the character, i.e.
>>
>> (prin1 ?⌘ (current-buffer)) => ?⌘
>
> I don't think I understand what you are looking for. Would using the
> %c format in a call to 'format' be okay? If not, why not?
The problem is that it's necessary to print a long list with vectors
that contain characters. For example:
(prin1 '(("'A" . [?Á])
("'E" . [?É])
("'I" . [?Í])
("'O" . [?Ó])
("'U" . [?Ú])
("'Y" . [?Ý]))
(current-buffer))
currently prints:
(("'A" . [193])
("'E" . [201])
("'I" . [205])
("'O" . [211])
("'U" . [218])
("'Y" . [221]))
whereas it would be nicer to print characters as characters,
not as integers:
(("'A" . [?Á])
("'E" . [?É])
("'I" . [?Í])
("'O" . [?Ó])
("'U" . [?Ú])
("'Y" . [?Ý]))
I can't find a variable that could change the output format
of integers to print them as characters.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 17:48:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>> I don't know how to map a key sequence to 2 characters.
>> When trying to map to 2 characters ?у and ?́ :
>
>> (define-key map (apply 'vector '(?' ?у)) (vector ?у ?́ ))
>
>> typing 'y inserts only the last character ?́ , not both ?у and ?́ .
>
> Canʼt you pass a string containing ?y and ?́ as the last argument to
> define-key? (although you might want to use the ?\N{NAME} or ?\uXXXX
> syntax to stop Emacs combining that U+0301 with the question mark)
I tried to use a string as the last argument to define-key,
and the result is weird: the Help buffer says that the key binding
is actually a keyboard macro, and invoking it does strange things.
For example, when a binding is a string "ö", then typing its keys
calls the command 'upcase-word'. No idea why it works this way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 18:17:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Wed, 21 Oct 2020 20:23:51 +0300
>
> > I don't think I understand what you are looking for. Would using the
> > %c format in a call to 'format' be okay? If not, why not?
>
> The problem is that it's necessary to print a long list with vectors
> that contain characters. For example:
>
> (prin1 '(("'A" . [?Á])
> ("'E" . [?É])
> ("'I" . [?Í])
> ("'O" . [?Ó])
> ("'U" . [?Ú])
> ("'Y" . [?Ý]))
> (current-buffer))
Why do you have to use prin1?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 18:29:01 GMT)
Full text and
rfc822 format available.
Message #191 received at 43866 <at> debbugs.gnu.org (full text, mbox):
>> The problem is that it's necessary to print a long list with vectors
>> that contain characters. For example:
>>
>> (prin1 '(("'A" . [?Á])
>> ("'E" . [?É])
>> ("'I" . [?Í])
>> ("'O" . [?Ó])
>> ("'U" . [?Ú])
>> ("'Y" . [?Ý]))
>> (current-buffer))
>
> Why do you have to use prin1?
Actually I need to use pp-to-string to pretty-print the list,
but pp-to-string calls '(prin1 object (current-buffer))'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 18:36:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Wed, 21 Oct 2020 21:27:16 +0300
>
> >> (prin1 '(("'A" . [?Á])
> >> ("'E" . [?É])
> >> ("'I" . [?Í])
> >> ("'O" . [?Ó])
> >> ("'U" . [?Ú])
> >> ("'Y" . [?Ý]))
> >> (current-buffer))
> >
> > Why do you have to use prin1?
>
> Actually I need to use pp-to-string to pretty-print the list,
> but pp-to-string calls '(prin1 object (current-buffer))'.
prin1 accepts a function as its 2nd argument; can you use that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Wed, 21 Oct 2020 20:14:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 43866 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> >> (prin1 '(("'A" . [?Á])
>> >> ("'E" . [?É])
>> >> ("'I" . [?Í])
>> >> ("'O" . [?Ó])
>> >> ("'U" . [?Ú])
>> >> ("'Y" . [?Ý]))
>> >> (current-buffer))
>> >
>> > Why do you have to use prin1?
>>
>> Actually I need to use pp-to-string to pretty-print the list,
>> but pp-to-string calls '(prin1 object (current-buffer))'.
>
> prin1 accepts a function as its 2nd argument; can you use that?
I tried to use a function in the 2nd argument, but it's called
for every digit of the integer that represents a character,
so I don't know what to do with these digits.
However, do you think something like the following is a good idea?
Let-binding a new variable 'print-integers-as-chars' to t:
(let ((print-integers-as-chars t))
(pp '(("'A" . [?Á])
("'E" . [?É])
("'I" . [?Í])
("'O" . [?Ó])
("'U" . [?Ú])
("'Y" . [?Ý]))
(current-buffer)))
prints integers as characters:
(("'A" . [?Á])
("'E" . [?É])
("'I" . [?Í])
("'O" . [?Ó])
("'U" . [?Ú])
("'Y" . [?Ý]))
with this patch:
[print-integers-as-chars.patch (text/x-diff, inline)]
diff --git a/src/print.c b/src/print.c
index dca095f281..1755eea738 100644
--- a/src/print.c
+++ b/src/print.c
@@ -1908,8 +1908,16 @@ print_object (Lisp_Object obj, Lisp_Object printcharfun, bool escapeflag)
{
case_Lisp_Int:
{
- int len = sprintf (buf, "%"pI"d", XFIXNUM (obj));
- strout (buf, len, len, printcharfun);
+ if (!NILP (Vprint_integers_as_chars) && CHARACTERP (obj))
+ {
+ int len = sprintf (buf, "%s", SDATA (call1 (intern ("prin1-char"), obj)));
+ strout (buf, len, len, printcharfun);
+ }
+ else
+ {
+ int len = sprintf (buf, "%"pI"d", XFIXNUM (obj));
+ strout (buf, len, len, printcharfun);
+ }
}
break;
@@ -2247,6 +2255,10 @@ syms_of_print (void)
that represents the number without losing information. */);
Vfloat_output_format = Qnil;
+ DEFVAR_LISP ("print-integers-as-chars", Vprint_integers_as_chars,
+ doc: /* Print integers as characters. */);
+ Vprint_integers_as_chars = Qnil;
+
DEFVAR_LISP ("print-length", Vprint_length,
doc: /* Maximum length of list to print before abbreviating.
A value of nil means no limit. See also `eval-expression-print-length'. */);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Thu, 22 Oct 2020 13:00:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Wed, 21 Oct 2020 22:39:08 +0300
>
> However, do you think something like the following is a good idea?
>
> Let-binding a new variable 'print-integers-as-chars' to t:
>
> (let ((print-integers-as-chars t))
> (pp '(("'A" . [?Á])
> ("'E" . [?É])
> ("'I" . [?Í])
> ("'O" . [?Ó])
> ("'U" . [?Ú])
> ("'Y" . [?Ý]))
> (current-buffer)))
>
> prints integers as characters:
>
> (("'A" . [?Á])
> ("'E" . [?É])
> ("'I" . [?Í])
> ("'O" . [?Ó])
> ("'U" . [?Ú])
> ("'Y" . [?Ý]))
>
> with this patch:
The idea is fine, but I have a few comments about implementation:
> case_Lisp_Int:
> {
> - int len = sprintf (buf, "%"pI"d", XFIXNUM (obj));
> - strout (buf, len, len, printcharfun);
> + if (!NILP (Vprint_integers_as_chars) && CHARACTERP (obj))
^^^^^^^^^^^^^^^^^^^^^^^^
If this is supposed to be a boolean variable, please use DEFVAR_BOOL,
with all the consequences.
> + int len = sprintf (buf, "%s", SDATA (call1 (intern ("prin1-char"), obj)));
Do we really need to call Lisp? I thought we were quite capable of
printing characters from C, aren't we?
> @@ -2247,6 +2255,10 @@ syms_of_print (void)
> that represents the number without losing information. */);
> Vfloat_output_format = Qnil;
>
> + DEFVAR_LISP ("print-integers-as-chars", Vprint_integers_as_chars,
> + doc: /* Print integers as characters. */);
> + Vprint_integers_as_chars = Qnil;
I wonder whether it wouldn't be cleaner to add another optional
argument to prin1, and let it bind some internal variable so that
print_object does this, instead of exposing this knob to Lisp.
Because print_object is used all over the place, and who knows what
will this do to other callers?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Sat, 30 Apr 2022 12:20:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 43866 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> + DEFVAR_LISP ("print-integers-as-chars", Vprint_integers_as_chars,
>> + doc: /* Print integers as characters. */);
>> + Vprint_integers_as_chars = Qnil;
>
> I wonder whether it wouldn't be cleaner to add another optional
> argument to prin1, and let it bind some internal variable so that
> print_object does this, instead of exposing this knob to Lisp.
> Because print_object is used all over the place, and who knows what
> will this do to other callers?
There's also prin1-to-string, and adding a parameter to these functions
just for this doesn't seem quite right.
However, I agree with you that adding a new print-* variable is bad, too
(because users will invariably set them in .emacs and then things break
in some obscure package).
So I wonder whether we could come up with a new convention for print
variables like this, which would allow us to extend printing more
without adding new print variables.
What about -- adding a new parameter to prin1 and prin1-to-string that's
a plist of printing features? That is, something like:
(prin1 object nil '(length 20 integers-as-chars t))
And this would allow us to introduce a special value for that parameter,
like t, which means "use the standard values for everything".
That means we could get rid of the gazillion places where we have
(let ((print-length nil)
(print-level nil))
(prin1 object))
That would instead just be (prin1 object nil t). (And the same with
prin1-to-string.) This would hopefully be less error-prone than what we
have today -- we've had so many bug reports from packages forgetting to
bind one or the other when saving data.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 30 Apr 2022 12:20:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Sat, 30 Apr 2022 12:30:01 GMT)
Full text and
rfc822 format available.
Message #208 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Juri Linkov <juri <at> linkov.net>, rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Sat, 30 Apr 2022 14:19:32 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> + DEFVAR_LISP ("print-integers-as-chars", Vprint_integers_as_chars,
> >> + doc: /* Print integers as characters. */);
> >> + Vprint_integers_as_chars = Qnil;
> >
> > I wonder whether it wouldn't be cleaner to add another optional
> > argument to prin1, and let it bind some internal variable so that
> > print_object does this, instead of exposing this knob to Lisp.
> > Because print_object is used all over the place, and who knows what
> > will this do to other callers?
>
> There's also prin1-to-string, and adding a parameter to these functions
> just for this doesn't seem quite right.
>
> However, I agree with you that adding a new print-* variable is bad, too
> (because users will invariably set them in .emacs and then things break
> in some obscure package).
>
> So I wonder whether we could come up with a new convention for print
> variables like this, which would allow us to extend printing more
> without adding new print variables.
>
> What about -- adding a new parameter to prin1 and prin1-to-string that's
> a plist of printing features? That is, something like:
>
> (prin1 object nil '(length 20 integers-as-chars t))
My worries were mainly because this new variable affected print_object
directly, and because print_object is called in many places unrelated
to prin1 etc.
I'm okay with what you propose, but I don't see how would that
eliminate the reasons for my worries. The implementation of the
effect of this argument is still in print_object, so the question that
is of interest to me is how will we communicate these arguments to
print_object?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Sat, 30 Apr 2022 14:50:02 GMT)
Full text and
rfc822 format available.
Message #211 received at 43866 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I'm okay with what you propose, but I don't see how would that
> eliminate the reasons for my worries. The implementation of the
> effect of this argument is still in print_object, so the question that
> is of interest to me is how will we communicate these arguments to
> print_object?
I was thinking that prin1* would just set/bind a new global variable
(but one that isn't visible to the Lisp level).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Sat, 30 Apr 2022 15:27:02 GMT)
Full text and
rfc822 format available.
Message #214 received at 43866 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: juri <at> linkov.net, rpluim <at> gmail.com, 43866 <at> debbugs.gnu.org
> Date: Sat, 30 Apr 2022 16:49:14 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I'm okay with what you propose, but I don't see how would that
> > eliminate the reasons for my worries. The implementation of the
> > effect of this argument is still in print_object, so the question that
> > is of interest to me is how will we communicate these arguments to
> > print_object?
>
> I was thinking that prin1* would just set/bind a new global variable
> (but one that isn't visible to the Lisp level).
Then this sounds almost exactly like what I suggested back then, so I
agree, of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Sat, 30 Apr 2022 18:50:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 43866 <at> debbugs.gnu.org (full text, mbox):
Heh, `print-integers-as-characters' already exists -- it was added in
2020.
Anyway, I still think adding a parameter like described to prin1 would
be nice, but it's not necessary for this feature, which somehow had
something to do with Italian postfix.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43866; Package
emacs.
(Sun, 29 May 2022 13:37:02 GMT)
Full text and
rfc822 format available.
Message #220 received at 43866 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Anyway, I still think adding a parameter like described to prin1 would
> be nice, but it's not necessary for this feature, which somehow had
> something to do with Italian postfix.
Re-skimming this bug thread, I think the original issue was fixed by
Eli at the time -- E= was added (for euro sign) -- but then the
discussion went on to whether we should have an input method/command
based on
/usr/share/X11/locale/en_US.UTF-8/Compose
So I'm closing this bug report and opening a new one that's about that.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
43866 <at> debbugs.gnu.org and Francesco Potortì <pot <at> gnu.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 29 May 2022 13:37:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 27 Jun 2022 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 304 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.