Menu
▾
▴
alphacocoa-devel — AlphaCocoa Development List
You can subscribe to this list here.
| 2016 |
Jan
|
Feb
|
Mar
(12) |
Apr
(19) |
May
(60) |
Jun
(77) |
Jul
(23) |
Aug
(8) |
Sep
(28) |
Oct
(16) |
Nov
(95) |
Dec
(56) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2017 |
Jan
(127) |
Feb
(169) |
Mar
(59) |
Apr
(132) |
May
(27) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(15) |
Oct
(12) |
Nov
(15) |
Dec
(17) |
| 2018 |
Jan
|
Feb
(2) |
Mar
(25) |
Apr
(19) |
May
(28) |
Jun
(75) |
Jul
(48) |
Aug
|
Sep
(31) |
Oct
(26) |
Nov
(51) |
Dec
(82) |
| 2019 |
Jan
(46) |
Feb
(7) |
Mar
(8) |
Apr
|
May
(9) |
Jun
(8) |
Jul
(21) |
Aug
(30) |
Sep
(9) |
Oct
(16) |
Nov
(14) |
Dec
(23) |
| 2020 |
Jan
|
Feb
(6) |
Mar
|
Apr
(7) |
May
(47) |
Jun
(12) |
Jul
(7) |
Aug
(5) |
Sep
(4) |
Oct
(24) |
Nov
(15) |
Dec
(14) |
| 2021 |
Jan
(6) |
Feb
(5) |
Mar
(20) |
Apr
(6) |
May
(46) |
Jun
(17) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2025 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bernard D. <bde...@us...> - 2020-12-11 17:06:41
|
- **status**: fixed --> closed - **Version**: 9.1.3 --> 9.2 --- ** [tickets:#237] Adapt the size of the selected region when a search-and-replace reduce it** **Status:** closed **Created:** Wed Jul 15, 2020 12:22 PM UTC by Sylvain Loiseau **Last Updated:** Sat Oct 17, 2020 05:21 PM UTC **Owner:** nobody Suppose the following document, with six "\n\n" patterns: x x x z z z And suppose the six first lines (from the first "x" to the line before the first "z") selected. If I run "Search and replace", check "Only in selection", and replace "\n\n" by "\n", I reduce the number of lines in the region. However, the region selected by Alpha keep its previous size, and then now encompass lines with "z". This prevent me from applying a succession of string replacements that can change the region size. Maybe it's possible to have the replacement function track the number of lines added (or removed), and change the region size accordingly? Maybe it's not easy... All the best, Sylvain --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-12-11 17:06:28
|
- **status**: fixed --> closed - **Version**: 9.1.3 --> 9.2 --- ** [tickets:#239] pageHeader prints untitled instead of document title** **Status:** closed **Created:** Sat Sep 26, 2020 06:25 AM UTC by Bernard Desgraupes **Last Updated:** Fri Oct 16, 2020 08:18 AM UTC **Owner:** Bernard Desgraupes (This bug was reported by Burkhard Schmidt on AlphaTcl-User) After I turn on "Print Header" in Alpha's global preferences, indeed a nice header appears on each page printed. With one exception: The document name always is "Untitled" instead of (what I would naively expect) the file name of the document. Is there an easy way to get the document name into the header printed? --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-12-11 17:03:57
|
- **status**: open --> fixed --- ** [tickets:#242] Diff missing variable error when trying to run on Mac Catalina** **Status:** fixed **Created:** Tue Nov 17, 2020 11:22 PM UTC by Kathryn Hargreaves **Last Updated:** Fri Dec 11, 2020 05:03 PM UTC **Owner:** nobody When try to run on Mac 10.15.5 (19F101) Catalina on a Late 2012 Mac mini, get Diff error: variable not there. --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-12-11 17:03:52
|
This is the same issue as in Ticket #243. This is fixed now. Changes committed to the repository ([rev. 1985](https://sourceforge.net/p/alphacocoa/code/1985/)). The indices must be rebuilt. --- ** [tickets:#242] Diff missing variable error when trying to run on Mac Catalina** **Status:** open **Created:** Tue Nov 17, 2020 11:22 PM UTC by Kathryn Hargreaves **Last Updated:** Fri Dec 11, 2020 03:09 PM UTC **Owner:** nobody When try to run on Mac 10.15.5 (19F101) Catalina on a Late 2012 Mac mini, get Diff error: variable not there. --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-12-11 17:02:57
|
- **status**: open --> fixed --- ** [tickets:#243] Problems Loading Modes: Diff** **Status:** fixed **Created:** Wed Dec 09, 2020 11:35 PM UTC by John **Last Updated:** Fri Dec 11, 2020 05:02 PM UTC **Owner:** nobody I just installed AlphaCocoa 9.2.1 (freshly downloaded from Sourceforge) on a stock 2019 MacBook Pro running Catalina (10.15.7). After an uneventful copy from the .dmg to the Application folder, I lauched AlphaCocoa and was greeted by a dialog saying "Problems Loading Modes: Diff" and "Do you want to see the errors?" with No and Yes. Clicking Yes gave me "variable either doesn't exist or is local:" Nothing more. I am currently running AlphaCocoa 9.2.1 on the identical hardware and the same operating system but with many customizations and added software. That installtion does not have this problem. On the theory that I got a bad download, I tried removing AlphaCocoa and redownloaiding and reinstalling. No joy. What is going wrong and what can I do to fix it? Once the errors are displayed, I can use AlphaCocoa normally. However, file comparison does not seem to work. It works fine on my other computer. --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-12-11 17:02:20
|
Hi John, I have tested this directly and indeed this is the problem. This is fixed now. Changes committed to the repository ([rev. 1985](https://sourceforge.net/p/alphacocoa/code/1985/)). The indices must be rebuilt. --- ** [tickets:#243] Problems Loading Modes: Diff** **Status:** open **Created:** Wed Dec 09, 2020 11:35 PM UTC by John **Last Updated:** Fri Dec 11, 2020 02:09 PM UTC **Owner:** nobody I just installed AlphaCocoa 9.2.1 (freshly downloaded from Sourceforge) on a stock 2019 MacBook Pro running Catalina (10.15.7). After an uneventful copy from the .dmg to the Application folder, I lauched AlphaCocoa and was greeted by a dialog saying "Problems Loading Modes: Diff" and "Do you want to see the errors?" with No and Yes. Clicking Yes gave me "variable either doesn't exist or is local:" Nothing more. I am currently running AlphaCocoa 9.2.1 on the identical hardware and the same operating system but with many customizations and added software. That installtion does not have this problem. On the theory that I got a bad download, I tried removing AlphaCocoa and redownloaiding and reinstalling. No joy. What is going wrong and what can I do to fix it? Once the errors are displayed, I can use AlphaCocoa normally. However, file comparison does not seem to work. It works fine on my other computer. --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-12-11 15:09:45
|
Ah now I understand. See Ticket #243. --- ** [tickets:#242] Diff missing variable error when trying to run on Mac Catalina** **Status:** open **Created:** Tue Nov 17, 2020 11:22 PM UTC by Kathryn Hargreaves **Last Updated:** Fri Nov 20, 2020 01:33 PM UTC **Owner:** nobody When try to run on Mac 10.15.5 (19F101) Catalina on a Late 2012 Mac mini, get Diff error: variable not there. --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-12-11 14:09:53
|
Hi John, such an error occurs during startup when Alpha loads the initialization scripts of all the modes. Not sure what's going on but could you try the following experiment : * edit the file /Applications/Alpha.app/Contents/Resources/Libraries/AlphaTcl/Cache/index/mode * find the line that says ``` prefs::modified DiffmodeVars ``` * insert a # at the beginning of this line * save the file * quit Alpha and relaunch Does this solve the problem ? --- ** [tickets:#243] Problems Loading Modes: Diff** **Status:** open **Created:** Wed Dec 09, 2020 11:35 PM UTC by John **Last Updated:** Wed Dec 09, 2020 11:35 PM UTC **Owner:** nobody I just installed AlphaCocoa 9.2.1 (freshly downloaded from Sourceforge) on a stock 2019 MacBook Pro running Catalina (10.15.7). After an uneventful copy from the .dmg to the Application folder, I lauched AlphaCocoa and was greeted by a dialog saying "Problems Loading Modes: Diff" and "Do you want to see the errors?" with No and Yes. Clicking Yes gave me "variable either doesn't exist or is local:" Nothing more. I am currently running AlphaCocoa 9.2.1 on the identical hardware and the same operating system but with many customizations and added software. That installtion does not have this problem. On the theory that I got a bad download, I tried removing AlphaCocoa and redownloaiding and reinstalling. No joy. What is going wrong and what can I do to fix it? Once the errors are displayed, I can use AlphaCocoa normally. However, file comparison does not seem to work. It works fine on my other computer. --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: John <uni...@us...> - 2020-12-09 23:35:28
|
--- ** [tickets:#243] Problems Loading Modes: Diff** **Status:** open **Created:** Wed Dec 09, 2020 11:35 PM UTC by John **Last Updated:** Wed Dec 09, 2020 11:35 PM UTC **Owner:** nobody I just installed AlphaCocoa 9.2.1 (freshly downloaded from Sourceforge) on a stock 2019 MacBook Pro running Catalina (10.15.7). After an uneventful copy from the .dmg to the Application folder, I lauched AlphaCocoa and was greeted by a dialog saying "Problems Loading Modes: Diff" and "Do you want to see the errors?" with No and Yes. Clicking Yes gave me "variable either doesn't exist or is local:" Nothing more. I am currently running AlphaCocoa 9.2.1 on the identical hardware and the same operating system but with many customizations and added software. That installtion does not have this problem. On the theory that I got a bad download, I tried removing AlphaCocoa and redownloaiding and reinstalling. No joy. What is going wrong and what can I do to fix it? Once the errors are displayed, I can use AlphaCocoa normally. However, file comparison does not seem to work. It works fine on my other computer. --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Dr E. W L. <el...@li...> - 2020-12-02 09:00:20
|
Bernard, as always, great stuff. Thank you. And of course the below "confused by the > character" confused it too :-)-O I have always wondered, is there a way to support AlphaX, you must have costs for servers and stuff... greetings, el On 02/12/2020 10:55, Bernard Desgraupes wrote: > Hello Eberhard, > > yes this has been fixed. > The problem was that the proc text::isInSingleComment (which had been > recently redefined) was confused by the > character at the end of the > URL contained in this line. > > The fix will be in 9.2.2. > > Cheers, > Bernard |
|
From: Bernard D. <bde...@or...> - 2020-12-02 08:56:15
|
Hello Eberhard,
yes this has been fixed.
The problem was that the proc text::isInSingleComment (which had been recently redefined) was confused by the > character at the end of the URL contained in this line.
The fix will be in 9.2.2.
Cheers,
Bernard
> Le 2 déc. 2020 à 09:07, Dr Eberhard W Lisse <el...@li...> a écrit :
>
> Bernard,
>
> any progress on the email issue?
>
> el
>
> On 23/10/2020 09:41, Bernard Desgraupes wrote:
>> Hi Eberhard,
>>
>> unfortunately no :-(
>>
>> I’ll look into it now.
>>
>> Bernard
>>
>>
>>> Le 23 oct. 2020 à 09:22, Dr Eberhard W Lisse <el...@li...> a écrit :
>>>
>>> Bernard,
>>>
>>> does it fix my email issue?
>>>
>>> el
>>>
>>> On 2020-10-23 08:57 , Bernard Desgraupes wrote:
>>>> Hi all,
>>>>
>>>> I'm pleased to announce the release of Alpha 9.2.1 ("Gianfar-2
>>>> <https://alphacocoa.sourceforge.io/AlphaStar.html>") for Mac OS X 10.11
>>>> or greater (El Capitan, Sierra, High Sierra, Mojave, Catalina).
>>>>
>>>> This is a minor technical update that fixes recent issues found in 9.2.
>>>> See below.
>>>>
>>> [...]
>>>
>>>
>>> --
>>> Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist
>>> el...@li... / * | Telephone: +264 81 124 6733 (cell)
>>> PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP
>>> 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
>>>
>>>
>>> _______________________________________________
>>> AlphaTcl-users mailing list
>>> Alp...@li...
>>> http://lists.sourceforge.net/lists/listinfo/alphatcl-users
>
> --
> Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist
> el...@li... / * | Telephone: +264 81 124 6733 (cell)
> PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP
> 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
|
|
From: Dr E. W L. <el...@li...> - 2020-12-02 08:25:41
|
Bernard,
any progress on the email issue?
el
On 23/10/2020 09:41, Bernard Desgraupes wrote:
> Hi Eberhard,
>
> unfortunately no :-(
>
> I’ll look into it now.
>
> Bernard
>
>
>> Le 23 oct. 2020 à 09:22, Dr Eberhard W Lisse <el...@li...> a écrit :
>>
>> Bernard,
>>
>> does it fix my email issue?
>>
>> el
>>
>> On 2020-10-23 08:57 , Bernard Desgraupes wrote:
>>> Hi all,
>>>
>>> I'm pleased to announce the release of Alpha 9.2.1 ("Gianfar-2
>>> <https://alphacocoa.sourceforge.io/AlphaStar.html>") for Mac OS X 10.11
>>> or greater (El Capitan, Sierra, High Sierra, Mojave, Catalina).
>>>
>>> This is a minor technical update that fixes recent issues found in 9.2.
>>> See below.
>>>
>> [...]
>>
>>
>> --
>> Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist
>> el...@li... / * | Telephone: +264 81 124 6733 (cell)
>> PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP
>> 10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
>>
>>
>> _______________________________________________
>> AlphaTcl-users mailing list
>> Alp...@li...
>> http://lists.sourceforge.net/lists/listinfo/alphatcl-users
--
Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist
el...@li... / * | Telephone: +264 81 124 6733 (cell)
PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP
10007, Namibia ;____/ Sect 20 of Act No. 4 of 2019 may apply
|
|
From: James C. <jpg...@us...> - 2020-11-22 11:47:23
|
Hello Bernard, thanks for the detailed summary and discussions which explain the problems well ! The solution this is converging towards (the secondary encoding which is the user’s responsability) makes perfect sense, and I’ll say no more. All the best, James > On 21 Nov 2020, at 16:38, Bernard Desgraupes via AlphaCocoa-devel <alp...@li...> wrote: > > Dear Andreas, > thank you for your suggestions which go way beyond the initial request contained in this Ticket. > > As far as this ticket is concerned, I'd like to clarify what happens when Alpha reads a file. The file contains bytes and Alpha must translate (not convert) these bytes to letters. To make this possible, the user must specify the encoding (which seves as a translation table). If your file contains the byte 0xE9, here is what happens depending on the encoding declared by the user: > if the user told to use Latin1 encoding (ISO-8859-1), Alpha translates the byte to 'é' > if the user told to use macRoman encoding, Alpha translates the byte to 'È' > * if the user told to use UTF8 encoding form, there is an error because byte 0xE9 is forbidden in UTF8. > > So when I wrote that opening a Latin1 file in macRoman encoding yields "wrong" characters, what is wrong there is that the user misled Alpha. Alpha just does what it was told to do. > > If you ask to open any file in any 1-byte encoding (like macRoman, Latin1, ISO-8859-7 for greek, KOI8 for russian, etc), there will never be an error message. OTOH, you may see an error message when the input encoding is UTF8 because some bytes are forbidden depending on their position in multi-byte sequences, so Alpha will tell you that your file can not be UTF8 because it contains invalid sequences. > > The only "conversion" which takes place occurs when Alpha builds its internal buffer which contains only UTF16 two-byte sequences. The user should not be concerned by this: it is only an internal representation. When you save your modified file, Alpha performs the necessary backward conversion to write out the proper bytes in the desired output encoding. > > The original request made in this ticket means that there should be a fallback mechanism when Alpha detects that the file is not valid UTF8 : it suggests to use some heuristics to guess what the encoding could be. Unfortunately there is no reliable method for detecting an encoding. James suggested to use the file command line tool which tries to guess the encoding : but it can easily be fooled and give wrong answers. I would not rely on it. > > Joachim suggested that the user define a sort of secondary encoding (or fallback encoding) that Alpha would use silently when UTF8 fails : this could be useful but still it is the user's responsibility to specify a secondary encoding that suit her needs. If mostly all your non-UTF8 files are in macRoman, it makes sense to set this secondary encoding to macRoman. But if the file was Latin1, well, too bad... you just misled Alpha. > > [tickets:#240] Encoding > > Status: open > Created: Sat Oct 24, 2020 07:43 AM UTC by James Connolly > Last Updated: Fri Nov 20, 2020 05:28 PM UTC > Owner: nobody > > Hello, first thanks for all the great work from a long term user (≈1997 on) ! > > A suggestion :Would it be possible to have a "Default encoding : Check file on open"? > > This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. > > At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. > > Cheers, James > > p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". > > Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ > > To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. > > _______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel --- ** [tickets:#240] Encoding** **Status:** open **Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly **Last Updated:** Sat Nov 21, 2020 03:38 PM UTC **Owner:** nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: James C. <jpg...@gm...> - 2020-11-22 11:15:50
|
Hello Bernard, thanks for the detailed summary and discussions which explain the problems well ! The solution this is converging towards (the secondary encoding which is the user’s responsability) makes perfect sense, and I’ll say no more. All the best, James > On 21 Nov 2020, at 16:38, Bernard Desgraupes via AlphaCocoa-devel <alp...@li...> wrote: > > Dear Andreas, > thank you for your suggestions which go way beyond the initial request contained in this Ticket. > > As far as this ticket is concerned, I'd like to clarify what happens when Alpha reads a file. The file contains bytes and Alpha must translate (not convert) these bytes to letters. To make this possible, the user must specify the encoding (which seves as a translation table). If your file contains the byte 0xE9, here is what happens depending on the encoding declared by the user: > if the user told to use Latin1 encoding (ISO-8859-1), Alpha translates the byte to 'é' > if the user told to use macRoman encoding, Alpha translates the byte to 'È' > * if the user told to use UTF8 encoding form, there is an error because byte 0xE9 is forbidden in UTF8. > > So when I wrote that opening a Latin1 file in macRoman encoding yields "wrong" characters, what is wrong there is that the user misled Alpha. Alpha just does what it was told to do. > > If you ask to open any file in any 1-byte encoding (like macRoman, Latin1, ISO-8859-7 for greek, KOI8 for russian, etc), there will never be an error message. OTOH, you may see an error message when the input encoding is UTF8 because some bytes are forbidden depending on their position in multi-byte sequences, so Alpha will tell you that your file can not be UTF8 because it contains invalid sequences. > > The only "conversion" which takes place occurs when Alpha builds its internal buffer which contains only UTF16 two-byte sequences. The user should not be concerned by this: it is only an internal representation. When you save your modified file, Alpha performs the necessary backward conversion to write out the proper bytes in the desired output encoding. > > The original request made in this ticket means that there should be a fallback mechanism when Alpha detects that the file is not valid UTF8 : it suggests to use some heuristics to guess what the encoding could be. Unfortunately there is no reliable method for detecting an encoding. James suggested to use the file command line tool which tries to guess the encoding : but it can easily be fooled and give wrong answers. I would not rely on it. > > Joachim suggested that the user define a sort of secondary encoding (or fallback encoding) that Alpha would use silently when UTF8 fails : this could be useful but still it is the user's responsibility to specify a secondary encoding that suit her needs. If mostly all your non-UTF8 files are in macRoman, it makes sense to set this secondary encoding to macRoman. But if the file was Latin1, well, too bad... you just misled Alpha. > > [tickets:#240] Encoding > > Status: open > Created: Sat Oct 24, 2020 07:43 AM UTC by James Connolly > Last Updated: Fri Nov 20, 2020 05:28 PM UTC > Owner: nobody > > Hello, first thanks for all the great work from a long term user (≈1997 on) ! > > A suggestion :Would it be possible to have a "Default encoding : Check file on open"? > > This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. > > At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. > > Cheers, James > > p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". > > Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ > > To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. > > _______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel |
|
From: Bernard D. <bde...@us...> - 2020-11-21 15:38:13
|
Dear Andreas, thank you for your suggestions which go way beyond the initial request contained in this Ticket. As far as this ticket is concerned, I'd like to clarify what happens when Alpha *reads* a file. The file contains bytes and Alpha must *translate* (not convert) these bytes to letters. To make this possible, the user must specify the encoding (which seves as a translation table). If your file contains the byte `0xE9`, here is what happens depending on the encoding declared by the user: * if the user told to use Latin1 encoding (ISO-8859-1), Alpha translates the byte to 'é' * if the user told to use macRoman encoding, Alpha translates the byte to 'È' * if the user told to use UTF8 encoding form, there is an error because byte `0xE9` is forbidden in UTF8. So when I wrote that opening a Latin1 file in macRoman encoding yields "wrong" characters, what is wrong there is that the user misled Alpha. Alpha just does what it was told to do. If you ask to open *any* file in *any* 1-byte encoding (like macRoman, Latin1, ISO-8859-7 for greek, KOI8 for russian, etc), there will *never* be an error message. OTOH, you may see an error message when the input encoding is UTF8 because some bytes are forbidden depending on their position in multi-byte sequences, so Alpha will tell you that your file *can not* be UTF8 because it contains invalid sequences. The only "conversion" which takes place occurs when Alpha builds its internal buffer which contains only UTF16 two-byte sequences. The user should not be concerned by this: it is only an internal *representation*. When you save your modified file, Alpha performs the necessary backward conversion to write out the proper bytes in the desired output encoding. The original request made in this ticket means that there should be a fallback mechanism when Alpha detects that the file is not valid UTF8 : it suggests to use some heuristics to guess what the encoding could be. Unfortunately there is no reliable method for detecting an encoding. James suggested to use the `file` command line tool which tries to guess the encoding : but it can easily be fooled and give wrong answers. I would not rely on it. Joachim suggested that the user define a sort of secondary encoding (or fallback encoding) that Alpha would use silently when UTF8 fails : this could be useful but still it is the user's responsibility to specify a secondary encoding that suit her needs. If mostly all your non-UTF8 files are in macRoman, it makes sense to set this secondary encoding to macRoman. But if the file was Latin1, well, too bad... you just misled Alpha. --- ** [tickets:#240] Encoding** **Status:** open **Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly **Last Updated:** Fri Nov 20, 2020 05:28 PM UTC **Owner:** nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Fischlin A. <and...@en...> - 2020-11-21 15:00:51
|
Dear Bernard,
I fear I was not clear enough with the alternative solution. More in detail it would be characterized by following:
* A preference by which the user can define the expected input encoding, e.g MacRoman, of any file that is opened
* A preference by which the user can define the target encoding, e.g UTF-8, for any currently open file that is to be saved
* When the target encoding is possible without any error from the input encoding (target encoding a super set of the input encoding, e.g. this is the case with MacRoman where all characters can be encoded with UTF-8), no warning is thrown at the user and a silent conversion becomes possible (but controlled by following preference)
* A preference by which the user can have above conversion being done silently or with a warning like the current behavior whenever a file is opened that does not match the input encoding as currently selected by the user. Perhaps default throw the warning if the file is not encoded in the expected input encoding (current behavior). But I personally would also be open to another default, under the condition the preference allows me to control this behavior.
This calls for further clarifications:
* No preference to suppress any true encoding error warnings, since they must show up always when a conversion error is encountered, e.g.
* (i) when a file to be opened is not in the expected input encoding; or
* (ii) the input encoding and target encoding do not support auto-conversion (warning could be thrown at the moment the user selects the input and target encoding, but user can dismiss this warning); or alternatively warning is only triggered depending on the file content, i.e. this warning is only triggered during opening if the file contains actually some characters that are contained only in the input encoding and that cannot be auto-converted to the traget encoding; or
* (iii) when the user tries to switch during editing to a target encoding that does not allow to save all characters, e.g. a UTF-8 encoded file saving to MacRoman that contains characters that are not representable in MacRoman (same file content dependent warning as above, but the warning is triggered only when setting the file to the new target encoding); or
* (iv) when the user tries to save a file as last edited (dirty) with characters that cannot be encoded properly with the current target encoding (again user can force the save nevertheless).
* In case of an intentional manual encoding you should be able to override above listed warnings always and save the file nevertheless in any encoding. E.g. you should be able to save an originally UTF-8 encoded file in MacRoman even if it contains characters that cannot be encoded correctly in MacRoman.
Regards,
I hope this is now clearer and better thought through.
Andreas
ETH Zurich
Prof. em. Dr. Andreas Fischlin
IPCC Vice-Chair WGII
Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics
CHN E 24
Universitaetstrasse 16
8092 Zurich
SWITZERLAND
and...@en...<mailto:and...@en...>and...@en...<mailto:and...@en...>
www.sysecol.ethz.ch/people/andreas.fischlin.hmlhttp://www.sysecol.ethz.ch/people/andreas.fischlin.hml
+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 595-4050 mobile
Make it as simple as possible, but distrust it!
________________________________
On 20/11/2020, at 18:28, Bernard Desgraupes via AlphaCocoa-devel alp...@li...<mailto:alp...@li...<mailto:alp...@li...<mailto:alp...@li...>> wrote:
If I understand correctly Joachim's proposal this SecondaryEncoding would be empty by default which would correspond to the current behavior (which is what Andreas prefers) but Joachim himself would set it to MacRoman, and James would set it to ISO-8859-1 (aka Latin1). So everybody would be happy.
But if thereafter Joachim tries to open a Latin1 file, this file will be silently opened in MacRoman giving wrong characters for all the accented letters: he would have to use the Open File command and explicitely set the encoding to Latin1 in the dialog.
________________________________
[tickets:#240]<https://sourceforge.net/p/alphacocoa/tickets/240/>https://sourceforge.net/p/alphacocoa/tickets/240/ Encoding
Status: open
Created: Sat Oct 24, 2020 07:43 AM UTC by James Connolly
Last Updated: Fri Nov 20, 2020 02:51 PM UTC
Owner: nobody
Hello, first thanks for all the great work from a long term user (≈1997 on) !
A suggestion :Would it be possible to have a "Default encoding : Check file on open"?
This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails.
At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking.
Cheers, James
p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion".
________________________________
Sent from sourceforge.net<http://sourceforge.net>http://sourceforge.net<http://sourceforge.net/> because alp...@li...<mailto:alp...@li...>alp...@li...<mailto:alp...@li...> is subscribed to https://sourceforge.net/p/alphacocoa/tickets/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
________________________________
AlphaCocoa-devel mailing list
Alp...@li...<mailto:Alp...@li...>Alp...@li...<mailto:Alp...@li...>
https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel
________________________________
[tickets:#240]<https://sourceforge.net/p/alphacocoa/tickets/240/> Encoding
Status: open
Created: Sat Oct 24, 2020 07:43 AM UTC by James Connolly
Last Updated: Fri Nov 20, 2020 05:28 PM UTC
Owner: nobody
Hello, first thanks for all the great work from a long term user (≈1997 on) !
A suggestion :Would it be possible to have a "Default encoding : Check file on open"?
This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails.
At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking.
Cheers, James
p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion".
________________________________
Sent from sourceforge.net<http://sourceforge.net> because alp...@li...<mailto:alp...@li...> is subscribed to https://sourceforge.net/p/alphacocoa/tickets/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
_______________________________________________
AlphaCocoa-devel mailing list
Alp...@li...<mailto:Alp...@li...>
https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel
|
|
From: Fischlin A. <afi...@us...> - 2020-11-21 11:14:49
|
Dear Bernard, I do not necessarily prefer the current behavior, since it is indeed a bit cumbersome. I would therefore also prefer a simpler, more automated approach. However, to really explain what I would prefer, I would need more clarity what the proposal actually is as I explained in my previous e-mail. The only thing I can say at this point already is, (i) yes, I welcome some support in easier conversion to a desirable encoding such as UTF-8, (ii) but I wish to have sufficient control over the behavior, e.g. easy to dismiss warnings when a problematic conversion was made. No warning when I make a big step in transforming many files in a particular manner or a warning when I occasionally deal with some files, when I would appreciate to learn that a particular conversion is about to take place, so I can decide whether I wanna go with it or not. This seems to me to perhaps mean: - A preference by which the user can define a target encoding, e.g UTF-8 - convenient facilities for convenient conversions such as opening of a MacRoman file triggers no warning, when the original encoding could be changed to the user defined target encoding such as UTF-8 - A preference to suppress or enable warnings when a conversion as described above takes place, my preference for the default would be to show the warnings (similar to current behavior) However, a preference to suppress all warnings, even when the encoding cannot be converted without error, I consider to be questionable (e.g. silently open a Latin1 file and giving wrong characters), at least please not by default. I prefer here clearly a warning and a dialog as currently offered. Perhaps the solution is an even other one: - A preference by which the user can define the expected encoding, e.g MacRoman, of any file that is opened - A preference by which the user can define the target encoding, e.g UTF-8, for any currently open file that is to be saved - No preference to suppress any warnings, since they show up always when a conversion fails, e.g. when a file to be opened does not match the expected encoding or when the user tries to save a file with an encoding that does not allow to save all characters, e.g. a UTF-8 encoded file saving to MacRoman that contains characters that are not representable in MacRoman. Of course you should also be able to override such a warning, e.g. in case of an intentional manual encoding. Regards, Andreas ETH Zurich Prof. em. Dr. Andreas Fischlin IPCC Vice-Chair WGII Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND and...@en...<mailto:and...@en...> www.sysecol.ethz.ch/people/andreas.fischlin.hml<http://www.sysecol.ethz.ch/people/andreas.fischlin.hml> +41 44 633-6090 phone +41 44 633-1136 fax +41 79 595-4050 mobile Make it as simple as possible, but distrust it! ________________________________________________________________________ On 20/11/2020, at 18:28, Bernard Desgraupes via AlphaCocoa-devel <alp...@li...<mailto:alp...@li...>> wrote: If I understand correctly Joachim's proposal this SecondaryEncoding would be empty by default which would correspond to the current behavior (which is what Andreas prefers) but Joachim himself would set it to MacRoman, and James would set it to ISO-8859-1 (aka Latin1). So everybody would be happy. But if thereafter Joachim tries to open a Latin1 file, this file will be silently opened in MacRoman giving wrong characters for all the accented letters: he would have to use the Open File command and explicitely set the encoding to Latin1 in the dialog. ________________________________ [tickets:#240]<https://sourceforge.net/p/alphacocoa/tickets/240/> Encoding Status: open Created: Sat Oct 24, 2020 07:43 AM UTC by James Connolly Last Updated: Fri Nov 20, 2020 02:51 PM UTC Owner: nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". ________________________________ Sent from sourceforge.net<http://sourceforge.net> because alp...@li...<mailto:alp...@li...> is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. _______________________________________________ AlphaCocoa-devel mailing list Alp...@li...<mailto:Alp...@li...> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel --- ** [tickets:#240] Encoding** **Status:** open **Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly **Last Updated:** Fri Nov 20, 2020 05:28 PM UTC **Owner:** nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-11-20 17:29:05
|
If I understand correctly Joachim's proposal this *SecondaryEncoding* would be empty by default which would correspond to the current behavior (which is what Andreas prefers) but Joachim himself would set it to MacRoman, and James would set it to ISO-8859-1 (aka Latin1). So everybody would be happy. But if thereafter Joachim tries to open a Latin1 file, this file will be silently opened in MacRoman giving wrong characters for all the accented letters: he would have to use the Open File command and explicitely set the encoding to Latin1 in the dialog. --- ** [tickets:#240] Encoding** **Status:** open **Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly **Last Updated:** Fri Nov 20, 2020 02:51 PM UTC **Owner:** nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Fischlin A. <afi...@us...> - 2020-11-20 15:59:43
|
Dear all, Perhaps that’s a solution that means less effort when opening older files, indeed. I would basically welcome to have less to do when opening files. However, I am not fully convinced that simply defining a default encoding is always what we want for following reasons, my default encoding being UTF-8: (i) I like nevertheless to be reminded that the file is not encoded in UTF-8, e.g. MacRoman, since I prefer to “convert” all my files sooner or later to UTF-8 encoding whenever I modify files. Perhaps a preference can be added that warns me nevertheless that the file was opened in a not UTF-8 when you implement this solution. If someone does not want such reminders, the preference can be set to no give such warnings. (ii) Another option might be to have a preference for automatic conversion when implementing this solution, i.e. the file is opened without warning and silently converted to UTF-8, a choice you might have to confirm when you save it, where you could refuse to save it in UTF-8 if you have second thoughts about this auto conversion to the UTF-8 encoding. Perhaps above arguments are not particularly valid, since I may not have well understood what is proposed. In any case I have to admit that it is not particularly clear what is meant by "Default encoding : Check file on open”. Does this mean I can define what my default encoding is (my understanding)? And do I have a preference whether the mismatch triggers the current dialog or not? The latter might be my point (i) above. Regards, Andreas ETH Zurich Prof. em. Dr. Andreas Fischlin IPCC Vice-Chair WGII Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND and...@en...<mailto:and...@en...> www.sysecol.ethz.ch/people/andreas.fischlin.hml<http://www.sysecol.ethz.ch/people/andreas.fischlin.hml> +41 44 633-6090 phone +41 44 633-1136 fax +41 79 595-4050 mobile Make it as simple as possible, but distrust it! ________________________________________________________________________ On 20/11/2020, at 15:51, Bernard Desgraupes via AlphaCocoa-devel <alp...@li...<mailto:alp...@li...>> wrote: Hi Joachim, I agree, it is an elegant solution. I'll try to implement it. ________________________________ [tickets:#240]<https://sourceforge.net/p/alphacocoa/tickets/240/> Encoding Status: open Created: Sat Oct 24, 2020 07:43 AM UTC by James Connolly Last Updated: Fri Nov 20, 2020 01:26 PM UTC Owner: nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". ________________________________ Sent from sourceforge.net<http://sourceforge.net> because alp...@li...<mailto:alp...@li...> is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. _______________________________________________ AlphaCocoa-devel mailing list Alp...@li...<mailto:Alp...@li...> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel --- ** [tickets:#240] Encoding** **Status:** open **Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly **Last Updated:** Fri Nov 20, 2020 02:51 PM UTC **Owner:** nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Fischlin A. <and...@en...> - 2020-11-20 15:44:23
|
Dear all, Perhaps that’s a solution that means less effort when opening older files, indeed. I would basically welcome to have less to do when opening files. However, I am not fully convinced that simply defining a default encoding is always what we want for following reasons, my default encoding being UTF-8: (i) I like nevertheless to be reminded that the file is not encoded in UTF-8, e.g. MacRoman, since I prefer to “convert” all my files sooner or later to UTF-8 encoding whenever I modify files. Perhaps a preference can be added that warns me nevertheless that the file was opened in a not UTF-8 when you implement this solution. If someone does not want such reminders, the preference can be set to no give such warnings. (ii) Another option might be to have a preference for automatic conversion when implementing this solution, i.e. the file is opened without warning and silently converted to UTF-8, a choice you might have to confirm when you save it, where you could refuse to save it in UTF-8 if you have second thoughts about this auto conversion to the UTF-8 encoding. Perhaps above arguments are not particularly valid, since I may not have well understood what is proposed. In any case I have to admit that it is not particularly clear what is meant by "Default encoding : Check file on open”. Does this mean I can define what my default encoding is (my understanding)? And do I have a preference whether the mismatch triggers the current dialog or not? The latter might be my point (i) above. Regards, Andreas ETH Zurich Prof. em. Dr. Andreas Fischlin IPCC Vice-Chair WGII Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 24 Universitaetstrasse 16 8092 Zurich SWITZERLAND and...@en...<mailto:and...@en...> www.sysecol.ethz.ch/people/andreas.fischlin.hml<http://www.sysecol.ethz.ch/people/andreas.fischlin.hml> +41 44 633-6090 phone +41 44 633-1136 fax +41 79 595-4050 mobile Make it as simple as possible, but distrust it! ________________________________________________________________________ On 20/11/2020, at 15:51, Bernard Desgraupes via AlphaCocoa-devel <alp...@li...<mailto:alp...@li...>> wrote: Hi Joachim, I agree, it is an elegant solution. I'll try to implement it. ________________________________ [tickets:#240]<https://sourceforge.net/p/alphacocoa/tickets/240/> Encoding Status: open Created: Sat Oct 24, 2020 07:43 AM UTC by James Connolly Last Updated: Fri Nov 20, 2020 01:26 PM UTC Owner: nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". ________________________________ Sent from sourceforge.net<http://sourceforge.net> because alp...@li...<mailto:alp...@li...> is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. _______________________________________________ AlphaCocoa-devel mailing list Alp...@li...<mailto:Alp...@li...> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel |
|
From: Bernard D. <bde...@us...> - 2020-11-20 14:51:04
|
Hi Joachim, I agree, it is an elegant solution. I'll try to implement it. --- ** [tickets:#240] Encoding** **Status:** open **Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly **Last Updated:** Fri Nov 20, 2020 01:26 PM UTC **Owner:** nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Joachim K. <ko...@ma...> - 2020-11-20 14:45:11
|
Hi, I would like to suggest a more pragmatic solution, namely a second option prefs setting. For example, I would set UTF-8 as my first option and MacRoman as my second option, and Alpha would try first UTF-8, and it if doesn't work, try MacRoman (without presenting the dialogue to ask me to choose another encoding). It would work fine most of the time. Only very rarely would I have to open a windows file (and I would be willing to deal with that case in a more manual way, if I could have a more automatic treatment of all my old files in MacRoman). James would select ISO-8859 as second option, and it would seem to do the job for him. People having many files of different encodings would simply leave the second option undefined, to avoid automatic mistakes. If it is deemed to unsafe to open files automatically without really being sure, another possibility would be to use the second-option pref simply to pre-set the default item in the pop-up of the dialogue. That would allow the user at least to proceed very quickly by hitting OK by return, without having to dig into the pop-up with the mouse. Cheers, Joachim. On 20/11/2020 14:26, Bernard Desgraupes via AlphaCocoa-devel wrote: > Hi James, > thank you for the suggestion. The problem with the /file/ command is > that it is not sufficiently accurate and reliable. For instance, I > tested it (with option |-I| to get a mime type) on a file encoded in > macRoman and got: > |text/plain; charset=unknown-8bit| > I tested it on a file containing greek text written ISO-8859-7 and got : > |text/plain; charset=iso-8859-1| (sic, 8859-1, not 8859-7). > Same wrong result with a russian text in ISO8859-5. > I'm afraid this would lead to wrong decisions that would be quite > frustrating for the user. > > ------------------------------------------------------------------------ > > *[tickets:#240] <https://sourceforge.net/p/alphacocoa/tickets/240/> > Encoding* > > *Status:* open > *Created:* Sat Oct 24, 2020 07:43 AM UTC by James Connolly > *Last Updated:* Sat Oct 24, 2020 07:46 AM UTC > *Owner:* nobody > > Hello, first thanks for all the great work from a long term user (≈1997 > on) ! > > A suggestion :Would it be possible to have a "Default encoding : Check > file on open"? > > This "check file on open" would, upon opening a file, have Alpha check > the file's (e.g. BSD "file" command) and use that. And only then open > the "Encodings popup" if this fails. > > At present I have many files in ISO-8859 and the pop-up is working > rather hard. And I'm not inclined to convert them all to UTF-8 in order > to avoid further potential problems : if Alpha can handle ISO-8859, why > not silently continue to do so where appropriate is my thinking. > > Cheers, James > > p.s. not files as "bug" nor "task" but as "RFE" which I hope means > "suggestion". > > ------------------------------------------------------------------------ > > Sent from sourceforge.net because alp...@li... > is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ > > To unsubscribe from further messages, a project admin can change > settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. > Or, if this is a mailing list, you can unsubscribe from the mailing list. > > > > _______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel > |
|
From: Joachim K. <jk...@us...> - 2020-11-20 14:45:04
|
Hi, I would like to suggest a more pragmatic solution, namely a second option prefs setting. For example, I would set UTF-8 as my first option and MacRoman as my second option, and Alpha would try first UTF-8, and it if doesn't work, try MacRoman (without presenting the dialogue to ask me to choose another encoding). It would work fine most of the time. Only very rarely would I have to open a windows file (and I would be willing to deal with that case in a more manual way, if I could have a more automatic treatment of all my old files in MacRoman). James would select ISO-8859 as second option, and it would seem to do the job for him. People having many files of different encodings would simply leave the second option undefined, to avoid automatic mistakes. If it is deemed to unsafe to open files automatically without really being sure, another possibility would be to use the second-option pref simply to pre-set the default item in the pop-up of the dialogue. That would allow the user at least to proceed very quickly by hitting OK by return, without having to dig into the pop-up with the mouse. Cheers, Joachim. On 20/11/2020 14:26, Bernard Desgraupes via AlphaCocoa-devel wrote: > Hi James, > thank you for the suggestion. The problem with the /file/ command is > that it is not sufficiently accurate and reliable. For instance, I > tested it (with option |-I| to get a mime type) on a file encoded in > macRoman and got: > |text/plain; charset=unknown-8bit| > I tested it on a file containing greek text written ISO-8859-7 and got : > |text/plain; charset=iso-8859-1| (sic, 8859-1, not 8859-7). > Same wrong result with a russian text in ISO8859-5. > I'm afraid this would lead to wrong decisions that would be quite > frustrating for the user. > > ------------------------------------------------------------------------ > > *[tickets:#240] <https://sourceforge.net/p/alphacocoa/tickets/240/> > Encoding* > > *Status:* open > *Created:* Sat Oct 24, 2020 07:43 AM UTC by James Connolly > *Last Updated:* Sat Oct 24, 2020 07:46 AM UTC > *Owner:* nobody > > Hello, first thanks for all the great work from a long term user (≈1997 > on) ! > > A suggestion :Would it be possible to have a "Default encoding : Check > file on open"? > > This "check file on open" would, upon opening a file, have Alpha check > the file's (e.g. BSD "file" command) and use that. And only then open > the "Encodings popup" if this fails. > > At present I have many files in ISO-8859 and the pop-up is working > rather hard. And I'm not inclined to convert them all to UTF-8 in order > to avoid further potential problems : if Alpha can handle ISO-8859, why > not silently continue to do so where appropriate is my thinking. > > Cheers, James > > p.s. not files as "bug" nor "task" but as "RFE" which I hope means > "suggestion". > > ------------------------------------------------------------------------ > > Sent from sourceforge.net because alp...@li... > is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ > > To unsubscribe from further messages, a project admin can change > settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. > Or, if this is a mailing list, you can unsubscribe from the mailing list. > > > > _______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel > --- ** [tickets:#240] Encoding** **Status:** open **Created:** Sat Oct 24, 2020 07:43 AM UTC by James Connolly **Last Updated:** Fri Nov 20, 2020 01:26 PM UTC **Owner:** nobody Hello, first thanks for all the great work from a long term user (≈1997 on) ! A suggestion :Would it be possible to have a "Default encoding : Check file on open"? This "check file on open" would, upon opening a file, have Alpha check the file's (e.g. BSD "file" command) and use that. And only then open the "Encodings popup" if this fails. At present I have many files in ISO-8859 and the pop-up is working rather hard. And I'm not inclined to convert them all to UTF-8 in order to avoid further potential problems : if Alpha can handle ISO-8859, why not silently continue to do so where appropriate is my thinking. Cheers, James p.s. not files as "bug" nor "task" but as "RFE" which I hope means "suggestion". --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-11-20 13:33:51
|
Not sure I understand what this is about. --- ** [tickets:#242] Diff missing variable error when trying to run on Mac Catalina** **Status:** open **Created:** Tue Nov 17, 2020 11:22 PM UTC by Kathryn Hargreaves **Last Updated:** Tue Nov 17, 2020 11:22 PM UTC **Owner:** nobody When try to run on Mac 10.15.5 (19F101) Catalina on a Late 2012 Mac mini, get Diff error: variable not there. --- Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
|
From: Bernard D. <bde...@us...> - 2020-11-20 13:32:41
|
Thank you for reporting this. It is indeed a bug. I tested your example in Text Edit which handles it correctly.
Both Alpha and Text Edit rely on the Cocoa text engine, so I have to find out how the behavior gets corrupted in the case of Alpha.
---
** [tickets:#241] Rectangular replace (copy/paste) fails**
**Status:** open
**Created:** Wed Nov 11, 2020 12:42 PM UTC by K.-M. Schindler
**Last Updated:** Wed Nov 11, 2020 12:42 PM UTC
**Owner:** nobody
After a rectangular copy covering mutiple lines, the rectangular paste on another rectangular selection fails in so far as the paste is inserted at the first position with new lines for the rest of the copy. Example:
AA 11 aa 111
BB 22 bb 222
CC 33 cc 333
DD 44 dd 444
EE 55 ee 555
Rectangular selecting bb and cc and copy and pasting to the rectangular selection of CC and DD yields:
AA 11 aa 111
BB 22 bb 222
bb
cc 33 cc 333
44 dd 444
EE 55 ee 555
Note that the correct parts are deleted, but the insert fails maybe due to a wrong interpretation of the separation of the parts. I also had a look whether it results from some settings, but could not find anything.
---
Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
368 messages has been excluded from this view by a project administrator.
