alphacocoa-devel — AlphaCocoa Development List

[Alphacocoa-devel] [alphacocoa:tickets] #127 double-clicked selections are not click extendible

[Joachim K. <jk...@us...>]

---

** [tickets:#127] double-clicked selections are not click extendible**

**Status:** open
**Created:** Mon Apr 17, 2017 07:33 PM UTC by Joachim Kock
**Last Updated:** Mon Apr 17, 2017 07:33 PM UTC
**Owner:** nobody


1) If you double-click-and-release on a word to have it selected, and then 
shift-click at the following word, nothing happens.  The correct behaviour would
be to extend the selection.  (This behaviour is in AlphaX and in most other
editable-text fields.  For example this works in AlphaCocoa's text field inside
the search dialogue!)

It works correctly if the the first selection was made by click-drag-release.
So somehow there are two kinds of selections, which is already strange.

2) In fact the really nice word-selection extensions (which also work in AlphaX
and most other places) are made by double-clicking on a word and then
moving the mouse /without releasing the mouse button/, until the desired 
selection is reached, and then release.  The great thing about this technique
is that the double-click that initiated the drag-selection ensures that only 
whole words are selected.

I consider the first a bug.  The second is perhaps rather a feature request.


---

Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Alphacocoa-devel] [alphacocoa:tickets] #126 Revert To Saved dialog doesn't catch return

[Giovanni D. <gd...@us...>]

---

** [tickets:#126] Revert To Saved dialog doesn't catch return**

**Status:** open
**Created:** Mon Apr 17, 2017 05:05 PM UTC by Giovanni Dore
**Last Updated:** Mon Apr 17, 2017 05:05 PM UTC
**Owner:** nobody


If you call "Revert To Saved" in a dirty window wou get a dialog asking if you want to revert to the saved version of the file.
Hitting return inserts a carriage return in the file instead of accepting to revert.


---

Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Joachim K. <jk...@us...>]

- **status**: open --> fixed
- **Comment**:

Confirming that everything works now.  Thanks!



---

