I remember when I used to cringe that an application was built with Tcl/Tk because it would be very slow and need quite a bit more memory than a similar application written in C or C++. But, today, I suspect this editor is an order of magnitude faster and an order of magnitude smaller than Atom or VSCode (this is purely speculation, of course...but, I feel like it's a reasonable hunch, based on my experience with Tcl/Tk in the past).
Not like C/C++ applications go easy on memory these days, either. When GUI libraries include CSS and JavaScript interpreters, suddenly MFC and Motif look less bloaty…
Never mind Java editors/IDE, which are pretty much standard these days.
The only "standard" full-fledged IDEs I can think of that are Java are IntelliJ and Eclipse. Visual Studio (WPF), Xcode (Cocoa), Qt Creator (Qt), KDevelop (KDE Frameworks/Qt), GTK Builder (GTK) are all built with their platform's native toolkit.
Concerning text editors, I think that field is split between Electron-based, Sublime and terminal-based editors. I can't picture users writing in Java editors in 2018.
Let me clarify that, with "standard" I didn't mean exclusive, just that running a Java IDE ain't exactly exotic or weird. IntelliJ and its variants alone are a good share of the market.
I don't think that kind of memory usage is necessarily common - I get sessions that grow for whatever reason but typically I can have several emacs instances running at once using less than 100MB each - the ones I treat like notepads are often less than 10MB.
Hmm, why would one run several emacs instances? Emacs supports the client-server model, which I find very convenient and fast. Basically having `EDITOR="emacsclient -n"` allows you to use the one emacs everywhere.
I run them with different color themes and fonts (randomly chosen from a list on startup) so I can instantly see which window is being used for which project (I juggle several at work - I also take advantage of Windows 10's virtual desktops so get them spread out all over the place). If one of them goes haywire I don't feel bad about killing it since the others remain unaffected, so I never really considered using just a single server instance. Since I don't run out of memory and have CPU cycles to spare most of the time, it works well enough for my current needs.
I also tend to run the windows with partial transparency so I can see bits and pieces of other sessions/browsers/etc behind them - something I was slightly hesitant to start doing but that has made using the computer feel much more "lightweight" (for lack of a better term). I've found it surprisingly useful to have emacs show a second buffer slightly faded directly through the first one.
I too, for a time, had setup my system so that windows were partially transparent. It looked cool, and helped to find windows when they were hidden behind other ones. Then, one day, I turned the partial transparency off, and found it to be very relaxing on my sight and brain. I didn't feel any strain when I started, but I guess it accumulated.
For context, I use a tiling window manager with an average of 4 to 7 windows per workspace-monitor combo. Back then, I also set up a moving background (a screensaver always on in the root window). In fact, I think that was the primary motivator. I had gone years without a wallpaper because having a tiling window manager made it meaningless and I was missing having some eye candy. Having partial transparency would let me see the moving background through the windows. Anyway, I digress and I'm back to no transparency, no background, in any case.
So, Hackernews, here is what I want you to do. Create a website with "solve this with your editor" challenges where everybody can upload screencasts and compete. :)
An obvious metric would be /time to completion/ but I would also be interested to see /can be done with mouse only while drinking coffee/ or in general /can be done one-handed/, /can be done left handed/ (so the mouse is free) or maybe /keystrokes+clicks/ instead of general timing because it takes the typing speed out of it. Some metric that measures how many shortcuts you have to memorize would be great, too.
There is a very large margin between time I spend considering the solution to a problem and the time I then spend writing it, so my main consideration with an editor is ergonomics. For example, if I can do a change without moving my hands off the home row in 20 seconds, that's better than a 5 second change that involves alternating between the keyboard and the mouse.
There's http://www.vimgolf.com/ which is obviously focussed on Vim, but there's nothing stopping people from keeping a scoreboard of the same challenges for other editors. For example, the Kakoune editor has their own: https://github.com/mawww/golf/
This is not very useful because vimgolf ends up with very efficient commands that are not at all what the typical vim user would use; or in other words the benchmark will get gamed.
Back when I was a macOS user (back when we just called it System 7 …) I discovered Alpha: an extensible editor written in TCL. It was pretty amazing, and was what first opened my eyes to what could be done with a scriptable editor.
There seems to be a lot of influence between editors which to me is the most interesting part of all of this. Just looking at TKE's screenshots, it resembles VS Code to a not-insignificant degree, and VS Code and Atom both seem to have been inspired graphically by Light Table, and all of these as well as Alpha have a programmability that's heavily inspired by Emacs, although Alpha's GUI is closer to TextMate which was influenced by BB Edit, and the history of editors is something I'd love to see someone with more knowledge of the history do a more comprehensive write-up of it.
I never really got how Multi-Cursor / Multi selection became such a big deal. It really never happens to me that I have to write the same thing on N-lines, and when that happens VIM ninja works just as well.
Visual editing and selection-before-action allow for users to be much more confident that they’re doing the right thing, and to build up commands step by step with feedback along the way. The problem that multiple selection solves is then the same thing that repetition of a bunch of commands solves in vim.
A bunch of longstanding vim users I know now use kakoune because of the visual feedback they can get when doing something new with their editor.
It doesn’t have to be an either/or choice, having both can work.
For example, I’ve just used vim-multiple-cursors¹ to rename a parameter to a function, and I could have done that with “straight” vim too. However, for quick operations a simple `C-n`… to select the name, followed by `c` to change all at once just /felt/ nice.
Ehm, I agree with the Vim point, but think of those who won't/can't spend time getting past that Vim learning curve.
Especially for people dealing with csv files, tabular data or digging through logfiles, Multi-Cursor and Multi-selection are concepts that are easy to grasp, and can help productivity immensely, with things that are not that easy using Nano or Notepad.
Simple cases in point : Use a regular expression to find and copy all lines with a particular pattern, or copy-paste a few csv lines with a couple of fields modified.
Vim has macros[1] and other replay tools for occasions like that.
I think the issue with Vim isn't so much that things can't be done in it but more that the discoverability of Vim features is pretty poor. eg by the time you've searched the web for a quick way to do a multiline edit, you could have just done it manually. GUI IDEs tend to be better for discoverability (generally speaking).
Agreed, I think of macro as a superset of multiple-cursors. Heck, with macro you can even run arbitrary code to generate text dynamically. I had the pleasure of doing this multiple times.
In Emacs, you can use multiple registers for storing code and data for this purpose
Sure but does it really happen that often, whenever there are regularities usually there's some variation that makes it useless.
Don't get me wrong, I don't mind the feature, thing is I run in it so rarely so I don't get why it would be a major sellingpoint. For example this project and perhaps more notably sublime (an editor that I do enjoy quite a bit!)
Assuming the '_' characters are on the same column for all lines then vim's block visual is quite adequate for the task. If it's not the case then I don't know how multiple-cursor will help, you still need some kind of regex to put the cursors at the right places, don't you?
With multiple cursors you are seeing the changes as you are editing. and you have all of the normal editing shortcuts at your disposal. Example, if you made a mistake while typing just hit undo.
Yes, no silver bullet. But most of my use case I find a generic pattern so I don't check the individual edits. Anything more complex I'll switch to macros.
Btw, I meant undo like global undo which will let you undo the last keypress for all of the cursors. In your case, you meant undo for a particular instance of change I guess.
Also, let's say there is different character after _
it's more keystrokes (and more complicated ones) than just doing cursor editing, and you have to think of every replacements in advance while with the multi cursor if you have five others replacements to make in the same line you can just make them easily one after the other
Disclaimer: Do not want to start a flamewar and I will continue to use TCL/TK for the forthcoming years.
It is a really pitty that Tcl does not suppport a Lispy alternative interface to the language. I used many times Tcl/TK which saved the day repeatedly. I would like to have a really nice CL or Scheme interface to all TCL/TK goodies or support alternative syntax like JS or JVM languages.
Once there was a Scipad. What happened with that project?
PS/Tk for Chicken Scheme [0] would be my serious recommendation.
There is STklos [1], which is a R5RS Scheme with Tk embedded into it, as well as GTK+ for when you feel the need. It is actively developed. (Started out in life as Scheme Tk).
While I know you mean sexps, ordinary Tcl itself has a lot of Lisp-like features that I didn't really understand when I was using it in the 1990s -- it's a lot closer to Lisp than it is to something like Perl which it resembles more superficially.
"Scipad is a powerful editor and graphical debugger for programs written in Scilab language. It is a mature and highly configurable programmer's editor, including features like syntax colorization, regexp search/replace, parentheses matching, logical/physical line numbering, peer windows, line and block text editing, and much more. Scipad can be used along with Scicoslab or Scilab, but even as a standalone text editor."
"Scipad is entirely written in Tcl/Tk and Scilab language."
I'm here to second LTK :-). It's a while since I last used it (2012, 2013, I think?) but it was, and I'm sure it still is, a very good library. It's easy to get started with, easy to work with, easy to debug.
error copying "lib" to "lib/tke/lib": "lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/...skipped.../tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/lib/tke/doc/md/TKE Developer Guide/Plugin Development/Safe (Untrusted) Interpreter Description.md": file name too long
That looks like what you would get if you asked it to install in the same directory you downloaded it to.
It would try to copy lib/ into itself, resulting in your "lib/tke/lib/tke/lib/tke/..." mess.
Like:
$ mkdir lib
$ mkdir lib/tke
$ tclsh
% file copy lib lib/tke/lib
error copying "lib" to "lib/tke/lib": "lib/tke/lib/tke/[cut off long string here]": file name too long
Specify a root directory other than the current directory and it should work.
I wonder if tcl should disallow copying a directory into itself.
In 2001, I created an open source Verilog code coverage application called Covered and hosted it on SourceForge due to its dominance in open source hosting at that time. When it was time to start TKE about 10 years later, I stayed on SourceForge because I was familiar with its capabilities and GitHub wasn't really a big deal like it is today. These days, I keep it on SourceForge because I have some development workflows that are dependent on my SourceForge setup.
Don't worry, TKE has nothing to do with BitCoin :)
http://chiselapp.com/ is where most of the active TCL repositories are stored, at least for fossil. For git, it seems to be a mix of GitHub and gitlab.
This appears to be non-high-DPI-aware on Windows (on Win10, the OS pixel-scales it on a 4K display). Is it possible to fix, or a fundamental Tk limitation?
Could you elaborate on this? I use TKE in Vim mode every day and haven't run into issues with supported Vim motions. What motions did you try doing? Tcl/Tk is usually pretty difficult to crash.
I recall that there was an issue in Tk in regards to the wordstart/wordend index adjectives (which the 'b' command uses); however, I thought that was an issue with 8.5 version of Tk. What version of Tcl/Tk are you using? If you go to the About window within TKE, it will show which version is being used.
TKE uses some automation to attempt to provide translations (as if you haven't already guessed). If you have some time, fixing the translation file would be greatly appreciated!
Back in the day my editor of choice on classic MacOS was called Alpha, also extensible in Tcl. Can’t find any version of it for OSX. I’ll take this one for a spin later!
There should be a bot or a separate feature on HN which would add a FAQ section automatically based on a title, a domain and maybe if we are wild on contents. So when something is hosted on Source Forge this link could be presented: https://arstechnica.com/information-technology/2016/06/under...
I find it surprising how merciless some people are in remembering this issue with Sourceforge.
Considering how loved Microsoft is these days when it was a much worse player in the past, likely even set back personal computing a decade, and all their anticompetetive actions.
I chalk it up as some kind of disappointment by expecting better of SF than others.
Not surprising, their most basic criteria already requires a custom annotation in JavaScript code. Unless a page panders to this specific test it is set up to fail.
Wow, long time not seen Tcl/Tk. I came in touch with it and I can't find anything nice to say about Tcl. So a round of applause to you for building an editor with it.