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: Joachim K. <ko...@ma...> - 2018-03-24 14:09:45
|
Hi Eberhard, > When I indent a line (txt file/mail) and continue to write, > subsequent lines do not get indented I noticed this too, but it turns out just to be a preference flag (mode specific), which possibly in AlphaX was on by default: indentOnReturn. > and when I issue CMD-I on the second or subsequent line all, > including the first one get wrapped properly but not indented. If I > do same on the first line all is well, wraps the whole paragraph > indented. I think this is by design: the indentParagraph operation decides the indentation amount according to the line where the cursor is. Cheers, Joachim. |
From: Dr E. W L. <el...@li...> - 2018-03-24 10:31:45
|
When I indent a line (txt file/mail) and continue to write, subsequent lines do not get indented and when I issue CMD-I on the second or subsequent line all, including the first one get wrapped properly but not indented. If I do same on the first line all is well, wraps the whole paragraph indented. Would that be a feature or a bug? greetings, el — Sent from Dr Lisse’s iPad Mini > |
From: Chris S. <cs...@us...> - 2018-03-24 07:12:51
|
Further to this, if you double click on delta in \delta_{n} then it is \delta_ that is selected, so the { is breaking the word. From: Joachim Kock via AlphaCocoa-devel <alp...@li...<mailto:alp...@li...>> Reply-To: Ticket 152 <15...@ti...<mailto:15...@ti...>> Date: Saturday, 24 March 2018 5:56 pm To: "alp...@li...<mailto:alp...@li...>" <alp...@li...<mailto:alp...@li...>> Cc: Joachim Kock <jk...@us...<mailto:jk...@us...>> Subject: [Alphacocoa-devel] [alphacocoa:tickets] #152 latex mode word double-click ________________________________ [tickets:#152]<https://sourceforge.net/p/alphacocoa/tickets/152/> latex mode word double-click Status: open Created: Sat Mar 24, 2018 06:56 AM UTC by Joachim Kock Last Updated: Sat Mar 24, 2018 06:56 AM UTC Owner: nobody In latex mode, if you double click on delta in \delta_n everything is selected, including the underscore n. The correct would be to have selected only \delta. (Indeed, underscore cannot be be said to be part of any notion of word in tex; it is an operator.) I have experimented with the definition of TeXmodeVars(wordBreak), but suspect that it may be a core problem. For example, the arrow keys, option-left and option-right, correctly understand that underscore is not part of a word. ________________________________ Sent from sourceforge.net<http://sourceforge.net> because alp...@li...<mailto:alp...@li...> is subscribed to https://sourceforge.net/p/alphacocoa/tickets/<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.<https://sourceforge.net/p/alphacocoa/admin/tickets/options.> Or, if this is a mailing list, you can unsubscribe from the mailing list. --- ** [tickets:#152] latex mode word double-click** **Status:** open **Created:** Sat Mar 24, 2018 06:56 AM UTC by Joachim Kock **Last Updated:** Sat Mar 24, 2018 06:56 AM UTC **Owner:** nobody In latex mode, if you double click on delta in \delta_n everything is selected, including the underscore n. The correct would be to have selected only \delta. (Indeed, underscore cannot be be said to be part of any notion of word in tex; it is an operator.) I have experimented with the definition of TeXmodeVars(wordBreak), but suspect that it may be a core problem. For example, the arrow keys, option-left and option-right, correctly understand that underscore is not part of a word. --- 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: Christopher S. <Chr...@un...> - 2018-03-24 07:12:41
|
Further to this, if you double click on delta in \delta_{n} then it is \delta_ that is selected, so the { is breaking the word. From: Joachim Kock via AlphaCocoa-devel <alp...@li...<mailto:alp...@li...>> Reply-To: Ticket 152 <15...@ti...<mailto:15...@ti...>> Date: Saturday, 24 March 2018 5:56 pm To: "alp...@li...<mailto:alp...@li...>" <alp...@li...<mailto:alp...@li...>> Cc: Joachim Kock <jk...@us...<mailto:jk...@us...>> Subject: [Alphacocoa-devel] [alphacocoa:tickets] #152 latex mode word double-click ________________________________ [tickets:#152]<https://sourceforge.net/p/alphacocoa/tickets/152/> latex mode word double-click Status: open Created: Sat Mar 24, 2018 06:56 AM UTC by Joachim Kock Last Updated: Sat Mar 24, 2018 06:56 AM UTC Owner: nobody In latex mode, if you double click on delta in \delta_n everything is selected, including the underscore n. The correct would be to have selected only \delta. (Indeed, underscore cannot be be said to be part of any notion of word in tex; it is an operator.) I have experimented with the definition of TeXmodeVars(wordBreak), but suspect that it may be a core problem. For example, the arrow keys, option-left and option-right, correctly understand that underscore is not part of a word. ________________________________ Sent from sourceforge.net<http://sourceforge.net> because alp...@li...<mailto:alp...@li...> is subscribed to https://sourceforge.net/p/alphacocoa/tickets/<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.<https://sourceforge.net/p/alphacocoa/admin/tickets/options.> Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Chris S. <cs...@us...> - 2018-03-24 06:59:21
|
Hi Bernard, I’m at home, where I only have a single screen, and so this is from memory (which my wife reliably informs me is usually at fault). In any event, with 2 screens you have a menu bar on both screen. On the screen with the active window, whichever that maybe, the menu bar is bright (like when you have a single screen). On the other screen the menu bar is faded in appearance. This changes as you work with windows on one screen or another. The Status Bar, on the other hand appears only on one window. In my case this is the left-hand screen. From memory this can be changed via the Displays System Preference. As someone with fairly monocular vision, I would find it preferable if the Status Bar had the same behaviour as the Menu Bar because, when focussed on the right-hand screen, it is easy to miss things that appear in the Status Bar, which is configured with a fairly small font. (Making the Status Bar font larger might improve things a little but it doesn’t change the fact that one’s eyes do tend to focus on just one screen at a time.) From: Bernard Desgraupes <bde...@us...<mailto:bde...@us...>> Reply-To: "[alphacocoa:tickets]" <15...@ti...<mailto:15...@ti...>> Date: Saturday, 24 March 2018 5:46 pm To: "[alphacocoa:tickets]" <15...@ti...<mailto:15...@ti...>> Subject: [alphacocoa:tickets] #150 Staus Bar Location I do not have a second screen so I'm not familiar with this setting. Does the menu bar move from one screen to the other as it becomes the active screen. Reading the doc, I had the impression that the menu bar remains on the primary screen. The active screen if called main screen in the doc: The main screen is not necessarily the same screen that contains the menu bar or has its origin at (0, 0). The main screen refers to the screen containing the window that is currently receiving keyboard events. It is the main screen because it is the one with which the user is most likely interacting. The screen containing the menu bar is always the first object (index 0) in the array returned by the screens method. ________________________________ [tickets:#150]<https://sourceforge.net/p/alphacocoa/tickets/150/> Staus Bar Location Status: open Created: Sun Mar 18, 2018 08:31 PM UTC by Chris Skeels Last Updated: Sun Mar 18, 2018 08:31 PM UTC Owner: nobody When working with 2 monitors the Menu bar is bold on whichever screen that the active window, however, the Status Bar stays firmly on the left-hand window. This seems an odd choice, especially if the Status Bar is beeing used for prompts and error messages. Is it possible to have the Status Bar appear on the monitor with the active window? If not, might that option be added? ________________________________ Sent from sourceforge.net<http://sourceforge.net> because you indicated interest in https://sourceforge.net/p/alphacocoa/tickets/150/<https://sourceforge.net/p/alphacocoa/tickets/150/> To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/<https://sourceforge.net/auth/subscriptions/> --- ** [tickets:#150] Status Bar Location** **Status:** open **Created:** Sun Mar 18, 2018 08:31 PM UTC by Chris Skeels **Last Updated:** Sat Mar 24, 2018 06:47 AM UTC **Owner:** nobody When working with 2 monitors the Menu bar is bold on whichever screen that the active window, however, the Status Bar stays firmly on the left-hand window. This seems an odd choice, especially if the Status Bar is beeing used for prompts and error messages. Is it possible to have the Status Bar appear on the monitor with the active window? If not, might that option be added? --- 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. <jk...@us...> - 2018-03-24 06:56:51
|
--- ** [tickets:#152] latex mode word double-click** **Status:** open **Created:** Sat Mar 24, 2018 06:56 AM UTC by Joachim Kock **Last Updated:** Sat Mar 24, 2018 06:56 AM UTC **Owner:** nobody In latex mode, if you double click on delta in \delta_n everything is selected, including the underscore n. The correct would be to have selected only \delta. (Indeed, underscore cannot be be said to be part of any notion of word in tex; it is an operator.) I have experimented with the definition of TeXmodeVars(wordBreak), but suspect that it may be a core problem. For example, the arrow keys, option-left and option-right, correctly understand that underscore is not part of a word. --- 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...> - 2018-03-24 06:47:12
|
- **summary**: Staus Bar Location --> Status Bar Location --- ** [tickets:#150] Status Bar Location** **Status:** open **Created:** Sun Mar 18, 2018 08:31 PM UTC by Chris Skeels **Last Updated:** Sat Mar 24, 2018 06:46 AM UTC **Owner:** nobody When working with 2 monitors the Menu bar is bold on whichever screen that the active window, however, the Status Bar stays firmly on the left-hand window. This seems an odd choice, especially if the Status Bar is beeing used for prompts and error messages. Is it possible to have the Status Bar appear on the monitor with the active window? If not, might that option be added? --- 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...> - 2018-03-24 06:46:23
|
I do not have a second screen so I'm not familiar with this setting. Does the menu bar move from one screen to the other as it becomes the active screen. Reading the doc, I had the impression that the menu bar remains on the *primary* screen. The active screen if called *main* screen in the doc: > The main screen is not necessarily the same screen that contains the menu bar or has its origin at (0, 0). The main screen refers to the screen containing the window that is currently receiving keyboard events. It is the main screen because it is the one with which the user is most likely interacting. The screen containing the menu bar is always the first object (index 0) in the array returned by the screens method. --- ** [tickets:#150] Staus Bar Location** **Status:** open **Created:** Sun Mar 18, 2018 08:31 PM UTC by Chris Skeels **Last Updated:** Sun Mar 18, 2018 08:31 PM UTC **Owner:** nobody When working with 2 monitors the Menu bar is bold on whichever screen that the active window, however, the Status Bar stays firmly on the left-hand window. This seems an odd choice, especially if the Status Bar is beeing used for prompts and error messages. Is it possible to have the Status Bar appear on the monitor with the active window? If not, might that option be added? --- 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: Chris S. <cs...@us...> - 2018-03-23 23:50:22
|
--- ** [tickets:#151] DiffBOA** **Status:** open **Created:** Fri Mar 23, 2018 11:50 PM UTC by Chris Skeels **Last Updated:** Fri Mar 23, 2018 11:50 PM UTC **Owner:** nobody I am not surewhat the recommended Diff application is but, for better or worse, I am currently using DiffBOA. In recent times I have noticed that if I try to compare windows I get error messages telling me that there is a problem setting up the Diff menu. If I just hit Continue then it seems to get over the problem and carry on correctly. I can't recall exactly when this started happening, or even if I used to use one of the other Diff apps offered under Alpha>Global Setup>Helper Applications... Sorry not to have more useful information to offer. --- 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...> - 2018-03-23 12:18:22
|
Hi Chris, thank you for reporting. I can reproduce the problem. I'll look into this. --- ** [tickets:#148] Problems with the Better Templates feature** **Status:** open **Created:** Wed Mar 14, 2018 12:33 AM UTC by Chris Skeels **Last Updated:** Wed Mar 14, 2018 12:33 AM UTC **Owner:** nobody I will illustrate the problem with a simple example. Start with the better Better Templates feature turned off and in a TeX window do the following: 1. Create an inline equation displaying the cube of x, say, using first the keystroke combination ctrl-cmd-m (which should produce \( | \) • where the | denotes the cursor, then typing x, shift-6, 3, tab, tab should leave you with \( x^{3} \)|. 2. Turn on the Better Templates feature and then repeat 1. I get \( x^{3|}• \)• Subsequent uses of the tab key moves the cursor to a variety of curious places, but never to the next bullet stop. The problem appears to be related to nested templates. For example, if, after ctrl-cmd-m I just hit tab, then the cursor moves to the bullet stop outside the environment, as it should. --- 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...> - 2018-03-22 19:43:40
|
- **status**: open --> closed - **Version**: 9.0b4 --> 9.0rc1 --- ** [tickets:#147] Encoding issues** **Status:** closed **Created:** Thu Dec 07, 2017 08:01 PM UTC by Chris Skeels **Last Updated:** Wed Mar 14, 2018 01:24 AM UTC **Owner:** nobody Milestone: Version 9.0rc1 (RC1) (31) Alpha is inconsistent in how it deals with encoding issues. Suppose I wish to open a file that I have most recently edited in AlphaX, so that I know the encoding is macRoman. If I use the menu item File>Open, or equivalently cmd-O, the Alpha opens the file quite happily. Conversely, if I drag the file from a Finder window to the Alpha icon in the Dock then I am greeted by a dialog box telling me that the file couldn't be opened using text encoding UTF8 but that I can try again using a different encoding. However, selecting Western (Mac OS Roman) is unsuccessful, as was anything else I tried. On cancelling out of this dialog I get another dialog telling me that the file couldn't be opened because it doesn't exist, although it does and it continues to open happily in AlphaX. Similarly, having successfully opened the file via File>Open, its name is now available in the File>Open Recent sub-menu.. If I select it the Alpha just silently does nothing. --- 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: Chris S. <cs...@us...> - 2018-03-18 20:32:04
|
--- ** [tickets:#150] Staus Bar Location** **Status:** open **Created:** Sun Mar 18, 2018 08:31 PM UTC by Chris Skeels **Last Updated:** Sun Mar 18, 2018 08:31 PM UTC **Owner:** nobody When working with 2 monitors the Menu bar is bold on whichever screen that the active window, however, the Status Bar stays firmly on the left-hand window. This seems an odd choice, especially if the Status Bar is beeing used for prompts and error messages. Is it possible to have the Status Bar appear on the monitor with the active window? If not, might that option be added? --- 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: Chris S. <cs...@us...> - 2018-03-14 01:24:22
|
This is not a problem that I am still seeing. This Bug should probably be closed. Cheers, Chris. --- ** [tickets:#147] Encoding issues** **Status:** open **Created:** Thu Dec 07, 2017 08:01 PM UTC by Chris Skeels **Last Updated:** Fri Dec 08, 2017 07:19 AM UTC **Owner:** nobody Milestone: Version 9.0rc1 (RC1) (31) Alpha is inconsistent in how it deals with encoding issues. Suppose I wish to open a file that I have most recently edited in AlphaX, so that I know the encoding is macRoman. If I use the menu item File>Open, or equivalently cmd-O, the Alpha opens the file quite happily. Conversely, if I drag the file from a Finder window to the Alpha icon in the Dock then I am greeted by a dialog box telling me that the file couldn't be opened using text encoding UTF8 but that I can try again using a different encoding. However, selecting Western (Mac OS Roman) is unsuccessful, as was anything else I tried. On cancelling out of this dialog I get another dialog telling me that the file couldn't be opened because it doesn't exist, although it does and it continues to open happily in AlphaX. Similarly, having successfully opened the file via File>Open, its name is now available in the File>Open Recent sub-menu.. If I select it the Alpha just silently does nothing. --- 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: Chris S. <cs...@us...> - 2018-03-14 01:17:21
|
--- ** [tickets:#149] Printing area** **Status:** open **Created:** Wed Mar 14, 2018 01:17 AM UTC by Chris Skeels **Last Updated:** Wed Mar 14, 2018 01:17 AM UTC **Owner:** nobody If one prints from Alpha then the page margins are pretty wide and, unlike many other apps, there doesn't seem to be any scope to change this. Is it possible to provide greater control over page margins when printing? --- 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: Chris S. <cs...@us...> - 2018-03-14 00:33:54
|
--- ** [tickets:#148] Problems with the Better Templates feature** **Status:** open **Created:** Wed Mar 14, 2018 12:33 AM UTC by Chris Skeels **Last Updated:** Wed Mar 14, 2018 12:33 AM UTC **Owner:** nobody I will illustrate the problem with a simple example. Start with the better Better Templates feature turned off and in a TeX window do the following: 1. Create an inline equation displaying the cube of x, say, using first the keystroke combination ctrl-cmd-m (which should produce \( | \) • where the | denotes the cursor, then typing x, shift-6, 3, tab, tab should leave you with \( x^{3} \)|. 2. Turn on the Better Templates feature and then repeat 1. I get \( x^{3|}• \)• Subsequent uses of the tab key moves the cursor to a variety of curious places, but never to the next bullet stop. The problem appears to be related to nested templates. For example, if, after ctrl-cmd-m I just hit tab, then the cursor moves to the bullet stop outside the environment, as it should. --- 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: David C. <da...@pa...> - 2018-02-09 20:14:54
|
Thank you so much — a milestone! So far, so good. David > On Feb 7, 2018, at 4:35 AM, bde...@or... wrote: > > > I have just uploaded the first release candidate for the final version of Alpha. This is Alpha RC1 (version 9.0rc1) for Mac OS X 10.9 or greater. > > See at the end of this message, the main changes contained in this new release. > > If you had previously downloaded another preview release, make sure you replace it entirely by the new one, in particular if you keep a working copy for updates as explained in TN #1: How to update the core ? and TN #3: How to update the AlphaTcl library ?. > > Please, read the release notes which will be displayed the first time you launch Alpha and can be accessed later from the Help menu. > > Here is the URL to download the disk image: > https://sourceforge.net/projects/alphacocoa/files/9.0rc1/Alpha_9.0rc1.dmg.zip/download (27.64M) > > The MD5 checksum is: b5c3fc7f1267ba3e77421728e78d60e1 > The SHA1 checksum is: 2e5aaed0d5472738b606ea15c00292c8f5ddf25a > > Don't hesitate to post bug reports, even if they concern a missing functionality which still has to be implemented. Bug reports are essential to keep track of all the deficiencies. See Alpha's Bug Tracker. > > Thank you for trying Alpha. > Cheers, > Bernard > Changes from previous version > > • New core command [spellchecker] to implement the system wide spell checking facility. > • Implemented services available to other applications. Alpha now provides two services called New Alpha Document With Selection and Open Selected File in Alpha. > • New xserv service 'OS X Spell Checker' to access the built-in Cocoa spell checker. > • New QA #4: How to enable Alpha Services ?. > • New QA #5: How to do spell checking with Alpha ?. > • New item Show/Hide Substitutions Panel in the Search menu. It lets you apply user's system-wide substitutions defined in the Keyboard/Shortcuts panel of the OS X System Preferences. > • Modified [revert] command to fix a problem with multifile replacements which blocked the application. > The following bugs have been fixed (but remain open until the fix is confirmed): > • Ticket #145: The Include menu has disappeared from HTML mode > • Ticket #146: After expansion, Math Modes menu crashes Alpha > The following tickets have been closed: > • Ticket #133: undo / redo > • Ticket #134: strange behavior of the 'undo' command for some actions > • Ticket #135: Right-arrow won't go past a dead accent > • Ticket #136: with soft wrapping, arrow keys should follow visual lines > • Ticket #137: Dynamic menu items are too slow > • Ticket #139: Problems with text selection > • Ticket #140: 'Standard Templates' function in Electric menu > • Ticket #141: Cancel 'Create A New ...' Prefs throws error > • Ticket #142: typo in tex environment name ('flushrignt') ? > • Ticket #143: Printing causes crash > • Ticket #144: AppleEvents fail on High Sierra > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > AlphaTcl-developers mailing list > Alp...@li... > http://lists.sourceforge.net/lists/listinfo/alphatcl-developers |
From: <bde...@or...> - 2018-02-07 12:35:43
|
I have just uploaded the first release candidate for the final version of Alpha. This is Alpha RC1 (version 9.0rc1) for Mac OS X 10.9 or greater. See at the end of this message, the main changes contained in this new release. If you had previously downloaded another preview release, make sure you replace it entirely by the new one, in particular if you keep a working copy for updates as explained in TN #1: How to update the core ? and TN #3: How to update the AlphaTcl library ?. Please, read the release notes which will be displayed the first time you launch Alpha and can be accessed later from the Help menu. Here is the URL to download the disk image: https://sourceforge.net/projects/alphacocoa/files/9.0rc1/Alpha_9.0rc1.dmg.zip/download (27.64M) The MD5 checksum is: b5c3fc7f1267ba3e77421728e78d60e1 The SHA1 checksum is: 2e5aaed0d5472738b606ea15c00292c8f5ddf25a Don't hesitate to post bug reports, even if they concern a missing functionality which still has to be implemented. Bug reports are essential to keep track of all the deficiencies. See Alpha's Bug Tracker. Thank you for trying Alpha. Cheers, Bernard Changes from previous version New core command [spellchecker] to implement the system wide spell checking facility. Implemented services available to other applications. Alpha now provides two services called New Alpha Document With Selection and Open Selected File in Alpha. New xserv service 'OS X Spell Checker' to access the built-in Cocoa spell checker. New QA #4: How to enable Alpha Services ?. New QA #5: How to do spell checking with Alpha ?. New item Show/Hide Substitutions Panel in the Search menu. It lets you apply user's system-wide substitutions defined in the Keyboard/Shortcuts panel of the OS X System Preferences. Modified [revert] command to fix a problem with multifile replacements which blocked the application. The following bugs have been fixed (but remain open until the fix is confirmed): Ticket #145: The Include menu has disappeared from HTML mode Ticket #146: After expansion, Math Modes menu crashes Alpha The following tickets have been closed: Ticket #133: undo / redo Ticket #134: strange behavior of the 'undo' command for some actions Ticket #135: Right-arrow won't go past a dead accent Ticket #136: with soft wrapping, arrow keys should follow visual lines Ticket #137: Dynamic menu items are too slow Ticket #139: Problems with text selection Ticket #140: 'Standard Templates' function in Electric menu Ticket #141: Cancel 'Create A New ...' Prefs throws error Ticket #142: typo in tex environment name ('flushrignt') ? Ticket #143: Printing causes crash Ticket #144: AppleEvents fail on High Sierra |
From: Bernard D. <bde...@or...> - 2017-12-08 07:24:07
|
Hi Chris, A few remarks to clarify how encodings are handled by Alpha: when a file is opened via File ↣ Open, the dialog lets you specify the encoding. when a file is opened by Drag and Drop on Alpha's icon, there is no way to know the encoding of the file, so Alpha tries the default input encoding (which is usually UTF8). If this fails, it presents a dialog asking to specify the encoding. when a file is opened via the recent files menu (File ↣ Open Recent), it means that this file was already edited recently. This menu is clever and remembers the encoding which was used the first time, so it does not ask (and it could be wrong if in the meantime the file was reencoded into something different). Some considerations useful to know about encodings: UTF8 is a multi-bytes encoding with very strict rules about the byte sequences. A character may be represented by 1 to 4 bytes, and bytes are formatted so that there is no ambiguity about whether a particular byte is the first, second, third or fourth element of a sequence. This is why if you attempt to edit as UTF8 a file which is not UTF8-encoded, it is most likely that some bytes will be seen as malformed and Alpha will scream. MacRoman, Latin1, CP1252 are single byte encodings, so if you attempt to open any file in one of these encodings, the file will be read byte by byte, and opening will never fail. Every byte will be accepted but of course may be misinterpreted if you specified the wrong (single-byte) encoding. Files in pure ascii (with all the bytes less than 127) may be successfully opened in any encoding. Ascii is a common denominator of all these encodings, including UTF8 (possibly with a few exceptions concerning control codes). Now, concerning the issue reported by this ticket, is it possible to have (privately) a file which fails to be opened as you describe ? Le 8 déc. 2017 à 02:22, Chris Skeels via AlphaCocoa-devel <alp...@li...> a écrit : > One further observation. The earlier comments were based on experience on a machine running OS X 10.9.5. I don't observe any of these symptoms on a machine running OS X 10.12.6. > > [tickets:#147] Encoding issues > > Status: open > Created: Thu Dec 07, 2017 08:01 PM UTC by Chris Skeels > Last Updated: Thu Dec 07, 2017 08:01 PM UTC > Owner: nobody > > Milestone: Version 9.0rc1 (RC1) (31) > > Alpha is inconsistent in how it deals with encoding issues. > > Suppose I wish to open a file that I have most recently edited in AlphaX, so that I know the encoding is macRoman. If I use the menu item File>Open, or equivalently cmd-O, the Alpha opens the file quite happily. Conversely, if I drag the file from a Finder window to the Alpha icon in the Dock then I am greeted by a dialog box telling me that the file couldn't be opened using text encoding UTF8 but that I can try again using a different encoding. However, selecting Western (Mac OS Roman) is unsuccessful, as was anything else I tried. On cancelling out of this dialog I get another dialog telling me that the file couldn't be opened because it doesn't exist, although it does and it continues to open happily in AlphaX. > > Similarly, having successfully opened the file via File>Open, its name is now available in the File>Open Recent sub-menu.. If I select it the Alpha just silently does nothing. > > 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. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel |
From: Bernard D. <bde...@us...> - 2017-12-08 07:19:28
|
A few remarks to clarify how encodings are handled by Alpha: * when a file is opened via File ↣ Open, the dialog lets you specify the encoding. * when a file is opened by Drag and Drop on Alpha's icon, there is no way to know the encoding of the file, so Alpha tries the default input encoding (which is usually UTF8). If this fails, it presents a dialog asking to specify the encoding. * when a file is opened via the recent files menu (File ↣ Open Recent), it means that this file was already edited recently. This menu is clever and remembers the encoding which was used the first time, so it does not ask (and it could be wrong if in the meantime the file was reencoded into something different). Some considerations useful to know about encodings: * UTF8 is a multi-bytes encoding with very strict rules about the byte sequences. A character may be represented by 1 to 4 bytes, and bytes are formatted so that there is no ambiguity about whether a particular byte is the first, second, third or fourth element of a sequence. This is why if you attempt to edit as UTF8 a file which is not UTF8-encoded, it is most likely that some bytes will be seen as malformed and Alpha will scream. * MacRoman, Latin1, CP1252 are single byte encodings, so if you attempt to open any file in one of these encodings, the file will be read byte by byte, and opening will never fail. Every byte will be accepted but of course may be misinterpreted if you specified the wrong (single-byte) encoding. * Files in pure ascii (with all the bytes less than 127) may be successfully opened in any encoding. Ascii is a common denominator of all these encodings, including UTF8 (possibly with a few exceptions concerning control codes). Now, concerning the issue reported by this ticket, is it possible to have (privately) a file which fails to be opened as you describe ? --- ** [tickets:#147] Encoding issues** **Status:** open **Created:** Thu Dec 07, 2017 08:01 PM UTC by Chris Skeels **Last Updated:** Fri Dec 08, 2017 01:22 AM UTC **Owner:** nobody Milestone: Version 9.0rc1 (RC1) (31) Alpha is inconsistent in how it deals with encoding issues. Suppose I wish to open a file that I have most recently edited in AlphaX, so that I know the encoding is macRoman. If I use the menu item File>Open, or equivalently cmd-O, the Alpha opens the file quite happily. Conversely, if I drag the file from a Finder window to the Alpha icon in the Dock then I am greeted by a dialog box telling me that the file couldn't be opened using text encoding UTF8 but that I can try again using a different encoding. However, selecting Western (Mac OS Roman) is unsuccessful, as was anything else I tried. On cancelling out of this dialog I get another dialog telling me that the file couldn't be opened because it doesn't exist, although it does and it continues to open happily in AlphaX. Similarly, having successfully opened the file via File>Open, its name is now available in the File>Open Recent sub-menu.. If I select it the Alpha just silently does nothing. --- 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: Chris S. <cs...@us...> - 2017-12-08 01:22:04
|
One further observation. The earlier comments were based on experience on a machine running OS X 10.9.5. I don't observe any of these symptoms on a machine running OS X 10.12.6. --- ** [tickets:#147] Encoding issues** **Status:** open **Created:** Thu Dec 07, 2017 08:01 PM UTC by Chris Skeels **Last Updated:** Thu Dec 07, 2017 08:01 PM UTC **Owner:** nobody Milestone: Version 9.0rc1 (RC1) (31) Alpha is inconsistent in how it deals with encoding issues. Suppose I wish to open a file that I have most recently edited in AlphaX, so that I know the encoding is macRoman. If I use the menu item File>Open, or equivalently cmd-O, the Alpha opens the file quite happily. Conversely, if I drag the file from a Finder window to the Alpha icon in the Dock then I am greeted by a dialog box telling me that the file couldn't be opened using text encoding UTF8 but that I can try again using a different encoding. However, selecting Western (Mac OS Roman) is unsuccessful, as was anything else I tried. On cancelling out of this dialog I get another dialog telling me that the file couldn't be opened because it doesn't exist, although it does and it continues to open happily in AlphaX. Similarly, having successfully opened the file via File>Open, its name is now available in the File>Open Recent sub-menu.. If I select it the Alpha just silently does nothing. --- 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: Chris S. <cs...@us...> - 2017-12-07 20:01:44
|
--- ** [tickets:#147] Encoding issues** **Status:** open **Created:** Thu Dec 07, 2017 08:01 PM UTC by Chris Skeels **Last Updated:** Thu Dec 07, 2017 08:01 PM UTC **Owner:** nobody Milestone: Version 9.0rc1 (RC1) (31) Alpha is inconsistent in how it deals with encoding issues. Suppose I wish to open a file that I have most recently edited in AlphaX, so that I know the encoding is macRoman. If I use the menu item File>Open, or equivalently cmd-O, the Alpha opens the file quite happily. Conversely, if I drag the file from a Finder window to the Alpha icon in the Dock then I am greeted by a dialog box telling me that the file couldn't be opened using text encoding UTF8 but that I can try again using a different encoding. However, selecting Western (Mac OS Roman) is unsuccessful, as was anything else I tried. On cancelling out of this dialog I get another dialog telling me that the file couldn't be opened because it doesn't exist, although it does and it continues to open happily in AlphaX. Similarly, having successfully opened the file via File>Open, its name is now available in the File>Open Recent sub-menu.. If I select it the Alpha just silently does nothing. --- 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...> - 2017-12-07 18:59:49
|
- **status**: fixed --> closed --- ** [tickets:#144] AppleEvents fail on High Sierra** **Status:** closed **Created:** Thu Oct 26, 2017 01:29 PM UTC by Bernard Desgraupes **Last Updated:** Tue Oct 31, 2017 03:12 PM UTC **Owner:** nobody Sad news: most of Alpha's functionalities which rely on AppleEvents fail on Mac OS X 10.13 (aka High Sierra). As a consequence: one cannot open a file from a *Fileset* or from the *Recent Files* menu, one cannot use the *[edit]* proc, one cannot send a string for evaluation in R, one cannot use Excalibur for spell checking, etc, etc. Technically, it seems that this is caused by changes in the aegizmo syntax: the API function *AEBuildDesc* now reports errors for strings which used to work on previous versions of the operating system. I'm currently investigating this issue which will require changes in Alpha's core, in the AlphaTcl library and in the tclAE extension. So, if Alpha is vital for your work, I'd recommend *NOT* to upgrade your OS to High Sierra until version 9.0b4 of Alpha is released. Note though that only the functionalities based on AppleEvents are currently impacted: the rest of Alpha works normally. --- 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...> - 2017-12-07 18:59:11
|
- **status**: fixed --> closed --- ** [tickets:#142] typo in tex environment name ("flushrignt") ?** **Status:** closed **Created:** Wed Oct 25, 2017 12:06 PM UTC by Sylvain Loiseau **Last Updated:** Wed Oct 25, 2017 01:01 PM UTC **Owner:** nobody in TeXcmds.tcl there are two occurrences of flushrignt that most probably should be turned into flushright. --- 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...> - 2017-12-07 18:58:53
|
- **status**: fixed --> closed --- ** [tickets:#141] Cancel 'Create A New ...' Prefs throws error** **Status:** closed **Created:** Mon Oct 09, 2017 12:38 AM UTC by Chris Skeels **Last Updated:** Fri Oct 20, 2017 04:03 AM UTC **Owner:** nobody **Attachments:** - [Create_A_New….pdf](https://sourceforge.net/p/alphacocoa/tickets/141/attachment/Create_A_New%E2%80%A6.pdf) (87.4 kB; application/pdf) With New Document feature turned on: Select File > New > Create A New ... Then select the Prefs buttion in the resulting window followed by Cancel in the window that this action produces. The error thrown is shown in the attachment. --- 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...> - 2017-12-07 18:58:32
|
- **status**: fixed --> closed --- ** [tickets:#140] "Standard Templates" function in Electric menu** **Status:** closed **Created:** Thu Sep 14, 2017 01:51 PM UTC by Sylvain Loiseau **Last Updated:** Thu Sep 14, 2017 03:31 PM UTC **Owner:** nobody I create a standard template containing the "\" character, for instance in the string "\begin{itemize}". Then, I invoque this template. The string inserted in the file looks like "egin{itemize}". Looking in the prefs.tcl file, it appears that the"\" is not escaped. If I escape it (changing "\begin{itemize}" into "\\begin{itemize}" into the prefs.tcl file), the correct string is inserted. It seems the issue is around quote::Insert $template in electricMenu.tcl line 2982. --- 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. |