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: John M. <joh...@ed...> - 2019-11-04 03:08:10
|
Hi, I’m having a problem searching in file sets. I did not find any tickets discussing this problem. Before I spend a lot of time researching the problem, I would like to know if it is already on the developers’ radar. The problem is twofold. First, I seem to have to reselect the fileset to search each time I enter the Find dialog. It would be nice if the selection persisted from one instance of the search to the next. Second, and much more importantly, searching inside a fileset seems to change how the Regexp search works. Simple searches (those not using any grep at all and some using just simple grep) seem to work fine. However, a somewhat more complex search fails completely. It does not find anything in the current window and does not find anything in any of the other files in the fileset. For what it’s worth, I am using TeX filesets in Alpha 9.1 running on a 2014 MacBook Pro under Mojave (10.14.6). The “more complex” search that is giving me trouble right now has (?s)(monetary)(( +)| *(\n) *)(polic[^\s]+) in the Find field and \1-\5\4 in the Replace field. The response I get in the status bar is “Can’t find '(?s)(monetary)(( +)| *(\n) *)(polic[^\s]+)'; and there are no more files to search.” A partial work around to this problem is to press command-G after I get that error, which takes me through all instances of the search in that file. However, that does not cycle through the other files in the fileset. Finally, this problem does not seem to be restricted to filesets. Any selection In the Multiple Files panel seems to cause this problem. Best, John |
From: Bernard D. <bde...@or...> - 2019-10-17 12:05:16
|
Hi all, I'm pleased to announce the release of a new version of Alpha. This is Alpha 9.1 ("Peacock <file:///Users/bernardo/Workspace/Devel/Code/AlphaCocoa/Output/Release/9.1/AlphaStar.html>") for Mac OS X 10.11 or greater (El Capitan, Sierra, High Sierra, Mojave, Catalina). All versions of Alpha are named after a star. So, for this new release, meet Peacock <https://alphacocoa.sourceforge.io/AlphaStar.html>, which is α Pavonis, the α star of the Pavo constellation. Beware: the Maverick (10.9) and Yosemite (10.10) versions of OS X are no longer supported. The latest version of Alpha running on these two systems is 9.0.3. See at the end of this message, the main changes contained in this new release. Please, read the release notes which will be displayed the first time you launch Alpha and can be accessed later from the Help ↣ Developer Help menu. Here is the URL to download the disk image: https://sourceforge.net/projects/alphacocoa/files/9.1/Alpha_9.1.dmg.zip/download <https://sourceforge.net/projects/alphacocoa/files/9.1/Alpha_9.1.dmg.zip/download> (30.79M) The MD5 checksum is: bc77e45c968d5639f3f49cab3a57ec80 The SHA1 checksum is: 33561f89b45a36e2c0ac619627e5b1eeccdeabc6 The RMD160 checksum is: 194be0904adf680c8923e1d22db7d055cd8eac4e The SHA256 checksum is: c0913e2d2b7819a94f6be06fdc7c1622ebee6e76a63963e206ecf83ec05f7244 If you find problems with the application, don't hesitate to post bug reports. They are essential to keep track of the deficiencies. See Alpha's Bug Tracker <https://sourceforge.net/p/alphacocoa/tickets/>. Thank you for using Alpha. Cheers, Bernard <>Changes from previous version New help search facility via the Search Field located at the top of the Help menu. New package Character Palettes <https://alphacocoa.sourceforge.io/CharacterPalettesHelp.html> that provides palettes to insert special characters. New package Box Drawings <https://alphacocoa.sourceforge.io/BoxDrawingsHelp.html> that provides commands to draw a frame around a text selection or draw table borders for a tabulated block of text. It also features a Box characters palette. New LaTeX palette in TeX mode. It is a multipage palette that displays the mathematical symbols and inserts the corresponding LaTeX macro. The Special Characters submenus are now dynamic: characters with an uppercase form are obtained by pressing the Shift (⇧) key while the menu is opened. There is also a new submenu called User Characters to display user defined characters: the list of characters that will appear in this submenu is specified via the new User Special Characters global preference. New package Text Alignment that provides commands to align blocks of text (center, left, right). New internal library Country Flags that provides commands to get the special characters for country flags. New menu item Go To Previous Position in Go To submenu. Bound to ⌃⌥P. Package Latex Sizes has been renamed Latex Macros Cycle <https://alphacocoa.sourceforge.io/LatexMacrosCycleHelp.html>. The [view] <file:///Users/bernardo/Workspace/Devel/Code/AlphaCocoa/Current/Libraries/AlphaTcl/Help/Reference/view.html#cmd_view> command now allows you to create CollectionView <https://alphacocoa.sourceforge.io/Reference/view.html#view_collectionview> objects which are ordered collections of data items displayed in a customizable layout. New keys textContainer, textFrame, bottomBarHeight, topBarHeight, leftMarginWidth for the [getWinInfo] <https://alphacocoa.sourceforge.io/Syntax/getWinInfo.html> command. Revised windowZoom package (version 1.3). Thanks Joachim! New options -format and -locale for [mtime] <file:///Users/bernardo/Workspace/Devel/Code/AlphaCocoa/Current/Libraries/AlphaTcl/Help/Syntax/mtime.html#cmd_mtime>. The [mtime] <https://alphacocoa.sourceforge.io/Syntax/mtime.html> and [now] <https://alphacocoa.sourceforge.io/Syntax/now.html> commands now use the Unix epoch by default rather than the Mac epoch. The [now] command has a -mac option for compatibility. New subcommand [view children] <https://alphacocoa.sourceforge.io/Reference/view.html#cmd_view_children> to list the children views of a given view or root window. New mode Swift to support the editing of Swift programming files. The following bugs have been fixed (but remain open until the fix is confirmed): Ticket #217: HTML and CSS Mode Help uses yellow font towards the end. <https://sourceforge.net/p/alphacocoa/tickets/217/> Ticket #218: LASTMODIFIED <https://sourceforge.net/p/alphacocoa/tickets/218/> Ticket #219: focus shifts to end of line on indent <https://sourceforge.net/p/alphacocoa/tickets/219/> Ticket #220: saveHook error with multiple untitled documents <https://sourceforge.net/p/alphacocoa/tickets/220/>The following tickets have been closed: Ticket #215: status bar: file size <https://sourceforge.net/p/alphacocoa/tickets/215/> Ticket #216: Alpha No Longer Warns about Inconsistent Line Terminations (Line Endings) <https://sourceforge.net/p/alphacocoa/tickets/216/> |
From: Bernard D. <bde...@us...> - 2019-10-17 11:27:23
|
- **status**: fixed --> closed --- ** [tickets:#216] Alpha No Longer Warns about Inconsistent Line Terminations (Line Endings)** **Status:** closed **Created:** Sun Jun 23, 2019 02:15 AM UTC by jwq **Last Updated:** Thu Jul 04, 2019 05:14 PM UTC **Owner:** nobody I have files which *somehow* have mixed line ending markers. When these are opened in Alpha: 1. Alpha does not display the inconsistent line termination warning (it does display a wrap paragraph warning). 2. Alpha's window substitutes '\n' for '\r' so that a regexp search fails to find the '\r' characters which are present in the file. It would be great to have this fixed. --- 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...> - 2019-10-17 11:26:27
|
- **status**: fixed --> closed - **Version**: 9.0.5 --> 9.0 --- ** [tickets:#215] status bar: file size ** **Status:** closed **Created:** Mon Jun 17, 2019 12:40 PM UTC by ddforge **Last Updated:** Mon Jun 17, 2019 06:24 PM UTC **Owner:** nobody AlphaX used to display the size of a file every time it was saved in the status bar. For me, this is by far more handy than the menu item "word count", because I dont even need to touch the keyboard or mouse. Any chance to see the feature in AlphaCocoa? --- 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...> - 2019-10-06 08:36:51
|
- **status**: open --> fixed --- ** [tickets:#219] focus shifts to end of line on indent** **Status:** fixed **Created:** Fri Oct 04, 2019 07:07 AM UTC by Joachim Kock **Last Updated:** Sun Oct 06, 2019 08:36 AM UTC **Owner:** nobody With a very long line extending beyond the visible area, suppose you are near the beginning, and press Cmd-[ to indent the line. The indentation works correctly, and the cursor position is correctly preserved, but the focus shifts to the end of the line (which is so far right that the beginning of the line is then invisible. --- 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...> - 2019-10-06 08:36:36
|
This is fixed. The* [text replace] *command has a nice *-preserve* option which prevents the focus to move. Changes committed to the repository ([rev. 1790](https://sourceforge.net/p/alphacocoa/code/1790/)). --- ** [tickets:#219] focus shifts to end of line on indent** **Status:** open **Created:** Fri Oct 04, 2019 07:07 AM UTC by Joachim Kock **Last Updated:** Fri Oct 04, 2019 11:23 AM UTC **Owner:** nobody With a very long line extending beyond the visible area, suppose you are near the beginning, and press Cmd-[ to indent the line. The indentation works correctly, and the cursor position is correctly preserved, but the focus shifts to the end of the line (which is so far right that the beginning of the line is then invisible. --- 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...> - 2019-10-06 08:18:48
|
- **status**: open --> fixed --- ** [tickets:#220] saveHook error with multiple untitled documents** **Status:** fixed **Created:** Fri Oct 04, 2019 07:05 PM UTC by Joachim Kock **Last Updated:** Sun Oct 06, 2019 08:18 AM UTC **Owner:** nobody With the backup feature activated, try to save the second of some untitled windows. The actual save operation is accomplished correctly, but the following error is raised at the same time: 'saveHook' hook error log for proc 'backupOnSave': could not read "untitled": no such file or directory - errorInfo: could not read "untitled": no such file or directory while executing "file size $name" (procedure "backupOnSave" line 10) invoked from within "backupOnSave {untitled <2>}" ("eval" body line 1) invoked from within "eval backupOnSave {{untitled <2>}}" ("uplevel" body line 1) invoked from within "uplevel \#0 [list eval $proc $args]" --- 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...> - 2019-10-06 08:18:39
|
This is fixed. The *backupOnSave* proc was calling* [file size] *on a file which does not exist on disk. Changes committed to the repository ([rev. 1789](https://sourceforge.net/p/alphacocoa/code/1789/)). --- ** [tickets:#220] saveHook error with multiple untitled documents** **Status:** open **Created:** Fri Oct 04, 2019 07:05 PM UTC by Joachim Kock **Last Updated:** Fri Oct 04, 2019 07:05 PM UTC **Owner:** nobody With the backup feature activated, try to save the second of some untitled windows. The actual save operation is accomplished correctly, but the following error is raised at the same time: 'saveHook' hook error log for proc 'backupOnSave': could not read "untitled": no such file or directory - errorInfo: could not read "untitled": no such file or directory while executing "file size $name" (procedure "backupOnSave" line 10) invoked from within "backupOnSave {untitled <2>}" ("eval" body line 1) invoked from within "eval backupOnSave {{untitled <2>}}" ("uplevel" body line 1) invoked from within "uplevel \#0 [list eval $proc $args]" --- 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...> - 2019-10-06 06:56:53
|
- **status**: open --> fixed --- ** [tickets:#218] LASTMODIFIED** **Status:** fixed **Created:** Tue Aug 13, 2019 07:11 AM UTC by Christoph Schiller **Last Updated:** Sun Oct 06, 2019 06:56 AM UTC **Owner:** nobody The LASTMODIFIED command in BRITISH version produces <!-- #LASTMODIFIED TEXT="" FORM="LONG" LANG="British"--> 13. August 2019 <!-- /#LASTMODIFIED --> </span> whereas the dot should be missing in British dates: <!-- #LASTMODIFIED TEXT="" FORM="LONG" LANG="British"--> 13 August 2019 <!-- /#LASTMODIFIED --> </span> --- 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...> - 2019-10-06 06:56:35
|
This is fixed. There is now a much better support for locales. Added some new languages (japanese, chinese). Changes committed to the repository ([rev. 1788](https://sourceforge.net/p/alphacocoa/code/1788/)). The core must be rebuilt. --- ** [tickets:#218] LASTMODIFIED** **Status:** open **Created:** Tue Aug 13, 2019 07:11 AM UTC by Christoph Schiller **Last Updated:** Fri Oct 04, 2019 11:24 AM UTC **Owner:** nobody The LASTMODIFIED command in BRITISH version produces <!-- #LASTMODIFIED TEXT="" FORM="LONG" LANG="British"--> 13. August 2019 <!-- /#LASTMODIFIED --> </span> whereas the dot should be missing in British dates: <!-- #LASTMODIFIED TEXT="" FORM="LONG" LANG="British"--> 13 August 2019 <!-- /#LASTMODIFIED --> </span> --- 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...> - 2019-10-04 19:05:03
|
--- ** [tickets:#220] saveHook error with multiple untitled documents** **Status:** open **Created:** Fri Oct 04, 2019 07:05 PM UTC by Joachim Kock **Last Updated:** Fri Oct 04, 2019 07:05 PM UTC **Owner:** nobody With the backup feature activated, try to save the second of some untitled windows. The actual save operation is accomplished correctly, but the following error is raised at the same time: 'saveHook' hook error log for proc 'backupOnSave': could not read "untitled": no such file or directory - errorInfo: could not read "untitled": no such file or directory while executing "file size $name" (procedure "backupOnSave" line 10) invoked from within "backupOnSave {untitled <2>}" ("eval" body line 1) invoked from within "eval backupOnSave {{untitled <2>}}" ("uplevel" body line 1) invoked from within "uplevel \#0 [list eval $proc $args]" --- 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...> - 2019-10-04 11:24:34
|
Sorry, I missed this mid-summer bug ! I'll fix this. --- ** [tickets:#218] LASTMODIFIED** **Status:** open **Created:** Tue Aug 13, 2019 07:11 AM UTC by Christoph Schiller **Last Updated:** Tue Aug 13, 2019 07:15 AM UTC **Owner:** nobody The LASTMODIFIED command in BRITISH version produces <!-- #LASTMODIFIED TEXT="" FORM="LONG" LANG="British"--> 13. August 2019 <!-- /#LASTMODIFIED --> </span> whereas the dot should be missing in British dates: <!-- #LASTMODIFIED TEXT="" FORM="LONG" LANG="British"--> 13 August 2019 <!-- /#LASTMODIFIED --> </span> --- 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...> - 2019-10-04 11:23:34
|
You're right, this is unpleasant. I'll try to fix this. --- ** [tickets:#219] focus shifts to end of line on indent** **Status:** open **Created:** Fri Oct 04, 2019 07:07 AM UTC by Joachim Kock **Last Updated:** Fri Oct 04, 2019 07:07 AM UTC **Owner:** nobody With a very long line extending beyond the visible area, suppose you are near the beginning, and press Cmd-[ to indent the line. The indentation works correctly, and the cursor position is correctly preserved, but the focus shifts to the end of the line (which is so far right that the beginning of the line is then invisible. --- 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...> - 2019-10-04 07:07:27
|
--- ** [tickets:#219] focus shifts to end of line on indent** **Status:** open **Created:** Fri Oct 04, 2019 07:07 AM UTC by Joachim Kock **Last Updated:** Fri Oct 04, 2019 07:07 AM UTC **Owner:** nobody With a very long line extending beyond the visible area, suppose you are near the beginning, and press Cmd-[ to indent the line. The indentation works correctly, and the cursor position is correctly preserved, but the focus shifts to the end of the line (which is so far right that the beginning of the line is then invisible. --- 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...> - 2019-10-04 07:03:38
|
I still see this. Cmd-right and Cmd-shift-right work as expected, but Cmd-left and Cmd-shift-left still jump all the way to the start of the logical line, rather than following the visual line. (This is in 9.0.7.) The culprit turns out to be [beginningOfLineSmart], which in turn relies on the Alpha command [beginningOfLine], which only works on logical lines. Is there some alternative that can be used instead, to get to the beginning of the visual line? --- ** [tickets:#181] Cmd-arrow should follow visual line, not logical** **Status:** closed **Created:** Wed Sep 26, 2018 08:02 PM UTC by Joachim Kock **Last Updated:** Tue Feb 19, 2019 09:51 AM UTC **Owner:** nobody With flowed text, cmd-left and cmd-right should follow visual line, not logical line. Same problem with shift-cmd-arrow. --- 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...@or...> - 2019-10-04 05:39:07
|
Hi Joachim, I have tested the new windowZoom package which works nicely! I just wanted to mention a few details in the proc [winZoom::trueZoom]. You get the geometry of the current window using [getGeometry]. I think you should rather use [getGeometry -c] where the -c option means that you get the content view’s frame: this is the entire window minus the toolbar and title bar. This contents rect includes the top control bar (with the popups) and the bottom message bar (with the row and column indicators). Their height is 22 and 15 pixels respectively. BTW this is the 22 pixels you asked me about a few days ago (I hadn’t realised at the moment). You could make more precise calculations with these values. Then at the end, to resize the window, you could use the [setGeometry] command which also supports the -c option. In order to make things more accurate, I have now defined two new keys for the[ getWinInfo] command: topBarHeight and bottomBarHeight so that you don’t need to hardwire the values 22 and 15 pixels. This new command returns the exact value (in particular, it would return 0 for a window created without a top or bottom bar). I can send you a development release of Alpha 9.1 if you want to play with this. Cheers, Bernard > Le 2 oct. 2019 à 17:06, Bernard Desgraupes <bde...@or...> a écrit : > > Thank you Joachim for the revised package. I’ll test it tomorrow. > > Concerning the checkout error, this is my fault. There is a typo in the updateAlphaTcl shell script at line 213. It says: > if [ -e UA_TEMP_ALPHATCL ] ; then > > and it should be > if [ -e $UA_TEMP_ALPHATCL ] ; then > > The dollar sign must have been erased accidentally. > This script is located in Alpha.app/Contents/Resources/Libraries/Extras. > > Sorry about that. > > Cheers, > Bernard > >> Le 2 oct. 2019 à 09:16, Joachim Kock <ko...@ma...> a écrit : >> >> Hi Bernard, >> >> I have a problem with developer check-out, >> invoked from the Update Menu: >> >> I always get a message like this (in a Terminal window): >> >> Checked out revision 1782. >> ...done >> can't find exported AlphaTcl - synchronization failed >> * removing temp dir >> >> This happens after >> >> /Users/kock/Applications/Alpha.app/Contents/Resources/Libraries/Extras/updateAlphaTcl -d /Users/kock/Applications/Alpha.app >> * creating temp dir... >> /var/folders/lx/v70nzsd96w19vr_gz101p_pm0000gn/T/alphatcl_svn.Xin8VQvH >> * performing checkout... >> A AlphaTcl/Tcl >> >> Any hint? >> >> Meanwhile, I attach the current windowZoom.tcl. >> It seems stable enough in specific tests, but it >> is not something I have tested extensively in >> daily use -- normally my windows already have the >> size I want. >> >> Actually the file contains a 'work-around', namely >> to ensure that zooming does not produce windows >> extending beyond the screen size. I think in the >> old Alphas this was automatic by default. Actually, >> while the zoom mechanism does this check manually, >> the standard win-resize procs such as shrinkDefault >> do not :-( They give a window whose lower scroll >> bar is outside the screen. The work-around could >> be applied to all these procs, but I wonder if not >> the old behaviour is actually preferrable... >> >> Cheers, >> Joachim. >> >> >> >> On 01/10/2019 12:49, Bernard Desgraupes wrote: >>> Hi Joachim, >>> did you finish your revision of the windowZoom package ? Is it ready for testing and inclusion in Alpha ? >>> No pressure intended, just wanted to know as a new release is on the rails. >>> Cheers, >>> Bernard >> <windowZoom.tcl> > |
From: Bernard D. <bde...@or...> - 2019-10-01 10:49:21
|
Hi Joachim, did you finish your revision of the windowZoom package ? Is it ready for testing and inclusion in Alpha ? No pressure intended, just wanted to know as a new release is on the rails. Cheers, Bernard |
From: Joachim K. <ko...@ma...> - 2019-09-22 06:10:22
|
Hi Bernard, thanks for looking into this. It is not worth spending more time on it. The offsets I found empirically work very well, so I'll just leave it at that. I will soon (well, at some point) commit a revision of the winZoom stuff. Cheers, Joachim. On 13/09/2019 15:51, Bernard Desgraupes wrote: > Hi Joachim, > > I’ve been looking at this and my guess is that the horizontal offset you need to add is due to the line numbers margin. Unfortunately this margin does not have a fixed width: that depends on the number of lines. If there are less than 10 lines, the margin is large enough to display 1-digit numbers, if it is between 10 and 99 it is large enough to display 2-digits numbers, etc. > This certainly complicates your calculations… > If necessary I could let the core provide the information about the line margin width (via getWinInfo). > > Now vertically, as I said before I think the offset is the title bar’s height (possibly augmented by the toolbar’s height). > > What do you think ? > > Bernard > >> Le 6 sept. 2019 à 21:56, Joachim Kock <ko...@ma...> a écrit : >> >> Hi Bernard, >> >> I am revising the windowZoom package. >> >> When I wrote it many years ago for AlphaX, >> I had to use some ad hoc home-made font- >> metrics tables valid only for Monaco :-( >> In AlphaCocoa, this looks childish, as we now have >> getWinInfo charWidth and getWinInfo lineHeight :-) >> Really cool -- it simplifies a lot. >> >> My question is about two offsets that seem >> required. I have determined them empirically: >> 12 horizontally and 63 vertically. So that >> the final calculation of window dimensions to >> hold $rowNum lines of $colNum chars (at a given >> font) is: >> >> # Calculate new geometry >> set x [getWinInfo charWidth] >> set y [getWinInfo lineHeight] >> set newWidth [expr {$x * $colNum + 12}] >> set newHeight [expr {$y * $rowNum + 63}] >> >> However, I cannot figure out how to explain >> these offsets. For example, the difference betweem >> getGeometry and getCeometry -c gives a vertical >> difference of 22 (and no horizontal difference). >> I have tried with line numbers turned off, but >> it does not seem to make any difference. >> >> Do you know how to determine these offsets in >> a more formal way, and what they depend on? >> >> Thanks! -- and no hurry. >> >> Cheers, >> Joachim. >> >> >> >> _______________________________________________ >> AlphaCocoa-devel mailing list >> Alp...@li... >> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel > |
From: Bernard D. <bde...@or...> - 2019-09-13 13:51:37
|
Hi Joachim, I’ve been looking at this and my guess is that the horizontal offset you need to add is due to the line numbers margin. Unfortunately this margin does not have a fixed width: that depends on the number of lines. If there are less than 10 lines, the margin is large enough to display 1-digit numbers, if it is between 10 and 99 it is large enough to display 2-digits numbers, etc. This certainly complicates your calculations… If necessary I could let the core provide the information about the line margin width (via getWinInfo). Now vertically, as I said before I think the offset is the title bar’s height (possibly augmented by the toolbar’s height). What do you think ? Bernard > Le 6 sept. 2019 à 21:56, Joachim Kock <ko...@ma...> a écrit : > > Hi Bernard, > > I am revising the windowZoom package. > > When I wrote it many years ago for AlphaX, > I had to use some ad hoc home-made font- > metrics tables valid only for Monaco :-( > In AlphaCocoa, this looks childish, as we now have > getWinInfo charWidth and getWinInfo lineHeight :-) > Really cool -- it simplifies a lot. > > My question is about two offsets that seem > required. I have determined them empirically: > 12 horizontally and 63 vertically. So that > the final calculation of window dimensions to > hold $rowNum lines of $colNum chars (at a given > font) is: > > # Calculate new geometry > set x [getWinInfo charWidth] > set y [getWinInfo lineHeight] > set newWidth [expr {$x * $colNum + 12}] > set newHeight [expr {$y * $rowNum + 63}] > > However, I cannot figure out how to explain > these offsets. For example, the difference betweem > getGeometry and getCeometry -c gives a vertical > difference of 22 (and no horizontal difference). > I have tried with line numbers turned off, but > it does not seem to make any difference. > > Do you know how to determine these offsets in > a more formal way, and what they depend on? > > Thanks! -- and no hurry. > > Cheers, > Joachim. > > > > _______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel |
From: Bernard D. <bde...@or...> - 2019-09-07 17:14:18
|
Hi Joachim, II do not know exactly why this is so. I also observed this when I used the -shrink option: we do not quite get what we want, but I never took the time to understand the problem. I will look at this more closely and try to solve this problem. Your question about getGeometry is different. The difference between getGeometry and getGeometry -c is the window decoration: vertically this is the height of the title bar. I guess that you have hidden the toolbar. When the toolbar is there then the difference is 65 instead of 22. More on this later. Cheers, Bernard > Le 6 sept. 2019 à 21:56, Joachim Kock <ko...@ma...> a écrit : > > Hi Bernard, > > I am revising the windowZoom package. > > When I wrote it many years ago for AlphaX, > I had to use some ad hoc home-made font- > metrics tables valid only for Monaco :-( > In AlphaCocoa, this looks childish, as we now have > getWinInfo charWidth and getWinInfo lineHeight :-) > Really cool -- it simplifies a lot. > > My question is about two offsets that seem > required. I have determined them empirically: > 12 horizontally and 63 vertically. So that > the final calculation of window dimensions to > hold $rowNum lines of $colNum chars (at a given > font) is: > > # Calculate new geometry > set x [getWinInfo charWidth] > set y [getWinInfo lineHeight] > set newWidth [expr {$x * $colNum + 12}] > set newHeight [expr {$y * $rowNum + 63}] > > However, I cannot figure out how to explain > these offsets. For example, the difference betweem > getGeometry and getCeometry -c gives a vertical > difference of 22 (and no horizontal difference). > I have tried with line numbers turned off, but > it does not seem to make any difference. > > Do you know how to determine these offsets in > a more formal way, and what they depend on? > > Thanks! -- and no hurry. > > Cheers, > Joachim. > > > > _______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel |
From: Joachim K. <ko...@ma...> - 2019-09-06 20:57:10
|
Hi Bernard, I am revising the windowZoom package. When I wrote it many years ago for AlphaX, I had to use some ad hoc home-made font- metrics tables valid only for Monaco :-( In AlphaCocoa, this looks childish, as we now have getWinInfo charWidth and getWinInfo lineHeight :-) Really cool -- it simplifies a lot. My question is about two offsets that seem required. I have determined them empirically: 12 horizontally and 63 vertically. So that the final calculation of window dimensions to hold $rowNum lines of $colNum chars (at a given font) is: # Calculate new geometry set x [getWinInfo charWidth] set y [getWinInfo lineHeight] set newWidth [expr {$x * $colNum + 12}] set newHeight [expr {$y * $rowNum + 63}] However, I cannot figure out how to explain these offsets. For example, the difference betweem getGeometry and getCeometry -c gives a vertical difference of 22 (and no horizontal difference). I have tried with line numbers turned off, but it does not seem to make any difference. Do you know how to determine these offsets in a more formal way, and what they depend on? Thanks! -- and no hurry. Cheers, Joachim. |
From: Dr E. W L. <el...@li...> - 2019-09-04 15:15:36
|
Thank you, that was the question and is the answer :-)-O greetings, el On 04/09/2019 17:01, Bernard Desgraupes wrote: > Hi Eberhard, > > Do I understand correctly: you mean you want to replace every occurence of > <mailto:some_email> > by > some_email > > It this is the question, then: > > - put the following regular expression in the Search field of the Find dialog > <mailto:([^@]+@[^>]+)> > > > - type > \1 > in the Replace field > > - check the Regexp check box > > - click on the Replace All button if you want all of them to be replaced > OR click Search Window and replace one by one by pressing cmd-J on every match > > > HTH, > Bernard > > >> Le 4 sept. 2019 à 12:31, Dr Eberhard W Lisse <el...@li...> a écrit : >> >> Hi, >> >> I can do a search with regular expression, as in something like >> >> <mailto:(.*\@.*\..*)> >> >> which will find >> >> <mailto:el...@li...> >> >> but I can find out whether and if to replace (all occurrences of) the >> above so that the outcome is the obvious >> >> el...@li... >> >> ie replace the whole regex with $1, and would appreciate pointers to the >> manual if this is possible. >> >> If it does not exist, would that bea useful feature? >> >> greetings, el >> >> -- >> Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) >> el...@li... / * | Telephone: +264 81 124 6733 (cell) >> PO Box 8421 / >> Bachbrecht, Namibia ;____/ >> >> >> _______________________________________________ >> AlphaCocoa-devel mailing list >> Alp...@li... >> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel -- Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) el...@li... / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 / Bachbrecht, Namibia ;____/ |
From: Bernard D. <bde...@or...> - 2019-09-04 15:09:10
|
Hi Eberhard, Do I understand correctly: you mean you want to replace every occurence of <mailto:some_email> by some_email It this is the question, then: - put the following regular expression in the Search field of the Find dialog <mailto:([^@]+@[^>]+)> - type \1 in the Replace field - check the Regexp check box - click on the Replace All button if you want all of them to be replaced OR click Search Window and replace one by one by pressing cmd-J on every match HTH, Bernard > Le 4 sept. 2019 à 12:31, Dr Eberhard W Lisse <el...@li...> a écrit : > > Hi, > > I can do a search with regular expression, as in something like > > <mailto:(.*\@.*\..*)> > > which will find > > <mailto:el...@li...> > > but I can find out whether and if to replace (all occurrences of) the > above so that the outcome is the obvious > > el...@li... > > ie replace the whole regex with $1, and would appreciate pointers to the > manual if this is possible. > > If it does not exist, would that bea useful feature? > > greetings, el > > -- > Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) > el...@li... / * | Telephone: +264 81 124 6733 (cell) > PO Box 8421 / > Bachbrecht, Namibia ;____/ > > > _______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel |
From: Dr E. W L. <el...@li...> - 2019-09-04 10:32:46
|
That should have read "...can NOT find out..." of course. el On 04/09/2019 12:31, Dr Eberhard W Lisse wrote: > Hi, > > I can do a search with regular expression, as in something like > > <mailto:(.*\@.*\..*)> > > which will find > > <mailto:el...@li...> > > but I can find out whether and if to replace (all occurrences of) the > above so that the outcome is the obvious > > el...@li... > > ie replace the whole regex with $1, and would appreciate pointers to the > manual if this is possible. > > If it does not exist, would that bea useful feature? > > greetings, el > -- Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) el...@li... / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 / Bachbrecht, Namibia ;____/ |
From: Dr E. W L. <el...@li...> - 2019-09-04 10:31:45
|
Hi, I can do a search with regular expression, as in something like <mailto:(.*\@.*\..*)> which will find <mailto:el...@li...> but I can find out whether and if to replace (all occurrences of) the above so that the outcome is the obvious el...@li... ie replace the whole regex with $1, and would appreciate pointers to the manual if this is possible. If it does not exist, would that bea useful feature? greetings, el -- Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) el...@li... / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 / Bachbrecht, Namibia ;____/ |