alphacocoa-devel — AlphaCocoa Development List

[Alphacocoa-devel] [alphacocoa:tickets] #222 Menu item highlighting broken in macOS Catalina

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

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



---

** [tickets:#222] Menu item highlighting broken in macOS Catalina**

**Status:** fixed
**Created:** Tue Dec 03, 2019 09:11 AM UTC by Burkhard Schmidt
**Last Updated:** Tue Dec 10, 2019 03:05 PM UTC
**Owner:** nobody


Click on a menu title in the menu bar to open the respective menu. The menu item the mouse is over is not highlighted. This happens only on macOS Catalina.


---

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] #222 Menu item highlighting broken in macOS Catalina

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

This is fixed now.

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


---

** [tickets:#222] Menu item highlighting broken in macOS Catalina**

**Status:** open
**Created:** Tue Dec 03, 2019 09:11 AM UTC by Burkhard Schmidt
**Last Updated:** Tue Dec 03, 2019 09:32 AM UTC
**Owner:** nobody


Click on a menu title in the menu bar to open the respective menu. The menu item the mouse is over is not highlighted. This happens only on macOS Catalina.


---

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] Window state in Alpha 9.1

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

Hi Greg,

thank you for the detailed explanations. This is food for thought. I now understand that this has to do with very long wrapped lines or paragraphs. I’ll look into this again.

Concerning the « line breaking » setting, this advocates for recording it in the window state too. I’ll make some experiments.

Cheers,
Bernard


> Le 6 déc. 2019 à 09:22, Greg Dunn <gre...@in...> a écrit :
> 
> Thanks for looking into this!
> 
> I've tried several different things to try to isolate the selection issue - including creation of a new file, copy/paste of text into a blank file, etc. and it only shows up in my "text mode" files.  I frequently use text mode for writings which heavily make use of the soft wrap feature, so one physical line may take up a significant number of apparent lines on the screen - if that is of any use to know.  The physical lines are numbered correctly, i.e., one wrapped line (no matter how far down the page it flows) gets a unique line number in the gutter.   I'm not sure how the physical vs. logical line count discrepancy is handled in Alpha when calculating where the file displays in a resizable text window, but that might point to a cause of this behavior.  I don't see any other issues when resizing a window or flowing text.
> 
> The auto line break in text mode is apparently overridden by the text mode preferences (i.e., the global line break prefs do not determine the state of auto line break in a text file).  When I set the text mode preference to "off", the file maintains that status.  I can set the individual file's auto line break to "on" via the pop-up menu and of course it does not get saved with the file state.  Therefore, opening the file again shows auto line break "off" again in the "I" popup.
> 
> If there is a way to have the line break state at file creation obey the mode preference but allow it to be changed and saved for an individual file, that would be nice - but I'm not sure if that would conflict with the way Alpha's mode settings operate for other modes.  So I'm hesitant to suggest a change just to satisfy one user's preferred actions.  Using a "magic" line is awkward for a pure text file which is intended to be shared via print or email, though it would be a possible short term workaround.
> 
> If this is of interest to anyone else, please feel free to contribute your thoughts.
> 
> On 12/6/19 2:25 AM, Bernard Desgraupes wrote:
>> Hi Greg,
>> I can’t reproduce the first issue: on reopening a file, the last position (or selection) is displayed approximately in the middle of the screen. Maybe there are additional circumstances causing what you see.
>> Concerning the second point,  « automatic line breaking » is not currently recorded in the window state (neither in version 9.0, nor in 9.1). This property is already controlled at different levels:
>> - global preference called Line Break (in the Text panel)
>> - mode-specific preference also called Line Break which some modes may define
>> - magic first line of your file which can contain a (linebreak) or (nolinebreak) statement. For instance, if your file is a TeX file, your first line could be
>> % -*-TeX-*- (nolinebreak)
>> I could include this property in the recorded window state in a future version if you think it is useful.
>> Cheers,
>> Bernard
>>> Le 6 déc. 2019 à 00:19, Greg Dunn <gre...@in...> a écrit :
>>> 
>>> I was editing some files which I had created with an earlier version of Alpha 9.x and noticed that the insert cursor was placed at the correct location in the file - however the window view shows a different location in the file.  Moving the insert cursor with a keyboard command of any kind pops the window view back to where the cursor is located, which is fine.
>>> 
>>> I have "record window state" turned on, and am also using "text wrapping".  As an incidental concern, even after unchecking "automatic line breaking" and then saving/closing the file, the item is checked again when re-opening the file.
>>> 
>>> Just checking to see whether I'm overlooking a setting (or need to clear preferences since I'm trying to open a file saved in [probably] 9.0) or if this is an actual misbehavior in Alpha...
>>> 
>>> High Sierra 10.13.6. Alpha 9.1 (8799).
>>> 
>>> -- 
>>> | Greg Dunn                        | "And I don't think it's my     |
>>> | gre...@in...                | fault... you never get what    |
>>> | The Sultan of Slack(tm)          | you want."                     |
>>> | http://www.indy.net/~gregdunn/   |                Patty Griffin   |
>>> 
>>> 
>>> _______________________________________________
>>> AlphaCocoa-devel mailing list
>>> Alp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel
> 
> 
> -- 
> | Greg Dunn                       | Every year is getting shorter,    |
> | gre...@in...               | never seem to find the time       |
> | The Sultan of Slack(tm)         | Plans that either come to nought  |
> | http://www.indy.net/~gregdunn/  | or half a page of scribbled lines |
> |                                 |                  Pink Floyd       |

