alphacocoa-devel — AlphaCocoa Development List

[Alphacocoa-devel] [alphacocoa:tickets] #187 Click is detected too slowly

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

- **status**: open --> closed
- **Version**: 9.0 --> 9.0.1



---

** [tickets:#187] Click is detected too slowly**

**Status:** closed
**Created:** Sun Oct 21, 2018 08:45 AM UTC by Joachim Kock
**Last Updated:** Thu Dec 13, 2018 07:20 AM UTC
**Owner:** nobody


Here is an annoying asynchronicity issue: do the following with 0.2-seconds intervals:
(1) click somewhere
(2) type a letter
(3) type a letter
What happens is that the first letter is inserted before the insertion-point movement
caused by the click :-( The second letter is inserted after the movement.

(I am not sure if 0.2 seconds is a precise indication, but it happens in practice.
The computer is relatively new MacBook Air running 10.13.4.)


---

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] #187 Click is detected too slowly

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

Thanks for the explanation. So I'm closing this report now.


---

** [tickets:#187] Click is detected too slowly**

**Status:** open
**Created:** Sun Oct 21, 2018 08:45 AM UTC by Joachim Kock
**Last Updated:** Thu Nov 01, 2018 12:00 PM UTC
**Owner:** nobody


Here is an annoying asynchronicity issue: do the following with 0.2-seconds intervals:
(1) click somewhere
(2) type a letter
(3) type a letter
What happens is that the first letter is inserted before the insertion-point movement
caused by the click :-( The second letter is inserted after the movement.

(I am not sure if 0.2 seconds is a precise indication, but it happens in practice.
The computer is relatively new MacBook Air running 10.13.4.)


---

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] #197 Default behaviour of "Clear Undo Stack on Save"

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

This is questionable and other users may agree or disagree. Changing this would also result in a growing memory footprint without the user being aware of it.
Unless there is massive popular demand, I would leave this setting as Alpha users are known to be smarter than others.


---

** [tickets:#197] Default behaviour of "Clear Undo Stack on Save"**

**Status:** open
**Created:** Tue Nov 13, 2018 11:12 AM UTC by Sylvain Loiseau
**Last Updated:** Tue Nov 13, 2018 11:12 AM UTC
**Owner:** nobody


A very minor point: by default, the Undo Stack is cleared on save. I know this is a preference that can be changed in global preference, Document, "Clear Undo Stack on Save". However, I'm wondering whether the default behaviour should not be to preserve the stack on save. This is the behaviour in most app, and before realizing it is different in Alpha -- and changing it in the pref -- one can lost work.




---

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] #209 Window position/size saved state is altered when re-opening a document

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

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



---

** [tickets:#209] Window position/size saved state is altered when re-opening a document**

**Status:** fixed
**Created:** Tue Dec 11, 2018 07:09 PM UTC by Greg Dunn
**Last Updated:** Thu Dec 13, 2018 07:07 AM UTC
**Owner:** nobody


When changing something like the wrapping and/or window size/position, recording the window
state and then saving the document, the document (when re-opened) displays with the top left corner of the window displaced downward by about 60 pixels.  The lower left/right coordinates aren't disturbed (so the window ends up being a little smaller).  

Subsequent opens of saved documents retain this offset - I had thought perhaps it was attempting to tile or overlap the windows, but it seems just to be applying a fixed offset from the upper left corner of the screen to the top left of the document window.  Curiously, if I reduce the window size by resizing from the top of the window, making it yet smaller, that state seems to be retained.  Resizing it so that the top nestles just below the status bar (where a default document is placed) and then saving does not retain the setting, but causes the window top left to be displaced downward again on re-open.

OS X Yosemite 10.10.5, Alpha 9.0.1 (8030)


---

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] #209 Window position/size saved state is altered when re-opening a document

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

Thanks for reporting this. You are right: there is a 54 pixels difference which is the height occupied by the* titlebar+statusbar+controlbar*. This is caused by a confusion between the contents rect and the frame rect of the window. The code was (wrongly) recording the contents rect but, on reopen, was interpreting it as the frame rect.
This is fixed.
Changes committed to the repository ([rev. 1585](https://sourceforge.net/p/alphacocoa/code/1585/)). The core must be rebuilt.


---

** [tickets:#209] Window position/size saved state is altered when re-opening a document**

**Status:** open
**Created:** Tue Dec 11, 2018 07:09 PM UTC by Greg Dunn
**Last Updated:** Tue Dec 11, 2018 07:09 PM UTC
**Owner:** nobody


When changing something like the wrapping and/or window size/position, recording the window
state and then saving the document, the document (when re-opened) displays with the top left corner of the window displaced downward by about 60 pixels.  The lower left/right coordinates aren't disturbed (so the window ends up being a little smaller).  

Subsequent opens of saved documents retain this offset - I had thought perhaps it was attempting to tile or overlap the windows, but it seems just to be applying a fixed offset from the upper left corner of the screen to the top left of the document window.  Curiously, if I reduce the window size by resizing from the top of the window, making it yet smaller, that state seems to be retained.  Resizing it so that the top nestles just below the status bar (where a default document is placed) and then saving does not retain the setting, but causes the window top left to be displaced downward again on re-open.

OS X Yosemite 10.10.5, Alpha 9.0.1 (8030)


---

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] #189 Erratic 'bottomRedraw'

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

For the record, I'm still investigating. No luck so far...


---

** [tickets:#189] Erratic 'bottomRedraw'**

**Status:** open
**Created:** Thu Nov 01, 2018 11:34 AM UTC by Joachim Kock
**Last Updated:** Fri Nov 09, 2018 04:29 PM UTC
**Owner:** nobody


Paste this report into an Alpha window with hard wrap
fillColumn=64. Resize the window to approximately 75 chars wide.
Make the window short enough vertically, say 15 lines high.
Scroll to place the Q line near the middle of the window. Now
start writing with short words after the Qs. At the moment the
end of the line (marked 888) hits the edge of the window, the
window focus suddenly jumps, making the active line the last
visible line of the window.

z
z
z
z
z

QQQ QQQ QQQ QQQ QQQ QQQ QQQ QQQ QQQ zzz zzz zzz zzz zzz 888
ggg ggg ggg ggg ggg ggg ggg ggg ggg ggg ggg ggg ggg ggg ggg

z
z
z
z
z
z
z
z
z
z
z
z
z
z



---

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] #196 Enter does not wok on menu item

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

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



---

** [tickets:#196] Enter does not wok on menu item**

**Status:** fixed
**Created:** Fri Nov 09, 2018 12:57 PM UTC by Sylvain Loiseau
**Last Updated:** Wed Dec 12, 2018 04:35 PM UTC
**Owner:** nobody


Having selected any menu entry with either the mouse or the keyboard and hitting "enter" does not trigger this menu item.


---

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] #196 Enter does not wok on menu item

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

No idea why it does not work: a tap on the trackpad works, but not the Return key.

Anyway this is fixed now. This was a VERY difficult one.
The NSKeyDown events are not delivered via [sendEvent] while running in NSEventTrackingRunLoopMode. So a runloop observer is installed to capture the *Return* key and trigger the corresponding menu action.
Changes committed to the repository ([rev. 1583](https://sourceforge.net/p/alphacocoa/code/1583/)). The core must be rebuilt.


---

** [tickets:#196] Enter does not wok on menu item**

**Status:** open
**Created:** Fri Nov 09, 2018 12:57 PM UTC by Sylvain Loiseau
**Last Updated:** Fri Nov 09, 2018 12:57 PM UTC
**Owner:** nobody


Having selected any menu entry with either the mouse or the keyboard and hitting "enter" does not trigger this menu item.


---

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] #208 RFE - add chosen text wrapping value to document saved window state

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

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



---

** [tickets:#208] RFE - add chosen text wrapping value to document saved window state**

**Status:** fixed
**Created:** Tue Dec 11, 2018 07:01 PM UTC by Greg Dunn
**Last Updated:** Wed Dec 12, 2018 07:36 AM UTC
**Owner:** nobody
**Attachments:**

- [text wrapping.png](https://sourceforge.net/p/alphacocoa/tickets/208/attachment/text%20wrapping.png) (19.9 kB; image/png)


I would like to see the "text wrapping" preference for a document be included in the "saved window state" parameters so that the document's chosen text wrapping is saved with the document and restored when the document is re-opened..


---

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] #208 RFE - add chosen text wrapping value to document saved window state

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

This is implemented now. The *Text Wrapping* state is saved as extended file attrtibute when the *Record Window State* item is on.
Changes committed to the repository ([rev. 1581](https://sourceforge.net/p/alphacocoa/code/1581/)). The core must be rebuilt.


---

** [tickets:#208] RFE - add chosen text wrapping value to document saved window state**

**Status:** open
**Created:** Tue Dec 11, 2018 07:01 PM UTC by Greg Dunn
**Last Updated:** Tue Dec 11, 2018 07:03 PM UTC
**Owner:** nobody
**Attachments:**

- [text wrapping.png](https://sourceforge.net/p/alphacocoa/tickets/208/attachment/text%20wrapping.png) (19.9 kB; image/png)


I would like to see the "text wrapping" preference for a document be included in the "saved window state" parameters so that the document's chosen text wrapping is saved with the document and restored when the document is re-opened..


---

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] Possible issues with saved state?

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

On 12/11/18 1:43 PM, Bernard Desgraupes wrote:
> Hi Greg,
> 
> thank you for the feedback.
> I’m replying below after each paragraph.

As always, thanks for the prompt responses!  I'll be adding a couple of tickets in a few moments.

> Le 11 déc. 2018 à 18:31, Greg Dunn <gre...@in...> a écrit :
> 
>> First of all, let me reiterate what a great job has been done in updating Alpha for OS X; every time I think I might need additional features in a
>> text editor, Alpha has already implemented them.  I don't know that I have any other application which has been my preferred choice for 20 years, and
>> which keeps moving forward.  Especially no application where the source is visible to all.
>>
>> I've been writing some documentation lately, and one of the features I use in such situations is the "Text Wrapping" preference.  It's nice to have a
>> choice between line mode and paragraph mode for different types of document, because I write lists as often as blog posts.  Unfortunately, I can't
>> seem to locate a way to retain the text wrapping state in a document between saves; I know it's not currently in the "record window state" parameters,
>> but all I see in the preferences is "wrap on open" which applies to all documents.  Am I overlooking something, or is this a design choice?  I can
>> deal with setting the wrap globally, I think, but it would be handy to have it selectable on a per-document basis.
> 
> There are two points here:
> - it would be feasible to also save the wrapping state  so that it is retained between session. You can enter an RFE for this !
> - I’m not sure what you mean by  « have it selectable on a per-document basis ». Do you mean a check box in the Open File dialog ? Or just adding the property to the window state parameters ?
> The wrapping state is selectable on a per-document basis with the Text Wrapping entry in the window info popup and/or menu. I think I’m missing your point.

I was afraid I wasn't being clear.  What I meant was that the property could be added to the saved state parameters - which is apparently the
preferred method of saving individual document states?

>> Another thing I stumbled across which may be a small bug: when changing something like the wrapping and/or window size/position, recording the window
>> state and then saving the document, the document re-opens with the top left corner of the window displaced downward by about 60 pixels.  The lower
>> left/right coordinates aren't disturbed.  Subsequent opens of saved documents retain this offset - I had thought perhaps it was attempting to tile or
>> overlap the windows, but it seems just to be applying a fixed offset from the upper left corner of the screen to the top left.  Curiously, if I reduce
>> the window size by resizing from the top of the window, making it yet smaller, that state seems to be retained.  Resizing it so that the top nestles
>> just below the status bar (where a default document is placed) and then saving does not retain the setting, but causes the window top left to be
>> displaced downward again on re-open.  Again, if this is a setting, I can't seem to locate it.
> 
> I’ll look into this. It pretty much looks like a bug. You can enter a Ticket for this !

Thanks - will do.

>> Related to the above, is seems that when enabling "record window state" and then executing the "save" command, the window state parameters appear to
>> be saved - but there is no visual indication that anything has been saved.  This action does not set either of the "buffer dirty" indicators or echo
>> anything in the status bar, which I can understand - it's not changing the buffer.  Again, if this is a design choice, fair enough; but it took me a
>> few tests to confirm that the window state was indeed being saved.  Perhaps a status message such as "state saved" might be helpful when the buffer
>> itself is not changed?  It works, so technically no change is needed, but I thought I'd bring up the subject.
> 
> I agree it would be more friendly to have some sort of acknowledgment coming from the application. No need for an RFE, I’ll do it.
> 
> Cheers,
> Bernard

Excellent!

-- 
| Greg Dunn                       | Using emacs as a text editor is  |
| gre...@in...               | like using a car to listen to    |
| The Sultan of Slack(tm)         | the radio.                       |
| http://www.indy.net/~gregdunn/  |                - Mike Campbell   |

[Alphacocoa-devel] [alphacocoa:tickets] #209 Window position/size saved state is altered when re-opening a document

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

---

** [tickets:#209] Window position/size saved state is altered when re-opening a document**

**Status:** open
**Created:** Tue Dec 11, 2018 07:09 PM UTC by Greg Dunn
**Last Updated:** Tue Dec 11, 2018 07:09 PM UTC
**Owner:** nobody


When changing something like the wrapping and/or window size/position, recording the window
state and then saving the document, the document (when re-opened) displays with the top left corner of the window displaced downward by about 60 pixels.  The lower left/right coordinates aren't disturbed (so the window ends up being a little smaller).  

Subsequent opens of saved documents retain this offset - I had thought perhaps it was attempting to tile or overlap the windows, but it seems just to be applying a fixed offset from the upper left corner of the screen to the top left of the document window.  Curiously, if I reduce the window size by resizing from the top of the window, making it yet smaller, that state seems to be retained.  Resizing it so that the top nestles just below the status bar (where a default document is placed) and then saving does not retain the setting, but causes the window top left to be displaced downward again on re-open.

OS X Yosemite 10.10.5, Alpha 9.0.1 (8030)


---

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] #208 RFE - add chosen text wrapping value to document saved window state

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

Sorry, meant to set type as RFE.  :-(


---

** [tickets:#208] RFE - add chosen text wrapping value to document saved window state**

**Status:** open
**Created:** Tue Dec 11, 2018 07:01 PM UTC by Greg Dunn
**Last Updated:** Tue Dec 11, 2018 07:01 PM UTC
**Owner:** nobody
**Attachments:**

- [text wrapping.png](https://sourceforge.net/p/alphacocoa/tickets/208/attachment/text%20wrapping.png) (19.9 kB; image/png)


I would like to see the "text wrapping" preference for a document be included in the "saved window state" parameters so that the document's chosen text wrapping is saved with the document and restored when the document is re-opened..


---

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] #208 RFE - add chosen text wrapping value to document saved window state

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

---

** [tickets:#208] RFE - add chosen text wrapping value to document saved window state**

**Status:** open
**Created:** Tue Dec 11, 2018 07:01 PM UTC by Greg Dunn
**Last Updated:** Tue Dec 11, 2018 07:01 PM UTC
**Owner:** nobody
**Attachments:**

- [text wrapping.png](https://sourceforge.net/p/alphacocoa/tickets/208/attachment/text%20wrapping.png) (19.9 kB; image/png)


I would like to see the "text wrapping" preference for a document be included in the "saved window state" parameters so that the document's chosen text wrapping is saved with the document and restored when the document is re-opened..


---

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] Possible issues with saved state?

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

Hi Greg,

thank you for the feedback.
I’m replying below after each paragraph.

Le 11 déc. 2018 à 18:31, Greg Dunn <gre...@in...> a écrit :

> First of all, let me reiterate what a great job has been done in updating Alpha for OS X; every time I think I might need additional features in a
> text editor, Alpha has already implemented them.  I don't know that I have any other application which has been my preferred choice for 20 years, and
> which keeps moving forward.  Especially no application where the source is visible to all.
> 
> I've been writing some documentation lately, and one of the features I use in such situations is the "Text Wrapping" preference.  It's nice to have a
> choice between line mode and paragraph mode for different types of document, because I write lists as often as blog posts.  Unfortunately, I can't
> seem to locate a way to retain the text wrapping state in a document between saves; I know it's not currently in the "record window state" parameters,
> but all I see in the preferences is "wrap on open" which applies to all documents.  Am I overlooking something, or is this a design choice?  I can
> deal with setting the wrap globally, I think, but it would be handy to have it selectable on a per-document basis.

There are two points here:
- it would be feasible to also save the wrapping state  so that it is retained between session. You can enter an RFE for this !
- I’m not sure what you mean by  « have it selectable on a per-document basis ». Do you mean a check box in the Open File dialog ? Or just adding the property to the window state parameters ?
The wrapping state is selectable on a per-document basis with the Text Wrapping entry in the window info popup and/or menu. I think I’m missing your point.

> Another thing I stumbled across which may be a small bug: when changing something like the wrapping and/or window size/position, recording the window
> state and then saving the document, the document re-opens with the top left corner of the window displaced downward by about 60 pixels.  The lower
> left/right coordinates aren't disturbed.  Subsequent opens of saved documents retain this offset - I had thought perhaps it was attempting to tile or
> overlap the windows, but it seems just to be applying a fixed offset from the upper left corner of the screen to the top left.  Curiously, if I reduce
> the window size by resizing from the top of the window, making it yet smaller, that state seems to be retained.  Resizing it so that the top nestles
> just below the status bar (where a default document is placed) and then saving does not retain the setting, but causes the window top left to be
> displaced downward again on re-open.  Again, if this is a setting, I can't seem to locate it.

I’ll look into this. It pretty much looks like a bug. You can enter a Ticket for this !

> 
> Related to the above, is seems that when enabling "record window state" and then executing the "save" command, the window state parameters appear to
> be saved - but there is no visual indication that anything has been saved.  This action does not set either of the "buffer dirty" indicators or echo
> anything in the status bar, which I can understand - it's not changing the buffer.  Again, if this is a design choice, fair enough; but it took me a
> few tests to confirm that the window state was indeed being saved.  Perhaps a status message such as "state saved" might be helpful when the buffer
> itself is not changed?  It works, so technically no change is needed, but I thought I'd bring up the subject.

I agree it would be more friendly to have some sort of acknowledgment coming from the application. No need for an RFE, I’ll do it.

Cheers,
Bernard

[Alphacocoa-devel] Possible issues with saved state?

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

First of all, let me reiterate what a great job has been done in updating Alpha for OS X; every time I think I might need additional features in a
text editor, Alpha has already implemented them.  I don't know that I have any other application which has been my preferred choice for 20 years, and
which keeps moving forward.  Especially no application where the source is visible to all.

I've been writing some documentation lately, and one of the features I use in such situations is the "Text Wrapping" preference.  It's nice to have a
choice between line mode and paragraph mode for different types of document, because I write lists as often as blog posts.  Unfortunately, I can't
seem to locate a way to retain the text wrapping state in a document between saves; I know it's not currently in the "record window state" parameters,
but all I see in the preferences is "wrap on open" which applies to all documents.  Am I overlooking something, or is this a design choice?  I can
deal with setting the wrap globally, I think, but it would be handy to have it selectable on a per-document basis.

Another thing I stumbled across which may be a small bug: when changing something like the wrapping and/or window size/position, recording the window
state and then saving the document, the document re-opens with the top left corner of the window displaced downward by about 60 pixels.  The lower
left/right coordinates aren't disturbed.  Subsequent opens of saved documents retain this offset - I had thought perhaps it was attempting to tile or
overlap the windows, but it seems just to be applying a fixed offset from the upper left corner of the screen to the top left.  Curiously, if I reduce
the window size by resizing from the top of the window, making it yet smaller, that state seems to be retained.  Resizing it so that the top nestles
just below the status bar (where a default document is placed) and then saving does not retain the setting, but causes the window top left to be
displaced downward again on re-open.  Again, if this is a setting, I can't seem to locate it.

Related to the above, is seems that when enabling "record window state" and then executing the "save" command, the window state parameters appear to
be saved - but there is no visual indication that anything has been saved.  This action does not set either of the "buffer dirty" indicators or echo
anything in the status bar, which I can understand - it's not changing the buffer.  Again, if this is a design choice, fair enough; but it took me a
few tests to confirm that the window state was indeed being saved.  Perhaps a status message such as "state saved" might be helpful when the buffer
itself is not changed?  It works, so technically no change is needed, but I thought I'd bring up the subject.

If any of these are indeed bugs or possible enhancements, I'll gladly submit one or more tickets to get them properly into the tracking system.  But
if I'm just missing a preference setting or appropriate usage of the feature, I'd rather know that before submitting pointless messages to the
tracker. :-)  I appreciate the determination and effort devoted to enhancing the application!

-- 
| Greg Dunn                       | If you believe in things that    |
| gre...@in...               | you can't understand, then       |
| The Sultan of Slack(tm)         | you'll suffer... Superstition    |
| http://www.indy.net/~gregdunn/  | ain't the way.                   |
|                                 |                  Stevie Wonder   |

[Alphacocoa-devel] [alphacocoa:tickets] #203 "Display Palettes" in Markdown mode: two bugs and one RFE

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

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

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



---

** [tickets:#203] "Display Palettes" in Markdown mode: two bugs and one RFE**

**Status:** fixed
**Created:** Tue Nov 20, 2018 02:42 PM UTC by Sylvain Loiseau
**Last Updated:** Mon Dec 10, 2018 07:05 PM UTC
**Owner:** nobody


When "Display Palettes" is activated in Mardown mode, two things seem strange:

- If I click again on "Display Palettes", only one palette disapears. Beside,  I suggest that the menu item swith to "Hide Palettes" once activated.
- If I switch to another document (while one Markdown file is open, with Palettes shown), the "Mardown"  menu disapear from the menu bar, but the Palettes are still visible

Beside, one RFE (maybe not a good one) : to have the shortcut displayed on the palette beside the function names.

Best,
Sylvain


---

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] #203 "Display Palettes" in Markdown mode: two bugs and one RFE

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

Both issues have been fixed.
The *Hide Palettes*  feature has been implemented as a dynamic menu item : it shows in the menu if you press the *Option* (⌥) key. The reason for this is that there are 4 floating windows which the user might close manually : if two floating windows are opened and the other two are closed, it is unclear what a single menu item should display (Show or Hide). So I prefer two distinct menu items, on an all-or-nothing basis.
Concerning the RFE,  I'm not sure it is worth the effort.



---

** [tickets:#203] "Display Palettes" in Markdown mode: two bugs and one RFE**

**Status:** open
**Created:** Tue Nov 20, 2018 02:42 PM UTC by Sylvain Loiseau
**Last Updated:** Tue Nov 20, 2018 02:42 PM UTC
**Owner:** nobody


When "Display Palettes" is activated in Mardown mode, two things seem strange:

- If I click again on "Display Palettes", only one palette disapears. Beside,  I suggest that the menu item swith to "Hide Palettes" once activated.
- If I switch to another document (while one Markdown file is open, with Palettes shown), the "Mardown"  menu disapear from the menu bar, but the Palettes are still visible

Beside, one RFE (maybe not a good one) : to have the shortcut displayed on the palette beside the function names.

Best,
Sylvain


---

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] #200 xml::electricClosingAngleBracket : two issues

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

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



---

** [tickets:#200] xml::electricClosingAngleBracket : two issues**

**Status:** fixed
**Created:** Mon Nov 19, 2018 08:57 AM UTC by Sylvain Loiseau
**Last Updated:** Mon Dec 10, 2018 03:18 PM UTC
**Owner:** nobody


In XML mode, xml::electricClosingAngleBracket offers to insert the end-tag of an XML element while typing the closing ">" of the start-tag.

I have noted two issues:

- with prefixed element name (QName), for instance "xsl:param", only "xsl" is inserted in the end tag. It is due to the regexp used for matching the start tag:

`regexp -- {[\w]+} $tag tag`
l.  511 of Modes/XML Modes/xmlMode.tcl
I think it could be turned into:

`regexp -- {[\w]*:?[\w]+} $tag tag`

- second ; when typing a start-tag at the very end of a document (the cursor is at the last position), the closing tag is not inserted. I havn't been able to trace the issue. It may be a common situation to enter the root element of a document and to expect it to be closed also.

Best,
Sylvain


---

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] #200 xml::electricClosingAngleBracket : two issues

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

Both issues are fixed now.
Regarding the first one, thanks for the regexp. One can even write just 
```
regexp -- {(\w+:)?\w+} $tag tag
```

The second issue was a core bug (an index out of bounds which caused Cocoa to raise an exception and stop processing).

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


---

** [tickets:#200] xml::electricClosingAngleBracket : two issues**

**Status:** open
**Created:** Mon Nov 19, 2018 08:57 AM UTC by Sylvain Loiseau
**Last Updated:** Mon Nov 19, 2018 10:00 AM UTC
**Owner:** nobody


In XML mode, xml::electricClosingAngleBracket offers to insert the end-tag of an XML element while typing the closing ">" of the start-tag.

I have noted two issues:

- with prefixed element name (QName), for instance "xsl:param", only "xsl" is inserted in the end tag. It is due to the regexp used for matching the start tag:

`regexp -- {[\w]+} $tag tag`
l.  511 of Modes/XML Modes/xmlMode.tcl
I think it could be turned into:

`regexp -- {[\w]*:?[\w]+} $tag tag`

- second ; when typing a start-tag at the very end of a document (the cursor is at the last position), the closing tag is not inserted. I havn't been able to trace the issue. It may be a common situation to enter the root element of a document and to expect it to be closed also.

Best,
Sylvain


---

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] #198 unsaved change when typesetting in tex mode

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

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



---

** [tickets:#198] unsaved change when typesetting in tex mode**

**Status:** fixed
**Created:** Tue Nov 13, 2018 11:16 AM UTC by Sylvain Loiseau
**Last Updated:** Mon Dec 10, 2018 02:32 PM UTC
**Owner:** nobody


When typesetting a buffer in tex mode that have unsaved changes, a dialog appears:

"The window 'xxx' has unsaved changes"...
Do you want to save it before typesetting?

The odd point is that the user is left with only one button "Save and Typeset", the question in the dialog being then rather rhetorical :-) Maybe a "abort" button would be more coherent, even if it will not be very useful in practice.


---

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] #198 unsaved change when typesetting in tex mode

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

This is fixed. There are now three buttons: *Save and Typeset*, *Typeset*, or *Cancel*. Note that you can bypass this dialog with the *Auto Save On Typeset* preference defined in TeX mode.
Changes committed to the repository ([rev. 1576](https://sourceforge.net/p/alphacocoa/code/1576/)).


---

** [tickets:#198] unsaved change when typesetting in tex mode**

**Status:** open
**Created:** Tue Nov 13, 2018 11:16 AM UTC by Sylvain Loiseau
**Last Updated:** Tue Nov 13, 2018 11:16 AM UTC
**Owner:** nobody


When typesetting a buffer in tex mode that have unsaved changes, a dialog appears:

"The window 'xxx' has unsaved changes"...
Do you want to save it before typesetting?

The odd point is that the user is left with only one button "Save and Typeset", the question in the dialog being then rather rhetorical :-) Maybe a "abort" button would be more coherent, even if it will not be very useful in practice.


---

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] #194 Same file opened twice with the "File->Open..." dialog

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

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



---

** [tickets:#194] Same file opened twice with the "File->Open..." dialog**

**Status:** fixed
**Created:** Thu Nov 08, 2018 03:21 PM UTC by Sylvain Loiseau
**Last Updated:** Mon Dec 10, 2018 01:18 PM UTC
**Owner:** nobody


If I drag (the icon of) a file on the Alpha icon, and if this file is already open, Alpha does not open it a second time a bring the corresponding buffer on the foreground. The same thing occurs if I select an already opened file in the "File->Open Recent" list.

However, if I select a file already opened in the "File->Open..." dialog, it open a new buffer of that file whose name is suffixed with <2>.

At some point (I cannot determinate when exactly), the "Open Recent" list start working the same way: each time I select the same file in the list, it open a new buffer, incrementing the <n> suffix.

Best,
Sylvain


---

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] #194 Same file opened twice with the "File->Open..." dialog

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

This is fixed. "File->Open..." dialog is now consistent with the other methods: if the file is already opened, Alpha brings it to front.
Changes committed to the repository ([rev. 1575](https://sourceforge.net/p/alphacocoa/code/1575/)).


---

** [tickets:#194] Same file opened twice with the "File->Open..." dialog**

**Status:** open
**Created:** Thu Nov 08, 2018 03:21 PM UTC by Sylvain Loiseau
**Last Updated:** Thu Nov 08, 2018 03:52 PM UTC
**Owner:** nobody


If I drag (the icon of) a file on the Alpha icon, and if this file is already open, Alpha does not open it a second time a bring the corresponding buffer on the foreground. The same thing occurs if I select an already opened file in the "File->Open Recent" list.

However, if I select a file already opened in the "File->Open..." dialog, it open a new buffer of that file whose name is suffixed with <2>.

At some point (I cannot determinate when exactly), the "Open Recent" list start working the same way: each time I select the same file in the list, it open a new buffer, incrementing the <n> suffix.

Best,
Sylvain


---

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] #193 Strange behavior while opening several modal windows

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

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



---

** [tickets:#193] Strange behavior while opening several modal windows**

**Status:** fixed
**Created:** Thu Nov 08, 2018 01:58 PM UTC by Sylvain Loiseau
**Last Updated:** Mon Dec 10, 2018 01:02 PM UTC
**Owner:** nobody


I open a modal window (say, Alpha->Preferences->Global Preferences...). I can then select another modal window (say, Alpha->Preferences->Global Setup->Features...) This second window does not apear until I select the Ok button of the first window. When doing so, the first modal window does not close, but the second window appear on the top of the first.

I'm not sure whether this is really a problem and, if so, where the problem is: the menu still being available while a modal window is open? the second window not appearing immediatly when requested?

Best,
Sylvain


---

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.