Textadept 12.2 beta

[orbitalquark]

Textadept 12.2 beta is released from https://github.com/orbitalquark/textadept/releases/tag/textadept_12.2_beta

The Qt version is now a single-instance application, just like the Gtk version.

Bugfixes:

• Fixed crash during logout/restart on Windows while Textadept is still running.
• Prevent key bindings in the macOS menu from overriding user-specified bindings.
• Fixed interpretation of '-' command line argument as reading from stdin.
• Prevent duplicate key events from Scintilla.
• Only show message box icons in the Gtk version if they exist.
• Fixed display of window and dialog icons in Gtk.
• Correctly highlight built-in Bash variables surrounded by "${...}".

Changes:

• Implemented single-instance functionality on Windows (and Linux with Qt).
• Dropped legacy 11.x compatibility shims.
• Added Brazilian Portuguese localization.
• Updated Hare, fstab, and Matlab lexers.
• Updated Markdown lexer to detect code blocks delimited by ~~~.
• Updated Bash lexer to disable conditional and arithmetic operator highlighting due to performance.
• Updated to Scintilla 5.3.7.

[amitbha]

12.2 beta has problem when open any file:

[string "view["rectangular_selection_modifier"]=4..."]:56: bad argument #2 to 'newindex' (number expected, got nil)
[string "view["rectangular_selection_modifier"]=4..."]:56: bad argument #2 to 'newindex' (number expected, got nil)
/opt/textadept/init.lua:67: attempt to call a nil value (method 'set_theme')

[amitbha]

Thanks for your reply. @orbitalquark
The config file /opt/textadept/init.lua is from release build. I comment out the line 67, it's ok now.
According to migrating-from-textadept-11-to-12, I checked my ~/.textadept/init.lua, migrated 'textadept.file_types' to lexer.detect_extensions. All works fine now.

[orbitalquark]

12.2 beta drops legacy 11.x compatibility shims. Do you have anything in your ~/.textadept/init.lua or custom modules that has not yet been migrated? You can easily test this by running something like textadept --force --userhome /tmp and then trying to open a file. If it works then there's something up with your custom stuff. I'm not seeing this issue on my Linux box with the release archive.

[ousia]

Sorry, @orbitalquark, but what has to be migrated in init.lua from version 11.x compatibility shims?

Does the documentation contain anywhere a list of the legacy code that has been dropped?

Excuse my inaccurate description, but all I get from Dropped legacy 11.x compatibility shims. is “what worked init.lua for TA 11 may or may not work not for TA 12.2”.

Many thanks for your help.

[orbitalquark]

https://orbitalquark.github.io/textadept/manual.html#migrating-from-textadept-11-to-12

The changelog for 12.0 contains that link.

[ousia]

Many thanks for your fast reply, @orbitalquark.

[amitbha]

I found an unexpected replacement in below condition:

  ab
    ab

Using regx ^[ ][ ] to delete the beginning two spaces of lines, but the result is:

ab
ab

Expected:

ab
  ab

[orbitalquark]

Fixed via 1ee44ff

[georgeraraujo]

Is it really a bug? I tested that regexp and that text on Notepad++ and SciTE, and the behavior was the same - 2 matches, and 3 replacements instead of 2.

[orbitalquark]

I think it is. If there are only 2 matches, replace all should replace just those matches, not more.

[georgeraraujo]

I see your point.

I view it like this: in the original text, there are 2 matches. We replace the first, and there is one match left. We replace the second, and then we have replaced the 2 original matches -- and in doing so, we produce another match in the resulting text. Should we only apply the substitution to the original text, or keep replacing until there are no more matches left in the resulting text?

Just my two cents.

[orbitalquark]

I would say apply the substitution to the original text. The user should not have to compute how/if replacements will end up generating subsequent matches. amitbha's original use case is perfectly valid in my opinion and I also though Textadept's behavior was buggy.

[amitbha]

Try ^( )(.*)$ and replace with \2.

Thanks. I solved it with vscode,

Thanks for the report. That does seem like a bug. If you have find highlighting turned on, Textadept will correctly report and highlight those 2 instances. However, when you do "replace all", it replaces 3.

Yes. the highlights are correct.

[snoopy]

What is the reason for dropping api_files support? I'm guessing because you want to move more towards the LSP side of things?
I'm not a huge fan of LSP yet and api_files provided a simple solution to add some language specific functionality like autocompletion.

[orbitalquark]

That's correct. At the time, I was generating API files by hand/script for supported language modules, and most of them were out of date. Migrating towards LSP allowed me to drop support for those language modules, and since nothing was utilizing api_files, I dropped that too. Less maintenance for me is a plus. Despite that, sometimes I do wish it was there.

[rgieseke]

Could probably be extracted and kept as an external module if someone volunteers? ;-)