5:59 p.m.
[CCing XEmacs Beta, because despite it originating at emacs-devel(a)gnu.org,
this isn’t directly relevant to the FSF’s Emacs any more, but there’s more
value in keeping it visible than in keeping it in private mail.]
Ar an séú lá is fiche de mí na Samhain, scríobh Paul Pogonyshev:
> > > [...] Recent betas of XEmacs do. Not to do it is
expected
> > > behaviour, when you think of it; it would be reasonable to bind
> > > M-Cyrillic_tse to something different to M-x, if both were
> > > available on the keyboard.
> >
> > Yeah, and then I'd have to remember if I'm typing in Russian or in
> > English and press different key combos in different layouts to say
> > delete a word.
>
> Yup, just like people using German or French layouts use different
> key combos in different layouts to say delete a word.
Oh, I feel sorry for them, then. I think it is very inconvenient. Maybe a
little less inconvenient than with Russian, since at least those
different keys have the same letters on them (as I understand.)
Much less inconvenient than with Russian, yes.
> > [...] Non-self-inserting keys _absolutely_ must work
independently
> > of the layout, at least by default.
>
> I agree--I did implement the support in XEmacs. This problem is not a
> problem I have personally, though, so my implementation may be incomplete;
> if you’d like to try it out, I’d love to have some feedback.
>
> [...]
Sorry, I'm on dial-up and I don't think I want to download megabytes just
to test it. I use GNU Emacs normally.
Sure. I hope you don’t mind if I ask you a few specific questions then --
-- If you see M-; listed as a key binding, is the first thing that occurs to
you to type Alt+Shift+8? Or would you go for Alt+ж, since ж is where ; is on
the US keyboard? Should we accept both?
-- More generally, does this need to be done just for the alphabetic
characters, or does punctuation need to be handled too? Looking at the
Russian key layout, there’s no way to type `, ^, $, so I suspect you’re
going to answer “yes” to me on that.
-- When I switch to the Russian layout in software, and type C-ч и to call
“switch-to-buffer” , I then need to switch the keyboard layout back if I am
to type *scratch*, which I frequently want to do. Is there a reasonable
thing we can do there that doesn’t make it necessary to switch layout?
Accepting “;ыскфеср;” as an equivalent buffer name for “*scratch*” doesn’t
really seem like a great idea to me; maybe you _wanted_ to create a buffer
with that name. I frequently create buffers named fdlsfdsfds and variations
on that, for example.
Further, my implementation doesn’t handle shifted characters and I realise
now that’s not good enough. Must fix it!
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
11:01 p.m.
New subject: thoughts on interaction of key bindings and input methods (was Re: wish: right alt/meta to switch keyboard layout while pressed)
Aidan Kehoe wrote:
[CCing XEmacs Beta, because despite it originating at emacs-devel(a)gnu.org,
this isn’t directly relevant to the FSF’s Emacs any more, but there’s more
value in keeping it visible than in keeping it in private mail.]
OK, I'll also CC it back to GNU Emacs' list for the same reason.
[...]
>
> Sorry, I'm on dial-up and I don't think I want to download megabytes just
> to test it. I use GNU Emacs normally.
Sure. I hope you don’t mind if I ask you a few specific questions then --
Sure.
-- If you see M-; listed as a key binding, is the first thing that
occurs to
you to type Alt+Shift+8? Or would you go for Alt+ж, since ж is where ; is on
the US keyboard? Should we accept both?
I can't say which would be the most natural thing to hit, because few apps
but Emacs use such extravagant shortcuts.
Maybe I'd say like this: if an application uses _localized shortucts_ (i.e.
is filled with things like `Ctrl-Щ' and stuff), I'd go for `Alt-Shift-8',
else
`Alt-ж' i.e. `Alt-;' on English layout. Since Emacs is not localized in this
way (and cannot and mustn't be, I think), typing `M-ж' for `M-;' is probably
more natural.
Localized key bindings are impossible for Emacs, since you cannot type say ']'
with the Russian keyboard layout. So, the only option is to type `C-]' as
it is on English layout, which implies you must type all the other shortcuts
like this, for UI consistency and to avoid clashes.
-- More generally, does this need to be done just for the alphabetic
characters, or does punctuation need to be handled too? Looking at the
Russian key layout, there’s no way to type `, ^, $, so I suspect you’re
going to answer “yes” to me on that.
I cannot answer `yes' to an `or' question ;) Based on what I stated above,
I'd say that all shortcuts, in Emacs at least, must be invariant to physical
keys, not to logical characters the keys produce with the current input
method/layout.
This is probably also better ergonomically, since for power users (like me ;)
key binding combos slip into subconsciousness. I don't think my internal
autopilot performs a ``hold the Meta key and type the semicolon, wherever it
is'' command, rather a ``press the key here with the left thumb, and another
one there with the third right finger.'' If it indeed works like that,
shortcuts staying at the same physical keys require less effort to memorize/
push into subconsciousness.
-- When I switch to the Russian layout in software, and type C-ч и to
call
“switch-to-buffer” , I then need to switch the keyboard layout back if I am
to type *scratch*, which I frequently want to do. Is there a reasonable
thing we can do there that doesn’t make it necessary to switch layout?
Accepting “;ыскфеср;” as an equivalent buffer name for “*scratch*” doesn’t
really seem like a great idea to me; maybe you _wanted_ to create a buffer
with that name. I frequently create buffers named fdlsfdsfds and variations
on that, for example.
Accepting `;ыскфеср;' as `*scratch*' won't work as a generic solution for
the reason you mentioned. It may be an optional heuristic, turned off by
default. There were some interesting programs for Windows that would
automagically switch the layout for you once you had started typing gibberish
in the current layout. I.e. if you typed ``Heccrbq'', it would consider it
too weird an English word, backspace it and retype in Russian layout as
``Русский''. Likewise, it would automagically switch to English layout if
you typed ``щчньщкщт'' instead of ``oxymoron''. However, such
heuristical
things often work incorrectly with artificial languages, like programming
ones, and must never be forced on the user.
The only plausible generic solution I can think of is to track the layout for
each buffer separately. This may be very difficult to impossible to
implement with external layout switching. And that's precisely the reason
why I prefer to use Emacs' own input methods switched by `C-\'. This means
that I have to use different layout switching methods in Emacs and elsewhere,
but the advantages are more important for me.
Another, less important, superiority of Emacs input methods for me is the
ability to easily activate an otherwise not used input method. I
occasionally activate Greek and German input methods. With Emacs it is
relatively simple, while with say KDE it would mean that I'd have to either
constantly scroll through 4 layouts or go into the Conrol Center each time
I need one of the rarely used layouts.
Paul
1:48 a.m.
New subject: thoughts on interaction of key bindings and input methods (was Re: wish: right alt/meta to switch keyboard layout while pressed)
this is what i call the "russian c-x problem". at one point i had
worked out what the correct thing to do is, and there are various
comments to this effect in XEmacs; but i never finished it. it looks
like aidan went ahead and implemented it, though, right, aidan?
in events.h we have:
enum alternative_key_chars
{
KEYCHAR_CURRENT_LANGENV,
KEYCHAR_DEFAULT_USER,
KEYCHAR_DEFAULT_SYSTEM,
KEYCHAR_UNDERLYING_VIRTUAL_KEY_CURRENT_LANGENV,
KEYCHAR_UNDERLYING_VIRTUAL_KEY_DEFAULT_USER,
KEYCHAR_UNDERLYING_VIRTUAL_KEY_DEFAULT_SYSTEM,
KEYCHAR_QWERTY,
KEYCHAR_LAST
};
struct Lisp_Key_Data
{
#ifdef EVENT_DATA_AS_OBJECTS
struct lrecord_header lheader;
#endif /* EVENT_DATA_AS_OBJECTS */
/* What keysym this is; a character or a symbol. */
Lisp_Object keysym;
/* Modifiers held down when key was pressed: control, meta, etc.
Also includes buttons. For many keys, Shift is not a bit; that
is implicit in the keyboard layout. */
int modifiers;
/* Alternate character interpretations for this key in different
keyboard layouts. This deals with the problem of pressing C-x in
the Russian layout (the so-called "Russian C-x problem"), for
example: `x' gets mapped to a Cyrillic character, so what do we
do? For that matter, what about `C-x b'? What we do is look the
key up in the default locales (current language environment, user
default, system default), then check to see if the underlying
virtual key is alphabetic in the same three defaults, then
finally check US ASCII. We ignore the underlying virtual key for
the current layout to avoid the problem of a French speaker
(AZERTY layout) who temporarily switches to Russian: The virtual
keys underlying Russian are US-ASCII, so what the French speaker
things of as C-a (the key just to the right of TAB) appears as
C-q.
I've just implemented this in event-stream.c, and I really want to
see feedback from actual Russians about it, and whether it needs to
be much more complete than what I've done. E.g, the mapping back to
US Qwerty is hardcoded on the X11 side of things, and only deals
with the alphabetic characters.
Also, I think it's downright confusing for people with Roman
letters on their keyboard to have random other letters than are
described as calling some command, call that command. So I want to
consider enabling it by language environment.
[[ (#### We should probably ignore the current char and look
*ONLY* in alt_keychars for all control keys. What about the
English speaker who temporarily switches to the French layout and
finds C-q mapped to C-a?) ]]
No, we shouldn't. People who use the French layout expect that
pressing control with the key to the right of tab passes C-a to
emacs; English speakers (more exactly, Qwerty users) who
temporarily switch to the French layout encounter that issue in
every other app too, and they normally remap the keyboard in
software as soon as they can, or learn to live with Azerty. That
applies for all the Roman-alphabet keyboard layouts. Aidan Kehoe,
2005-05-15
I've taken out the dependency on MULE for this feature because it's
also useful in a non-Mule XEmacs where the user has set their font
to something ending in iso8859-5. How many of those users there
are, is another question. */
Ichar alt_keychars[KEYCHAR_LAST];
};
the first level of indenting in the comments is from me; stuff i wrote
back in 2001 or so. the second level is from aidan. what i wrote is
heavily based on microsoft's ui style guide, as they have a long
discussion of this issue.
note also that this algorithm *does* use the locale of the current
buffer; this is certainly possible under windows, where there is an
explicit api to query both the physical and logical keyboard.
it also seems that alphabetic and non-alphabetic keys should (perhaps)
behave differently.
now, from personal experience: i have had many times when i've been in
foreign countries and had to log on to the internet. typically, the
punctuation is in a completely different place. i always switched to us
layout, and found it nearly impossible to use any other layouts. i
*definitely* would expect in such a case that keyboard shortcuts
involving punctuation should follow the logical, not physical, layout --
but with the physical layout as a backup, so when i temporarily switch
to russian, i can still type C-x. (with alphabetic keys, it is
semi-feasible to search the keyboard in front of me to find the keys,
but this is just impossible for punctuation.)
ben
Paul Pogonyshev wrote:
Aidan Kehoe wrote:
>[CCing XEmacs Beta, because despite it originating at emacs-devel(a)gnu.org,
>this isn’t directly relevant to the FSF’s Emacs any more, but there’s more
>value in keeping it visible than in keeping it in private mail.]
>
>
OK, I'll also CC it back to GNU Emacs' list for the same reason.
>[...]
> >
> > Sorry, I'm on dial-up and I don't think I want to download megabytes
just
> > to test it. I use GNU Emacs normally.
>
>Sure. I hope you don’t mind if I ask you a few specific questions then --
>
>
Sure.
>-- If you see M-; listed as a key binding, is the first thing that occurs to
>you to type Alt+Shift+8? Or would you go for Alt+ж, since ж is where ; is on
>the US keyboard? Should we accept both?
>
>
I can't say which would be the most natural thing to hit, because few apps
but Emacs use such extravagant shortcuts.
Maybe I'd say like this: if an application uses _localized shortucts_ (i.e.
is filled with things like `Ctrl-Щ' and stuff), I'd go for `Alt-Shift-8',
else
`Alt-ж' i.e. `Alt-;' on English layout. Since Emacs is not localized in this
way (and cannot and mustn't be, I think), typing `M-ж' for `M-;' is probably
more natural.
Localized key bindings are impossible for Emacs, since you cannot type say ']'
with the Russian keyboard layout. So, the only option is to type `C-]' as
it is on English layout, which implies you must type all the other shortcuts
like this, for UI consistency and to avoid clashes.
>-- More generally, does this need to be done just for the alphabetic
>characters, or does punctuation need to be handled too? Looking at the
>Russian key layout, there’s no way to type `, ^, $, so I suspect you’re
>going to answer “yes” to me on that.
>
>
I cannot answer `yes' to an `or' question ;) Based on what I stated above,
I'd say that all shortcuts, in Emacs at least, must be invariant to physical
keys, not to logical characters the keys produce with the current input
method/layout.
This is probably also better ergonomically, since for power users (like me ;)
key binding combos slip into subconsciousness. I don't think my internal
autopilot performs a ``hold the Meta key and type the semicolon, wherever it
is'' command, rather a ``press the key here with the left thumb, and another
one there with the third right finger.'' If it indeed works like that,
shortcuts staying at the same physical keys require less effort to memorize/
push into subconsciousness.
>-- When I switch to the Russian layout in software, and type C-ч и to call
>“switch-to-buffer” , I then need to switch the keyboard layout back if I am
>to type *scratch*, which I frequently want to do. Is there a reasonable
>thing we can do there that doesn’t make it necessary to switch layout?
>Accepting “;ыскфеср;” as an equivalent buffer name for “*scratch*” doesn’t
>really seem like a great idea to me; maybe you _wanted_ to create a buffer
>with that name. I frequently create buffers named fdlsfdsfds and variations
>on that, for example.
>
>
Accepting `;ыскфеср;' as `*scratch*' won't work as a generic solution for
the reason you mentioned. It may be an optional heuristic, turned off by
default. There were some interesting programs for Windows that would
automagically switch the layout for you once you had started typing gibberish
in the current layout. I.e. if you typed ``Heccrbq'', it would consider it
too weird an English word, backspace it and retype in Russian layout as
``Русский''. Likewise, it would automagically switch to English layout if
you typed ``щчньщкщт'' instead of ``oxymoron''. However, such
heuristical
things often work incorrectly with artificial languages, like programming
ones, and must never be forced on the user.
The only plausible generic solution I can think of is to track the layout for
each buffer separately. This may be very difficult to impossible to
implement with external layout switching. And that's precisely the reason
why I prefer to use Emacs' own input methods switched by `C-\'. This means
that I have to use different layout switching methods in Emacs and elsewhere,
but the advantages are more important for me.
Another, less important, superiority of Emacs input methods for me is the
ability to easily activate an otherwise not used input method. I
occasionally activate Greek and German input methods. With Emacs it is
relatively simple, while with say KDE it would mean that I'd have to either
constantly scroll through 4 layouts or go into the Conrol Center each time
I need one of the rarely used layouts.
Paul
5:35 a.m.
New subject: thoughts on interaction of key bindings and input methods (was Re: wish: right alt/meta to switch keyboard layout while pressed)
On Sat, Nov 26, 2005 at 07:48:16PM -0600, Ben Wing wrote:
this is what i call the "russian c-x problem" [...]
Thanks, Ben. I was calling for 'more thought' and got a boatload full of
it, nearly more than I'm able to digest :-)
Regards
-- tomas
11:29 a.m.
New subject: thoughts on interaction of key bindings and input methods (was Re: wish: right alt/meta to switch keyboard layout while pressed )
Ben Wing wrote:
now, from personal experience: i have had many times when i've
been in
foreign countries and had to log on to the internet. typically, the
punctuation is in a completely different place. i always switched to us
layout, and found it nearly impossible to use any other layouts. i
*definitely* would expect in such a case that keyboard shortcuts
involving punctuation should follow the logical, not physical, layout --
but with the physical layout as a backup, so when i temporarily switch
to russian, i can still type C-x. (with alphabetic keys, it is
semi-feasible to search the keyboard in front of me to find the keys,
but this is just impossible for punctuation.)
I fail to see while it is impossible for punctuation, but here is my
reasoning. (I'm constantly referring to Russian layout since that's what
I use; I agree I'm somewhat biased because of this, since Russian uses a
different alphabet.)
Let's say we have punctuation following the logical layout, while the
alphabetical key bindings remain on physically the same keys. I won't
stress the consistency objection here, just the practical consequences
for a Russian layout users (must also apply to any layout with an
alphabet with more than 26 letters.)
According to your proposal, key binding for command `M-.' (find-tag)
will be on logical `M-.' in Russian layout, physically corresponding to
English `M-/'. Now, many variants of the Russian layout (including
Emacs' `russian-computer') don't have any way to type in the slash
except by using the keypad. So, the command `dabbrev-expand' (M-/)
becomes unavailable in Russian layout: there is no way to type that
logically. And if you type that as-in-English, it invokes `find-tag',
according to your proposal.
This is just one example. There are certainly more, involving such
key combinations like `M-^', `M-$' (which I use quite often) and others.
All these cannot be typed with Russian layout and their physical keys
clash with placement of punctuation on the Russian layout.
Physical correspondence with English layout (which, I think, is marked
on all keyboards, may be wrong here) is something all layouts have in
common. In all other aspects they have lots of differences, including
the location of keys corresponding to punctuation characters.
One not-yet-discussed possibility is to distinguish between layouts
for latin alphabet-based languages and all the rest (Cyrillic, Greek,
...) Since I only regularly use Russian and English layouts, maybe
someone using, say German or Swedish layouts, could comment on this.
Paul
6:35 p.m.
New subject: thoughts on interaction of key bindings and input methods (was Re: wish: right alt/meta to switch keyboard layout while pressed)
Ar an séú lá is fiche de mí na Samhain, scríobh Ben Wing:
this is what i call the "russian c-x problem". at one
point i had
worked out what the correct thing to do is, and there are various
comments to this effect in XEmacs; but i never finished it. it looks
like aidan went ahead and implemented it, though, right, aidan?
Yes. I’ve never tested the the Win32 support, though--it looks like your
implementation is complete, but I couldn’t say if it works or not.
[...] note also that this algorithm *does* use the locale of the
current
buffer; this is certainly possible under windows, where there is an
explicit api to query both the physical and logical keyboard.
The X11 side of things doesn’t. It just supplies Qwerty as an alternative.
Win32 locale support in general is much superior, and providing the same
level of functionality in pure X11 is just impossible. There is no locale ->
key layout mapping available, for a start.
it also seems that alphabetic and non-alphabetic keys should
(perhaps)
behave differently.
What I take from this response from Paul --
>>-- If you see M-; listed as a key binding, is the first thing
that
>>occurs to you to type Alt+Shift+8? Or would you go for Alt+ж, since ж
>>is where ; is on the US keyboard? Should we accept both?
>
>I can't say which would be the most natural thing to hit, because few apps
>but Emacs use such extravagant shortcuts.
is that we have to support this processing for punctuation as well as for
alphanumeric characters. If he doesn’t know which would be the most natural
thing to hit, then people in general will hit both, and as well as that,
lots of ASCII punctuation just isn’t available on a Russian keyboard. (This
position is different from what I thought when I implemented the X11 support
in the first place, btw.) It’s not that reasonable to make forward-word
available by default but not ispell-word, just because ispell-word uses the
dollar sign.
[..] (with alphabetic keys, it is semi-feasible to search the
keyboard in
front of me to find the keys, but this is just impossible for
punctuation.)
This is my experience too, strangely enough, since there’s no reasonable
ground for punctuation being much harder to find than letters.
Okay, I’ve just posted code to xemacs-patches(a)xemacs.org that takes into
account what Paul said, and moves the fallback mapping from raw X11 keycodes
to the US layout to hardware-specific Lisp, which is where it should be. I’d
love to have some commentary on it.
>The only plausible generic solution I can think of is to track
the
>layout for each buffer separately. This may be very difficult to
>impossible to implement with external layout switching. And that's
>precisely the reason why I prefer to use Emacs' own input methods
>switched by `C-\'. This means that I have to use different layout
>switching methods in Emacs and elsewhere, but the advantages are more
>important for me.
I get what you mean there; there are three or four input methods that I
regularly use, and being able to switch to a specific one with C-u C-\,
without messing around with character maps, makes my life significantly
easier. Indeed, I find myself typing IPA into XEmacs and pasting it into
other applications--admittedly I do use a local hack to get the glyphs to
display, so in general it’s not any better than GNU Emacs for this.
--
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.
3:49 a.m.
New subject: thoughts on interaction of key bindings and input methods
Removing emacs-devel, as I don't pretend to recommend what to do for
GNU Emacs. Feel free to quote me if you want to recommend it, though.
>>>> "Aidan" == Aidan Kehoe
<kehoea(a)parhasard.net> writes:
Aidan> The X11 side of things doesn’t. It just supplies Qwerty as
Aidan> an alternative. Win32 locale support in general is much
Aidan> superior, and providing the same level of functionality in
Aidan> pure X11 is just impossible. There is no locale -> key
Aidan> layout mapping available, for a start.
Today, "pure X11" can probably be taken to include the XKBD
extension. This should be capable of providing similar levels of
support. I don't promise it, but XKBD support is probably something
we should do anyway, so this is another reason to look at that.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:25 a.m.
New subject: thoughts on interaction of key bindings and input methods (was Re: wish: right alt/meta to switch keyboard layout while pressed)
Paul Pogonyshev wrote:
Ben Wing wrote:
>now, from personal experience: i have had many times when i've been in
>foreign countries and had to log on to the internet. typically, the
>punctuation is in a completely different place. i always switched to us
>layout, and found it nearly impossible to use any other layouts. i
>*definitely* would expect in such a case that keyboard shortcuts
>involving punctuation should follow the logical, not physical, layout --
>but with the physical layout as a backup, so when i temporarily switch
>to russian, i can still type C-x. (with alphabetic keys, it is
>semi-feasible to search the keyboard in front of me to find the keys,
>but this is just impossible for punctuation.)
>
>
I fail to see while it is impossible for punctuation
my experience was being in, e.g., thailand or morocco and trying to type
url's and passwords and such with punctuation in them. places like this
often type latin characters using the british or french or some other
european layout. the location of the punctuation was completely random
(from my perspective). characters like '＠' can often be typed only
using an AltGr combination. the keyboards often had multiple
punctuation labels on each key, in different colors, corresponding to
the different layouts that were most common. all of this made it just
impossible to locate punctuation using an unfamiliar layout.
it seems that we want to have some notion of "default" layout. in my
case, i want the default layout to be us, no matter what the physical
layout, but in your case you don't want things changing just because you
temporarily switched the layout to russian. but i don't know if there
is an easy solution for both cases.
ben
7:09 p.m.
New subject: thoughts on interaction of key bindings and input methods (was Re: wish: right alt/meta to switch keyboard layout while pressed)
Ben Wing wrote:
it seems that we want to have some notion of "default"
layout. in my
case, i want the default layout to be us, no matter what the physical
layout, but in your case you don't want things changing just because you
temporarily switched the layout to russian. but i don't know if there
is an easy solution for both cases.
There must be a misunderstanding. I'd like the keys (with modifiers) work
as if the current layout was English (US), no matter what the current
layout is. Without modifiers, they would of course insert the
corresponding character based on the current layout. Seems like we speak
of the same thing in different words, or, alternatively, I misunderstood
you this time :)
In fact, the internal Emacs input methods do just what I described. I
just checked that. As it was mentioned here, in German layout keys for
`z' and `y' are swapped relatively to the English layout. So, the key
labelled `z' on my keyboard would type `y' after `C-x RET C-\ german RET'.
However, combination `C-z' would still invoke `iconify-or-deiconify-frame',
not `yank'.
That's what I mean by physical vs. logical. It may blurry with different
alphabets, like Cyrillic. But with German it should be more
understandable: the key labelled `z' remains at physically the same
position no matter what layout I use. However, with German layout, the
logical key `z' swaps with logical key `y'.
So, to finally clarify my position: I want layouts switched with external
methods (`xkb') work just like Emacs internal input methods with regard
to key bindings.
Paul
6724
days inactive
6726
days old
8 comments
5 participants
participants (5)
-
Aidan Kehoe -
Ben Wing -
Paul Pogonyshev -
Stephen J. Turnbull -
Tomas Zerolo