Currenlty SubEthaEdit just opens up compiler and linter errors in temporary text windows. It would be great to have this output in a more orderly fashion integrated, parsed and used so one would have infrastructure for recognizing and using the line and character information of those outputs, as well have it more orderly added to the files that caused them. Might be related to #1 to have a good project wide place.

The term Throwback is borrowed from StrongEd on RiscOS, as an homage to the spiritual predecessor of SubEthaEdit. It displayed such results in a ThrowBack window that was more or less behaving like a find results window.

This bug is coming from #29, but that original idea there was simply to restyle the existing tabs to match "Safari's". This has since (potentially) grown into the larger project of replacing SubEthaEdit's custom tabbing facilities with AppKit's new built-in solution. As I'll explain further down, this has more implications than I originally thought, so I wanted to sync up and make sure this is something we actually want before going forward. For starters, I want to make sure that the goals I have in my head match up with those of everyone else, especially SubEtha's owners:

1. Modernize and ideally use the platform look-and-feel.

   This is the simplest (and IMO most important) goal, and is achievable by more means than using AppKit's native tabbing. We could simply restyle PSMTabBarControl for example.

2. Create a sustainable way of maintaining platform look-and-feel.

   The argument for using native tabs here is that now that macOS has its own tabbing mechanism, it is likely to subtly change on each major release, and thus create unbounded maintenance work to constantly keep SubEtha's style inline with those. This would be one of the stronger arguments in favor of using native tabs.

3. Support subtle current and future tabbing behaviors.

   Similar to the above, we don't want to have to play the "replicate" framework game of supporting every key-command and built-in behavior in a world where we choose to skin the tabs and give the user the expectation that they will work the same (such as macOS's "show all tabs" view).

4. Simplifying the code base

   IMO the least important reason to do this, but worth mentioning, that if it is possible to use less custom concepts and thus make the codebase more accessible to people that "just know AppKit", it can have inherent additional value.

That being said, I took the time yesterday to read up on macOS's tabs, and they are unfortunately 1) very poorly documented, and 2) IMO not ...ideally designed. For starters, the only place I actually found any substantial information was in this WWDC video (which has an attached transcript). There is nothing on the level of the old "document model architecture" docs or anything like that. If I am mistaken and simply missed this, please let me know!

Now on to the design. Apparently Apple's main goal here was to make tabs "magically just work" on unaltered macOS apps. So the feature goes to great lengths to not provide any additional modeling, and instead is a "grand illusion". Tabs do not share a window like in every other implementation I've seen. Instead, windows are considered to be in a group by the windowing system and the windowing system then only shows one of them at a time. To make a different tab the selected tab, you merely order that window front of the others in the group.

While this is certainly a neat trick, it, as far as I can tell, leaves very little room for future flexibility. For example, I predict it will be difficult to have a sensible project window architecture (unless we play along with this game and make every window in a project have its own sidebar of files, etc). I have no idea of the performance implications of going from a shared-views model of tabbing to a "duplicate everything" model as is implied here.