Re: [Alphacocoa-devel] Window state in Alpha 9.1

[Greg D. <gre...@in...>]

Thanks for looking into this!

I've tried several different things to try to isolate the selection issue - including creation of a new file, copy/paste of text into a blank file, 
etc. and it only shows up in my "text mode" files.  I frequently use text mode for writings which heavily make use of the soft wrap feature, so one 
physical line may take up a significant number of apparent lines on the screen - if that is of any use to know.  The physical lines are numbered 
correctly, i.e., one wrapped line (no matter how far down the page it flows) gets a unique line number in the gutter.   I'm not sure how the physical 
vs. logical line count discrepancy is handled in Alpha when calculating where the file displays in a resizable text window, but that might point to a 
cause of this behavior.  I don't see any other issues when resizing a window or flowing text.

The auto line break in text mode is apparently overridden by the text mode preferences (i.e., the global line break prefs do not determine the state 
of auto line break in a text file).  When I set the text mode preference to "off", the file maintains that status.  I can set the individual file's 
auto line break to "on" via the pop-up menu and of course it does not get saved with the file state.  Therefore, opening the file again shows auto 
line break "off" again in the "I" popup.

If there is a way to have the line break state at file creation obey the mode preference but allow it to be changed and saved for an individual file, 
that would be nice - but I'm not sure if that would conflict with the way Alpha's mode settings operate for other modes.  So I'm hesitant to suggest a 
change just to satisfy one user's preferred actions.  Using a "magic" line is awkward for a pure text file which is intended to be shared via print or 
email, though it would be a possible short term workaround.

If this is of interest to anyone else, please feel free to contribute your thoughts.

On 12/6/19 2:25 AM, Bernard Desgraupes wrote:
> Hi Greg,
> 
> I can’t reproduce the first issue: on reopening a file, the last position (or selection) is displayed approximately in the middle of the screen. Maybe there are additional circumstances causing what you see.
> 
> Concerning the second point,  « automatic line breaking » is not currently recorded in the window state (neither in version 9.0, nor in 9.1). This property is already controlled at different levels:
> - global preference called Line Break (in the Text panel)
> - mode-specific preference also called Line Break which some modes may define
> - magic first line of your file which can contain a (linebreak) or (nolinebreak) statement. For instance, if your file is a TeX file, your first line could be
> % -*-TeX-*- (nolinebreak)
> 
> I could include this property in the recorded window state in a future version if you think it is useful.
> 
> Cheers,
> Bernard
> 
> 
> 
>> Le 6 déc. 2019 à 00:19, Greg Dunn <gre...@in...> a écrit :
>>
>> I was editing some files which I had created with an earlier version of Alpha 9.x and noticed that the insert cursor was placed at the correct location in the file - however the window view shows a different location in the file.  Moving the insert cursor with a keyboard command of any kind pops the window view back to where the cursor is located, which is fine.
>>
>> I have "record window state" turned on, and am also using "text wrapping".  As an incidental concern, even after unchecking "automatic line breaking" and then saving/closing the file, the item is checked again when re-opening the file.
>>
>> Just checking to see whether I'm overlooking a setting (or need to clear preferences since I'm trying to open a file saved in [probably] 9.0) or if this is an actual misbehavior in Alpha...
>>
>> High Sierra 10.13.6. Alpha 9.1 (8799).
>>
>> -- 
>> | Greg Dunn                        | "And I don't think it's my     |
>> | gre...@in...                | fault... you never get what    |
>> | The Sultan of Slack(tm)          | you want."                     |
>> | http://www.indy.net/~gregdunn/   |                Patty Griffin   |
>>
>>
>> _______________________________________________
>> AlphaCocoa-devel mailing list
>> Alp...@li...
>> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel
> 
> 


