alphacocoa-devel — AlphaCocoa Development List

[Alphacocoa-devel] [alphacocoa:tickets] #233 tab after \label{}• in TeX mode

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

- **status**: fixed --> closed
- **Version**: 9.0 --> 9.1.2



---

** [tickets:#233] tab after \label{}• in TeX mode**

**Status:** closed
**Created:** Wed May 20, 2020 03:32 PM UTC by  Laurent PRALY
**Last Updated:** Tue May 26, 2020 08:06 AM UTC
**Owner:** nobody


In TeXmode, if after typing
\label{}•
I move the cursor back to put it between { and }
and then I use the key TAB, then \label{}• is removed.
If follow the same steps with say ref, i.e.
\ref{}• , back between { and } and  TAB, I jump to the next stop, i.e., I get
\ref{}
with the cursor after }

Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.

Question: is there a way to disable this feature.

Note that, on purpose, I am not using the binding (and proc) which creates  \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•


---

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] #234 TeX Synchronization with Skim is broken

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

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

This is fixed now.
Changes committed to the repository ([rev. 1909](https://sourceforge.net/p/alphacocoa/code/1909/)).



---

** [tickets:#234] TeX Synchronization with Skim is broken**

**Status:** fixed
**Created:** Mon Jun 01, 2020 05:53 AM UTC by Bernard Desgraupes
**Last Updated:** Mon Jun 01, 2020 05:59 AM UTC
**Owner:** nobody


(Entering this bug for the record).
I have been privately reported that TeX mode's Synchronize command does not work in Alpha version 9.1.2 when Skim is used a PDF viewer. This is an Alpha issue (Skim has nothing to do with it).


---

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] #234 TeX Synchronization with Skim is broken

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

This is caused by a typo. In version 9.1.2, Alpha introduced a new command [applescript](https://alphacocoa.sourceforge.io/Reference/applescript.html) in replacement of the old Tclapplescript extension. 
The typo is in the file 
`Alpha.app/Contents/Resources/Libraries/AlphaTcl/Tcl/SystemCode/CorePackages/fileServices.tcl` on line 137.
It should be 
```
    applescript execute $script
```
instead of 
```
    applescript execute -- $script
```



---

** [tickets:#234] TeX Synchronization with Skim is broken**

**Status:** open
**Created:** Mon Jun 01, 2020 05:53 AM UTC by Bernard Desgraupes
**Last Updated:** Mon Jun 01, 2020 05:53 AM UTC
**Owner:** nobody


(Entering this bug for the record).
I have been privately reported that TeX mode's Synchronize command does not work in Alpha version 9.1.2 when Skim is used a PDF viewer. This is an Alpha issue (Skim has nothing to do with it).


---

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] #234 TeX Synchronization with Skim is broken

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

---

** [tickets:#234] TeX Synchronization with Skim is broken**

**Status:** open
**Created:** Mon Jun 01, 2020 05:53 AM UTC by Bernard Desgraupes
**Last Updated:** Mon Jun 01, 2020 05:53 AM UTC
**Owner:** nobody


(Entering this bug for the record).
I have been privately reported that TeX mode's Synchronize command does not work in Alpha version 9.1.2 when Skim is used a PDF viewer. This is an Alpha issue (Skim has nothing to do with it).


---

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] #227 Includes "Update Folder..." in HTML Mode possibly buggy

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

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



---

** [tickets:#227] Includes "Update Folder..."  in HTML Mode possibly buggy**

**Status:** fixed
**Created:** Sun Apr 05, 2020 08:07 AM UTC by Christoph Schiller
**Last Updated:** Sat May 30, 2020 09:31 AM UTC
**Owner:** nobody


In Alpha 9.1.1, in HTML mode on OSX 10.14.6, there is, in the top menu, an icon that looks like a plate with a fork (just before "Help")
In that menu, there is a "Includes" line with a submenu.

The "Update window" works well, it substitutes the code between two INCLUDE tags.

The "Update folder..." has no effect. Maybe I use it wrongly (but there is no indication in the manual or in the mailing list).
I would expect it to update all html files in the selected folder - but my Alpha only says: 
"Folder updated successfully" (after asking whether to update subfolders).
However, my Aplpha does not update any file at all, whatever I answer.

Is this a bug or am I making a  mistake?




---

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] #227 Includes "Update Folder..." in HTML Mode possibly buggy

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

Hi Christoph, I started debugging this part of the code and indeed it looks wrong. It is very old and still contains pre-OSX things ! A complete overhaul is clearly necessary. 

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



---

** [tickets:#227] Includes "Update Folder..."  in HTML Mode possibly buggy**

**Status:** open
**Created:** Sun Apr 05, 2020 08:07 AM UTC by Christoph Schiller
**Last Updated:** Sat May 30, 2020 07:03 AM UTC
**Owner:** nobody


In Alpha 9.1.1, in HTML mode on OSX 10.14.6, there is, in the top menu, an icon that looks like a plate with a fork (just before "Help")
In that menu, there is a "Includes" line with a submenu.

The "Update window" works well, it substitutes the code between two INCLUDE tags.

The "Update folder..." has no effect. Maybe I use it wrongly (but there is no indication in the manual or in the mailing list).
I would expect it to update all html files in the selected folder - but my Alpha only says: 
"Folder updated successfully" (after asking whether to update subfolders).
However, my Aplpha does not update any file at all, whatever I answer.

Is this a bug or am I making a  mistake?




---

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] #227 Includes "Update Folder..." in HTML Mode possibly buggy

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

Yes, I see that.
This is fixed now. I still need to test more before I can commit the fixes.
Cheers,
Bernard

> Le 30 mai 2020 à 09:03, Christoph Schiller <cs...@us...> a écrit :
> 
> Just as feedback to you: It appears that "Includes-Update Window" and "Includes-Update File ..." and "Includes-Insert Include Tags" all work properly. Just the other two (Folder and Home Page) do not seem to work.
> 

[Alphacocoa-devel] [alphacocoa:tickets] #227 Includes "Update Folder..." in HTML Mode possibly buggy

[Christoph S. <cs...@us...>]

Just as feedback to you: It appears that "Includes-Update Window" and "Includes-Update File ..." and "Includes-Insert Include Tags" all work properly. Just the other two (Folder and Home Page) do not seem to work. 


---

** [tickets:#227] Includes "Update Folder..."  in HTML Mode possibly buggy**

**Status:** open
**Created:** Sun Apr 05, 2020 08:07 AM UTC by Christoph Schiller
**Last Updated:** Sat May 30, 2020 05:52 AM UTC
**Owner:** nobody


In Alpha 9.1.1, in HTML mode on OSX 10.14.6, there is, in the top menu, an icon that looks like a plate with a fork (just before "Help")
In that menu, there is a "Includes" line with a submenu.

The "Update window" works well, it substitutes the code between two INCLUDE tags.

The "Update folder..." has no effect. Maybe I use it wrongly (but there is no indication in the manual or in the mailing list).
I would expect it to update all html files in the selected folder - but my Alpha only says: 
"Folder updated successfully" (after asking whether to update subfolders).
However, my Aplpha does not update any file at all, whatever I answer.

Is this a bug or am I making a  mistake?




---

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] #227 Includes "Update Folder..." in HTML Mode possibly buggy

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

- **status**: expected --> open
- **Comment**:

Hi Christoph, I started debugging this part of the code and indeed it looks wrong. It is very old and still contains pre-OSX things ! A complete overhaul is clearly necessary. I'm reopening this ticket.



---

** [tickets:#227] Includes "Update Folder..."  in HTML Mode possibly buggy**

**Status:** open
**Created:** Sun Apr 05, 2020 08:07 AM UTC by Christoph Schiller
**Last Updated:** Fri May 29, 2020 07:17 PM UTC
**Owner:** nobody


In Alpha 9.1.1, in HTML mode on OSX 10.14.6, there is, in the top menu, an icon that looks like a plate with a fork (just before "Help")
In that menu, there is a "Includes" line with a submenu.

The "Update window" works well, it substitutes the code between two INCLUDE tags.

The "Update folder..." has no effect. Maybe I use it wrongly (but there is no indication in the manual or in the mailing list).
I would expect it to update all html files in the selected folder - but my Alpha only says: 
"Folder updated successfully" (after asking whether to update subfolders).
However, my Aplpha does not update any file at all, whatever I answer.

Is this a bug or am I making a  mistake?




---

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] #227 Includes "Update Folder..." in HTML Mode possibly buggy

[Christoph S. <cs...@us...>]

Thank you for all your help - and for your wonderful editor. I still do not get it working, but I also do not want to waste your time any more. I lost too many hours now, just trying. If anybody else ever gets the command "Update folder.." in HTML mode to actually do something, I'd be happy to hear about it. My site is www.motionmountain.net


---

** [tickets:#227] Includes "Update Folder..."  in HTML Mode possibly buggy**

**Status:** expected
**Created:** Sun Apr 05, 2020 08:07 AM UTC by Christoph Schiller
**Last Updated:** Fri May 29, 2020 04:39 AM UTC
**Owner:** nobody


In Alpha 9.1.1, in HTML mode on OSX 10.14.6, there is, in the top menu, an icon that looks like a plate with a fork (just before "Help")
In that menu, there is a "Includes" line with a submenu.

The "Update window" works well, it substitutes the code between two INCLUDE tags.

The "Update folder..." has no effect. Maybe I use it wrongly (but there is no indication in the manual or in the mailing list).
I would expect it to update all html files in the selected folder - but my Alpha only says: 
"Folder updated successfully" (after asking whether to update subfolders).
However, my Aplpha does not update any file at all, whatever I answer.

Is this a bug or am I making a  mistake?




---

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] #227 Includes "Update Folder..." in HTML Mode possibly buggy

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

Hi Christoph, there is some information available in Alpha's HTML mode help in the 
[Includes](https://alphacocoa.sourceforge.io/HtmlCssModeHelp.html#AIDASEC62) section.
My understanding is that the *Home Page Folder* should contain files that are dynamic and the *Includes Folder* should contain the files whose contents are inserted inside the `<!-- #INCLUDE` tags. In other words, the files in *Home Page Folder*  do have `<!-- #INCLUDE` tags and have to be updated if the portions they include changed.


---

** [tickets:#227] Includes "Update Folder..."  in HTML Mode possibly buggy**

**Status:** expected
**Created:** Sun Apr 05, 2020 08:07 AM UTC by Christoph Schiller
**Last Updated:** Thu May 28, 2020 05:10 AM UTC
**Owner:** nobody


In Alpha 9.1.1, in HTML mode on OSX 10.14.6, there is, in the top menu, an icon that looks like a plate with a fork (just before "Help")
In that menu, there is a "Includes" line with a submenu.

The "Update window" works well, it substitutes the code between two INCLUDE tags.

The "Update folder..." has no effect. Maybe I use it wrongly (but there is no indication in the manual or in the mailing list).
I would expect it to update all html files in the selected folder - but my Alpha only says: 
"Folder updated successfully" (after asking whether to update subfolders).
However, my Aplpha does not update any file at all, whatever I answer.

Is this a bug or am I making a  mistake?




---

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] #227 Includes "Update Folder..." in HTML Mode possibly buggy

[Christoph S. <cs...@us...>]

Bernard, can I ask for clarifications? I have all my html files in a Home Page Folder called .../ HTML
I now also have a folder called .../HTML-includes which is defined as Include Folder

Which files (the html files to be updated, and the code parts/snippets to be included) have to be in which folder? 

Where is this explained? For a new user it is not easy...


---

** [tickets:#227] Includes "Update Folder..."  in HTML Mode possibly buggy**

**Status:** expected
**Created:** Sun Apr 05, 2020 08:07 AM UTC by Christoph Schiller
**Last Updated:** Mon May 04, 2020 07:07 AM UTC
**Owner:** nobody


In Alpha 9.1.1, in HTML mode on OSX 10.14.6, there is, in the top menu, an icon that looks like a plate with a fork (just before "Help")
In that menu, there is a "Includes" line with a submenu.

The "Update window" works well, it substitutes the code between two INCLUDE tags.

The "Update folder..." has no effect. Maybe I use it wrongly (but there is no indication in the manual or in the mailing list).
I would expect it to update all html files in the selected folder - but my Alpha only says: 
"Folder updated successfully" (after asking whether to update subfolders).
However, my Aplpha does not update any file at all, whatever I answer.

Is this a bug or am I making a  mistake?




---

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] Alpha Release 9.1.2 (Alcyone)

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

Hi all,

I'm pleased to announce the release of a new version of Alpha. This is Alpha 9.1.2 ("Alcyone <https://alphacocoa.sourceforge.io/AlphaStar.html>") for Mac OS X 10.11 or greater (El Capitan, Sierra, High Sierra, Mojave, Catalina). 

All versions of Alpha are named after a star. So, for this new release, meet Alcyone <https://alphacocoa.sourceforge.io/AlphaStar.html>, which is η Tauri, the η star of the Taurus constellation. 

Beware: the Maverick (10.9) and Yosemite (10.10) versions of OS X are no longer supported. The latest version of Alpha running on these two systems is 9.0.3. 

See at the end of this message, the main changes contained in this new release. 

Please, read the release notes which will be displayed the first time you launch Alpha and can be accessed later from the Help ↣ Developer Help menu. 

Here is the URL to download the disk image: 
https://sourceforge.net/projects/alphacocoa/files/9.1.2/Alpha_9.1.2.dmg.zip/download <https://sourceforge.net/projects/alphacocoa/files/9.1.2/Alpha_9.1.2.dmg.zip/download> (32.88M) 

The MD5 checksum is: 191701f412a70b2e5aa77e2588d1ac0a 
The SHA1 checksum is: ed1a5a726ccfc1fd3d29468c0d92f5db9784cfd1 
The RMD160 checksum is: 4c19ba4684b82a6a33b06a303c45b25caa187005 
The SHA256 checksum is: 7f9885cc622c3f750b3331ade0d9f2c8e0355ba8363b1ab19841c73e7043a153 

If you find problems with the application, don't hesitate to post bug reports. They are essential to keep track of the deficiencies. See Alpha's Bug Tracker <https://sourceforge.net/p/alphacocoa/tickets/>. 

Thank you for using Alpha. 
Cheers, 
Bernard
 <>Changes from previous version

New debugging core command [dumpViews] <https://alphacocoa.sourceforge.io/Syntax/dumpViews.html>.
New mechanism to navigate in commands history with a popover window.
All consoles now record their command history between sessions.
New -docviewFrame option for views included in a scroll view. Used to scroll these views programmatically.
Reintroduced the old Option Click On Titlebar functionality using popover windows.
Installed the Option Click On Titlebar functionality in many modes.
new core command [applescript] <https://alphacocoa.sourceforge.io/Reference/applescript.html> to run AppleScript code or script files. It is designed to replace the Tclapplescript extension.
New package Pinyin Accents that provides bindings to easily insert chinese tone marks on a vowel in pinyin transliteration. A palette is also available.
New core command [menuBar height] <https://alphacocoa.sourceforge.io/Reference/menuBar.html#cmd_menuBar_height>.
New subcommand [view ordered] <https://alphacocoa.sourceforge.io/Reference/view.html#cmd_view_ordered> to manage the order of root windows.
New IPA palette with the International Phonetic Alphabet symbols.
New Zsh mode <https://alphacocoa.sourceforge.io/ZshModeHelp.html> to edit Z Shell script files.
New keyword darkMode for the [getAppInfo] <https://alphacocoa.sourceforge.io/Syntax/getAppInfo.html> command. It returns a boolean value indicating whether dark mode is currently enabled.
New preference Tab Deletes Empty Labels in LaTeX mode to control the behavior of the Tab key when completing some math environment templates. See Ticket #233 <https://sourceforge.net/p/alphacocoa/tickets/233/>.
The following bugs have been fixed (but remain open until the fix is confirmed):
Ticket #225: 'Prefs Search' button broken in top-level Prefs Dashboard <https://sourceforge.net/p/alphacocoa/tickets/225/>
Ticket #226: Replace Alll on Very Large File Executes Save <https://sourceforge.net/p/alphacocoa/tickets/226/>
Ticket #227: Includes 'Update Folder...' in HTML Mode possibly buggy <https://sourceforge.net/p/alphacocoa/tickets/227/>
Ticket #228: Alpha Crashes on Launch With Multiple Users <https://sourceforge.net/p/alphacocoa/tickets/228/>
Ticket #229: Selected text is invisible, depending on highlighting settings in System Preferences <https://sourceforge.net/p/alphacocoa/tickets/229/>
Ticket #230: Search & Replace: Patterns menu in updates only after restart <https://sourceforge.net/p/alphacocoa/tickets/230/>
Ticket #231: Automatic Line Breaking global preference not honoured <https://sourceforge.net/p/alphacocoa/tickets/231/>
Ticket #233: tab after \\label\{\}• in TeX mode <https://sourceforge.net/p/alphacocoa/tickets/233/>The following tickets have been closed:
Ticket #221: Search in Filesets is broken if regexp contains \\n <https://sourceforge.net/p/alphacocoa/tickets/221/>
Ticket #222: Menu item highlighting broken in macOS Catalina <https://sourceforge.net/p/alphacocoa/tickets/222/>
Ticket #223: accented chars in path names <https://sourceforge.net/p/alphacocoa/tickets/223/>
Ticket #224: Quicksearch can't find -west <https://sourceforge.net/p/alphacocoa/tickets/224/>

[Alphacocoa-devel] [alphacocoa:tickets] #231 Automatic Line Breaking global preference not honoured

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

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



---

** [tickets:#231] Automatic Line Breaking global preference not honoured**

**Status:** fixed
**Created:** Sat May 02, 2020 05:45 AM UTC by jwq
**Last Updated:** Tue May 26, 2020 09:17 AM UTC
**Owner:** nobody


Alpha does not honour the "Line Break" setting in the "Alpha Preferences : Text" dialog, which appears to be a global dialog. It's the dialog that prefs search finds when searching for "breaking" but it is also part of the global preferences dialog, under the text menu. Even if this is set to "No Line Breaking" new windows open in text mode with the default "Automatic Line Breaking".  Automatic Line Breaking has to be disabled in the Mode preferences "Alpha Preferences : "Text" Mode". This was difficult to find, in large part because prefs search does not show the Text Mode preference, only the global preference, for Line Break. This has caused me a fair bit of frustration over a long period of time - which is why I think this is a bug that needs to be fixed.


---

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

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

[Alphacocoa-devel] [alphacocoa:tickets] #233 tab after \label{}• in TeX mode

[L. P. <lau...@us...>]

<span style="font-family:verdana,geneva,sans-serif; font-size:14px">OK. Thanks for the clarification. In this case I do agree. This is very handy</span>

<div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : "Bernard Desgraupes"<br>
A : "[alphacocoa:tickets] " <23...@ti...><br>
Envoyé: mardi 26 Mai 2020 10:06<br>
Objet : [alphacocoa:tickets] #233 tab after \label{}• in TeX mode<br>
 
<div class="gl_quoted">

We are speaking here about the situation where templates introduce empty labels. For instance, if you insert a template for the align environment (select Maths Environments > align… and, say, choose 2 equations), here is what Alpha inserts in your document (the vertical bar here shows the location of the insertion cursor):



\begin{align}
    | & •
    \label{•}\\
    • & •
    \label{•}
\end{align}•



Now when you press the Tab key in order to fill the template, if you do not want a label it vanishes automatically. If you want one, just fill it out. This is very handy.



[tickets:#233] tab after \label{}• in TeX mode


Status: fixed
Created: Wed May 20, 2020 03:32 PM UTC by Laurent PRALY
Last Updated: Tue May 26, 2020 05:03 AM UTC
Owner: nobody


In TeXmode, if after typing
\label{}•
I move the cursor back to put it between { and }
and then I use the key TAB, then \label{}• is removed.
If follow the same steps with say ref, i.e.
\ref{}• , back between { and } and TAB, I jump to the next stop, i.e., I get
\ref{}
with the cursor after }


Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.


Question: is there a way to disable this feature.


Note that, on purpose, I am not using the binding (and proc) which creates \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•



Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/alphacocoa/tickets/233/


To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/




 



   
 



---

** [tickets:#233] tab after \label{}• in TeX mode**

**Status:** fixed
**Created:** Wed May 20, 2020 03:32 PM UTC by  Laurent PRALY
**Last Updated:** Tue May 26, 2020 08:06 AM UTC
**Owner:** nobody


In TeXmode, if after typing
\label{}•
I move the cursor back to put it between { and }
and then I use the key TAB, then \label{}• is removed.
If follow the same steps with say ref, i.e.
\ref{}• , back between { and } and  TAB, I jump to the next stop, i.e., I get
\ref{}
with the cursor after }

Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.

Question: is there a way to disable this feature.

Note that, on purpose, I am not using the binding (and proc) which creates  \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•


---

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] #231 Automatic Line Breaking global preference not honoured

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

Attached new dialog.


Attachments:

- [warn_shadowed_pref_dialog.png](https://sourceforge.net/p/alphacocoa/tickets/_discuss/thread/f046f651e6/7b33/attachment/warn_shadowed_pref_dialog.png) (66.1 kB; image/png)


---

** [tickets:#231] Automatic Line Breaking global preference not honoured**

**Status:** open
**Created:** Sat May 02, 2020 05:45 AM UTC by jwq
**Last Updated:** Tue May 26, 2020 09:13 AM UTC
**Owner:** nobody


Alpha does not honour the "Line Break" setting in the "Alpha Preferences : Text" dialog, which appears to be a global dialog. It's the dialog that prefs search finds when searching for "breaking" but it is also part of the global preferences dialog, under the text menu. Even if this is set to "No Line Breaking" new windows open in text mode with the default "Automatic Line Breaking".  Automatic Line Breaking has to be disabled in the Mode preferences "Alpha Preferences : "Text" Mode". This was difficult to find, in large part because prefs search does not show the Text Mode preference, only the global preference, for Line Break. This has caused me a fair bit of frustration over a long period of time - which is why I think this is a bug that needs to be fixed.


---

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

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

[Alphacocoa-devel] [alphacocoa:tickets] #231 Automatic Line Breaking global preference not honoured

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

As a matter of fact, this is already what happens. For example, the preference called *fillColumn* has an associated global variable called also *fillColumn* and Alpha takes care of updating the value of this variable when the mode changes. So, if you are in a mode that supports a *fillColumn* preference, the value of the *fillColumn* variable is the one defined by the mode (either the default value or a user-defined one). Otherwise the *fillColumn* variable contains the global setting (ditto, either the default value or a user-defined one).
I think this is a good design and its implementation is quite smart (modesty forbids, I'm not the author!).
I have now implemented a dialog which is presented to the user when she modifies the value of this kind of preferences (namely global preferences that may be shadowed by a mode-specific preference). I attach a snapshot of this dialog. 



---

** [tickets:#231] Automatic Line Breaking global preference not honoured**

**Status:** open
**Created:** Sat May 02, 2020 05:45 AM UTC by jwq
**Last Updated:** Sat May 23, 2020 01:48 AM UTC
**Owner:** nobody


Alpha does not honour the "Line Break" setting in the "Alpha Preferences : Text" dialog, which appears to be a global dialog. It's the dialog that prefs search finds when searching for "breaking" but it is also part of the global preferences dialog, under the text menu. Even if this is set to "No Line Breaking" new windows open in text mode with the default "Automatic Line Breaking".  Automatic Line Breaking has to be disabled in the Mode preferences "Alpha Preferences : "Text" Mode". This was difficult to find, in large part because prefs search does not show the Text Mode preference, only the global preference, for Line Break. This has caused me a fair bit of frustration over a long period of time - which is why I think this is a bug that needs to be fixed.


---

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

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

[Alphacocoa-devel] [alphacocoa:tickets] #233 tab after \label{}• in TeX mode

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

We are speaking here about the situation where templates introduce empty labels. For instance, if you insert a template for the *align* environment (select *Maths Environments > align…* and, say,  choose 2 equations), here is what Alpha inserts in your document (the vertical bar here shows the location of the insertion cursor):
```
\begin{align}
	| & •
	\label{•}\\
	• & •
	\label{•}
\end{align}•
```
Now when you press the Tab key in order to fill the template, if you do not want a label it vanishes automatically. If you want one, just fill it out. This is very handy.



---

** [tickets:#233] tab after \label{}• in TeX mode**

**Status:** fixed
**Created:** Wed May 20, 2020 03:32 PM UTC by  Laurent PRALY
**Last Updated:** Tue May 26, 2020 05:03 AM UTC
**Owner:** nobody


In TeXmode, if after typing
\label{}•
I move the cursor back to put it between { and }
and then I use the key TAB, then \label{}• is removed.
If follow the same steps with say ref, i.e.
\ref{}• , back between { and } and  TAB, I jump to the next stop, i.e., I get
\ref{}
with the cursor after }

Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.

Question: is there a way to disable this feature.

Note that, on purpose, I am not using the binding (and proc) which creates  \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•


---

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] #233 tab after \label{}• in TeX mode

[L. P. <lau...@us...>]

<span style="font-family:verdana,geneva,sans-serif; font-size:14px">But then why this behavior for \label{} only, why not also for \bibitem{}, \ref{}, \cite{}, ... ?<br>
<br>
My view point is:<br>
If you don't want a label you do not enter it, instead of entering it and then deleting it with a procedure nominally supposed to move the cursor to the next or previous bullet and in particular to exit the range of {}<br>
<br>
It is anyway a good thing that we can monitor the behavior. Thank you for this.<br>
<br>
Laurent Praly</span>

<div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : "Bernard Desgraupes"<br>
A : "[alphacocoa:tickets] " <23...@ti...><br>
Envoyé: mardi 26 Mai 2020 07:03<br>
Objet : [alphacocoa:tickets] #233 tab after \label{}• in TeX mode<br>
 
<div class="gl_quoted">

In fact, I agree with Vittorio that the deletion of empty \label{} macros is quite useful inside math environment templates: if you don't want the label, just press Tab instead of removing it manually.
So, there is now a new preference in LaTeX mode called Tab Deletes Empty Labels to control this behavior. For compatibility, it is activated by default. It can be unset in the Electrics panel of the Alpha ↣ TeX Mode Setup ↣ Mode Preferences dialog.



[tickets:#233] tab after \label{}• in TeX mode


Status: fixed
Created: Wed May 20, 2020 03:32 PM UTC by Laurent PRALY
Last Updated: Fri May 22, 2020 10:39 AM UTC
Owner: nobody


In TeXmode, if after typing
\label{}•
I move the cursor back to put it between { and }
and then I use the key TAB, then \label{}• is removed.
If follow the same steps with say ref, i.e.
\ref{}• , back between { and } and TAB, I jump to the next stop, i.e., I get
\ref{}
with the cursor after }


Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.


Question: is there a way to disable this feature.


Note that, on purpose, I am not using the binding (and proc) which creates \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•



Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/alphacocoa/tickets/233/


To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/




 



   
 



---

** [tickets:#233] tab after \label{}• in TeX mode**

**Status:** fixed
**Created:** Wed May 20, 2020 03:32 PM UTC by  Laurent PRALY
**Last Updated:** Tue May 26, 2020 05:03 AM UTC
**Owner:** nobody


In TeXmode, if after typing
\label{}•
I move the cursor back to put it between { and }
and then I use the key TAB, then \label{}• is removed.
If follow the same steps with say ref, i.e.
\ref{}• , back between { and } and  TAB, I jump to the next stop, i.e., I get
\ref{}
with the cursor after }

Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.

Question: is there a way to disable this feature.

Note that, on purpose, I am not using the binding (and proc) which creates  \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•


---

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] #233 tab after \label{}• in TeX mode

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

In fact, I agree with Vittorio that the deletion of empty `\label{}` macros is quite useful inside math environment templates: if you don't want the label, just press Tab instead of removing it manually.
So, there is now a new preference in LaTeX mode called *Tab Deletes Empty Labels* to control this behavior. For compatibility, it is activated by default. It can be unset in the *Electrics* panel of the *Alpha ↣ TeX Mode Setup ↣ Mode Preferences* dialog.


---

** [tickets:#233] tab after \label{}• in TeX mode**

**Status:** fixed
**Created:** Wed May 20, 2020 03:32 PM UTC by  Laurent PRALY
**Last Updated:** Fri May 22, 2020 10:39 AM UTC
**Owner:** nobody


In TeXmode, if after typing
\label{}•
I move the cursor back to put it between { and }
and then I use the key TAB, then \label{}• is removed.
If follow the same steps with say ref, i.e.
\ref{}• , back between { and } and  TAB, I jump to the next stop, i.e., I get
\ref{}
with the cursor after }

Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.

Question: is there a way to disable this feature.

Note that, on purpose, I am not using the binding (and proc) which creates  \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•


---

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] Alpha drag & drop

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

A quick update - I started seeing the behavior on one instance of Alpha this morning, so I experimented with a number of things to characterize its 
behavior.  What I found was that while in a freshly launched copy of the app, drag and drop behaved as expected, it's actually still working after the 
app has been open for 24 hours - but it now takes second and a half or so of holding the mouse button down before the arrow cursor appears and the 
text can be dragged.  Attempting to move the cursor within a second results in the selection being changed rather than dragging it.  It's possible 
that this was the case before, but I wasn't waiting long enough - I'm very used to Alpha being responsive during text edits and this is quite a bit 
longer than seems usual.  It's certainly longer than it was yesterday.

I have launched and quit numerous apps during the last day, but nothing appeared to happen to Alpha's behavior at the time of each action.

For comparison, I looked at my copies of LibreOffice and Pages, which change modes within a fraction of a second.  LibreOffice does not change the 
cursor till you start to drag, while Pages changes it before you move the cursor; but I'm not sure LibreOffice uses Cocoa text.  So for my next test 
I'm going to leave Pages open for a while and check its behavior frequently.  It's possible that something is globally affecting Cocoa text behavior 
when a document is left open for an extended period.  If it continues to affect only Alpha, I'll try deleting prefs and run the test again.

> Message: 3
> Date: Fri, 22 May 2020 07:20:43 -0400
> From: Greg Dunn <gre...@in...>
> To: Bernard Desgraupes <bde...@or...>
> Cc: alp...@li...
> Subject: Re: [Alphacocoa-devel] Drag and drop - Alpha 9.1.1
> Message-ID: <fe6...@in...>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> As always, your work on Alpha is appreciated!  I will keep in mind that D&D is not fully under Alpha's control as I continue to look for clues.  I
> have instances running on 3 machines at this time and hope to find a link to the misbehavior somewhere.  So far, I've been checking after
> launching/quitting each of my regular applications that Alpha has or has not changed its behavior.  Hopefully I can isolate and - better yet -
> reproduce this quirk in a manner that allows it to be identified and squashed.  Even if it's just by changing something on my machine!
> 
> On 5/22/20 5:53 AM, Bernard Desgraupes wrote:
>> Hi Greg,
>>
>> thank you for this additional input. Drag and Drop is not implemented by Alpha itself but is provided for free by the Cocoa Text view. It?s hard to guess what they are doing under the hood. But clearly there is a wrong interaction at some point. Indeed if something is consistently reproducible, it will give us a clue.
>>
>> Cheers,
>> Bernard
>>
>>> Le 21 mai 2020 ? 20:11, Greg Dunn <gre...@in...> a ?crit :
>>>
>>> Just a follow-up - not expecting any action on it, but I wanted to report that this drag and drop failure seems to be very repeatable after Alpha has been running for a number of consecutive days.  Restarting Alpha seems to fix it every time.  A sign of the issue is that the cursor remains an I-beam instead of changing to the arrow, after the mouse button has been depressed and held.  I have not been able to find a workaround other than restarting the application.  My second machine has a new instance of Alpha which was restarted at the same time, as a control.  We'll see if it exhibits this behavior, and when.
>>>
>>> Interestingly, and even on a fresh restart of Alpha, I will frequently get a file where the cursor remains as an arrow and cannot be changed to the I-beam even after clicking multiple locations in the text.  Double-clicking a word or dragging to highlight it and then clicking in the word restores the I-beam cursor; clicking outside the selected word or text grouping does not restore the I-beam.  Drag and drop works properly both before and after the cursor changes shape.  Notably, switching to another app and then back to Alpha causes the misbehavior to return - this is repeatable. Since the block of text becomes (or should be) draggable after selecting and a cursor change is involved in both cases, I have a suspicion that there is some kind of correlation here; I have not seen both behaviors at the same time.  If I find other seemingly related issues I will try to document them.
>>>
>>> I need to track these items daily under consistent conditions to see if anything occurs (like perhaps the launch of another application) which causes the failure to follow.  The last time I did this, it worked for a considerable time and then I forgot to check daily - when of course it began to act up.  Sigh.  Closing all windows and creating new ones doesn't fix the issue, so it appears to be something in Alpha's application memory region and not in the file's buffer.  I will be a little more thorough and try to pin it down more closely this time.
> 
> 


-- 
| Greg Dunn                       | Trust yourself; trust Ivanova.   |
| gre...@in...               | Anybody else... shoot 'em.       |
| The Sultan of Slack(tm)         |                 Susan Ivanova    |
| http://www.indy.net/~gregdunn/  |                                  |

[Alphacocoa-devel] [alphacocoa:tickets] #231 Automatic Line Breaking global preference not honoured

[jwq <jw...@us...>]

Bernard, thanks for the reply. I'd like to acknowledge that, as discussed a while ago, modifying the preferences behaviour for all the modes is going to take a *lot* of work. Some suggestion for potential solutions.

Probably the simplest solution is to remove all global preferences which have corresponding mode preferences and rely only on the mode preferences. It's the brute force approach to resolving the problem: preferences are either global or mode. Some modes which rely on global values which are being removed may need mode preferences created. This is going to be a lot of work, but probably less work than the elegant solution.

The elegant solution is to write a code which allows mode preferences to reference/inherit from the global setting: an additional mode preference setting value "Global Default" which is de-referenced in code as the global preference value. That's going to mean replacing every use of a mode preference *variable* with a mode preference *function* which returns either the global or the local preference value *and* extensive changes to the GUI.

I believe we all agreed the last time that this was discussed that pushing the global value to the mode values is going to be error-prone and the same amount of work.



---

** [tickets:#231] Automatic Line Breaking global preference not honoured**

**Status:** open
**Created:** Sat May 02, 2020 05:45 AM UTC by jwq
**Last Updated:** Fri May 22, 2020 12:29 PM UTC
**Owner:** nobody


Alpha does not honour the "Line Break" setting in the "Alpha Preferences : Text" dialog, which appears to be a global dialog. It's the dialog that prefs search finds when searching for "breaking" but it is also part of the global preferences dialog, under the text menu. Even if this is set to "No Line Breaking" new windows open in text mode with the default "Automatic Line Breaking".  Automatic Line Breaking has to be disabled in the Mode preferences "Alpha Preferences : "Text" Mode". This was difficult to find, in large part because prefs search does not show the Text Mode preference, only the global preference, for Line Break. This has caused me a fair bit of frustration over a long period of time - which is why I think this is a bug that needs to be fixed.


---

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

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

[Alphacocoa-devel] [alphacocoa:tickets] Re: #233 tab after \label{}• in TeX mode

[Vittorio <vit...@us...>]

let me say that there is some rational in the behavior: \label{}• is removed only if the label si empty. Since an empty label does not make any sense, deleting the label command is reasonable.
But it is fine with me if the behavior is changed.

best regards

Vittorio


> Il giorno 22 mag 2020, alle ore 12:53, Laurent PRALY via AlphaCocoa-devel <alp...@li...> ha scritto:
> 
> Cher Bernard
> 
> 
> 
> A nouveau un grand merci pour votre aide pour cet autre problème. Au moins cette fois, ce n'est pas ma configuration qui est en cause.
> 
> 
> 
> Par contre je vois que cette proc TeX::nextStop est déjà sous cette forme
> 
> FILE: "latexEnvironments.tcl"
> 
>                                           created: 11/10/1992 {10:42:08 AM}
> 
>                                       last update: 2011-10-24 21:19:50
> 
> Il est donc étrange que le problème que je mentionne n'ait pas déjà été signalé depuis 2011. Ces 4 lignes ont donc peut-être leur raison d'être pour une toute autre cause. Donc comme vous érivez
> 
> Unless I hear objections
> 
> 
> 
> Bien cordialement
> 
> Laurent Praly
> 
> De : "Bernard Desgraupes"
> 
> A : "[alphacocoa:tickets] " <23...@ti...>
> 
> Envoyé: vendredi 22 Mai 2020 12:05
> 
> Objet : [alphacocoa:tickets] #233 tab after \label{}• in TeX mode
> 
>  
> 
> 
> Hi Laurent,
> 
> thank you for reporting this oddity. It is indeed quite surprising and I don't see the rationale here. The same happens if you have something like
> 
> \label{eq:}•
> 
> and similarly with a few other hardcoded prefixes.
> 
> The culprit in found in proc TeX::nextStop (in file latexEnvironments.tcl). To get ridd of this behaviour, you should comment out lines 1285-1288.
> 
> Unless I hear objections, I'll remove all this part of the code.
> 
> 
> 
> 
>  <https://sourceforge.net/p/alphacocoa/tickets/233/>[tickets:#233] <https://sourceforge.net/p/alphacocoa/tickets/233/> tab after \label{}• in TeX mode
> 
> 
> Status: open
> Created: Wed May 20, 2020 03:32 PM UTC by Laurent PRALY
> Last Updated: Wed May 20, 2020 03:32 PM UTC
> Owner: nobody
> 
> In TeXmode, if after typing
> \label{}•
> I move the cursor back to put it between { and }
> and then I use the key TAB, then \label{}• is removed.
> If follow the same steps with say ref, i.e.
> \ref{}• , back between { and } and TAB, I jump to the next stop, i.e., I get
> \ref{}
> with the cursor after }
> 
> Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.
> 
> Question: is there a way to disable this feature.
> 
> Note that, on purpose, I am not using the binding (and proc) which creates \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•
> 
> 
> 
> Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/alphacocoa/tickets/233/ <https://sourceforge.net/p/alphacocoa/tickets/233/>
> 
> To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ <https://sourceforge.net/auth/subscriptions/>
>  
> 
> 
> 
> <link href="https://sourceforge.net/p/alphacocoa/tickets/233/" itemprop="url"> <meta content="View" itemprop="name"> <meta content="View" itemprop="description">
>  
> 
> [tickets:#233] <https://sourceforge.net/p/alphacocoa/tickets/233/> tab after \label{}• in TeX mode
> 
> Status: fixed
> Created: Wed May 20, 2020 03:32 PM UTC by Laurent PRALY
> Last Updated: Fri May 22, 2020 10:39 AM UTC
> Owner: nobody
> 
> In TeXmode, if after typing
> \label{}•
> I move the cursor back to put it between { and }
> and then I use the key TAB, then \label{}• is removed.
> If follow the same steps with say ref, i.e.
> \ref{}• , back between { and } and TAB, I jump to the next stop, i.e., I get
> \ref{}
> with the cursor after }
> 
> Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.
> 
> Question: is there a way to disable this feature.
> 
> Note that, on purpose, I am not using the binding (and proc) which creates \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•
> 
> Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ <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. <https://sourceforge.net/p/alphacocoa/admin/tickets/options.> Or, if this is a mailing list, you can unsubscribe from the mailing list.
> 
> _______________________________________________
> AlphaCocoa-devel mailing list
> Alp...@li...
> https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel




---

** [tickets:#233] tab after \label{}• in TeX mode**

**Status:** fixed
**Created:** Wed May 20, 2020 03:32 PM UTC by  Laurent PRALY
**Last Updated:** Fri May 22, 2020 10:39 AM UTC
**Owner:** nobody


In TeXmode, if after typing
\label{}•
I move the cursor back to put it between { and }
and then I use the key TAB, then \label{}• is removed.
If follow the same steps with say ref, i.e.
\ref{}• , back between { and } and  TAB, I jump to the next stop, i.e., I get
\ref{}
with the cursor after }

Actually this strange behavior seems to occur only with \label. I understand that a "label" should be entered between { and }. But I want to be free to do it rigth away or later.

Question: is there a way to disable this feature.

Note that, on purpose, I am not using the binding (and proc) which creates  \label{}• . In doing so, I want to argue that the problem is not with this proc, but seems to be in the proc elec::nextStopOrIndent given by Tab. But why is the behavior different between \label{}• and \ref{}•


---

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] #231 Automatic Line Breaking global preference not honoured

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

I agree that this mechanism cries for improvement. I'll try to find a solution. There should be some sort of cascading for a parameter at the global level to be reproduced at the mode level unless the user has already customized the value in a particular mode.



---

** [tickets:#231] Automatic Line Breaking global preference not honoured**

**Status:** open
**Created:** Sat May 02, 2020 05:45 AM UTC by jwq
**Last Updated:** Sat May 02, 2020 05:46 AM UTC
**Owner:** nobody


Alpha does not honour the "Line Break" setting in the "Alpha Preferences : Text" dialog, which appears to be a global dialog. It's the dialog that prefs search finds when searching for "breaking" but it is also part of the global preferences dialog, under the text menu. Even if this is set to "No Line Breaking" new windows open in text mode with the default "Automatic Line Breaking".  Automatic Line Breaking has to be disabled in the Mode preferences "Alpha Preferences : "Text" Mode". This was difficult to find, in large part because prefs search does not show the Text Mode preference, only the global preference, for Line Break. This has caused me a fair bit of frustration over a long period of time - which is why I think this is a bug that needs to be fixed.


---

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

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

Re: [Alphacocoa-devel] Drag and drop - Alpha 9.1.1

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

As always, your work on Alpha is appreciated!  I will keep in mind that D&D is not fully under Alpha's control as I continue to look for clues.  I 
have instances running on 3 machines at this time and hope to find a link to the misbehavior somewhere.  So far, I've been checking after 
launching/quitting each of my regular applications that Alpha has or has not changed its behavior.  Hopefully I can isolate and - better yet - 
reproduce this quirk in a manner that allows it to be identified and squashed.  Even if it's just by changing something on my machine!

On 5/22/20 5:53 AM, Bernard Desgraupes wrote:
> Hi Greg,
> 
> thank you for this additional input. Drag and Drop is not implemented by Alpha itself but is provided for free by the Cocoa Text view. It’s hard to guess what they are doing under the hood. But clearly there is a wrong interaction at some point. Indeed if something is consistently reproducible, it will give us a clue.
> 
> Cheers,
> Bernard
> 
>> Le 21 mai 2020 à 20:11, Greg Dunn <gre...@in...> a écrit :
>>
>> Just a follow-up - not expecting any action on it, but I wanted to report that this drag and drop failure seems to be very repeatable after Alpha has been running for a number of consecutive days.  Restarting Alpha seems to fix it every time.  A sign of the issue is that the cursor remains an I-beam instead of changing to the arrow, after the mouse button has been depressed and held.  I have not been able to find a workaround other than restarting the application.  My second machine has a new instance of Alpha which was restarted at the same time, as a control.  We'll see if it exhibits this behavior, and when.
>>
>> Interestingly, and even on a fresh restart of Alpha, I will frequently get a file where the cursor remains as an arrow and cannot be changed to the I-beam even after clicking multiple locations in the text.  Double-clicking a word or dragging to highlight it and then clicking in the word restores the I-beam cursor; clicking outside the selected word or text grouping does not restore the I-beam.  Drag and drop works properly both before and after the cursor changes shape.  Notably, switching to another app and then back to Alpha causes the misbehavior to return - this is repeatable. Since the block of text becomes (or should be) draggable after selecting and a cursor change is involved in both cases, I have a suspicion that there is some kind of correlation here; I have not seen both behaviors at the same time.  If I find other seemingly related issues I will try to document them.
>>
>> I need to track these items daily under consistent conditions to see if anything occurs (like perhaps the launch of another application) which causes the failure to follow.  The last time I did this, it worked for a considerable time and then I forgot to check daily - when of course it began to act up.  Sigh.  Closing all windows and creating new ones doesn't fix the issue, so it appears to be something in Alpha's application memory region and not in the file's buffer.  I will be a little more thorough and try to pin it down more closely this time.


-- 
| Greg Dunn                       | this is slowly taking me apart.  |
| gre...@in...               | grey would be the color if i     |
| The Sultan of Slack(tm)         | had a heart.                     |
| http://www.indy.net/~gregdunn/  |                Trent Reznor      |