0 users browsing Projects. | 1 guest | 2 bots
| Near |
Posted on 18-12-27, 00:22
|
|
Burned-out Genius Developer
Post: #1 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
I wrote a text editor, for various reasons. It's like VS code, Sublime, or Atom I guess, if any of those programs were written in ~500 lines of code and ran natively on FreeBSD. GTK only (so Linux and BSD, or if you're adventurous enough ... potentially Windows or macOS.) You must run "make install" for now, since I don't have a fallback for missing config files yet. The default mimetypes.bml file is missing a huge amount of extensions, but I'll get to them in time. Three modes of operations: amethyst -- open an empty new document amethyst filename -- open an existing document with no tree view amethyst directory -- open a folder and allow recursive access to all subfiles/subfolders The editor itself has a text mode and a simple hex mode (currently read-only though, hiro::HexEdit needs more work.) No real features beyond save, save all, find (forward and backward search), and goto (line.) Has a safeguard against files being modified externally when you go to save changes, tells you if it can't save for some reason, detects read-only files, and has a snazzy close dialog to choose which still-modified files you want to save or not. You can't (currently) do things like rescan folders in directory mode to find new/deleted files/folders, rename files, create/delete files/folders, spawn new documents with the editor already open, save an open file as a different filename (that creates too many gotchas like saving it as a different file that's already open in the editor), use the search function all that well in hex mode (strings that wrap on 16-byte boundaries will miss), do a find+replace, etc. But probably in the future I'll add more stuff. I'd appreciate if anyone able to run it could do some testing. My own testing shows it works fine, but I'm obviously a bit worried that if I missed something serious, it could mess up my source code or worse, which would be extremely bad. If you can't run it, peeking at the source for issues would be helpful, too. I'm only planning to develop this to the extent I want to use it. Idea being, it's 500 lines, feel free to add any features you want yourself. Thanks in advance! https://files.byuu.org/releases/amethyst_v1.tar.xz  |
| neologix |
Posted on 18-12-27, 03:32
|
 Post: #14 of 49 Since: 10-29-18 Last post: 1901 days Last view: 1786 days |
While I understand that this is a relatively early version, I'm a tad disappointed that the hiro/source-edit widget hasn't yet made its way over to non-gtk implementations yet. For hiro/hex-edit, at least on macOS you might be able to get away with borrowing some code from Hex Fiend, but I don't know yet what would be a good starting point for syntax highlighting textboxes (TextMate and Fraise might be good candidates, but without yet looking at their sources I wouldn't be surprised if they have super-custom paint() loops instead of some native Cocoa source-edit widget). |
| CaptainJistuce |
Posted on 18-12-27, 04:47
|
|
Custom title here
 Post: #156 of 1164 Since: 10-30-18 Last post: 63 days Last view: 9 hours |
Posted by byuuAwesome! I know you've been talking about this for a while. Also, hi. --- In UTF-16, where available. --- |
| creaothceann |
Posted on 18-12-27, 10:24
|
 Post: #39 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