-- 
| Greg Dunn                       | Every year is getting shorter,    |
| gre...@in...               | never seem to find the time       |
| The Sultan of Slack(tm)         | Plans that either come to nought  |
| http://www.indy.net/~gregdunn/  | or half a page of scribbled lines |
|                                 |                  Pink Floyd       |

Re: [Alphacocoa-devel] Window state in Alpha 9.1

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

Hi Greg,

I can’t reproduce the first issue: on reopening a file, the last position (or selection) is displayed approximately in the middle of the screen. Maybe there are additional circumstances causing what you see.

Concerning the second point,  « automatic line breaking » is not currently recorded in the window state (neither in version 9.0, nor in 9.1). This property is already controlled at different levels:
- global preference called Line Break (in the Text panel)
- mode-specific preference also called Line Break which some modes may define
- magic first line of your file which can contain a (linebreak) or (nolinebreak) statement. For instance, if your file is a TeX file, your first line could be
% -*-TeX-*- (nolinebreak)

I could include this property in the recorded window state in a future version if you think it is useful.

Cheers,
Bernard



> Le 6 déc. 2019 à 00:19, Greg Dunn <gre...@in...> a écrit :
> 
> I was editing some files which I had created with an earlier version of Alpha 9.x and noticed that the insert cursor was placed at the correct location in the file - however the window view shows a different location in the file.  Moving the insert cursor with a keyboard command of any kind pops the window view back to where the cursor is located, which is fine.
> 
> I have "record window state" turned on, and am also using "text wrapping".  As an incidental concern, even after unchecking "automatic line breaking" and then saving/closing the file, the item is checked again when re-opening the file.
> 
> Just checking to see whether I'm overlooking a setting (or need to clear preferences since I'm trying to open a file saved in [probably] 9.0) or if this is an actual misbehavior in Alpha...
> 
> High Sierra 10.13.6. Alpha 9.1 (8799).
> 
> -- 
> | Greg Dunn                        | "And I don't think it's my     |
> | gre...@in...                | fault... you never get what    |
> | The Sultan of Slack(tm)          | you want."                     |
> | http://www.indy.net/~gregdunn/   |                Patty Griffin   |
> 
> 
> _______________________________________________
> AlphaCocoa-devel mailing list
> Alp...@li...
> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel

[Alphacocoa-devel] Window state in Alpha 9.1

[Greg D. <gre...@in...>]

I was editing some files which I had created with an earlier version of Alpha 9.x and noticed that the insert cursor was placed at the correct 
location in the file - however the window view shows a different location in the file.  Moving the insert cursor with a keyboard command of any kind 
pops the window view back to where the cursor is located, which is fine.

I have "record window state" turned on, and am also using "text wrapping".  As an incidental concern, even after unchecking "automatic line breaking" 
and then saving/closing the file, the item is checked again when re-opening the file.

Just checking to see whether I'm overlooking a setting (or need to clear preferences since I'm trying to open a file saved in [probably] 9.0) or if 
this is an actual misbehavior in Alpha...

High Sierra 10.13.6. Alpha 9.1 (8799).

-- 
| Greg Dunn                        | "And I don't think it's my     |
| gre...@in...                | fault... you never get what    |
| The Sultan of Slack(tm)          | you want."                     |
| http://www.indy.net/~gregdunn/   |                Patty Griffin   |

[Alphacocoa-devel] [alphacocoa:tickets] #223 accented chars in path names

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

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



---

** [tickets:#223] accented chars in path names**

**Status:** fixed
**Created:** Wed Dec 04, 2019 09:55 AM UTC by Joachim Kock
**Last Updated:** Wed Dec 04, 2019 02:20 PM UTC
**Owner:** nobody


There is a problem with file::hasOpenWindows if the argument is a path with accented letters.
The problem is with [winNames -f], which returns window names with composed 2-byte-encoded accented letters. The string comparison detects the encoding difference.
I seem to remember that Alpha already has some normal-form procs for handling this kind of situation. If would be good if they could be applied to winNames.


---

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] #223 accented chars in path names

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

