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...@gm...> - 2017-04-10 06:09:30
|
Yes I was surprised it disappeared like that. We must understand why your Alpha is executed in a AppTranslocation directory. This certainly has to do with the CodeSigning paranoïa. Alpha is not codesigned at the moment. I never ventured in these areas so right now I'm clueless. |
|
From: Joachim K. <jk...@us...> - 2017-04-09 17:05:24
|
I don't know how to inspect the pasteboard, but I think the best would be to see what AlphaX does, which different formats it leaves there on Copy. Since by experience pasteboard content from AlphaX does not have any formatting, I guess this means that there is no Rich Text or similar. I think it is a good idea in AlphaCocoa to remove this Rich Text manually after each Copy operation, and I don't see how it could break internal Copy-and Paste, since in any case it appears that when Alpha pastes, it does not use any of the Rich Text formats. --- ** [tickets:#120] Copy copies also font info** **Status:** open **Created:** Tue Apr 04, 2017 07:31 PM UTC by Joachim Kock **Last Updated:** Tue Apr 04, 2017 09:50 PM UTC **Owner:** nobody Alpha (in contrast to AlphaX) copies text WITH formatting, instead of just copying the text as a sequence of chars. I think this is wrong, since the formatting is not an attribute of the text copied but only an artefact of how the text editor presents the text on screen. (In practical terms, when from time to time I have to edit a Word document, I always found it useful to do as much as possible of the editing in AlphaX, before pasting it into Word, where it will be inserted free of formatting. I hope this use of AlphaX can be inherited by Alpha.) If for some reason the new behaviour is deemed useful, perhaps this is not a bug report but a feature request: could we then have a prefs flag for controlling this, please? --- 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: Vittorio <vit...@us...> - 2017-04-09 16:59:19
|
The problem is still there, sorry for claiming it was over. (Alpha 9.0b2 OSX Sierra 10.12.4) I think it is related to the global variable $HOME. In the tcl shell I get «» puts $HOME /private/var/folders/../AppTranslocation/../Alpha.app/Contents/Resources/Libraries/AlphaTcl Vittorio --- ** [tickets:#71] Error in Developer Checkout** **Status:** closed **Created:** Tue Nov 29, 2016 11:24 AM UTC by Vittorio **Last Updated:** Fri Mar 31, 2017 05:48 PM UTC **Owner:** nobody The procedure seem to work fine, at the end I get the message: Message: "error deleting "/private/var/folders/.../AlphaCocoa.app/Contents/Resources/Libraries/AlphaTcl": read-only file system" --- 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...> - 2017-04-09 16:57:22
|
--- ** [tickets:#124] link detection dirties window** **Status:** open **Created:** Sun Apr 09, 2017 04:57 PM UTC by Joachim Kock **Last Updated:** Sun Apr 09, 2017 04:57 PM UTC **Owner:** nobody Open the file fileManipulation.tcl in the AlphaTcl library. Close it again without doing anything. A dialogue asks to save changes, discard or cancel. Quite weird since no changes were made. Try Cancel. Then try Undo, to try to figure out what the changes were. No actual changes are undone, but Vince's email address is selected! The bug has to do with automatic link detection. It does not occur with link detection off. --- 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...> - 2017-04-09 16:48:16
|
Hi Bernard, you are right about the old alphac: Welcome to Alpha's AlphaTcl shell. «» exec which alphac /Volumes/Home/kock/bin/alphac «» Where is the correct place for it? How is Skim supposed to find it other than looking for it in the PATH? If file::openWithSelection is not invoked anymore, how does it work? (I searched the AlphaTcl library without finding other mention of alphac than in connection with file::openWithSelection.) Thanks again. Cheers, Joachim. |
|
From: Bernard D. <bde...@or...> - 2017-04-09 15:05:38
|
Hi Joachim, On second thought I have another theory because I don't think Skim knows about Alpha (it knows about AlphaCocoa). So maybe you have been using a recent alphac which tried to speak with AlphaCocoa. This can't work. Bernard Envoyé de mon iPhone > Le 8 avr. 2017 à 12:02, Bernard Desgraupes <bde...@gm...> a écrit : > > Hi Joachim, > > It very much looks like you have an old version of alphac because proc file::openWithSelection is not invoked any longer. Or you are running two Alphas simultaneously and there is a port confusion. I have tested the new > alphac a lot and I think it works. But it must communicate with the right Alpha. The mechanism of storing the port number in a file in /tmp is wrong (and has been wrong for years, already with AlphaX). Concurrent Alphas overwrite each other. Even worse: when one quits it erases the temp file. > Could it be a scenario like this? > Cheers, > Bernard > > Envoyé de mon iPhone > >> Le 8 avr. 2017 à 09:17, Joachim Kock <jk...@us...> a écrit : >> >> >> [tickets:#121] alphac broken >> >> Status: open >> Created: Sat Apr 08, 2017 07:17 AM UTC by Joachim Kock >> Last Updated: Sat Apr 08, 2017 07:17 AM UTC >> Owner: nobody >> >> When backward synching from Skim, I get the following error: >> >> Message: "Error # while executing a command from 127.0.0.1:50784" >> Error Code: NONE >> Command: file::openWithSelection /path/to/file.tex 9 0 10 0 >> Error: invalid command name "file::openWithSelection" >> # while executing >> error $msg >> (procedure "::alphaServer::readCommand" line 129) # invoked from within >> ::alphaServer::readCommand sock7fdc14667690 127.0.0.1 50784 >> >> Apparently the special interpreter for alphac has become too restricted. >> >> If I execute the exact same command by selecting it in the error window >> and doing Cmd-L, it 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. >> >> ------------------------------------------------------------------------------ >> 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 > ------------------------------------------------------------------------------ > 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...@or...> - 2017-04-09 15:00:39
|
Hi Giovanni,
You are right. This is because double click in this case is delegated to Cocoa which does not know about TeX mode and its word breaking rules. On the contrary forwardWord et al. are handled by Alpha itself. I'll fix that.
Cheers,
Bernard
Envoyé de mon iPhone
> Le 8 avr. 2017 à 13:59, Giovanni Dore <gd...@us...> a écrit :
>
>
> [tickets:#123] In TeX mode there are two different definitions of word
>
> Status: open
> Created: Sat Apr 08, 2017 11:59 AM UTC by Giovanni Dore
> Last Updated: Sat Apr 08, 2017 11:59 AM UTC
> Owner: nobody
>
> In TeX mode the procedures backward one word and move one word use an ad hoc definition of word, while the procedures that extend the selection use the standard definition.
> Hence there are different behaviors; when moving the cursor "\frac" is a word and "4x" is considered as two different words, while when selcting "\frac" is not a word ("frac" is a word) and "4x" is one word.
> It would be better to have coherent behaviors.
>
> Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/alphacocoa/tickets/123/
>
> To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
>
|
|
From: Giovanni D. <gd...@us...> - 2017-04-08 11:59:15
|
---
** [tickets:#123] In TeX mode there are two different definitions of word**
**Status:** open
**Created:** Sat Apr 08, 2017 11:59 AM UTC by Giovanni Dore
**Last Updated:** Sat Apr 08, 2017 11:59 AM UTC
**Owner:** nobody
In TeX mode the procedures backward one word and move one word use an ad hoc definition of word, while the procedures that extend the selection use the standard definition.
Hence there are different behaviors; when moving the cursor "\frac" is a word and "4x" is considered as two different words, while when selcting "\frac" is not a word ("frac" is a word) and "4x" is one word.
It would be better to have coherent behaviors.
---
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...> - 2017-04-08 10:09:25
|
Hi all, To make the extra scripts alphac and ralpha easily accessible, I have uploaded a separate archive on SourceForge called AlphaTools_9.0b2.zip in the same folder as the Alpha dmg. Cheers, Bernard Envoyé de mon iPhone |
|
From: Bernard D. <bde...@gm...> - 2017-04-08 10:02:26
|
Hi Joachim, It very much looks like you have an old version of alphac because proc file::openWithSelection is not invoked any longer. Or you are running two Alphas simultaneously and there is a port confusion. I have tested the new alphac a lot and I think it works. But it must communicate with the right Alpha. The mechanism of storing the port number in a file in /tmp is wrong (and has been wrong for years, already with AlphaX). Concurrent Alphas overwrite each other. Even worse: when one quits it erases the temp file. Could it be a scenario like this? Cheers, Bernard Envoyé de mon iPhone > Le 8 avr. 2017 à 09:17, Joachim Kock <jk...@us...> a écrit : > > > [tickets:#121] alphac broken > > Status: open > Created: Sat Apr 08, 2017 07:17 AM UTC by Joachim Kock > Last Updated: Sat Apr 08, 2017 07:17 AM UTC > Owner: nobody > > When backward synching from Skim, I get the following error: > > Message: "Error # while executing a command from 127.0.0.1:50784" > Error Code: NONE > Command: file::openWithSelection /path/to/file.tex 9 0 10 0 > Error: invalid command name "file::openWithSelection" > # while executing > error $msg > (procedure "::alphaServer::readCommand" line 129) # invoked from within > ::alphaServer::readCommand sock7fdc14667690 127.0.0.1 50784 > > Apparently the special interpreter for alphac has become too restricted. > > If I execute the exact same command by selecting it in the error window > and doing Cmd-L, it 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. > > ------------------------------------------------------------------------------ > 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: Joachim K. <jk...@us...> - 2017-04-08 07:32:19
|
--- ** [tickets:#122] serious problem with fillParagraph and comments** **Status:** open **Created:** Sat Apr 08, 2017 07:32 AM UTC by Joachim Kock **Last Updated:** Sat Apr 08, 2017 07:32 AM UTC **Owner:** Joachim Kock There is a serious problem with fillParagraph in connection with comments: if the paragraph filled is preceded immediately by a commented block of text, sometimes the filling messes up the two blocks, either resulting in some commented text being part of the non-commented text, or some non-commented text ending up inside the comment. Here is a rather small example (must be in TeX mode): % The ojiijiji % defines in this way a that is, $R_\bullet:\Deltagen\op\to\Grpd$. The pullback construction Place the insertion point on the third line and do Cmd-I. Curiously enough, the following example in Text mode has no problem: > The ojiijiji > defines in this way a that is, $R_\bullet:\Deltagen\op\to\Grpd$. The pullback construction I promise to look into this, hopefully over Easter. At the moment I just want to warn everybody. --- 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...> - 2017-04-08 07:17:23
|
---
** [tickets:#121] alphac broken**
**Status:** open
**Created:** Sat Apr 08, 2017 07:17 AM UTC by Joachim Kock
**Last Updated:** Sat Apr 08, 2017 07:17 AM UTC
**Owner:** nobody
When backward synching from Skim, I get the following error:
Message: "Error # while executing a command from 127.0.0.1:50784"
Error Code: NONE
Command: file::openWithSelection /path/to/file.tex 9 0 10 0
Error: invalid command name "file::openWithSelection"
# while executing
error $msg
(procedure "::alphaServer::readCommand" line 129) # invoked from within
::alphaServer::readCommand sock7fdc14667690 127.0.0.1 50784
Apparently the special interpreter for alphac has become too restricted.
If I execute the exact same command by selecting it in the error window
and doing Cmd-L, it 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: Eberhard W L. <el...@us...> - 2017-04-07 10:45:43
|
Great, I'll wait for the next beta release as I don't want to compile from source. Thank you so much. greetings el On 06/04/2017 20:18, Bernard Desgraupes wrote: > I have now implemented the hardwired port number. The default value is > 51954. There is a global preference /alphaServerPort/ (found in the > /General/ panel of the /Global Preferences/) in case you need another > value. The /ralpha/ script has been slightly modified (but was already > aware of port 51954). Also updated the doc. This has been tested and > seems to work fine. > > Changes committed to the repository (rev. 1306 > <http://sourceforge.net/p/alphacocoa/code/1306/>). [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el...@li... / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/ --- ** [tickets:#73] Edit remote file locally** **Status:** fixed **Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse **Last Updated:** Thu Apr 06, 2017 07:18 PM UTC **Owner:** Bernard Desgraupes Hi Eberhard, this is certainly feasible. I’ll have a look at the rmate script. Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ? Cheers, Bernard Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit : Bernard, during the absence of a production level AlphaCocoa I have been using TextMate2. There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab). rmate sits on the python repository from which pip installs it. Will it be possible to implement this in AlphaCocoa? el --- 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-04-06 19:18:00
|
I have now implemented the hardwired port number. The default value is 51954. There is a global preference *alphaServerPort* (found in the *General* panel of the *Global Preferences*) in case you need another value. The *ralpha* script has been slightly modified (but was already aware of port 51954). Also updated the doc. This has been tested and seems to work fine. Changes committed to the repository ([rev. 1306](http://sourceforge.net/p/alphacocoa/code/1306/)). --- ** [tickets:#73] Edit remote file locally** **Status:** fixed **Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse **Last Updated:** Thu Apr 06, 2017 02:30 PM UTC **Owner:** Bernard Desgraupes Hi Eberhard, this is certainly feasible. I’ll have a look at the rmate script. Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ? Cheers, Bernard Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit : Bernard, during the absence of a production level AlphaCocoa I have been using TextMate2. There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab). rmate sits on the python repository from which pip installs it. Will it be possible to implement this in AlphaCocoa? el --- 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: Eberhard W L. <el...@us...> - 2017-04-06 14:59:08
|
There was no trouble, none at all. Thank you. el On 06/04/2017 15:30, Bernard Desgraupes wrote: > Oh I understand now. It means that the ralpha contained in the bundle > is outdated. This is a flaw in my release script which did not detect > this. Sorry for the trouble. > --- ** [tickets:#73] Edit remote file locally** **Status:** fixed **Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse **Last Updated:** Thu Apr 06, 2017 02:30 PM UTC **Owner:** Bernard Desgraupes Hi Eberhard, this is certainly feasible. I’ll have a look at the rmate script. Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ? Cheers, Bernard Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit : Bernard, during the absence of a production level AlphaCocoa I have been using TextMate2. There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab). rmate sits on the python repository from which pip installs it. Will it be possible to implement this in AlphaCocoa? el --- 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-04-06 14:30:38
|
Oh I understand now. It means that the ralpha contained in the bundle is outdated. This is a flaw in my release script which did not detect this. Sorry for the trouble. --- ** [tickets:#73] Edit remote file locally** **Status:** fixed **Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse **Last Updated:** Thu Apr 06, 2017 01:00 PM UTC **Owner:** Bernard Desgraupes Hi Eberhard, this is certainly feasible. I’ll have a look at the rmate script. Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ? Cheers, Bernard Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit : Bernard, during the absence of a production level AlphaCocoa I have been using TextMate2. There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab). rmate sits on the python repository from which pip installs it. Will it be possible to implement this in AlphaCocoa? el --- 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: Eberhard W L. <el...@us...> - 2017-04-06 13:16:17
|
Bernard, Only one Alpha is running :-)-O I had the latest version and only one running, and took ralpha from that but have now downloaded your archive and scp'ed it over. That works. While you are at it can you make Alpha bring the new (remote file) window to the foreground? Thank you very much. el On 06/04/2017 14:00, Bernard Desgraupes wrote: > Thank you for the error log. As far as I can see, there is obviously > some sort of confusion about the version which is used. The error > is a syntax error which refers to an older version of the proc > editRemoteFile. > > Could you make sure of the following points: > > * you installed the latest version of ralpha on your remote > machine (it is found inside the Alpha 9.0b2 bundle in > Alpha.app/Contents/Resources/Libraries/Extras/ralpha). Alternatively > I have made a separate release of the command line tools /alphac/ > and /ralpha/ here > <https://sourceforge.net/projects/alphacocoa/files/9.0b2/AlphaTools_9.0b2.zip> > on SourceForge. > * you are running Alpha 9.0b2 (and no other Alpha is running > simultaneously). This is very important because it two versions of > Alpha are running the mechanism wreaks havoc. There is a confusion > of ports. In cse of doubt quit all Alphas and relaunch 9.0b2. > > I have just tested again ralpha on a remote machine via ssh and it > works just fine for me. > > BTW, I have also implemented the hard-wired port solution ... but this > is another story. I'll commit the changes later. [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el...@li... / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/ --- ** [tickets:#73] Edit remote file locally** **Status:** fixed **Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse **Last Updated:** Thu Apr 06, 2017 01:00 PM UTC **Owner:** Bernard Desgraupes Hi Eberhard, this is certainly feasible. I’ll have a look at the rmate script. Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ? Cheers, Bernard Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit : Bernard, during the absence of a production level AlphaCocoa I have been using TextMate2. There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab). rmate sits on the python repository from which pip installs it. Will it be possible to implement this in AlphaCocoa? el --- 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-04-06 13:00:31
|
Thank you for the error log. As far as I can see, there is obviously some sort of confusion about the version which is used. The error is a syntax error which refers to an older version of the proc editRemoteFile. Could you make sure of the following points: * you installed the latest version of ralpha on your remote machine (it is found inside the Alpha 9.0b2 bundle in Alpha.app/Contents/Resources/Libraries/Extras/ralpha). Alternatively I have made a separate release of the command line tools *alphac* and *ralpha* [here](https://sourceforge.net/projects/alphacocoa/files/9.0b2/AlphaTools_9.0b2.zip) on SourceForge. * you are running Alpha 9.0b2 (and no other Alpha is running simultaneously). This is very important because it two versions of Alpha are running the mechanism wreaks havoc. There is a confusion of ports. In cse of doubt quit all Alphas and relaunch 9.0b2. I have just tested again ralpha on a remote machine via ssh and it works just fine for me. BTW, I have also implemented the hard-wired port solution ... but this is another story. I'll commit the changes later. --- ** [tickets:#73] Edit remote file locally** **Status:** fixed **Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse **Last Updated:** Thu Apr 06, 2017 11:39 AM UTC **Owner:** Bernard Desgraupes Hi Eberhard, this is certainly feasible. I’ll have a look at the rmate script. Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ? Cheers, Bernard Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit : Bernard, during the absence of a production level AlphaCocoa I have been using TextMate2. There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab). rmate sits on the python repository from which pip installs it. Will it be possible to implement this in AlphaCocoa? el --- 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: Eberhard W L. <el...@us...> - 2017-04-06 12:22:56
|
Bernard,
This is not depending on which file I edit, or extension, or (remote)
host OS.
Here is the error message of a one liner
./ralpha -p 51421 test.file.for.ralpha
staright copy-and-pasted:
Message: "Error # while executing a command from 127.0.0.1:51429"
Error Code: NONE
Command: editRemoteFile test.file.for.ralpha 0 {} utf-8 {} {{This is a
little test file containing 1 lineof text
}}
Error: wrong # args: should be "editRemoteFile winName mode encoding
selection ?winContents?"
# while executing
error $msg
(procedure "::alphaServer::readCommand" line 129)
# invoked from within
::alphaServer::readCommand sock7f8dbfa0cf90 127.0.0.1 51429
51954 sounds fine. If it's being used by another program the slogin
session will squeal and I know about that I must look.
BTW, I use iTerm2 and it has "Profiles" where I can hardwire the slogin
command and the port, but also where I can put the name of the remote
computer in color on the screen, which is very hand when working on
different sessions at the same time...
Thank you very much for all the work you have put in and are putting in.
greetings, el
On 06/04/2017 12:39, Bernard Desgraupes wrote:
> I am well aware of the annoyance of having Alpha Server listening
> on a different time at each session and have already hardwired a
> port number (51954) in ralpha (but haven't yet installed it in Alpha
> itself). I will experiment with this. The only (very unlikely)
> drawback would be if another program had opened the same port.
>
> Concerning the error, I'd be glad to have the entire text of the
> error. Your image shows only the top part. It suggests though that
> you were remotely editing the ralpha script itself, am I right. If
> that is the case, it sounds unwise because it means editing an
> executable while it is running. But maybe I'm wrong.
[...]
--
Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar)
el...@li... / * | Telephone: +264 81 124 6733 (cell)
PO Box 8421 \ /
Bachbrecht, Namibia ;____/
---
** [tickets:#73] Edit remote file locally**
**Status:** fixed
**Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse
**Last Updated:** Thu Apr 06, 2017 11:39 AM UTC
**Owner:** Bernard Desgraupes
Hi Eberhard,
this is certainly feasible. I’ll have a look at the rmate script.
Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ?
Cheers,
Bernard
Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit :
Bernard,
during the absence of a production level AlphaCocoa I have been using TextMate2.
There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab).
rmate sits on the python repository from which pip installs it.
Will it be possible to implement this in AlphaCocoa?
el
---
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-04-06 11:39:27
|
I am well aware of the annoyance of having Alpha Server listening on a different time at each session and have already hardwired a port number (51954) in ralpha (but haven't yet installed it in Alpha itself). I will experiment with this. The only (very unlikely) drawback would be if another program had opened the same port. Concerning the error, I'd be glad to have the entire text of the error. Your image shows only the top part. It suggests though that you were remotely editing the ralpha script itself, am I right. If that is the case, it sounds unwise because it means editing an executable while it is running. But maybe I'm wrong. --- ** [tickets:#73] Edit remote file locally** **Status:** fixed **Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse **Last Updated:** Thu Apr 06, 2017 09:57 AM UTC **Owner:** Bernard Desgraupes Hi Eberhard, this is certainly feasible. I’ll have a look at the rmate script. Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ? Cheers, Bernard Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit : Bernard, during the absence of a production level AlphaCocoa I have been using TextMate2. There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab). rmate sits on the python repository from which pip installs it. Will it be possible to implement this in AlphaCocoa? el --- 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. <ond...@us...> - 2017-04-06 09:57:28
|
I have played with it and notice that local Alpha changes the port it listens to, when called again. That is most unhelpful, as I would like to "hardwire" that port into my profile on iTerm2 to slogin and I have to change it in ralpha or call it with -p. That said, I get the error from Alpha 9.0b2 (Beta2) (6669) which is shown in the attachment. Attachments: - [ralpha.png](https://sourceforge.net/p/alphacocoa/tickets/_discuss/thread/4b28d574/54de/attachment/ralpha.png) (68.1 kB; image/png) --- ** [tickets:#73] Edit remote file locally** **Status:** fixed **Created:** Tue Dec 13, 2016 07:17 PM UTC by Eberhard W Lisse **Last Updated:** Tue Apr 04, 2017 03:09 PM UTC **Owner:** Bernard Desgraupes Hi Eberhard, this is certainly feasible. I’ll have a look at the rmate script. Could you enter an RFE in Alpha’s Tickets tracker so that I have a reminder ? Cheers, Bernard Le 13 déc. 2016 à 19:30, Dr Eberhard W Lisse <el...@li...> a écrit : Bernard, during the absence of a production level AlphaCocoa I have been using TextMate2. There is one feature without which I can no longer work, namely logging onto a remote ssh host with -R #####:localhost:###### and TextMate listening on that port so that if one edits a file on the remote host with rmate filename, TextMate will edit the file in a local window (tab). rmate sits on the python repository from which pip installs it. Will it be possible to implement this in AlphaCocoa? el --- 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-04-04 21:50:31
|
I have no control over what another application decides to use. Each application looks for the different flavours present in the pasteboard and then is free to choose any one it is interested in. Probably Word uses the `public.rtf` (or possibly `NeXT Rich Text Format v1.0 pasteboard type`) flavour rather than the `public.utf8-plain-text` one. The only thing I can think of would be to erase the `public.rtf` type just after copying in Alpha so that Word has no other choice than picking `public.utf8-plain-text`. I'll experiment with this idea: I hope it won't break copies from Alpha to itself! --- ** [tickets:#120] Copy copies also font info** **Status:** open **Created:** Tue Apr 04, 2017 07:31 PM UTC by Joachim Kock **Last Updated:** Tue Apr 04, 2017 09:34 PM UTC **Owner:** nobody Alpha (in contrast to AlphaX) copies text WITH formatting, instead of just copying the text as a sequence of chars. I think this is wrong, since the formatting is not an attribute of the text copied but only an artefact of how the text editor presents the text on screen. (In practical terms, when from time to time I have to edit a Word document, I always found it useful to do as much as possible of the editing in AlphaX, before pasting it into Word, where it will be inserted free of formatting. I hope this use of AlphaX can be inherited by Alpha.) If for some reason the new behaviour is deemed useful, perhaps this is not a bug report but a feature request: could we then have a prefs flag for controlling this, please? --- 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...> - 2017-04-04 21:41:39
|
Hi all, I have fixed a minor bug which prevented displaying the Global Preferences in Alpha 9.0b2 released earlier today (Ticket #119). If you have downloaded it (before UTC/GMT is 21:27 on Tuesday, April 4, 2017), please grab a new copy. The link is unchanged. https://sourceforge.net/projects/alphacocoa/files/9.0b2/Alpha-9.0b2.dmg.zip/download The new checksums are: MD5: 796147e00743cd0e99a963a136d354c3 SHA1: 12e1bd34ac6116f7b3eaa1002c83332e2336ae14 Cheers, Bernard |
|
From: Joachim K. <jk...@us...> - 2017-04-04 21:34:29
|
Pasting in Alpha works as expeced: even text copied from Word or from a web browser is pasted into Alpha without formatting. In other words, Alpha takes from the pasteboard only the information that befits a text editor, namely the plain text. The problem is the other way around, that Copy in Alpha places formatting info in the pasteboard. The logical thing would be that since it only takes text, it should also only put text there (since anyway the formatting does not really belong to the text chunk but rather to the user interface). But if this is complicated to achieve, never mind. It is of course much more important that rectangular copy and paste works correctly. --- ** [tickets:#120] Copy copies also font info** **Status:** open **Created:** Tue Apr 04, 2017 07:31 PM UTC by Joachim Kock **Last Updated:** Tue Apr 04, 2017 09:16 PM UTC **Owner:** nobody Alpha (in contrast to AlphaX) copies text WITH formatting, instead of just copying the text as a sequence of chars. I think this is wrong, since the formatting is not an attribute of the text copied but only an artefact of how the text editor presents the text on screen. (In practical terms, when from time to time I have to edit a Word document, I always found it useful to do as much as possible of the editing in AlphaX, before pasting it into Word, where it will be inserted free of formatting. I hope this use of AlphaX can be inherited by Alpha.) If for some reason the new behaviour is deemed useful, perhaps this is not a bug report but a feature request: could we then have a prefs flag for controlling this, please? --- 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-04-04 21:16:02
|
In order to fix [Ticket #79: Paste upon rectangular copy inserts spaces instead of \\n](http://sourceforge.net/p/alphacocoa/tickets/79/) I have delegated *Copy/Paste* entirely to Cocoa (no more intervention from Alpha). This ensures that multiple selections as well as rectangular selections are now handled correctly. When a chunk of text is copied in Alpha, many different flavours are stored in the pasteboard. Actually, with a simple *Copy*, I see ``` CorePasteboardFlavorType TEXT CorePasteboardFlavorType styl CorePasteboardFlavorType ustl CorePasteboardFlavorType ut16 NSStringPboardType NeXT Rich Text Format v1.0 pasteboard type com.apple.traditional-mac-plain-text public.rtf public.utf16-external-plain-text public.utf8-plain-text ``` The flavour you mention is `public.utf8-plain-text`. But now the target application (say Word) may decide to use any of the flavours contained in the pasteboard and we have no control on this. It is possible it picks the `public.rtf` which may contain font information. Or is it the other way round you are concerned with (pasting in Alpha something coming from an other application)? --- ** [tickets:#120] Copy copies also font info** **Status:** open **Created:** Tue Apr 04, 2017 07:31 PM UTC by Joachim Kock **Last Updated:** Tue Apr 04, 2017 07:31 PM UTC **Owner:** nobody Alpha (in contrast to AlphaX) copies text WITH formatting, instead of just copying the text as a sequence of chars. I think this is wrong, since the formatting is not an attribute of the text copied but only an artefact of how the text editor presents the text on screen. (In practical terms, when from time to time I have to edit a Word document, I always found it useful to do as much as possible of the editing in AlphaX, before pasting it into Word, where it will be inserted free of formatting. I hope this use of AlphaX can be inherited by Alpha.) If for some reason the new behaviour is deemed useful, perhaps this is not a bug report but a feature request: could we then have a prefs flag for controlling this, please? --- 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.
){kind=link}