How does it handle viewing & editing multi-GB log files updating in the background? :) My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| SuperMikeMan |
Posted on 18-12-31, 00:11
|
|
Post: #2 of 6
Since: 10-31-18 Last post: 1944 days Last view: 71 days |
Posted by byuuI decided to be that guy and try this, as I have on many occasions before on hiro/gtk only projects of yours. Setting up msys2 to get windows versions of gtk and then compiling it turned out not to be all that hard. The only real issue compiling was I had to remove -static from the windows stuff in nall/GNUmakefile because there weren't static libs for GTK (although the error the linker spits out for this makes it look like it couldn't find any libs, even though the dynamic ones are right where it's already looking, which is dumb and took a litle bit of figuring out what it was really complaining about). Oh, and I had to copy those two bml files from data to next to the executable, of course. The much bigger issue that took me ages to figure out was why the program was then always closing immediately. As it turns out, the issue was an initialization race condition in hiro where both the Hotkeys and pKeyboard were apparently being initialized before Keyboard::keys which was breaking everything and resulting in every hotkey reading as being pressed on the first keyboard poll, including the quit hotkey, closing the program immediately. More specifically, what would happen is, because of Keyboard::keys not being initialized yet, for all the Hotkeys, hotkey.state->sequence would be set, but hotkey.state->keys would not be breaking Keyboard::poll seen below
auto Keyboard::poll() -> vector<bool> { auto pressed = pKeyboard::poll(); for(auto& hotkey : state.hotkeys) { bool active = hotkey.state->sequence.size() > 0; for(auto& key : hotkey.state->keys) { if(pressed[key]) continue; active = false; break; } if(hotkey.state->active != active) { hotkey.state->active = active; active ? hotkey.doPress() : hotkey.doRelease(); } } return pressed; } Basically, it means active is true, and the for loop doesn't run at all, and the if block does on first poll and runs hotkey.doPress() A similar issue happened in pKeyboard::poll()
auto pKeyboard::poll() -> vector<bool> { Here, Keyboard::keys not yet being initialized when pKeyboard::initialize got called means settings.keycodes never got set and is empty, so nothing ever gets polled.if(Application::state().quit) return {}; vector<bool> result; char state[256]; #if defined(DISPLAY_XORG) XQueryKeymap(pApplication::state().display, state); #endif for(auto& code : settings.keycodes) { result.append(_pressed(state, code)); } return result; } My hacky workaround in both polls was more or less to check if things are initialized correctly in them, and initialize them on the spot if they weren't, namely
auto Keyboard::poll() -> vector<bool> { and
auto pressed = pKeyboard::poll(); for(auto& hotkey : state.hotkeys) { bool active = hotkey.state->sequence.size() > 0; if(hotkey.state->keys.size() == 0) {hotkey.setSequence(hotkey.sequence());} //<-- This line for(auto& key : hotkey.state->keys) { ...
auto pKeyboard::poll() -> vector<bool> { if(Application::state().quit) return {}; if(settings.keycodes.size() == 0) { initialize(); } //<-- and this one vector<bool> result; ... Not really the nicest way to do it, but there's not really a good way around the compiler deciding to run constructors that are using Keyboard::keys before actually initializing Keyboard::keys to any more than an empty vector, which seems to be what was happening. Only on Windows, though, on my linux box, it built and ran cleanly. Which was part of what was so confusing, since it'd be like 95% of the same hiro/gtk code running either way. Also, to Kawa, I'm kind of missing the pre tag for inline code stuff already, bolding just isn't really the same as the kind of formatting the code and source tags here do for blocks |
| wertigon |
Posted on 18-12-31, 13:09
|
|
Post: #15 of 205
Since: 11-24-18 Last post: 155 days Last view: 27 days |
This looks promising. So, when will you add Lisp support and modal editing? ;) Yes, not entirely serious - I'm just a bit sad to see that the old ways of customizable editors and the editing language of vi is slowly dying. But this is not the place, nor time to start the old editor wars again... Good luck with this! |
| wareya |
Posted on 18-12-31, 18:59 (revision 1)
|
 Post: #25 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Modal editors are a lot less intuitive than non-modal editors, and it's impossible to justify making a modal editor in 2018 if you're not already indoctrinated into using them. Heavily scripted editor customization always leads to serious problems with performance or design down the line. It's also opaque and hard to learn. Of course, if you know the systems well and you've spent enough time with them, modal interfaces and heavy scripting can make it easier to do certain things, but a lot of the things that they make easier can be made easier by just improving your editor - support for multiple text cursors is a good first. Customizable editors are still around, you just see "plugins" instead of "scripts" (even if they're still written in a scripting language), because you need a clean interface for extensions to talk to the editor through anyway. |
| Screwtape |
Posted on 19-01-01, 05:52
|
|
Full mod
 Post: #75 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Posted by wertigon You should totally check out Kakoune. Kakoune is to Vi/Vim as Plan9 is to Unix: the best ideas, concentrated, polished, and extended. It's got multiple cursors, it's got regexes, it's built for integration with other tools.. it's more powerful than Vim, but with a much smoother learning curve. It's not for everyone, but at this point I can't imagine switching to a different editor unless it's one I write myself. The ending of the words is ALMSIVI. |
| wertigon |
Posted on 19-01-01, 23:30
|
|
Post: #16 of 205
Since: 11-24-18 Last post: 155 days Last view: 27 days |
Yes, modal editors are clunkier to learn, just like the command line. Vi is especially hard to take in. However, having finally learned the vi language, for a language of button presses it is, I can finally do really complicated edits really fast. Of course, vi does have some antiquated concepts, hardly suited for modern times. So does emacs. When it comes to keyboard-only mode, vi and emacs are kings. But, these days some tasks are better suited for mouse. In my opinion, an ideal editor should offer: * Keyboard centrism. Because it's still the best way to edit and inspect code. * Multi language support. Visual Studio is a great code editor for C, C# and C++ but sucks for Python, JavaScript and CSS for instance. * Discoverability. It should be easy to discover the more advanced functions of the editor, at your own pace. * Convenience. Things like autocomplete, intellisense, auto-formatted code and command recordings greatly simplify my life. * Version control support, preferrably as a plugin. * Project navigation, vim is great for managing a few configuration files but any project bigger than a dozen files become quite cumbersome to manage in vim alone, not to mention something big like the Firefox source code. Visual Studio and Eclipse are great at Discoverability, Project navigation and score high at Convenience, but often fails at version control, multi language and keyboard centrism. Meanwhile, emacs and vi are both great at keyboard centrism and multi language support, and are in many ways more convenient to use - but does not offer the same overview with projects and both suck at being discoverable, despite things like Spacemacs. Modal editors shouldn't really have to be an impossibility however; how about an editor that offers ctrl+space as a way to enter command mode for instance, but insert mode still allows for rudimentary commands such as save, cut, copy and paste. Lastly, emacs does have quite a few nice advantages I have yet to find anywhere else. Undo-tree is simply glorious magic, magit has to be one of the best git frontends I have yet to encounter and evil mode allows me to do all my vi editing magic right there in emacs. So, right now nothing beats emacs for my use cases, but the quest for the perfect editor still continues... And I'll have to check out Kakoune too. :) |
| Near |
Posted on 19-01-04, 20:03 (revision 1)
|
|
Burned-out Genius Developer
Post: #4 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
> I'm a tad disappointed that the hiro/source-edit widget hasn't yet made its way over to non-gtk implementations yet The thing is, it uses GtkSourceView. That gives us: * color syntax highlighting based on a set of rules * color scheme selection * highlight current line * visual brace matching * show line numbers on the left Plus a bunch of other things I don't want. Plus, if I were willing to use GTK3 only, GtkSourceView3 can highlight a phrase everywhere it appears, which is *incredibly useful* for searching. Unfortunately, I have no idea how they ad-hoc implemented that on gedit 2 before GtkSourceView2 even supported it. We could create a kind of light-weight custom SourceEdit control with Windows and Qt, but in the end it'd basically just be a TextEdit control, and if we're lucky, with line numbers. Not very nice. But even line numbers I'm not sure how we could really do those. The basic idea is we'd need a widget container with two widgets, but then how do we keep the two widgets in perfect scrolled synchronization with one another with only a single scroll bar? Hard problem. I don't want to approach it like HexEdit, where I actually put the addresses in the text itself, because that complicates the hell out of everything, including that you can't select multiple lines of text without pulling in the offsets (fine for a hex editor, bad for source code.) > The much bigger issue that took me ages to figure out was why the program was then always closing immediately. Ah, sorry, Talarubi recently found the same issue. I don't have a non-hacky fix for it yet. C++ object construction ordering is a trainwreck. |
| neologix |
Posted on 19-01-05, 02:15 (revision 1)
|
|
Post: #17 of 49 Since: 10-29-18 Last post: 1901 days Last view: 1786 days |
Ah. Even though you don't necessarily like SciTE have you considered just the Scintilla highlighting component as a code inspiration? It seems to continue to be supported, having had updates as recently as October 2017, so maybe the code is reasonably understandable. I know the text editing component of the older version of the Sphere Editor used it to great success. |
| Wowfunhappy |
Posted on 19-08-01, 00:47
|
|
Post: #9 of 21
Since: 11-08-18 Last post: 1254 days Last view: 1254 days |
Is this still available everywhere? I'm getting a 404 not found. I've actually been looking for a very, very minimal code editor with syntax highlighting... |
| Screwtape |
Posted on 19-08-01, 03:36
|
|
Full mod
Post: #311 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Depending on what platforms you use, you may be interested in TextAdept, or GNU Nano. The ending of the words is ALMSIVI. |
| Duck Penis |
Posted on 19-08-01, 16:54
|
|
Stirrer of Shit
Post: #549 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by byuu What about using another GUI toolkit? Try nuklear or imgui, for instance. Cross-platform, minimalist, extensible, public domain. Then you could add in whatever controls you wanted to. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Kawaoneechan |
Posted on 19-08-01, 18:15
|
|
Random title!
 Post: #315 of 599 Since: 10-29-18 Last post: 195 days Last view: 5 hours |
Did you seriously just suggest byuu use a different GUI toolkit? You did not just do that! |
| Duck Penis |
Posted on 19-08-01, 20:47
|
|
Stirrer of Shit
Post: #551 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Well, by my understanding, they do different things. His is a lowest-common-denominator mapping to GTK/Win32/Cocoa, which restricts you to using their widgets, but on the other hand gives you a native look. That is good for serious business use, but not so much for when you want fine-grained control. Whereas these are immediate-mode toolkits, which enable you to draw anything at all without restriction. I suppose another way might be to add a nuklear backend to hiro and then say amethyst should only ever be compiled using this backend. This is extremely ugly. But on the flip side, it would enable you to use bsnes/higan without having to start your X server. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Kawaoneechan |
Posted on 19-08-01, 22:18
|
|
Tall, Dark and Bishōjo
Post: #316 of 599 Since: 10-29-18 Last post: 195 days Last view: 5 hours |
You do realize you're talking about byuu here, right? |
| creaothceann |
Posted on 19-08-01, 22:30
|
|
Post: #180 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
https://www.reddit.com/r/emulation/comments/ciy5tj/bsnes_v108_released/evbi18r/?context=3 My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| tomman |
Posted on 19-08-01, 23:32
|
|
Dinosaur
 Post: #467 of 1315 Since: 10-30-18 Last post: 58 days Last view: 18 hours |
Posted by creaothceann Also the pages lack the first-level heading element — h1, incorrectly using the header element instead. The header element has a totally different meaning than heading elements like h1, h2, etc. Webshit UX designer confirmed. Seriously, not every website has to follow "design rules" as long as the information is clearly laid out in a readable fashion. KISS. byuu's websites are an excellent exhibit of this (his design choices may look weird in this era, but our eyes and bandwidth bills greatly thank sensible designs like those - who cares if you're "Doing It Wrong™" with ancient HTML tags?!) Posted by Kawa Unfortunately no cure has been found for Reality Distortion Fields yet :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Duck Penis |
Posted on 19-08-02, 00:19
|
|
Stirrer of Shit
Post: #554 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by KawaPoint taken. Posted by tomman You've got to have some kind of standards. Writing substandard HTML is going to cause all sorts of issues later on down the line. It's like going too hard with the idiomatic C and invoking UB, and then claiming it's not UB because it compiles. Civilizations abandoned the law of the jungle thousands of years ago, when will technology follow suit? If the goal is just "ooga booga grug want text in browser fast," then why bother generating valid HTML at all? Then you could use a far simpler regex-based conversion. If you just write the elements you want and save as .html, Firefox/Chrome renders it just fine. There's no need to use the "real" tag names either. You can just make them up and use CSS to style them, and it will look as normal. No need for garbage like meta, head, body, or html, you can just start writing. Here, try pasting this into a HTML file and opening in your browser. It renders fine, so it must be valid HTML.
<h1>grug want big text</h1> <header>ooga booga</header> <p>Seriously, not every website has to follow "design rules" as long as the information is clearly laid out in a readable fashion. <span>KISS. byuu's websites are an <style> red { color:red} header{ font-size:2em; </style> excellent exhibit of this </p> <red>(his design choices may look weird in this era, but our eyes and bandwidth bills greatly thank sen<title>FAST WEB DEVELOPMENT - CONTACT SUREANEM NOW</title>sible designs like those - who cares if you're "Doing It Wrong™" with ancient HTML tags?!)</text> <html><!-- Granted, there is something to be said for this style of web development as a deliberate statement, but you should probably at least try to use the tags they give you as far as possible. Consider text browsers, for instance, or browsers without such sophisticated parsers. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
