If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#256
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
Smokey Joe
news 07:01:40 GMT in alt.windows7.general, wrote: You have to understand something. If *you* had introduced SMB to the discussion, Lewis would have accused you of moving the goalposts, but since it was he who widened the scope, your objections are "myopic in the extreme". Pretty amazing, but it's what he does. We see it here in the mac groups on a regular basis. I've learned a bit about some of the posters I had no prior interaction with, until a short time ago. -- To prevent yourself from being a victim of cyber stalking, it's highly recommended you visit he https://tekrider.net/pages/david-brooks-stalker.php ================================================== = Fidelity: A virtue peculiar to those who are about to be betrayed. |
Ads |
#257
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
Lewis
Wed, 03 Jan 2018 14:22:39 GMT in alt.windows7.general, wrote: [snip] As far as i'm concerned, SMB is just an attempt to side track the original discussion. OK, I thought it was a natural evolution from saying "windows supports weird characters" because windows networking (which a whole lot of people use, often without knowing it) does not support it. Think it more as a warning for a passing reader. A passing reader is most likely not going to opt for using characters available in extended ascii to name files. Who wants to hold down alt while they hit the numeric keypad for each character, or, write a tiny program (or large I suppose, depending on language/compiler used) to do it for them? What gain would they get by doing so? Some parts of the Windows OS as a whole do, yes. The OS itself for the most part, does not. Not sure what distinction you are making there. Windows will not allow you to name a file with any of " / \ ? * | (yes, quote is a forbidden character). You also cannot use '..' in any part of a filename. You also cannot use NULL or any ASCII character with a value under 32 (decimal). NULL cannot be used as the first letter because it's reserved for deleted files. ascii characters under the value of 32 decimal are not extended ascii. Many of those are control codes from decades gone by. As you stated, Windows isn't going to let you use pipes, paths, or wildcard statements as part of a filename. And it wouldn't make any sense to me for it to do so. Nor would it allow '..' as that's already known to be traverse one folder up. I fail to see what the examples you've provided have to do with the discussion? The list of forbidden characters on Unix is "/" and the list of forbidden characters on macOS is ":", and neither OS will complain about a file ending in a . and, as far as I know, neither has reserved filenames that you cannot use. If you end a file with a period on Windows, it's considered to have no extension. For GUI only people, that could be a problem. It's possible that null in the first position might be an issue, but it is not an issue within the filename. I did state you couldn't use it as the first character. For what should be an obvious reason. It is an issue when it's a list of characters you have to remember, all of which would reasonably be useful in a filename/folder name. Invoices 2010 Invoices 01/2012 Photos 12:00-13:00 "Weird" Al Yankovic/ *** Important Docs ||| Temporary Trash Final? Paper If ONE of those has to be worked around because of the OS, that's one thing, but when all of them are forbidden, it is an issue. It's an issue for you, apparently. Not for me or a slew of other Windows users out there. I treat the filename character limitations you seem to have a problem with the same way. I don't often find myself needing to use slashes to represent a date for example. periods work fine for that purpose. You've trained yourself to work around the limitations of Windows naming convention, that doens't make those limitations a good thing, it just means you've learned them. Actually, I didn't train myself to work around a Windows limitation. I wasn't using Windows yet. My first computer had issues with various types of 'illegal filenames' too and the old habits simply carried over with me. -- To prevent yourself from being a victim of cyber stalking, it's highly recommended you visit he https://tekrider.net/pages/david-brooks-stalker.php ================================================== = Use hope and imagination as weapons of survival and progress. |
#258
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Diesel
wrote: As far as i'm concerned, SMB is just an attempt to side track the original discussion. OK, I thought it was a natural evolution from saying "windows supports weird characters" because windows networking (which a whole lot of people use, often without knowing it) does not support it. Think it more as a warning for a passing reader. A passing reader is most likely not going to opt for using characters available in extended ascii to name files. Who wants to hold down alt while they hit the numeric keypad for each character, or, write a tiny program (or large I suppose, depending on language/compiler used) to do it for them? What gain would they get by doing so? they'd gain being able to use the correct characters for file names (or whatever else), such as maana or telfono. needing to use the numeric keypad to those characters is a windows shortcoming. on a mac, it's normally done either using the option key modifier (for usa keyboards) or it's an actual key (for international keyboards). for example: option-g option-2 option-p in recent versions of mac os x, holding down a key will show alternate choices when available (which can be disabled): https://support.apple.com/library/co...are/images/en_ US/osx/osx_tipyn_alternate_characters.png Some parts of the Windows OS as a whole do, yes. The OS itself for the most part, does not. Not sure what distinction you are making there. Windows will not allow you to name a file with any of " / \ ? * | (yes, quote is a forbidden character). You also cannot use '..' in any part of a filename. You also cannot use NULL or any ASCII character with a value under 32 (decimal). NULL cannot be used as the first letter because it's reserved for deleted files. ascii characters under the value of 32 decimal are not extended ascii. Many of those are control codes from decades gone by. not all file systems use null to mark a deleted file, including mac hfs. in classic mac os, null was valid in a file name and was sometimes used as the first character to force a file to alphabetically sort at the top, although that was considered to be a bad idea. using control characters was also valid. however, in mac os x, null is not valid. As you stated, Windows isn't going to let you use pipes, paths, or wildcard statements as part of a filename. And it wouldn't make any sense to me for it to do so. Nor would it allow '..' as that's already known to be traverse one folder up. I fail to see what the examples you've provided have to do with the discussion? that's because windows has a lot of limitations that don't exist on other systems. The list of forbidden characters on Unix is "/" and the list of forbidden characters on macOS is ":", and neither OS will complain about a file ending in a . and, as far as I know, neither has reserved filenames that you cannot use. If you end a file with a period on Windows, it's considered to have no extension. For GUI only people, that could be a problem. then that's a bug in whatever gui it is. on a mac, there is no issue with a file that ends in a . and it even knows what app to use when double-clicked. |
#259
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message Diesel wrote:
Lewis Wed, 03 Jan 2018 14:22:39 GMT in alt.windows7.general, wrote: [snip] As far as i'm concerned, SMB is just an attempt to side track the original discussion. OK, I thought it was a natural evolution from saying "windows supports weird characters" because windows networking (which a whole lot of people use, often without knowing it) does not support it. Think it more as a warning for a passing reader. A passing reader is most likely not going to opt for using characters available in extended ascii to name files. Who wants to hold down alt while they hit the numeric keypad for each character, Good point, I'd forgotten how arcane and terrible Windows method to access extra characters is. I have a friend named Zoë and one of her main complains about Windows (and a reason she uses is a Mac) is how difficult it is to type her name. Some parts of the Windows OS as a whole do, yes. The OS itself for the most part, does not. Not sure what distinction you are making there. Windows will not allow you to name a file with any of " / \ ? * | (yes, quote is a forbidden character). You also cannot use '..' in any part of a filename. You also cannot use NULL or any ASCII character with a value under 32 (decimal). NULL cannot be used as the first letter because it's reserved for deleted files. NULL cannot be used anywhere in a filename in Windows. ascii characters under the value of 32 decimal are not extended ascii. Many of those are control codes from decades gone by. Yes, and? As you stated, Windows isn't going to let you use pipes, paths, or wildcard statements as part of a filename. And it wouldn't make any sense to me for it to do so. Nor would it allow '..' as that's already known to be traverse one folder up. I fail to see what the examples you've provided have to do with the discussion? Windows has many restrictions on filenames that other OSes do not have. The list of forbidden characters on Unix is "/" and the list of forbidden characters on macOS is ":", and neither OS will complain about a file ending in a . and, as far as I know, neither has reserved filenames that you cannot use. If you end a file with a period on Windows, it's considered to have no extension. For GUI only people, that could be a problem. It's possible that null in the first position might be an issue, but it is not an issue within the filename. I did state you couldn't use it as the first character. For what should be an obvious reason. It is an issue when it's a list of characters you have to remember, all of which would reasonably be useful in a filename/folder name. Invoices 2010 Invoices 01/2012 Photos 12:00-13:00 "Weird" Al Yankovic/ *** Important Docs ||| Temporary Trash Final? Paper If ONE of those has to be worked around because of the OS, that's one thing, but when all of them are forbidden, it is an issue. It's an issue for you, apparently. Not for me or a slew of other Windows users out there. Many windows users run into these restrictions all the time and then have to think of a way to rename a filename on the spot from what they intended to something that the OS will allow. With the much larger number of forbidden characters, this happens a lot more on Windows. The ones I hear complaints most from office drones I support are the and ?. The one I had the most issues with myself when I was using Windows for more than the wintendo was the " since it was in many filenames, and all over my mp3s. But I think we've beaten reserved characters to death, at this point. -- Ille Qui Nos Omnes Servabit |
#260
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
Lewis
Thu, 04 Jan 2018 17:00:37 GMT in alt.windows7.general, wrote: A passing reader is most likely not going to opt for using characters available in extended ascii to name files. Who wants to hold down alt while they hit the numeric keypad for each character, Good point, I'd forgotten how arcane and terrible Windows method to access extra characters is. I have a friend named Zoë and one of her main complains about Windows (and a reason she uses is a Mac) is how difficult it is to type her name. She'd rather have to hold down option and enter a specific key to get the last character proper for her name? It's for proper pronunciation anyway, isn't it? Does it somehow make people unfamiliar with the proper way of doing that learn it? Some parts of the Windows OS as a whole do, yes. The OS itself for the most part, does not. Not sure what distinction you are making there. Windows will not allow you to name a file with any of " / \ ? * | (yes, quote is a forbidden character). You also cannot use '..' in any part of a filename. You also cannot use NULL or any ASCII character with a value under 32 (decimal). NULL cannot be used as the first letter because it's reserved for deleted files. NULL cannot be used anywhere in a filename in Windows. Well, actually, it can. But the file manager won't like you for doing it. The OS itself doesn't care, as long as the first character isn't a null. ascii characters under the value of 32 decimal are not extended ascii. Many of those are control codes from decades gone by. Yes, and? And what? You brought up the characters, I didn't. I was just informing you that they aren't extended ascii, so.. I didn't quite understand why you bothered with them? Btw, what you wrote isn't entirely true. You can use a few of the ones from the 32 or less set, but not all of them. The code for beep for example can be used, if you wish to be obnoxious. It's only useful tho if the person is doing a dir from console. The file manager won't beep at you when it displays the file. I just pulled my little chart up, there's actually more than a few you can use in a filename, but, you can't do it from a console prompt alone or file manager. I was actually bad about using two hidden spaces with a real space in between a folders 'extension' back in the day to make the folder unavailable to a normal user. DOS would claim it didn't exist. In fairness though, I didn't originate the idea, I stole it from some creative copy protection tricks I'd learned on a machine that I got before my first PC. When windows 95 came along though, the jig was up, it would enter those previously 'non existant' folders without a bit of trouble. Ah well, there's a time for everything and everything has a time limit, right? Hah, I just confirmed I can still use hiddenspace/space/hidden space in a filename/foldername on Windows XP. space btw, is character 32 on the ascii table. Hidden space is character 255. So when I opted to rename "work" to "work.hiddenspace/space/hiddenspace" it shows up in dir as "work." And if you click it in windows file manager, you can see it has a three character extension attached. Double clicking the file doesn't even bring up the window asking what you'd like to open it with though. I can copy/paste it from folder to folder with no issue. Let's try doing the same to a folder now. You can easily access it from console. Type test hit tab, it puts it in quotes; it appears to have three spaces for the extension. press enter. poof, you're in the folder. (drat). And you can do the same thing with file manager. double clicking (I have mine setup for double click) enters the folder, no problem. It just shows up as having three 'spaces' for the extension. One actually is space; character 32 (one you said I couldn't use rofl) and the other two aren't. I can even rename it, by entering test hitting tab and selecting a new name. ren doesn't even care I used an actual space as part of the filename. *shrug* Back in the days of real DOS though, this was an easy method for keeping directories off limits to most. As I said though, once windows95 came out, this little trick was over. As you stated, Windows isn't going to let you use pipes, paths, or wildcard statements as part of a filename. And it wouldn't make any sense to me for it to do so. Nor would it allow '..' as that's already known to be traverse one folder up. I fail to see what the examples you've provided have to do with the discussion? Windows has many restrictions on filenames that other OSes do not have. Windows can't allow you to use those characters due to backwards compatability from the days of DOS which actually did have them reserved. Since NTFS opted to support previous DOS/Windows shell environments, they had no choice. But I think we've beaten reserved characters to death, at this point. I suppose so. -- To prevent yourself from being a victim of cyber stalking, it's highly recommended you visit he https://tekrider.net/pages/david-brooks-stalker.php ================================================== = To be, or not to be. *BOOM!* Not to be. |
#261
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
nospam
Thu, 04 Jan 2018 04:47:49 GMT in alt.windows7.general, wrote: needing to use the numeric keypad to those characters is a windows shortcoming. A windows shortcoming? You don't actually need to use the numeric keypad, you do have other ways of selecting the extended ascii characters if one so desired. But the point remains, what normal user is going to search for characters that aren't shown on their keyboards? How many normal users even know there's 255 characters in the ASCII table in the first place? Of those, how many do you suppose know that the first 32 or so are actually relics from decades gone by? on a mac, it's normally done either using the option key modifier (for usa keyboards) or it's an actual key (for international keyboards). for example: option-g option-2 option-p Okay, so you can press two keys instead when if using the alt method on Windows, I have to press a total of four. Alt and the corresponding keycode representing the ascii character. like (that's alt 225). Does each character on a mac keyboard generate an extended ascii key if pressed in the combination you're using? For me, I can bring up a simple 'chart' to see all the characters along with their corresponding codes, so I don't have to memorize each option+character to do it. NULL cannot be used as the first letter because it's reserved for deleted files. ascii characters under the value of 32 decimal are not extended ascii. Many of those are control codes from decades gone by. not all file systems use null to mark a deleted file, including mac hfs. I didn't say all files systems used null to mark a file as deleted. DOS/Windows do. It was also used on the color computer family, and, I think (but not for certain) the old commodores. I don't know if Atari and amiga used the same one then or not. however, in mac os x, null is not valid. So it's a reserved character then? Not that it really matters, most end users aren't going to be using null. Obviously. As you stated, Windows isn't going to let you use pipes, paths, or wildcard statements as part of a filename. And it wouldn't make any sense to me for it to do so. Nor would it allow '..' as that's already known to be traverse one folder up. I fail to see what the examples you've provided have to do with the discussion? that's because windows has a lot of limitations that don't exist on other systems. Those aforementioned limitations predate Windows by several years. Windows provides backward compatability to a point and that's why those reserved characters are still present today. They come from the days of DOS and OS's very similiar to DOS, but, not being DOS as you know it on the PC platform. Due to backwards compatability, it's necessary for Windows to follow certain rules setup long before it existed. Had MS not concerned themselves with that and were willing to leave hundreds of thousands of programs out in the cold, when they went to the first version of NTFS since it emulates some DOS functionality, they could have overhauled the underlying file system entirely then and freed those characters up. But, they chose to continue supporting older code from Dos and prior iterations of Windows to a point, and had no choice but to continue emulating the old style file system that had those restrictions in the first place. They couldn't have done this with the Windows 9x flavor as those actually were still glorified shells built on top of DOS, NTFS was an entirely different creature and didn't have to follow the old file system format/layout or anything else. If it didn't, it would have tossed many programs out in the cold and probably hurt NTFS adoption as a result. Os/2 (an IBM system that MS was a partner with at one point) had the same issues and decisions to make. They too opted to support the older stuff so kept the 'file system' those programs knew available to them. And thus, the limitations. The list of forbidden characters on Unix is "/" and the list of forbidden characters on macOS is ":", and neither OS will complain about a file ending in a . and, as far as I know, neither has reserved filenames that you cannot use. If you end a file with a period on Windows, it's considered to have no extension. For GUI only people, that could be a problem. then that's a bug in whatever gui it is. It's not a bug. It's an association issue. For the most part, Windows associates extensions with the app chosen to open them, unless it examines the file header when you opt to open it and chooses the best program based on the file header. .reg is associated with registry editor, for example. on a mac, there is no issue with a file that ends in a . and it even knows what app to use when double-clicked. A mac stores this information elsewhere as meta data. It's just not as straight forward as Windows is concerning file associations. -- To prevent yourself from being a victim of cyber stalking, it's highly recommended you visit he https://tekrider.net/pages/david-brooks-stalker.php ================================================== = 'There is no cause for alarm! ... But there probably will be.' - Brain |
#262
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Diesel
wrote: needing to use the numeric keypad to those characters is a windows shortcoming. A windows shortcoming? You don't actually need to use the numeric keypad, you do have other ways of selecting the extended ascii characters if one so desired. But the point remains, what normal user is going to search for characters that aren't shown on their keyboards? the ones that want their text to look correct. also no searching is required. nearly all are intuitively obvious: shift-4 $, option-4 option-= option-/ the keyboard layout can als be changed to include them, with either a keyboard cover (cheap) or an actual foreign keyboard. for example, a spanish keyboard: https://d25rq8gxcq0p71.cloudfront.ne.../int%20keyboar d.jpg How many normal users even know there's 255 characters in the ASCII table in the first place? Of those, how many do you suppose know that the first 32 or so are actually relics from decades gone by? they don't need to know any of that and macs use unicode wherever possible. what users need to know is how to type or whatever other characters they want. on a mac, it's normally done either using the option key modifier (for usa keyboards) or it's an actual key (for international keyboards). for example: option-g option-2 option-p Okay, so you can press two keys instead when if using the alt method on Windows, I have to press a total of four. Alt and the corresponding keycode representing the ascii character. like (that's alt 225). it's one key & a modifier, no different than holding shift while typing 3 for #, or shift and = for +. your four keys are in sequence and far slower, plus it requires memorizing numbers for each character, which is absurd. Does each character on a mac keyboard generate an extended ascii key if pressed in the combination you're using? most do, but not all. For me, I can bring up a simple 'chart' to see all the characters along with their corresponding codes, so I don't have to memorize each option+character to do it. that's also an option, but it's slower. it's useful for less commonly used characters, and there's a lot of them in unicode. https://i.stack.imgur.com/5Urmz.png NULL cannot be used as the first letter because it's reserved for deleted files. ascii characters under the value of 32 decimal are not extended ascii. Many of those are control codes from decades gone by. not all file systems use null to mark a deleted file, including mac hfs. I didn't say all files systems used null to mark a file as deleted. DOS/Windows do. It was also used on the color computer family, and, I think (but not for certain) the old commodores. I don't know if Atari and amiga used the same one then or not. it's still an incredibly dumb idea. however, in mac os x, null is not valid. So it's a reserved character then? Not that it really matters, most end users aren't going to be using null. Obviously. mac os x, with unix under the hood, uses c strings, where null indicates the end of a string. therefore null *can't* be part of a string. classic mac os mostly used pascal strings, where the first character of a string is a length byte, leaving the rest of the string to be *any* character, including null. there was no issue with a file name that had one or more nulls. it was not a good idea, but it definitely did work, along with control characters. As you stated, Windows isn't going to let you use pipes, paths, or wildcard statements as part of a filename. And it wouldn't make any sense to me for it to do so. Nor would it allow '..' as that's already known to be traverse one folder up. I fail to see what the examples you've provided have to do with the discussion? that's because windows has a lot of limitations that don't exist on other systems. Those aforementioned limitations predate Windows by several years. Windows provides backward compatability to a point and that's why those reserved characters are still present today. They come from the days of DOS and OS's very similiar to DOS, but, not being DOS as you know it on the PC platform. Due to backwards compatability, it's necessary for Windows to follow certain rules setup long before it existed. in other words, carrying on the mistakes of the past. The list of forbidden characters on Unix is "/" and the list of forbidden characters on macOS is ":", and neither OS will complain about a file ending in a . and, as far as I know, neither has reserved filenames that you cannot use. If you end a file with a period on Windows, it's considered to have no extension. For GUI only people, that could be a problem. then that's a bug in whatever gui it is. It's not a bug. It's an association issue. For the most part, Windows associates extensions with the app chosen to open them, unless it examines the file header when you opt to open it and chooses the best program based on the file header. .reg is associated with registry editor, for example. if the user renames a file causing it to lose its association, it's a bug. simple as that. on a mac, that doesn't happen. on a mac, there is no issue with a file that ends in a . and it even knows what app to use when double-clicked. A mac stores this information elsewhere as meta data. It's just not as straight forward as Windows is concerning file associations. it's actually very straightforward and was *well* ahead of its time. unfortunately, the rest of the world is fixated on extensions. |
#263
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Diesel
wrote: A passing reader is most likely not going to opt for using characters available in extended ascii to name files. Who wants to hold down alt while they hit the numeric keypad for each character, Good point, I'd forgotten how arcane and terrible Windows method to access extra characters is. I have a friend named Zoë and one of her main complains about Windows (and a reason she uses is a Mac) is how difficult it is to type her name. She'd rather have to hold down option and enter a specific key to get the last character proper for her name? It's for proper pronunciation anyway, isn't it? Does it somehow make people unfamiliar with the proper way of doing that learn it? it's for correct spelling and no more difficult to type than using shift to capitalize the first (or any other) character. |
#264
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On Fri, 05 Jan 2018 12:29:30 -0500, nospam
wrote: In article , Diesel wrote: A passing reader is most likely not going to opt for using characters available in extended ascii to name files. Who wants to hold down alt while they hit the numeric keypad for each character, Good point, I'd forgotten how arcane and terrible Windows method to access extra characters is. I have a friend named Zoë and one of her main complains about Windows (and a reason she uses is a Mac) is how difficult it is to type her name. She'd rather have to hold down option and enter a specific key to get the last character proper for her name? It's for proper pronunciation anyway, isn't it? Does it somehow make people unfamiliar with the proper way of doing that learn it? it's for correct spelling and no more difficult to type than using shift to capitalize the first (or any other) character. What do you know about using shift to capitalize? Have you ever done it? |
#265
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message Diesel wrote:
nospam Thu, 04 Jan 2018 04:47:49 GMT in alt.windows7.general, wrote: needing to use the numeric keypad to those characters is a windows shortcoming. A windows shortcoming? You don't actually need to use the numeric keypad, you do have other ways of selecting the extended ascii characters if one so desired. But the point remains, what normal user is going to search for characters that aren't shown on their keyboards? Zoë, Chloë, Anton*a, and the billions of people who don't speak English. for example: option-g © option-2 option-p ¼ Okay, so you can press two keys instead when if using the alt method on Windows, I have to press a total of four. And you have to memorize that 0163 means something and 1064 means something entirely different. option-e + a vowel puts an accute accent on the vowel. Option-u plus a vowel puts ü over the vowel. So I don't have to remember a different 4 digit code for ë and ü and ö. Alt and the corresponding keycode representing the ascii character. Which is an idiotic UI. For me, I can bring up a simple 'chart' to see all the characters along with their corresponding codes, so I don't have to memorize each option+character to do it. Yeah, that's a great solution. Bring up a chart. -- "He is simply a shiver looking for a spine to run up." - Paul Keating |
#266
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message Diesel wrote:
Lewis NULL cannot be used anywhere in a filename in Windows. Well, actually, it can. But the file manager won't like you for doing it. The OS itself doesn't care, as long as the first character isn't a null. Go tell microsoft they are wrong then. They specifically note that NULL is forbidden and also mention that all codes under ASCII(32) are forbidden. But I am sure you know better than Microsoft. And what? You brought up the characters, I didn't. I was just informing you that they aren't extended ascii Why the hell would I care if they extend ASCII? They are among the *many* characters that Windows forbids in filenames. what you wrote isn't entirely true. You can use a few of the ones from the 32 or less set, but not all of them. See above. Microsoft say you can't. -- You came in that thing? You're braver than I thought! |
#267
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
Lewis wrote:
But the point remains, what normal user is going to search for characters that aren't shown on their keyboards? Zoë, Chloë, Anton*a, and the billions of people who don't speak English. Plus anyone who needs to correspond with any European country other than the UK. Plus anyone who prefers to spell café or première, or talk about Cañada College rather than Canada College (or spell tennis-players' names correctly). option-e + a vowel puts an accute accent on the vowel. Option-u plus a vowel puts ü over the vowel. So I don't have to remember a different 4 digit code for ë and ü and ö. Exactly. Easy typing of accented characters was one of the three reasons I bought my first Mac in 1989 instead of a PC. (The second was Finale, which was then only available on the Mac. The third was HyperCard sigh) Paul Magnussen |
#268
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On Fri, 5 Jan 2018 20:50:54 -0000 (UTC), Lewis
wrote: In message Diesel wrote: nospam Thu, 04 Jan 2018 04:47:49 GMT in alt.windows7.general, wrote: needing to use the numeric keypad to those characters is a windows shortcoming. A windows shortcoming? You don't actually need to use the numeric keypad, you do have other ways of selecting the extended ascii characters if one so desired. But the point remains, what normal user is going to search for characters that aren't shown on their keyboards? Zoë, Chloë, Anton*a, and the billions of people who don't speak English. for example: option-g © option-2 ? option-p ¼ Okay, so you can press two keys instead when if using the alt method on Windows, I have to press a total of four. And you have to memorize that 0163 means something and 1064 means something entirely different. No, you don't. That's only one of several ways to get those characters, and perhaps the most difficult of them all. option-e + a vowel puts an accute accent on the vowel. Option-u plus a vowel puts ü over the vowel. There are many similar ways to do the same thing in Windows. As a single example, you might want to try Wincompose (https://github.com/samhocevar/wincompose) So I don't have to remember a different 4 digit code for ë and ü and ö. Alt and the corresponding keycode representing the ascii character. Which is an idiotic UI. I wouldn't call it "idiotic," but I agree that it's a poor way. Windows has another built-in way--the International Keyboard, but I think's also a poor way. Fortunately there are third-party alternatives that make it much easier. |
#269
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message Ken Blake wrote:
On Fri, 5 Jan 2018 20:50:54 -0000 (UTC), Lewis wrote: In message Diesel wrote: nospam Thu, 04 Jan 2018 04:47:49 GMT in alt.windows7.general, wrote: needing to use the numeric keypad to those characters is a windows shortcoming. A windows shortcoming? You don't actually need to use the numeric keypad, you do have other ways of selecting the extended ascii characters if one so desired. But the point remains, what normal user is going to search for characters that aren't shown on their keyboards? Zoë, Chloë, Anton*a, and the billions of people who don't speak English. for example: option-g © option-2 ? option-p ¼ Okay, so you can press two keys instead when if using the alt method on Windows, I have to press a total of four. And you have to memorize that 0163 means something and 1064 means something entirely different. No, you don't. That's only one of several ways to get those characters, and perhaps the most difficult of them all. Pray tell. option-e + a vowel puts an accute accent on the vowel. Option-u plus a vowel puts ü over the vowel. There are many similar ways to do the same thing in Windows. As a single example, you might want to try Wincompose (https://github.com/samhocevar/wincompose) Ah, installing other software? No, that's not "same thing in Windows" that is "You can make Windows suck less by getting third party software." -- I find Windows of absolutely no technical interest... Mac OS X is a rock -solid system that's beautifully designed. I much prefer it to Linux. -- Bill Joy |
#270
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On Fri, 5 Jan 2018 22:49:01 -0000 (UTC), Lewis
wrote: In message Ken Blake wrote: On Fri, 5 Jan 2018 20:50:54 -0000 (UTC), Lewis wrote: In message Diesel wrote: nospam Thu, 04 Jan 2018 04:47:49 GMT in alt.windows7.general, wrote: needing to use the numeric keypad to those characters is a windows shortcoming. A windows shortcoming? You don't actually need to use the numeric keypad, you do have other ways of selecting the extended ascii characters if one so desired. But the point remains, what normal user is going to search for characters that aren't shown on their keyboards? Zoë, Chloë, Anton*a, and the billions of people who don't speak English. for example: option-g © option-2 ? option-p ¼ Okay, so you can press two keys instead when if using the alt method on Windows, I have to press a total of four. And you have to memorize that 0163 means something and 1064 means something entirely different. No, you don't. That's only one of several ways to get those characters, and perhaps the most difficult of them all. Pray tell. option-e + a vowel puts an accute accent on the vowel. Option-u plus a vowel puts ü over the vowel. There are many similar ways to do the same thing in Windows. As a single example, you might want to try Wincompose (https://github.com/samhocevar/wincompose) Ah, installing other software? No, that's not "same thing in Windows" that is "You can make Windows suck less by getting third party software." Your choice entirely. Feel free to believe whatever you want. I won't argue with you. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|