> -----Original Message----- > From: Mark Lentczner [mailto:ma...@glyphic.com] > Sent: Friday, May 28, 2004 7:18 PM > To: perl6-langu...@perl.org > Subject: Re: Periodic Table of the Operators
> Not to beat a dead horse, but....
> I've updated the Periodic table with almost all the changes that people > here sent me, as well as reading a few more threads and references. > This will be the last update for some time
> How are those without a US keyboard supposed to type this?
Probably the same way as those with US keyboards do -- US keyboards don't have a yen symbol on them either.
In 'Vim' I got lucky in guessing it first time as Ctrl+K Y e. On Windows you can probably press Alt Gr then type in some number. Or pick it from the character map utility. Or keep Joe's mail handy so that you can copy and paste it whenever you need it.
Or spell it out as zip and not use the operator form ...
> >>How are those without a US keyboard supposed to type this?
I assume you mean "with" a US keyboard? US keyboards don't have ¥. You can use " zip " if you want ASCII. Otherwise, it depends. But Yen is Unicode codepoint U+00A5 = 165 decimal, so you can type it in Windows as ALT + numpad 0165 even without any international keyboard layout. If you use vim, then you can use control-V (control-Q on Windows) 1 6 5 (or u 0 0 a 5), or the Ye digraph (control-K Y e, or, if you have the digraph option set, Y<backspace>e).
On Sat, 2004-05-29 at 19:04, Gabriel Ebner wrote: > Hello,
> Joe Gottman wrote: > > The zip operator is now the Yen sign (¥).
> How are those without a US keyboard supposed to type this?
Well, first off my US keyboard doesn't contain it. Second, you're not supposed to. ¥ is a shorthand for "zip", and if you don't want to use the funky one-character operator, just use the afunked three-character one.
-- Aaron Sherman <a...@ajs.com> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
I suspect there are more than a "few". I don't think there's anything constitutional about folks who like Emacs that prevents them from liking Perl or vice-versa. Even though (e)lisp is about as orthogonal as you can get and therefore something of a philosophical opposite to Perl. :)
Since you've added « and » to the list above, I'll add them as well:
Details again: you can always enter chars into Windows by holding down the ALT key and typing 0 plus the decimal code point on the numeric keypad, or into Vim by hitting control-V (control-Q in vim on Windows, since control-V is Paste) followed by either the decimal code point (no leading 0) or the letter u plus the hexadecimal code point. Vim digraphs are entered via control-K plus the two characters, or by setting the 'digraph' option and then typing the two characters separated by a backspace.
On Tue, Jun 01, 2004 at 04:21:14PM -0400, Mark J. Reed wrote: > Since you've added ? and ? to the list above, I'll add them as well:
What's so hard to type about the question mark? And what's so significant that you added it twice?
OK, so I know that you really meant to type <some bizarre character> and <some other bizarre character>.
This is what is so wrong about allowing unicode operators - yes, I don't need to write them, but if some other programmer writes one I have to be able to read it. And I can't.
> This is what is so wrong about allowing unicode operators - yes, I don't > need to write them, but if some other programmer writes one I have to be > able to read it. And I can't.
Well, for one thing, just because your email program doesn't let you display them, that doesn't mean you can't see them in your text editor. If I sent you a Perl program as an attachment I'm sure the "bizarre" characters would come through fine.
And for another thing, what bizarre email system are you using that in 2004 can't even handle Latin-1? It's not like they were something from way out in Unicodespace, nor was the message UTF8-encoded; just plain old, garden variety, 8-bpc ISO-8859-1. They were, incidentally, the guillemets; « = left-pointing (<<) and » = right-pointing (>>).
Mark J. Reed wrote: > On 2004-06-07 at 21:33:03, David Cantrell wrote: >>This is what is so wrong about allowing unicode operators - yes, I don't >>need to write them, but if some other programmer writes one I have to be >>able to read it. And I can't. > Well, for one thing, just because your email program doesn't let you display > them, that doesn't mean you can't see them in your text editor. If I > sent you a Perl program as an attachment I'm sure the "bizarre" > characters would come through fine.
The data in the file would, of course, be preserved, but that doesn't mean I could read it. Like when I was writing my earlier mail.
> And for another thing, what bizarre email system are you using that in > 2004 can't even handle Latin-1?
My console can be any of several platforms - in the last couple of weeks it has been a Linux box, a Windows PC, a Mac, a Sun workstation, and a real vt320 attached to a Sun. My mail sits on a hosted Linux box. To read it, I sometimes ssh in to the machine and read it using mutt in screen. At other times I read it using Mozilla Thunderbird over IMAP. In Thunderbird, the odd characters show up. But when I'm using a terminal session, I have found that the only practical way of getting consistent behaviour wherever I am is to use TERM=vt100. Windows is, of course, the main culprit in forcing me to vt100 emulation.
On Mon, Jun 07, 2004 at 10:52:32PM +0100, David Cantrell wrote:
> My console can be any of several platforms - in the last couple of weeks > it has been a Linux box, a Windows PC, a Mac, a Sun workstation, and a > real vt320 attached to a Sun. My mail sits on a hosted Linux box. To > read it, I sometimes ssh in to the machine and read it using mutt in > screen. At other times I read it using Mozilla Thunderbird over IMAP. > In Thunderbird, the odd characters show up. But when I'm using a > terminal session, I have found that the only practical way of getting > consistent behaviour wherever I am is to use TERM=vt100. Windows is, of > course, the main culprit in forcing me to vt100 emulation.
On Tue, Jun 08, 2004 at 11:30:51AM +0100, Tim Bunce wrote: > On Mon, Jun 07, 2004 at 10:52:32PM +0100, David Cantrell wrote: > > But when I'm using a > > terminal session, I have found that the only practical way of getting > > consistent behaviour wherever I am is to use TERM=vt100. Windows is, of > > course, the main culprit in forcing me to vt100 emulation. > I can recommend PuTTY for windows. Secure, small[1], fast, featureful > and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ > I'm using it now to ssh from a windows laptop to read email using > mutt in screen.
I can get it working with a Windows client, or a Mac client, or a $other_client, but I could never find any combination of voodoo that would work with *all* clients, so that I can disconnect (while leaving mutt running) then reconnect some random time later on some other platform and have it Just Work and have odd characters show up correctly. TERM=vt100 was the only way to get consistent results. Yes, I tried putty. I also tried cygwin/xfree86/xterm/openssh, to no avail.
> On Tue, Jun 08, 2004 at 11:30:51AM +0100, Tim Bunce wrote: > > On Mon, Jun 07, 2004 at 10:52:32PM +0100, David Cantrell wrote: > > > But when I'm using a > > > terminal session, I have found that the only practical way of getting > > > consistent behaviour wherever I am is to use TERM=vt100. Windows is, of > > > course, the main culprit in forcing me to vt100 emulation. > > I can recommend PuTTY for windows. Secure, small[1], fast, featureful > > and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ > > I'm using it now to ssh from a windows laptop to read email using > > mutt in screen.
> I can get it working with a Windows client, or a Mac client, or a > $other_client, but I could never find any combination of voodoo that > would work with *all* clients, so that I can disconnect (while leaving > mutt running) then reconnect some random time later on some other > platform and have it Just Work and have odd characters show up correctly. > TERM=vt100 was the only way to get consistent results. Yes, I tried > putty. I also tried cygwin/xfree86/xterm/openssh, to no avail.
isn't that what 'screen' is for?
--8<--- man screen
SCREEN(1) SCREEN(1)
NAME screen - screen manager with VT100/ANSI terminal emulation
DESCRIPTION Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC VT100 terminal and, in addition, sev- eral control functions from the ISO 6429 (ECMA 48, ANSI X3.64) and ISO 2022 standards (e.g. insert/delete line and support for multiple character sets). There is a scroll- back history buffer for each virtual terminal and a copy- and-paste mechanism that allows moving text regions between windows.
When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out : : -->8---
-- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i, AIX 4.3, SuSE 9.0, and Win2k. http://www.cmve.net/~merijn/ http://archives.develooper.com/daily-bu...@perl.org/ perl...@perl.org send smoke reports to: smokers-repo...@perl.org, QA: http://qa.perl.org
> I can recommend PuTTY for windows. Secure, small[1], fast, featureful > and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ > [1] So small it easily fits on a floppy. I keep a copy on my USB memory drive.
So small that even on modem lines, you can afford to download it each time you start it: http://startputty.com/ - if you trust them.
On Sun, May 30, 2004 at 03:33:34PM +0000, Smylers wrote: > Gabriel Ebner writes:
> > Joe Gottman wrote:
> > > The zip operator is now the Yen sign (¥).
> > How are those without a US keyboard supposed to type this?
> Probably the same way as those with US keyboards do -- US keyboards > don't have a yen symbol on them either.
> In 'Vim' I got lucky in guessing it first time as Ctrl+K Y e. On > Windows you can probably press Alt Gr then type in some number. Or > pick it from the character map utility. Or keep Joe's mail handy so > that you can copy and paste it whenever you need it.
> Or spell it out as zip and not use the operator form ...
> Smylers
What advantages have to use characters not in standard keyboards? Isn't it a little scary?
Regards.
-- Pedro Larroy Tovar | Linux & Network consultant | piotr%member.fsf.org
On Sun, Jun 13, 2004 at 03:40:27AM +0200, Pedro Larroy wrote: > What advantages have to use characters not in standard keyboards? Isn't > it a little scary?
Well, what do you consider a 'standard' keyboard? The zip operator/Yen sign probably appears on most keyboards in Japan, but on very few in the US. My US keyboard gives me no convenient way to type a 'u with umlaut' character, but I'm sure that my friend Roland, who lives in Switzerland, has no such limitation.
Like it or not, Unicode is the way of the future. Life really and truly will be easier once that becomes the default assumption; keyboard makers will start putting thought into how to provide easy access to normally-unused-in-this-locale characters, software will have to make it easy to work with foreign character sets, your terminal will not give you grief about displaying foreign characters, etc.
But it's kind of a chicken-and-egg problem. If the characters are never used, we don't need to worry about them--except when we do. So, by making them more commonly used, we help bring about the day when we don't need to worry about them.
And if you aren't ready to worry about them yet, I believe they all have ASCII equivalents (e.g., >>, <<, and zip).
[Pedro == pi...@larroy.com on Sun, 13 Jun 2004 03:40:27 +0200]
Pedro> What advantages have to use characters not in standard Pedro> keyboards?
Flexibility. Stylistic choice. There is More Than One Way To Do It. Power. Expressiveness.
Everything that makes Perl good.
Pedro> Isn't it a little scary?
Yes, very. Great phrasing.
Scary enough that this same question will continue to be asked over and over and over. You're not the only one afraid, believe me.
The "unicode operator" issue boils down to "even if you can't picture using it yourself, there are lots of people who can find good uses for it. And they should be allowed to do so if they wish."
It's extremely unlikely I personally will use Unicode operators in my code. I haven't yet seen an example presented where using a Unicode operator would save keystrokes, for instance. And it will likely be easier for me to remember the "long" ASCII versions of any "short" Unicode operators.
But it would be selfish and shortsighted to try to force that choice onto everyone.
Yes, fragmentation may occur. You may occasionally get P6 code that was written with a Unicode operator or two. You may have to pipe the code through a standard "p6unicode2p6ascii" program to read and/or edit it properly. But realistically, it's likely the community is unlikely to use them widely and the defacto standard in public code will be to stick with ASCII. If that doesn't happen, it will be a good sign that there was actually great pent-up demand for Unicode operators and people are glad they are around.
The only thing we have to fear (from the mere availability of Unicode operators) is fear itself.
Jared Rhine wrote: >I haven't yet seen an example presented where using a Unicode >operator would save keystrokes, for instance.
That depends entirely on how you plan to generate them. If you are relying on a special command in your editor of choice, yes, the ASCII equiv is fewer keystrokes. If, however, you remap your keyboard (easily doable in X and Win32, I'd assume Macs can as well), then the common Unicode characters are an AltGr away. Thus, « one shifted keystroke (AltGr-[), << is two shifted keystrokes (Shift-, Shift-,).
[Rod == r...@rodadams.net on Sun, 13 Jun 2004 11:10:34 -0500]
Jared> I haven't yet seen an example presented where using a Unicode Jared> operator would save keystrokes, for instance.
Rod> That depends entirely on how you plan to generate them. If you Rod> are relying on a special command in your editor of choice, yes, Rod> the ASCII equiv is fewer keystrokes. If, however, you remap your Rod> keyboard (easily doable in X and Win32, I'd assume Macs can as Rod> well), then the common Unicode characters are an AltGr Rod> away. Thus, « one shifted keystroke (AltGr-[), << is two shifted Rod> keystrokes (Shift-, Shift-,).
Ok. A reasonable point that hasn't been made yet in this multi-month discussion. It'll never actually "save" me characters, however; the most I'll achieve is parity.
I'll be more likely to remap MyMod-> to the macro '>>' than that similar-looking Unicodey character I don't know (or care) how to make yet. And MyMod-Y to expand to 'zip', not <Unicode Yen>.
Presumably, the argument for Unicode operators needs to (and does) go deeper than "saving keystrokes". TIMTOWTDI is the best argument I've seen thus far, with this little keyboard remapping discussion as an excellent example.