Basically, if the tabbing is highly simplistic, the AppKit model seems "painless", but potentially leaves you on your own after that. I personally am not particularly interested in project-management features (that's one of the reasons I like SubEthaEdit), but I am aware that others do strongly want them, so I feel it's important to flag this now.

Network.framework encapsulates a lot of great new advances in networking SubEthaEdit could benefit from.

This is an umbrella bug tracking its adoption.

Short Description

Code folding bar overlay over text repeatedly

Steps to Reproduce the Issue

1. Open BASH file (UTF-8/LF) - my example is 1000 lines, 3 spaces indentation, approx 5 indentation in file max.
2. Show Code folding & line numbers bar
3. Scroll up & down repeatedly

Expected Result

Text have to be visible from begginig of lines

Actual Result

Code folding bar overlay over first 5 or 6 characters after up/down scrolling action

Environment

• SubEthaEdit: Version 5.0 (6949)
• System: Version 10.14.2 (Build 18C54)
• Language: English

Hardware:

    Hardware Overview:

      Model Name: iMac
      Model Identifier: iMac17,1
      Processor Name: Intel Core i5
      Processor Speed: 3,2 GHz
      Number of Processors: 1
      Total Number of Cores: 4
      L2 Cache (per Core): 256 KB
      L3 Cache: 6 MB
      Memory: 16 GB
      Boot ROM Version: 161.0.0.0.0
      SMC Version (system): 2.33f10
      Serial Number (system): DGKRG05CGG7V
      Hardware UUID: 17421B1D-980D-5BA2-9560-74EA62462E44

When I copy & paste the command listed in the Advanced settings to install see, I get the following error:

$ sudo /Applications/SubEthaEdit.app/Contents/SharedSupport/bin/install.command
Password:
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- FileUtils (LoadError)
	from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
	from /Applications/SubEthaEdit.app/Contents/SharedSupport/bin/install.command:2:in `<main>'

I sort of feel like this should work out of the box...

With the native tab support of Cocoa it might be worth considering using that instead of the custom PSMTabBarControl solution. However, #1 - Project Context, might still want a custom solution.

SubEthaEdit ships with 4 Style sheets. It would be great to incorporate more of the popular color choices to provide out of the box.

This is an ongoing umbrella issue, please provide issues referencing this for each style you'd like to contribute to the main distribution.

HI
Is it possble to compile SubEthaEdit for lower version macOSX for example 10.9 or 10.10?
Thanx.

Not all source files have been moved to automatic reference counting. There is no reason for that other than that it hasn't been done yet. This is an umbrella issue tracking this.

If you move files to ARC not just as a side effect of another fix, please use an issue related to this to do so.

SubEthaEdit thrives on the dedication put into specific modes so the representation of that Language/Structured text is as useful, consistent and helpful as it can be.

This Issue serves as an Umbrella but to track the ongoing effort to make them as good as they can get:

• Update Modes to the latest specs of the language
• Improve Recognition of Syntax and Symbols
• Add new modes for more languages

Please file an issue for specific changes you want to make and mention this issue in them.

When I open a file directly from Fetch into SubEthaEdit the file will open and I can edit it. But when I save the changes they do not get send back to the original file on the FTP server. This used to work just fine with previous versions of SubEthaEdit (I just upgraded from the 32 bit version to version 5.0)

So on the face of it this seems like it should be a pretty trivial manual addition, just keying of the code-fence's tag and using that syntax mode for the body. However, while I plan on making a quick commit of this in the immediate, it would be nice to have something more automatic.

As an initial step, we could have a build script that just auto-generates these nested modes for every language and inserts them into the markdown mode, although this still won't support user's custom modes. This would also require other modes to specify their desired code-fence keys (for example, javascript supports probably "javascript", "js", "jsx", and "node").

Ideally there'd be an expressive way of iterating over all other modes at runtime such that markdown magically has knowledge of every other mode.

1. Part of umbrella bug: #7
2. Possibly relevant to #5 , although it would be nice to have something in there before a bigger change.

SubEthaEdit should provide a good online help.

Since there is none at the moment, a good starting point would be to setup infrastructure and concept to have one that can be easily maintained, translated and integrated by contributors.

https://developer.apple.com/library/archive/documentation/Carbon/Conceptual/ProvidingUserAssitAppleHelp/user_help_concepts/apple_help_concepts.html

When doing a debug build, we do have a style sheet editor for the SubEthaEdit .sss style sheets. That could and should be lifted to be in the app again.

It would be nice to be able to install SubEthaEdit using homebrew from the commandline.

Currently many text transformation features (e.g. pretty print XML, tidy and pretty print XHTML) are hard coded into SubEthaEdit.

Think about a good structure to provide more of these and make them also accessible through scripting and be enhanced in modes more directly than just the current AppleScript solution.

E.g. SubEthaEdit should have more great support for linting and pretty printing all sorts of source texts.

Part of #7.

It would be nice to be able to use vim mode for text editing

If you take a look at the editor built into Xcode, it has a really nice feature, distinct settings for indent-width and tab-width (check it out in the preferences, under Text Editing and then Indentation).

• Indent width is how much you indent when you press the TAB button on the keyboard.
• TAB width is how a tab-character (ASCII code 9) in a file should be interpreted.

These two concepts are orthogonal. Xcode and Emacs understand this. In SubEthaEdit (and many other “modern” GUI-based editors), they are conflated.

For many old-school Unix folks, in a file, a tab character always means 8-space based alignment. However, in our files, we might want different indents, and use spaces to do so (or a mix of spaces and tabs).

It would be fantastic if we adopted an approach similar to Xcode on this.

The current copy as XHTML feature emits very, let's call it baroque, html. However, having a great export of code snippets highlighted in the colors and style of SubEthaEdit for blog posts or other media that takes in HTML would be great. Also to have some nice export options to include line numbers, styling etc. There are offerings out there that do this great, so it probably would be best to gather the desired functionality here in this issue first.

E.g. we could have a good semantic mapping from the scope strings to existing CSS style sheets from other source highlighters on the web. Have the option of line numbers in various ways, maybe folding etc.

Currently the live WebPreview makes not much sense for non-HTML content. However, if we would provide a way to specify a preprocessor in the mode to convert the source live to HTML, we could make that meaningful for many languages/modes:

• Show Markdown output for markdown
• Show XML with an XSLT the way it makes sense
• Find other display forms for other languages (e.g. one could visualize the AST for programming languages hand have a nice visual representation)

They should not as documented.

https://github.com/subethaedit/SubEthaEdit-Modes/blob/master/Documentation/ExampleMode/Documentation/RegexSymbols_xml.md

Part of #7

Please add .editorconfig support to automatically set the most important editor preferences on a project by project basis.

https://editorconfig.org/

I still think BEEP is a tremendous protocol. It might be worth factoring that out and layering it nicely for others to use.

When I save a document no backup file (i. e. file with content from before last save but with extension '.bak' instead of original extension) is created.

It seems that the ability to overwrite text in a text editor is as rare as purple unicorns. After a quick survey of Mac editors (BBedit, Text Wrangler, Word, Pages, Xcode, etc) none of them seem to have this ability. I have an emacs editor that does, but I hate emacs. I also had a vim editor (which I love[d]), but it's been flakey for the last few years, and I've given up on it.

I could hop into a terminal and just use vi, but I would prefer the conveniences of sticking with a more visual editor.

Anyway, I hope you consider adding this seemingly simple, yet nigh impossible to find, feature.

Semantically already present in the style sheets, SubEthaEdit currently does not highlight the current line yet. This should be remedied.

In the regex help text document, I find groups. However, I do not see how to use the value of the captured group in the Replace box.

For instance in my document, I have 22 results when searching for:

"unit": "(?[\S ]+)"

But can't seem to get the captured group named 'uname' in the replace method.

-e

One big missing Feature of SubEthaEdit is the lack of a project context. This is an Umbrella bug for making this happen.

What I have in mind is a lightweight directory display that should be rooted in the SCM (usually git nowadays) directory up from the current file. Ideally we don't litter the file system with yet another .file but either intelligently infer this, or react to opening folders this way.

The Project context should be in line with SubEthaEdit in general, that means that it should be its own window that can be docked. It could serve as the basis for great functionality:

• powerful project wide search and replace
• constrain autocomplete for files in the same context
• simple access and recognition of build and linting scripts for the project opened
• project wide navigation (e.g. opening up of imported files, etc)
• SCM integration

steps:

open the attached file
double click on simple in the first file
press escape twice

results:

There are changes in the undo buffer that should not be there. e.g. cmd-z does modify the document

expected results:

undo buffer should be in sane state. cmd-z should either do nothing or at least result in an unmodified file eventually

minbug.txt

As is there is no good documentation around the protocol SubEthaEdit is currently running. It would be good to start an extensive documentation to keep that stable and enhance it in the future.

Currently only Coda and SubEthaEdit itself speak that protocol, but we could make it more interoperable with others. But both documentation and a good conformance suite would be vital for that to succeed.

While a free and open source SubEthaEdit now really removes the entry barrier to do live ad hoc collaboration with your peers, it would be great if SubEthaEdit could also sever a web app on demand so anybody could join and follow a document without having to have a mac.

E.g. think EtherPad served from the SubEthaEdit app on demand so you truly collaborate with anyone at any time. Current web technologies have advanced enough that this is a very viable option to have a great web app running and talking to SubEthaEdit.

Currently "await", "yield", and "export" don't highlight.

The Language Server Protocol has great potential for general purpose text editors. We should try to add support for it!

One of the most useful features of TextMate is the ability to directly edit files on servers you are accessing via ssh. To do this, it supports the rmate protocol.

This feature would be awesome to support in SEE!

Here is the best list of rmate implementations I could find: https://marketplace.visualstudio.com/items?itemName=rafaelmaiolla.remote-vscode

The oniguruma Regex engine still is quite powerful and worth incorporating. However, OgreKit as is has been discontinued, so it might be worth looking into factoring out the framework again and make it available to others.

When using google to find a C# mode for SubEthaEdit (search term "subethaedit c#"), the first suggestion for me is https://www.codingmonkeys.de/subethaedit/old/modes.html.
It wasn't obvious for me at first, that this was an obsolete site with links to obsolete modes that do no longer work with a current version of SubEthaEdit.
I'd like to suggest the "old" website to be removed to avoid confusion for others.

While the code is old, and the implementation details bleed through, the overall idea of having live collaboration based on transactions as a general framework is still appealing. Originally that is what the TCMMillionMonkeys directory wanted to become, but we never got around to it. But if done it could be a great opportunity to provide a collaboration framework with a well defined network standard to incorporate into other tools/apps.

It would be useful to add functionality via plugins.

error: SeeTextImporter has conflicting provisioning settings. SeeTextImporter is automatically signed, but code signing identity Developer ID Application: xxx has been manually specified.

Suggest adding CODE_SIGN_STYLE = Manual to Identity.xcconfig.

Please add a comment if this also affects you.

So I am currently using the latest version of SubEthaEdit (5.0 6949) alongside 3.5.4 (which has been my sole editor since it came out basically). I am experiencing significant performance discrepancy while typing in 5.0 vs. 3.5.4. Namely, SubEthaEdit will spin/lock intermittently, and just doing a quick "throw" scroll seems to drop frames and be "janky" as well. The file size are pretty small, about (150 lines or so).I haven't yet gotten the style on both to be identical (I've removed all the bold styles from the theme I'm using, and will be removing all the italics later today in an effort to see if its possibly something related to variable line heights?). But more than anything I wanted to make an umbrella bug to track this and confirm others are seeing it too. If so, happy to start profiling and trying to narrow it down, but wondering if there's some good places to start looking (was there a new syntax highlighting engine introduced in 4, different text rendering engine, etc.)

Add a chat panel for the current editors of a documents. Perhaps integrate slack somehow so I don't have to switch back and forth between the editor and Slack.

Add support for template strings: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

Oniguruma is currently at v6.9.0 vs. v5.13.5 shipping in SubEthaEdit. I just didn't want to disturb too much for the initial 5.0 SubEthaEdit build.

1. >see a.extension a
   -> two files open, a and a.extension
2. Click on the window containing a.extension (should be behind the window with a)
3. Hit Command-S to save
   --> The file name in the save sheet is pre-filled with "a"
   Expected: Should be "a.extension"

Would you be opposed to me making the tabs in SubEthaEdit match Safari's current style (the ones currently match Safari's old style). Want to make sure that's wanted before spending any time on it.

Steps to reproduce:

1. Create an applescript in the iCloud/Script Editor folder
2. Cmd-Option-drag the script into the see scripts folder ~/Library/Application Scripts/de.codingmonkeys.SubEthaEdit.MacFULL/
3. in see: (script menu)->Reload Scripts

Result:
Alias does not appear.

Expected Result:
Aliases appear in the same way as actual files do.

While it served us well in the past, creating modes isn't as easy and straight forward as it could be. We should reconsider updating the mode bundle format to improve on some of it's clumsier aspects:

• Remove redundancy (mode names and version e.g. are in multiple files, often annoying to update, one could merge these into less different files where appropriate)
• Switch away from XML (A lot of mode creation is based on regexes, and those need to be escaped quite annoyingly in XML, making the roundtrip on creating, update and maintenance less convenient as it could be. Switching to TOML is one avenue I would like to explore, as it has great support for strings in a way that don't need escaped.
• Switching to flat bundles might be beneficial to remove the deep hierarchy on editing.

Along those lines we should also think about making the mode states more semantical to improve reuse. While importing of modes is a great feature to have full language capabilities in all languages that embed other languages, there would be great potential to have great semantic entities for e.g. strings and number representations that can be mixed and matched to optimally and correctly represent them for the current mode.