You are right, this is a problem of composed vs. decomposed Unicode form. The proc [file::hasOpenWindows]  applies, on its argument, [file::ensureStandardPath] which invokes [file nativename] and [file normalize]: this converts the path to Unicode formC. But it should apply the same standardization on the paths returned by  [winNames -f].
This is fixed now. Changes committed to the repository ([rev. 1837](https://sourceforge.net/p/alphacocoa/code/1837/)).

For the record, here is the new definition of [file::hasOpenWindows] :
```
proc file::hasOpenWindows {fileName} {
	set n [file::ensureStandardPath $fileName]
	# Resolve symbolic links:
	if { [file exists $n] && [file type $n] eq "link" } {
		set n [file readlink $n]
	}
	set res [list]
	foreach w [winNames -f] {
		if {[file::ensureStandardPath [win::StripCount $w]] eq $n} {
			lappend res $w
		}
	}
	return $res
}
```

BTW, I have added in *fileManipulation.tcl* a new proc *[file::equalPaths] *to compare two paths regardless of the Unicode form.


---

** [tickets:#223] accented chars in path names**

**Status:** open
**Created:** Wed Dec 04, 2019 09:55 AM UTC by Joachim Kock
**Last Updated:** Wed Dec 04, 2019 09:55 AM UTC
**Owner:** nobody


There is a problem with file::hasOpenWindows if the argument is a path with accented letters.
The problem is with [winNames -f], which returns window names with composed 2-byte-encoded accented letters. The string comparison detects the encoding difference.
I seem to remember that Alpha already has some normal-form procs for handling this kind of situation. If would be good if they could be applied to winNames.


---

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] #223 accented chars in path names

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

---

** [tickets:#223] accented chars in path names**

**Status:** open
**Created:** Wed Dec 04, 2019 09:55 AM UTC by Joachim Kock
**Last Updated:** Wed Dec 04, 2019 09:55 AM UTC
**Owner:** nobody


There is a problem with file::hasOpenWindows if the argument is a path with accented letters.
The problem is with [winNames -f], which returns window names with composed 2-byte-encoded accented letters. The string comparison detects the encoding difference.
I seem to remember that Alpha already has some normal-form procs for handling this kind of situation. If would be good if they could be applied to winNames.


---

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] #222 Menu item highlighting broken in macOS Catalina

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

I think this happens after the aupgrade to 10.15.1.

Giovanni


---

** [tickets:#222] Menu item highlighting broken in macOS Catalina**

**Status:** open
**Created:** Tue Dec 03, 2019 09:11 AM UTC by Burkhard Schmidt
**Last Updated:** Tue Dec 03, 2019 09:26 AM UTC
**Owner:** nobody


Click on a menu title in the menu bar to open the respective menu. The menu item the mouse is over is not highlighted. This happens only on macOS Catalina.


---

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] #222 Menu item highlighting broken in macOS Catalina

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

Thanks for reporting, I haven't installed Catalina yet but I guess it's time...


---

** [tickets:#222] Menu item highlighting broken in macOS Catalina**

**Status:** open
**Created:** Tue Dec 03, 2019 09:11 AM UTC by Burkhard Schmidt
**Last Updated:** Tue Dec 03, 2019 09:11 AM UTC
**Owner:** nobody


Click on a menu title in the menu bar to open the respective menu. The menu item the mouse is over is not highlighted. This happens only on macOS Catalina.


---

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] #222 Menu item highlighting broken in macOS Catalina

[Burkhard S. <be...@us...>]

---

** [tickets:#222] Menu item highlighting broken in macOS Catalina**

**Status:** open
**Created:** Tue Dec 03, 2019 09:11 AM UTC by Burkhard Schmidt
**Last Updated:** Tue Dec 03, 2019 09:11 AM UTC
**Owner:** nobody


Click on a menu title in the menu bar to open the respective menu. The menu item the mouse is over is not highlighted. This happens only on macOS Catalina.


---

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] #221 Search in Filesets is broken if regexp contains \n

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

- **status**: open --> fixed
- **Version**: 9.1* --> 9.0



---

** [tickets:#221] Search in Filesets is broken if regexp contains \n**

**Status:** fixed
**Created:** Thu Nov 07, 2019 03:55 PM UTC by Bernard Desgraupes
**Last Updated:** Thu Nov 14, 2019 05:19 PM UTC
**Owner:** Bernard Desgraupes


(This bug was reported on the AlphaDev list by John Morris. I'm entering it in the bug tracker for easier reference)

Original message:
<< 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.>>



---

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] #221 Search in Filesets is broken if regexp contains \n

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

This is hopefully fixed now after a complete overhaul of the Supersearch package and the introduction of a new core command [scanFile](https://alphacocoa.sourceforge.io/Syntax/scanFile.html).
Changes committed to the repository ([rev. 1810](https://sourceforge.net/p/alphacocoa/code/1810/)). The core must be rebuilt.


---

** [tickets:#221] Search in Filesets is broken if regexp contains \n**

**Status:** open
**Created:** Thu Nov 07, 2019 03:55 PM UTC by Bernard Desgraupes
**Last Updated:** Thu Nov 07, 2019 04:03 PM UTC
**Owner:** Bernard Desgraupes


(This bug was reported on the AlphaDev list by John Morris. I'm entering it in the bug tracker for easier reference)

Original message:
<< 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.>>



---

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] #221 Search in Filesets is broken if regexp contains \n

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

Explanation: AlphaTcl relies on the scan commands (scancontext, scanmatch, etc.) defined by the TclX extension to perform its search in files on disk. Unfortunately these commands work on a line-by-line basis. AlphaTcl's workaround for this limitation is not robust enough and fails for the mentionned regexp which contains a linefeed symbol \n.
I'll try to fix this.


---

** [tickets:#221] Search in Filesets is broken if regexp contains \n**

**Status:** open
**Created:** Thu Nov 07, 2019 03:55 PM UTC by Bernard Desgraupes
**Last Updated:** Thu Nov 07, 2019 03:55 PM UTC
**Owner:** Bernard Desgraupes


(This bug was reported on the AlphaDev list by John Morris. I'm entering it in the bug tracker for easier reference)

Original message:
<< 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.>>



---

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] #221 Search in Filesets is broken if regexp contains \n

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

---

** [tickets:#221] Search in Filesets is broken if regexp contains \n**

**Status:** open
**Created:** Thu Nov 07, 2019 03:55 PM UTC by Bernard Desgraupes
**Last Updated:** Thu Nov 07, 2019 03:55 PM UTC
**Owner:** Bernard Desgraupes


(This bug was reported on the AlphaDev list by John Morris. I'm entering it in the bug tracker for easier reference)

Original message:
<< 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.>>



---

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] Search in Filesets

[John M. <joh...@ed...>]

Hi Bernard

>> 2. I often need to find an arbitrary number of nested delimiters. I found information about recursive searches that can do this. I know this can be done with some flavors of GREP, but it does not work with Alpha. It would be really cool if it did with in Alpha.
> 
> Do you have a pointer to this information about recursive searches. I’m not sure I understand what you’re referring to?

  I found a good entry point to the discussion on Stackoverflow at <https://stackoverflow.com/questions/133601/can-regular-expressions-be-used-to-match-nested-patterns>. The comments give plenty of discussion about why regular expressions can’t theoretically do recursion, but a few comments mention “context-free expressions,” which allow backtracking using an external stack. One comment mentions some tools that implement this possibility:

> From the books, regular expressions can't do that, but context-free expressions can. From the tools, modern expression parsers will call regular expressionsomething that is using an external stack, meaning able to backtrack, meaning able to recurse: those are context-free expressions in practice and as such you can do it as a one-liner with simili-PCRE2 (PHP, Java, .NET, Perl, ...) or ICU-compliant (Obj-C/Swift) tools, often with the (?>...) syntax, or alternatives such as the (?R) or (?0) syntaxes. – Cœur Aug 5 '15 at 7:38

  Of course, I don’t expect you to reinvent this yourself. I was just wondering if is is a matter of changing a switch in the current grep engine or using an easily accessible different grep engine in the modern Alpha.


Best,
John

Re: [Alphacocoa-devel] Search in Filesets

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

Hi John,

> Le 5 nov. 2019 à 16:47, John Morris <joh...@ed...> a écrit :
> 
> Hi Bernard,
>  Thank you for your quick response. I really appreciate all the work you do to keep Alpha working so well.
> 
>  I’m glad to hear that I’m not going crazy. I am confident that you will be able to clear up the trouble. While you are revising the package, it would be nice to offer two other requests.
> 
> 1. You may have noticed that I preface the search expression with (?s). The way I read Alpha's help about regular expressions, this is supposed to be the default. However, I find that it is only turned on sometimes, for certain searches. Therefore, I always have to remember to include that. It would be nice if it really were the default.

I’m not sure the doc is correct there. Might be outdated. I’ll have to check.


> 2. I often need to find an arbitrary number of nested delimiters. I found information about recursive searches that can do this. I know this can be done with some flavors of GREP, but it does not work with Alpha. It would be really cool if it did with in Alpha.

Do you have a pointer to this information about recursive searches. I’m not sure I understand what you’re referring to?

Re: [Alphacocoa-devel] Search in Filesets

[John M. <joh...@ed...>]

Hi Bernard,
  Thank you for your quick response. I really appreciate all the work you do to keep Alpha working so well.

  I’m glad to hear that I’m not going crazy. I am confident that you will be able to clear up the trouble. While you are revising the package, it would be nice to offer two other requests.

1. You may have noticed that I preface the search expression with (?s). The way I read Alpha's help about regular expressions, this is supposed to be the default. However, I find that it is only turned on sometimes, for certain searches. Therefore, I always have to remember to include that. It would be nice if it really were the default.

2. I often need to find an arbitrary number of nested delimiters. I found information about recursive searches that can do this. I know this can be done with some flavors of GREP, but it does not work with Alpha. It would be really cool if it did with in Alpha.

Best,
John

> On Nov 5, 2019, at 6:23 AM, Bernard Desgraupes <bde...@or...> wrote:
> 
> More about this…
> 
> After some investigation, it appears that the culprit is the \n in the regexp. There is nothing wrong with this regexp itself, it should work : what is wrong is the way AlphaTcl handles it. There is some legacy code (dating from AlphaX and maybe even earlier) which splits the regexp string into a first line and a tail and breaks everything. The code is very obscure there and it is clearly time to revise this package and proceed to a complete overhaul. My next goal...
> 
> Sorry for the inconvenience,
> Bernard

Re: [Alphacocoa-devel] Search in Filesets

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

More about this…

After some investigation, it appears that the culprit is the \n in the regexp. There is nothing wrong with this regexp itself, it should work : what is wrong is the way AlphaTcl handles it. There is some legacy code (dating from AlphaX and maybe even earlier) which splits the regexp string into a first line and a tail and breaks everything. The code is very obscure there and it is clearly time to revise this package and proceed to a complete overhaul. My next goal...

Sorry for the inconvenience,
Bernard

> Le 5 nov. 2019 à 11:23, Bernard Desgraupes <bde...@or...> a écrit :
> 
> Hi John,
> 
> thanks for reporting. Something is obviously going wrong there. I’ll have a look.
> 
> Cheers,
> 
> Bernard
> 
>> Le 4 nov. 2019 à 03:44, John Morris <joh...@ed...> a écrit :
>> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> AlphaCocoa-devel mailing list
>> Alp...@li...
>> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel
> 
> 
> 
> _______________________________________________
> AlphaCocoa-devel mailing list
> Alp...@li...
> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel

Re: [Alphacocoa-devel] Search in Filesets

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

Hi John,

thanks for reporting. Something is obviously going wrong there. I’ll have a look.

Cheers,

Bernard

> Le 4 nov. 2019 à 03:44, John Morris <joh...@ed...> a écrit :
> 
> 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
> 
> 
> 
> _______________________________________________
> AlphaCocoa-devel mailing list
> Alp...@li...
> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel

[Alphacocoa-devel] [alphacocoa:tickets] #220 saveHook error with multiple untitled documents

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

- **status**: fixed --> closed



---

** [tickets:#220] saveHook error with multiple untitled documents**

**Status:** closed
**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.

[Alphacocoa-devel] [alphacocoa:tickets] #219 focus shifts to end of line on indent

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

- **status**: fixed --> closed



---

** [tickets:#219] focus shifts to end of line on indent**

**Status:** closed
**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.

[Alphacocoa-devel] [alphacocoa:tickets] #218 LASTMODIFIED

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

- **status**: fixed --> closed



---

** [tickets:#218] LASTMODIFIED**

**Status:** closed
**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.

[Alphacocoa-devel] [alphacocoa:tickets] #217 HTML and CSS Mode Help uses yellow font towards the end.

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

- **status**: fixed --> closed



---

** [tickets:#217] HTML and CSS Mode Help uses yellow font towards the end.**

**Status:** closed
**Created:** Sun Jul 07, 2019 07:45 PM UTC by Christoph Schiller
**Last Updated:** Tue Jul 09, 2019 01:37 PM UTC
**Owner:** nobody


On 9.06 Ginan, reading HTML and CSS Mode Help is not possible: some fonts have no colour at all, some are yellow. This only occurs towards the end. The start is ok, though.

I see this after opening an HTML file, going (under the Alpha Menu) to HTML Mode Setup -> Mode Help.

The window starts well, but the end is unreadable.




---

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.