GNU bug report logs -
#23251
25.0.92; M-< and M-> don't work with Croatian keyboard
Previous Next
Reported by: Josko <jjezina <at> hotmail.com>
Date: Sat, 9 Apr 2016 16:02:02 UTC
Severity: normal
Found in version 25.0.92
Done: Eli Zaretskii <eliz <at> gnu.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 23251 in the body.
You can then email your comments to 23251 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#23251; Package
emacs.
(Sat, 09 Apr 2016 16:02:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Josko <jjezina <at> hotmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 09 Apr 2016 16:02:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: jjezina <at> hotmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.92; M-< and M-> don't work with Croatian keyboard
Date: Sat, 09 Apr 2016 17:00:39 +0200
Message-ID: <87d1pyltd4.fsf <at> TK-PC.i-did-not-set--mail-host-address--so-tickle-me>
--text follows this line--
With Croatian (HRV) keyboard active, instead of executing commands
beginning-of-buffer and end-of-buffer, M-< and M-> just insert
'<' and '>' characters in most (but not all) buffers.
C-h k M-< gives: '< runs the command self-insert-command' in all user
buffers open with C-x C-f.
Also, in '*GNU Emacs and '*About GNU Emacs*' buffers M-< gives '< is undefined'.
In the following buffers it works correctly:
*Help*, *Messages*, *Buffer List*, *Bug Help*
With e.g. Spanish keyboard which has exactly the same <> key
postion (next to Left Shift) everything works OK. Also with US keyboard.
No problems with CRO(HRV) keyboard in Emacs 24.5 either.
In GNU Emacs 25.0.92.1 (i686-pc-mingw32)
of 2016-03-31 built on LEG570
Repository revision: df441b362c25c4ad59ea3d83137328d0d4098eaf
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
'configure --host=i686-pc-mingw32'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS
Important settings:
value of $LANG: HRV
locale-coding-system: cp1250
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set [2 times]
Quit
< is undefined
> is undefined
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev 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 w32notify w32 multi-tty
make-network-process emacs)
Memory information:
((conses 8 90293 6364)
(symbols 32 19631 0)
(miscs 32 80 118)
(strings 16 15807 4101)
(string-bytes 1 430167)
(vectors 8 12493)
(vector-slots 4 437628 5702)
(floats 8 160 79)
(intervals 28 276 44)
(buffers 516 12))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sat, 09 Apr 2016 16:35:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 23251 <at> debbugs.gnu.org (full text, mbox):
> From: Josko <jjezina <at> hotmail.com>
> Date: Sat, 9 Apr 2016 15:17:30 +0000
> To: bug-gnu-emacs <at> gnu.org
> Subject: 25.0.92; M-< and M-> don't work with Croatian keyboard
> Date: Sat, 09 Apr 2016 17:00:39 +0200
>
> With Croatian (HRV) keyboard active, instead of executing commands
> beginning-of-buffer and end-of-buffer, M-< and M-> just insert
> '<' and '>' characters in most (but not all) buffers.
> C-h k M-< gives: '< runs the command self-insert-command' in all user
> buffers open with C-x C-f.
> Also, in '*GNU Emacs and '*About GNU Emacs*' buffers M-< gives '< is undefined'.
> In the following buffers it works correctly:
> *Help*, *Messages*, *Buffer List*, *Bug Help*
Please try the latest pretest of Emacs 25.1, we have changed the
keyboard handling there.
Also, what happens if you use the right Alt key instead of the left
Alt key to produce M-< etc.?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sat, 09 Apr 2016 16:39:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 23251 <at> debbugs.gnu.org (full text, mbox):
> From: jjezina <at> hotmail.com
> To: bug-gnu-emacs <at> gnu.org
> Subject: 25.0.92; M-< and M-> don't work with Croatian keyboard
> Date: Sat, 09 Apr 2016 17:00:39 +0200
>
> In the following buffers it works correctly:
> *Help*, *Messages*, *Buffer List*, *Bug Help*
This is just because in these buffers '<' and '>' do the same as M-<
and M->.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sun, 10 Apr 2016 02:39:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 23251 <at> debbugs.gnu.org (full text, mbox):
> From: Josko <jjezina <at> hotmail.com>
> Date: Sat, 9 Apr 2016 20:41:09 +0000
>
> Thank your for the quick answer.
>
> No effect with right ALT because that's AltGr key used for other characters-
> With CRO keyboard AltGr-< and AltGr-> produce no characters nor commands,
> but with US keyb. AltGr-< gives: 'Ç' char. , and nothing with AltGr->.
>
> Also, on CRO keyb., AltGr is mostly used for these chars:
> AltGR-v = @, AltGR-b = { , AltGr-n = }, AltGr-f = [ , AltGr-g = ] , AltGr-q = \ , AltGr-w = |
> etc.
> For example command M-@ is Alt-AltGr-v and works OK.
>
> ESC-< and ESC-> also work OK in 25.0.92.
>
> Finally-as soon as I switch to US keyboard (which is always installed in Windows) with ALT-SHIFT,
> everything is OK with Alt-< and Alt-> in all buffers...
>
> Regarding latest pretest 25.1 version, thanks for the suggestion.
> I've used the latest precompiled version from sourceforge.net/projects/emacs-bin/files/snapshots/
> (emacs-25-20160331T094545Z-bin-i686-mingw32.7z).
> That's how I've found that Spanish keyborad works because the uploader couldn't reproduce the problem.
> Sorry, I don't know how to compile it from sources myself...
Ilya, could you perhaps look into this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sun, 10 Apr 2016 19:29:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 23251 <at> debbugs.gnu.org (full text, mbox):
On Sun, Apr 10, 2016 at 05:38:12AM +0300, Eli Zaretskii wrote:
> > From: Josko <jjezina <at> hotmail.com>
> > Date: Sat, 9 Apr 2016 20:41:09 +0000
> >
> > Thank your for the quick answer.
> >
> > No effect with right ALT because that's AltGr key used for other characters-
> > With CRO keyboard AltGr-< and AltGr-> produce no characters nor commands,
> > but with US keyb. AltGr-< gives: 'Ç' char. , and nothing with AltGr->.
> >
> > Also, on CRO keyb., AltGr is mostly used for these chars:
> > AltGR-v = @, AltGR-b = { , AltGr-n = }, AltGr-f = [ , AltGr-g = ] , AltGr-q = \ , AltGr-w = |
> > etc.
> > For example command M-@ is Alt-AltGr-v and works OK.
> >
> > ESC-< and ESC-> also work OK in 25.0.92.
> >
> > Finally-as soon as I switch to US keyboard (which is always installed in Windows) with ALT-SHIFT,
> > everything is OK with Alt-< and Alt-> in all buffers...
> >
> > Regarding latest pretest 25.1 version, thanks for the suggestion.
> > I've used the latest precompiled version from sourceforge.net/projects/emacs-bin/files/snapshots/
> > (emacs-25-20160331T094545Z-bin-i686-mingw32.7z).
> > That's how I've found that Spanish keyborad works because the uploader couldn't reproduce the problem.
> > Sorry, I don't know how to compile it from sources myself...
>
> Ilya, could you perhaps look into this?
From
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23251
it is not clear what “Generate-Meta” settings are used in this bug,
given that there is no Meta key on the Windows.
• Is it with no init/site files?
• What happens if this key is pressed with Alt⸣s?
• What happens if this key is pressed with left Alt?
• What happens if this key is pressed with AltGr?
• What happens if this key is pressed with Alt and AltGr?
Myself, I won’t be able to test this for a few days, since the only
laptop-or-hardware-keyboard about me with ISO key present is not
accessible right now.
Yours,
Ilya
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sun, 10 Apr 2016 19:47:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 23251 <at> debbugs.gnu.org (full text, mbox):
On Sun, Apr 10, 2016 at 12:27:54PM -0700, Ilya Zakharevich wrote:
> From
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23251
> it is not clear what “Generate-Meta” settings are used in this bug,
> given that there is no Meta key on the Windows.
>
> • Is it with no init/site files?
> • What happens if this key is pressed with Alt⸣s?
> • What happens if this key is pressed with left Alt?
> • What happens if this key is pressed with AltGr?
> • What happens if this key is pressed with Alt and AltGr?
>
> Myself, I won’t be able to test this for a few days, since the only
> laptop-or-hardware-keyboard about me with ISO key present is not
> accessible right now.
On Win7, as far as it is visible from MSKLC, Spanish and Croatian
keyboards define the ISO key identically:
Base → <
Shift → >
Ctrl → FS=^\
There is no special binding for any other key (including any Alt).
Both keyboards look as having the bit KLLF_ALTGR (sp?) defined (but
probably MSKLC would lie about this!).
Ilya
P.S.
What confuses me is
with US keyb. AltGr-< gives: 'Ç' char. , and nothing with AltGr->.
This is not how US keyboard should behave; it does not define any
AltGr bindings! I even checked “US International”, and while it has
SOME AltGr bindings, it has none on the ISO key.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Tue, 12 Apr 2016 18:00:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 23251 <at> debbugs.gnu.org (full text, mbox):
On Mon, Apr 11, 2016 at 07:35:12PM +0000, Josko wrote:
> But with CRO keyb., on all OSes the same result - only < and > characters are shown. So Alt key is ignored or somehow blocked.
>
> Note that everything works OK in Emacs 24.5, so I comapred default (emacs -Q) modes and features with 25.0.92,
> disabling new features one by one but nothing changed.
Do you know about this one (quoting Eli):
I also added a new variable, w32-use-fallback-wm-chars-method, which,
when non-nil, makes Emacs use the old code from before your changes.
This way, one can check whether it is due to MY edit, bug#19994.
If it is my code which is at fault, there is a way to get finer info:
recompile with -DDBG_WM_CHARS; then my code emits several diagnostic
lines per a processed keypress.
Ilya
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Tue, 12 Apr 2016 18:44:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 23251 <at> debbugs.gnu.org (full text, mbox):
On Mon, Apr 11, 2016 at 07:35:12PM +0000, Josko wrote:
> But the most peculiar twist happened with Czech and Slovak keyboards-
> they are similar, not same, but have the same <> key postion - which is like on US keyboard,
> but accessed with AltGr. So AltGr-, is < and AltGr-. is >
>
> So, M-< is Alt-AltGr-, and M-> is Alt-AltGr-.
> Czech: both work OK
> Slovak: M-< works OK, but M-> inserts > character!
THIS I can reproduce. This is affected by MY patch.
Will not be able to look into it in more details quick — hopefully,
end of the week!
Ilya
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Thu, 14 Apr 2016 05:38:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 23251 <at> debbugs.gnu.org (full text, mbox):
On Sun, Apr 10, 2016 at 12:46:05PM -0700, Ilya Zakharevich wrote:
> keyboards define the ISO key identically:
> Base → <
> Shift → >
> Ctrl → FS=^\
>
> There is no special binding for any other key (including any Alt).
> Both keyboards look as having the bit KLLF_ALTGR (sp?) defined (but
> probably MSKLC would lie about this!).
Explanation for enquiring minds:
================================
OK, the reason for a peculiar behaviour of these keys is that they are
SECONDARY keypresses which produce the same character. So:
• The “more bullet-proofish” branch in my patch cannot handle such
keyspresses, and
• the fallback (“to assume that every modifier keys DID contribute¹⁾
to the generation of the character”) turned out to be too
simple-minded (for this unexpectedly frequent situation).
¹⁾ On Windows, for typical layouts, Alt (NOT AltGr!) and Win
modifiers would not affect the generated character.
This behaviour of layouts is a little bit more widespread than what I
expected. So far I found following pairs:
Primary Secondary Generate
Czech: AltGr-Q, AltGr-W ISO, Shift-ISO \, |
Croat: AltGr-Q, AltGr-W US-\, US-| \, |
Croat: AltGr-., AltGr-, ISO, Shift-ISO <, >
Slovak: AltGr-z AltGr-, >
Slovak: AltGr-. AltGr-ISO <
C-Y: US-/, US-| ISO, Shift-ISO \, |
(The last row is for Czech-QUERTY, but also for most US-compatible
keyboards.) Here US-foo means “the keypress producing ‘foo’ on US
keyboard”.
Also, on Czech-QUERTY, the following characters allow AltGr access
(“A-” below) at the “US layout locations”; together with
Czech-layout-specific keypresses, this creates duplication as (AFAIK):
Primary: US-! US-` A-US-_ A-US-: US-< US-- A-US--
Secondary: A-US-+ A-US-; US-? US-> A-US-? A-US-= US-/
Produce: + ; _ : ? = -
This creates a significant mess if one wants to allow using the
secondary locations with Alt modifier (for example, to generate Meta-;
by Alt-AltGr-;). It does not look like a small workaround is possible
(which does not break OTHER usage scenarios).
Ilya
P.S. I know a medium-sized workaround which would improve OTHER cases
as well. But it cannot be ready in a day or two!]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Thu, 14 Apr 2016 15:23:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 23251 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 13 Apr 2016 22:37:13 -0700
> From: Ilya Zakharevich <ilya <at> math.berkeley.edu>
> Cc: Josko <jjezina <at> hotmail.com>, 23251 <at> debbugs.gnu.org
>
> This creates a significant mess if one wants to allow using the
> secondary locations with Alt modifier (for example, to generate Meta-;
> by Alt-AltGr-;). It does not look like a small workaround is possible
> (which does not break OTHER usage scenarios).
>
> Ilya
>
> P.S. I know a medium-sized workaround which would improve OTHER cases
> as well. But it cannot be ready in a day or two!]
Thanks for looking into this.
Is it possible to devise a simple work-around that would depend on
some optional variable? The work-around doesn't need to handle all
usage scenarios, just allow using a particular keyboard layout with
reasonable results (e.g., it could break usage of some other layouts).
If such work-around is possible, I think we should consider it for
the upcoming Emacs 25.1 as a temporary stopgap.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sun, 17 Apr 2016 03:41:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 23251 <at> debbugs.gnu.org (full text, mbox):
Just in case somebody may try to use this table:
On Wed, Apr 13, 2016 at 10:37:13PM -0700, Ilya Zakharevich wrote:
> Also, on Czech-QUERTY, the following characters allow AltGr access
> (“A-” below) at the “US layout locations”; together with
> Czech-layout-specific keypresses, this creates duplication as (AFAIK):
>
> Primary: US-! US-` A-US-_ A-US-: US-< US-- A-US--
> Secondary: A-US-+ A-US-; US-? US-> A-US-? A-US-= US-/
> Produce: + ; _ : ? = -
I got this table (what is primary/secondary) by inspecting the
output of MSKLC. Turned out one cannot trust this output: MSKLC
reports not the current table in the layout, but what it thinks is a
“reasonable representation” (reordering keys, which is WRONG!).
Doing experiments with the buggy Emacs (and with a fixed one ;-) I see
that the actual table is much more reasonable (with one apparent bug
— see `=´ — uncovered ;-):
Primary: US-! US-` US-? US-> US-< A-US-= US-/
Secondary: A-US-+ A-US-; A-US-_ A-US-: A-US-? US-- A-US--
Produce: + ; _ : ? = -
Yours,
Ilya
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sun, 17 Apr 2016 03:48:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 23251 <at> debbugs.gnu.org (full text, mbox):
On Thu, Apr 14, 2016 at 06:21:28PM +0300, Eli Zaretskii wrote:
> Is it possible to devise a simple work-around that would depend on
> some optional variable? The work-around doesn't need to handle all
> usage scenarios, just allow using a particular keyboard layout with
> reasonable results (e.g., it could break usage of some other layouts).
>
> If such work-around is possible, I think we should consider it for
> the upcoming Emacs 25.1 as a temporary stopgap.
I much prefer a simple heuristic which (hopefully) breaks orders of
magnitude less things than what it fixes. Hopefully, this 2-LOC edit
must be such!
It affects ONLY the discussed case (“secondary” keys), and (if the
heuristic triggers) changes it by ONLY falling back to pre-my-patch
behaviour. I put a lot of comments explaining what happens, and
REALLY hope that the cases where this patch HURTS would NEVER arise…
Hope this helps,
Ilya
--- w32fns.c-pre-secondary 2015-08-16 18:53:58.569735600 -0700
+++ w32fns.c 2016-04-16 19:30:38.026157600 -0700
@@ -3149,6 +3149,42 @@ deliver_wm_chars (int do_translate, HWND
wParam));
if ((r & 0xFF) == wParam)
bitmap = r>>8; /* *b is reachable via simple interface */
+ else
+ {
+ /* VkKeyScanW() (essentially) returns the FIRST key with
+ the specified character; so here the pressed key is the
+ SECONDARY key producing the character.
+
+ Essentially, we have no information about the "role" of
+ modifiers on this key: which contribute into the
+ produced character (so "are consumed"), and which are
+ "extra" (must attache to bindable events).
+
+ The default above would consume ALL modifiers, so the
+ character is reported "as is". However, on many layouts
+ the ordering of the keys (in the layout table) is not
+ thought out well, so the "secondary" keys are often those
+ which the users would prefer to use with Alt-CHAR.
+ (Moreover - with e.g. Czech-QWERTY - the ASCII
+ punctuation is accessible from two equally [nu]preferable
+ AltGr-keys.)
+
+ SO: Heuristic: if the reported char is ASCII, AND Meta
+ modifier is a candidate, behave as if Meta is present
+ (fallback to the legacy branch; bug#23251).
+
+ (This would break layouts
+ - delivering ASCII characters
+ - on SECONDARY keys
+ - with not Shift/AltGr-like modifier combinations.
+ All 3 conditions together must be pretty exotic
+ cases - and a workaround exists: use "primary" keys!) */
+ if (*b < 0x80
+ && (wmsg.dwModifiers
+ & (alt_modifier | meta_modifier
+ | super_modifier | hyper_modifier)))
+ return 0;
+ }
if (*type_CtrlAlt == 'a') /* Simple Alt seen */
{
if ((bitmap & ~1) == 0) /* 1: KBDSHIFT */
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sun, 17 Apr 2016 03:57:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 23251 <at> debbugs.gnu.org (full text, mbox):
On Sat, Apr 16, 2016 at 08:47:05PM -0700, Ilya Zakharevich wrote:
> It affects ONLY the discussed case (“secondary” keys), and (if the
> heuristic triggers) changes it by ONLY falling back to pre-my-patch
> behaviour. I put a lot of comments explaining what happens, and
> REALLY hope that the cases where this patch HURTS would NEVER arise…
Forgot to say: I checked only the Slovak and Czech-QUERTY layouts (the
only layouts I know where the bug was triggered without ISO keys).
Every misbehaviour I noticed with the old version is fixed by this
patch. (This includes both cases: Alt-key and Alt-AltGr-key “losing”
Alt-modifier.)
Yours,
Ilya
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sun, 17 Apr 2016 14:50:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 23251 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 16 Apr 2016 20:47:05 -0700
> From: Ilya Zakharevich <ilya <at> math.berkeley.edu>
> Cc: jjezina <at> hotmail.com, 23251 <at> debbugs.gnu.org
>
> On Thu, Apr 14, 2016 at 06:21:28PM +0300, Eli Zaretskii wrote:
> > Is it possible to devise a simple work-around that would depend on
> > some optional variable? The work-around doesn't need to handle all
> > usage scenarios, just allow using a particular keyboard layout with
> > reasonable results (e.g., it could break usage of some other layouts).
> >
> > If such work-around is possible, I think we should consider it for
> > the upcoming Emacs 25.1 as a temporary stopgap.
>
> I much prefer a simple heuristic which (hopefully) breaks orders of
> magnitude less things than what it fixes.
That's even better, of course.
> Hopefully, this 2-LOC edit must be such!
Thanks.
Josko, can you see if the patch fixes your problems?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Thu, 21 Apr 2016 16:11:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 23251 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 16 Apr 2016 20:47:05 -0700
> From: Ilya Zakharevich <ilya <at> math.berkeley.edu>
> Cc: jjezina <at> hotmail.com, 23251 <at> debbugs.gnu.org
>
> On Thu, Apr 14, 2016 at 06:21:28PM +0300, Eli Zaretskii wrote:
> > Is it possible to devise a simple work-around that would depend on
> > some optional variable? The work-around doesn't need to handle all
> > usage scenarios, just allow using a particular keyboard layout with
> > reasonable results (e.g., it could break usage of some other layouts).
> >
> > If such work-around is possible, I think we should consider it for
> > the upcoming Emacs 25.1 as a temporary stopgap.
>
> I much prefer a simple heuristic which (hopefully) breaks orders of
> magnitude less things than what it fixes. Hopefully, this 2-LOC edit
> must be such!
Thanks, pushed to the emacs-25 branch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Thu, 21 Apr 2016 16:13:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 23251 <at> debbugs.gnu.org (full text, mbox):
> From: Josko <jjezina <at> hotmail.com>
> Date: Tue, 19 Apr 2016 22:46:31 +0000
>
> Hi,
> Thank you and Ilya for making the patch.
>
> I asked Dani to compile a new binary (emacs-bin at sourceforge) but this was his answer:
> "But the patch has not been applied to the repository (emacs-25 branch) yet.
> My binary releases are made from unmodified versions of the published source code."
>
> Will that be soon?
Done. Please test the next snapshot of emacs-25.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sat, 23 Apr 2016 15:57:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 23251 <at> debbugs.gnu.org (full text, mbox):
Thanks.
I confirm that all keys work fine now.
I've tested it with more than 20 keyboard layouts (both East and West European),
and all work OK.
________________________________________
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Thursday, April 21, 2016 4:12 PM
To: Josko
Cc: 23251 <at> debbugs.gnu.org
Subject: Re: bug#23251: 25.0.92; M-< and M-> don't work with Croatian keyboard
> From: Josko <jjezina <at> hotmail.com>
> Date: Tue, 19 Apr 2016 22:46:31 +0000
>
> Hi,
> Thank you and Ilya for making the patch.
>
> I asked Dani to compile a new binary (emacs-bin at sourceforge) but this was his answer:
> "But the patch has not been applied to the repository (emacs-25 branch) yet.
> My binary releases are made from unmodified versions of the published source code."
>
> Will that be soon?
Done. Please test the next snapshot of emacs-25.
Thanks.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 23 Apr 2016 17:58:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Josko <jjezina <at> hotmail.com>:
bug acknowledged by developer.
(Sat, 23 Apr 2016 17:58:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 23251-done <at> debbugs.gnu.org (full text, mbox):
> From: Josko <jjezina <at> hotmail.com>
> CC: "23251 <at> debbugs.gnu.org" <23251 <at> debbugs.gnu.org>
> Date: Sat, 23 Apr 2016 15:56:51 +0000
>
> Thanks.
>
> I confirm that all keys work fine now.
> I've tested it with more than 20 keyboard layouts (both East and West European),
> and all work OK.
Thanks for testing, I'm therefore closing the bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23251; Package
emacs.
(Sat, 23 Apr 2016 21:35:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 23251 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> Josko <jjezina <at> hotmail.com> writes:
> I confirm that all keys work fine now.
> I've tested it with more than 20 keyboard layouts (both East and West European),
> and all work OK.
Thank you for being thorough! It is most appreciated.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
[signature.asc (application/pgp-signature, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 22 May 2016 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 177 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.