** [tickets:#121] alphac broken**

**Status:** fixed
**Created:** Sat Apr 08, 2017 07:17 AM UTC by Joachim Kock
**Last Updated:** Wed Apr 12, 2017 10:38 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.

[Alphacocoa-devel] [alphacocoa:tickets] Re: #122 serious problem with fillParagraph and comments

[Bernard D. <bde...@us...>]

Great! Thanks!
To force a rebuild of the indices on everyone automatically you may increase the hardCodedCounter in SystemCode/Init/AlphaVersionInfo.tcl and commit. 

Envoyé de mon iPhone



---

** [tickets:#122] serious problem with fillParagraph and comments**

**Status:** fixed
**Created:** Sat Apr 08, 2017 07:32 AM UTC by Joachim Kock
**Last Updated:** Sun Apr 16, 2017 03:04 PM 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.

[Alphacocoa-devel] [alphacocoa:tickets] #122 serious problem with fillParagraph and comments

[Joachim K. <jk...@us...>]

- **status**: open --> fixed



---

** [tickets:#122] serious problem with fillParagraph and comments**

**Status:** fixed
**Created:** Sat Apr 08, 2017 07:32 AM UTC by Joachim Kock
**Last Updated:** Sun Apr 16, 2017 03:03 PM 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.

[Alphacocoa-devel] [alphacocoa:tickets] #122 serious problem with fillParagraph and comments

[Joachim K. <jk...@us...>]

OK, I have just committed the fixed regular expression in TeX mode then.
Indices must be rebuilt to apply the fix.


---

** [tickets:#122] serious problem with fillParagraph and comments**

**Status:** open
**Created:** Sat Apr 08, 2017 07:32 AM UTC by Joachim Kock
**Last Updated:** Sun Apr 16, 2017 09:43 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.

[Alphacocoa-devel] [alphacocoa:tickets] Re: #122 serious problem with fillParagraph and comments

[Bernard D. <bde...@us...>]

I don't think we should bother about Tcl regexp here. The search command does not rely on Tcl at all. It is implemented (in AlphaCocoa) using Cocoa's NSRegularExpression class and methods which provide Perl compliant regexps syntax. 
When AlphaTcl calls the regexp command there may be idiosyncrasies but them do not concern the search command. 


---

** [tickets:#122] serious problem with fillParagraph and comments**

**Status:** open
**Created:** Sat Apr 08, 2017 07:32 AM UTC by Joachim Kock
**Last Updated:** Sun Apr 16, 2017 09:43 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.

Re: [Alphacocoa-devel] [alphacocoa:tickets] Re: #122 serious problem with fillParagraph and comments

[Bernard D. <bde...@or...>]

I don't think we should bother about Tcl regexp here. The search command does not rely on Tcl at all. It is implemented (in AlphaCocoa) using Cocoa's NSRegularExpression class and methods which provide Perl compliant regexps syntax. 
When AlphaTcl calls the regexp command there may be idiosyncrasies but them do not concern the search command. 

[Alphacocoa-devel] [alphacocoa:tickets] Re: #122 serious problem with fillParagraph and comments

[Joachim K. <jk...@us...>]

On 16/04/2017 13:33, Bernard Desgraupes wrote:

> Could this have to do with the ?m flag option which is automatically
> set by the search command (see the -ml option to disable it) ?

Yes!  That's it.

I was not aware that [search] had this flag set
automatically.

So the issue has nothing to do with longest matches.

Then perhaps it is AlphaX who is right!

In any case the confusion is that

* the ?m flag in Tcl regexp does TWO things:
(1) it allows ^ and $ to match \n
(2) it prohibits . and [^a-z] to match \n

* the -ml flag in AlphaCocoa search does ONE thing:
(1) it allows ^ and $ to match \n

* AlphaX does not have such a flag for search,
but its behaviour agrees with Tcl regexp with
the ?m flag.

As an illustration, try a file with two lines

a
b

and do this from the status line:

search -r 1 {a[^c]b} 0

In AlphaCocoa, there is a match in position 0 3
In AlphaX there is no match.

Now try this:

search -r 1 {^b} 0

Both AlphaX and AlphaCocoa finds a match in
position 2 3.

The AlphaCocoa behaviour is exactly as documented
in the Alpha Commands file, since the -ml flag
specification does not mention (2).

However, one could consider if it would be better
design to modify Alpha's -ml flag so that it agrees
completely with the regexp ?m flag, and such that
Alpha's behaviour is consistent with AlphaX's.

On one hand it is good to stay as close as possible
to Tcl conventions, and on the other hand, there
could be other occurrences in AlphaTcl that assume
AlphaX's behaviour.

Cheers,
Joachim.






---

** [tickets:#122] serious problem with fillParagraph and comments**

**Status:** open
**Created:** Sat Apr 08, 2017 07:32 AM UTC by Joachim Kock
**Last Updated:** Sun Apr 16, 2017 09:43 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.

Re: [Alphacocoa-devel] [alphacocoa:tickets] #122 serious problem withfillParagraph and comments

[Joachim K. <ko...@ma...>]

On 16/04/2017 13:33, Bernard Desgraupes wrote:

> Could this have to do with the ?m flag option which is automatically
> set by the search command (see the -ml option to disable it) ?

Yes!  That's it.

I was not aware that [search] had this flag set
automatically.

So the issue has nothing to do with longest matches.

Then perhaps it is AlphaX who is right!

In any case the confusion is that

* the ?m flag in Tcl regexp does TWO things:
(1) it allows ^ and $ to match \n
(2) it prohibits . and [^a-z] to match \n

* the -ml flag in AlphaCocoa search does ONE thing:
(1) it allows ^ and $ to match \n

* AlphaX does not have such a flag for search,
but its behaviour agrees with Tcl regexp with
the ?m flag.

As an illustration, try a file with two lines

a
b

and do this from the status line:

search -r 1 {a[^c]b} 0

In AlphaCocoa, there is a match in position 0 3
In AlphaX there is no match.

Now try this:

search -r 1 {^b} 0

Both AlphaX and AlphaCocoa finds a match in
position 2 3.

The AlphaCocoa behaviour is exactly as documented
in the Alpha Commands file, since the -ml flag
specification does not mention (2).

However, one could consider if it would be better
design to modify Alpha's -ml flag so that it agrees
completely with the regexp ?m flag, and such that
Alpha's behaviour is consistent with AlphaX's.

On one hand it is good to stay as close as possible
to Tcl conventions, and on the other hand, there
could be other occurrences in AlphaTcl that assume
AlphaX's behaviour.

Cheers,
Joachim.

Re: [Alphacocoa-devel] [alphacocoa:tickets] #122 serious problem with fillParagraph and comments

[Bernard D. <bde...@gm...>]

Hi Joachim,

Thanks for looking into this. The proposed solution looks fine. 
Could this have to do with the ?m flag option which is automatically set by the search command (see the -ml option to disable it) ? See also the Flag Options section of the Regular Expression help. 

[Alphacocoa-devel] [alphacocoa:tickets] #122 serious problem with fillParagraph and comments

[Joachim K. <jk...@us...>]

Hi Bernard,

I have nailed down the fillParagraph problem.
It is a difference in how [search] matches in
AlphaX and in AlphaCocoa:

set startPara "(^|[^\\])%"
search -w $win -n -f 0 -r 1 -- "$startPara" $pos

In AlphaX the ^ takes precedence so that if there
is a leading % on a line then only that % is matched.
In AlphaCocoa, a longer match is found, namely 
including the \n before the %.  That \n matches the
character range in the square bracket, which is
alternative to ^.

This has nothing to do with the fact that we are
searching backwards (usually a good source of confusion).
The discrepancy is the exactly the same when seaching
forward.

I think the best convention is the one of AlphaCocoa,
because it conforms to the regular-expression rule that
between branches separated by | the longest match
should take precedence

(as I learned many years ago from this very nice book:
https://www.amazon.fr/Introduction-expressions-r%C3%A9guli%C3%A8res-Bernard-Desgraupes/dp/2711786803
)


If you agree, I will change the [^\\] to [^\\\r\n]
in the definition of TeX::startPara (as well as TeX::endPara).

I searched AlphaTcl for the pattern ^| to see if there were
other obvious potential victims of the AlphaX convention.
There are some similar patterns in [quote::Undisplay] and in
[TeX::convertDoubleDollarSigns] and friends, but they are
used in regexps and regsubs, not in searches, and they
are not part of the patterns actually being substituted,
so I think it is best to leave those expressions as they are.

Cheers,
Joachim.





---

** [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.

[Alphacocoa-devel] [alphacocoa:tickets] #125 status bar does not give focus back to main window field

[Joachim K. <jk...@us...>]

---

** [tickets:#125] status bar does not give focus back to main window field**

**Status:** open
**Created:** Sun Apr 16, 2017 08:15 AM UTC by Joachim Kock
**Last Updated:** Sun Apr 16, 2017 08:15 AM UTC
**Owner:** nobody


Do some command in the status bar with [execute], 
such as the command [getPos].

The result is correctly displayed in the status line.
But the focus is not properly returned to the main
editing field of the window.  The focus only comes 
back to the main editing window when you click
in it.

For example, typing has no effect before that click.
Actually it turns out that the chars typed are sent to
some invisible status-bar buffer: they turn up in the
status bar next time you open it with [execute]!

Pressing arrow keys causes a different phenomenon:
The insertion point is not visible at all while the
focus is elsewhere.  The insertion point is actually 
moved correctly, but it is invisible.  It only become 
visible after clicking in the window.





---

Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Alphacocoa-devel] [alphacocoa:tickets] #124 link detection dirties window

[Bernard D. <bde...@us...>]

There is not much I can do about this as Cocoa itself performs the link detection and considers that the document is modified. I agree that this is questionable concerning link detection (only text attributes are modified in that case unlike dash substitution which actually modifies the text). Note, on the other hand, that this *is* undoable.

What I can propose is to disable the document checking performed by Alpha when a document is opened (or make it depend on a new global preference which could be called *autoTextCheckingOnOpen*). In that case, if the preference is not enabled, links would not be marked automatically when the file is opened.

I have added a new menu item *Text ↣ Text Options ↣ Check Document* to force an immediate check of the entire document (for the currently enabled options). I have also modified Alpha so that text checking occurs as soon as some of the options found in the *Text Options* submenu is enabled (rather than depending on Cocoa to do so at a later unpredictable moment). This does not fix the current issue but might help with the proposed preference.

Note also that programmatically there is already a  [text check](http://alphacocoa.sourceforge.net/Reference/text.html#cmd_text_check) command.

Any thoughts ?

Changes committed to the repository ([rev. 1313](http://sourceforge.net/p/alphacocoa/code/1313/)). The core must be rebuilt.




---

** [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.

[Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Bernard D. <bde...@us...>]

I have fixed this now:

* using 'string is integer' instead of 'string is entier'
* solved the missing offset in tempfiles (resulting from 'typeset a selection' in TeX mode)

I have tested the PDF synchronization with Skim. It all works fine for me, both when typesetting an entire file or only a selection. Beware of the difficulty of ensuring the right *alphac* is called if you have several Alpha's (and AlphaCocoa's) stored on your machine. Skim finds alphac by first looking for an app with the right bundle ID. There is no guarantee that it picks the running one.

Changes committed to the repository ([rev. 1312](http://sourceforge.net/p/alphacocoa/code/1312/)). The core must be rebuilt.



---

** [tickets:#121] alphac broken**

**Status:** open
**Created:** Sat Apr 08, 2017 07:17 AM UTC by Joachim Kock
**Last Updated:** Mon Apr 10, 2017 10:40 PM 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.

Re: [Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Bernard D. <bde...@gm...>]

<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br>Le 9 avr. 2017 à 18:48, Joachim Kock &lt;ko...@ma...&gt; a écrit :<br><br><blockquote type="cite">Hi Bernard,<br><br>you are right about the old alphac:<br><br>Welcome to Alpha's AlphaTcl shell.<br>«» exec which alphac<br>/Volumes/Home/kock/bin/alphac<br>«»<br></blockquote><br>Ok this explains the confusion.<br><br><blockquote type="cite"><br>Where is the correct place for it?<br></blockquote><br>Anywhere along your PATH I’d say.<br><br><blockquote type="cite">How is Skim supposed to find it other than<br>looking for it in the PATH?<br><br></blockquote><br>Not sure how they do but I have to make a request to the Skim team to ask them to change AlphaCocoa to Alpha in a future release.<br>I don’t know how they invoke alphac. The information that have is:<br>the name of the application <br>its bundle ID<br>the name and location of the script (in the form 'alphac %s %l’)<br><br>But what part of this information they use I don’t know. I’ll have a look at their source code.<br><br>Cheers,<br>Bernard</body></html>

Re: [Alphacocoa-devel] [alphacocoa:tickets] #123 In TeX mode there are two different definitions of word

[Bernard D. <bde...@or...>]

Sadly my fix has nasty side effects on mouse dragging selections. I have to revert to the status quo ante. 

Envoyé de mon iPhone

> Le 11 avr. 2017 à 15:01, Bernard Desgraupes <bde...@gm...> a écrit :
> 
> This is almost fixed now. 
> 
> Moving with opt-left and opt-right was correct (i-e was mode aware). 
> Selecting by words using shift-opt-left and shift-opt-right is now working similarly. The only remaining issue concerns regression of an ongoing selection which still considers alphanumeric words only (and not "words" as defined by the different modes). There is no easy way to capture this situation besides entirely rewriting everything which I have no intention to do. 
> ------------------------------------------------------------------------------
> 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

Re: [Alphacocoa-devel] [alphacocoa:tickets] #123 In TeX mode there are two different definitions of word

[Bernard D. <bde...@gm...>]

This is almost fixed now. 

Moving with opt-left and opt-right was correct (i-e was mode aware). 
Selecting by words using shift-opt-left and shift-opt-right is now working similarly. The only remaining issue concerns regression of an ongoing selection which still considers alphanumeric words only (and not "words" as defined by the different modes). There is no easy way to capture this situation besides entirely rewriting everything which I have no intention to do. 

Re: [Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Bernard D. <bde...@or...>]

I'll look into Skim's code to understand why they choose Latin1 (this is iso8859-1) rather than UTF8. 

Alpha will not figure out the encoding. If no encoding is specified it will try UTF8 (in fact the inputEncoding pref which is UTF8 by default) and will protest if this is not the case. But it's fine with me to set encoding to "" by default in alphac. It does no harm. 

Envoyé de mon iPhone

> Le 11 avr. 2017 à 00:40, Joachim Kock <jk...@us...> a écrit :
> 
> One more thing: in the logs I see that the alphac command sent from Skim has encoding set to iso8859-1. Where could that value come from? I can't imagine Skim actively setting it. It does not seem to matter at all if the file is already open, but for a file not already open it will actually be opened in this exotic encoding!
> 
> In the script, there is an initialisation saying 
> set encoding [encoding system]
> Maybe this is not the optimal solution. If the caller really wants a specific encoding, it should explicitly demand it. Otherwise it seems wiser just not to specify anything, and let Alpha figure it out, rather than relying on some foreign system setting.
> 
> [tickets:#121] alphac broken
> 
> Status: open
> Created: Sat Apr 08, 2017 07:17 AM UTC by Joachim Kock
> Last Updated: Mon Apr 10, 2017 10:25 PM 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

Re: [Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Bernard D. <bde...@or...>]

Fine with me, i'll replace 'string is entier' by 'string is integer'. 

Concerning the temporary files I was not aware of this mechanism to typeset only a selection. I will reintroduce the missing block. 

Thanks for the insight. 

Bernard 

Envoyé de mon iPhone

> Le 11 avr. 2017 à 00:25, Joachim Kock <jk...@us...> a écrit :
> 
> [Some messages regarding this issue were not recorded in the bug tracker. It turned out I
> had an old alphac script in my path, incompatible with the new Alpha.]
> 
> I am now working with the newest alphac. It still does not work: the culprit is a command
> [string is entier] which is Tcl 8.6, but not valid in Tcl 8.5. But the alphac script is executed
> by the system Tcl installation, which in my case (OSX 10.11.5) is Tcl 8.5.9.
> 
> I think it is more likely alphac will run in this environment than it is that someone would pass it
> a linenumber not satisfying the oldfashioned [string is integer]. I propose that alphac reverts to
> the old [string is integer].
> 
> With this change, alphac works reasonably (and Skim finds the script inside the Alpha bundle). However, the mechanism does not correct for offsets in connection with temporary files. For example, on typesetSelection, Alpha creates a temporary file including some preamble, and records the size of the preamble in the temp-file array. When synctex calls back from Skim, of course it knows nothing about the temp file or the offset, so it 
> is up to Alpha to take this int account. The old proc file::openWithSelection took care of this, both redirecting to the mother file and offsetting. The new proc editFiles redirects to the correct file, but does not correct for the offset.
> 
> [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

[Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Joachim K. <jk...@us...>]

One more thing: in the logs I see that the alphac command sent from Skim has encoding set to iso8859-1. Where could that value come from? I can't imagine Skim actively setting it. It does not seem to matter at all if the file is already open, but for a file not already open it will actually be opened in this exotic encoding!

In the script, there is an initialisation saying 
set encoding [encoding system]
Maybe this is not the optimal solution.  If the caller really wants a specific encoding, it should explicitly demand it.  Otherwise it seems wiser just not to specify anything, and let Alpha figure it out, rather than relying on some foreign system setting.


---

** [tickets:#121] alphac broken**

**Status:** open
**Created:** Sat Apr 08, 2017 07:17 AM UTC by Joachim Kock
**Last Updated:** Mon Apr 10, 2017 10:25 PM 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.

[Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Joachim K. <jk...@us...>]

[Some messages regarding this issue were not recorded in the bug tracker. It turned out I
had an old alphac script in my path, incompatible with the new Alpha.]

I am now working with the newest alphac.  It still does not work: the culprit is a command
[string is entier] which is Tcl 8.6, but not valid in Tcl 8.5.  But the alphac script is executed
by the system Tcl installation, which in my case (OSX 10.11.5) is Tcl 8.5.9.

I think it is more likely alphac will run in this environment than it is that someone would pass it
a linenumber not satisfying the oldfashioned [string is integer]. I propose that alphac reverts to
the old [string is integer].

With this change, alphac works reasonably (and Skim finds the script inside the Alpha bundle).  However, the mechanism does not correct for offsets in connection with temporary files.  For example, on typesetSelection, Alpha creates a temporary file including some preamble, and records the size of the preamble in the temp-file array. When synctex calls back from Skim, of course it knows nothing about the temp file or the offset, so it 
is up to Alpha to take this int account.  The old proc file::openWithSelection took care of this, both redirecting to the mother file and offsetting.  The new proc editFiles redirects to the correct file, but does not correct for the offset.


---

** [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.

Re: [Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Bernard D. <bde...@gm...>]

Le 9 avr. 2017 à 18:48, Joachim Kock <ko...@ma...> a écrit :

> Hi Bernard,
> 
> you are right about the old alphac:
> 
> Welcome to Alpha's AlphaTcl shell.
> «» exec which alphac
> /Volumes/Home/kock/bin/alphac
> «»

Ok this explains the confusion.

> 
> Where is the correct place for it?

Anywhere along your PATH I’d say.

> How is Skim supposed to find it other than
> looking for it in the PATH?
> 

Not sure how they do but I have to make a request to the Skim team to ask them to change AlphaCocoa to Alpha in a future release.
I don’t know how they invoke alphac. The information that have is:
the name of the application 
its bundle ID
the name and location of the script (in the form 'alphac %s %l’)

But what part of this information they use I don’t know. I’ll have a look at their source code.

Cheers,
Bernard

Re: [Alphacocoa-devel] [alphacocoa:tickets] #121 alphac broken

[Bernard D. <bde...@gm...>]

Hi Joachim,

tha alphac magics takes place in the alphaServer package. Alphac finds out on which port the server is listening (by inspecting a file left by the server in /tmp) and sends an editFiles command which is routed to the alphaServer::editFiles proc via the safe interpreter. 

Envoyé de mon iPhone

> Le 9 avr. 2017 à 18:48, Joachim Kock <ko...@ma...> a écrit :
> 
> 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.
> 

Re: [Alphacocoa-devel] [alphacocoa:tickets] #120 Copy copies also font info

[Bernard D. <bde...@gm...>]

Hi Joachim,

I'll send you a little tool I've written to inspect the pasteboard's contents. 
Indeed AlphaX used to put only pure text in the pasteboard, three flavours IIRC: macRoman, UTF8 and UTF16. 
Now with Alpha it would be a question of removing rather than adding : Cocoa copies many different flavours and we would have to remove the RTF ones. I will experiment.