Jump to content

godbout

Member
 View Profile  See their activity

  • Posts

    323

  • Joined

  • Last visited

  • Days Won

    12

 Content Type 

Everything posted by godbout

  1. godbout
    isn't that term offensive? or is it Mongolian, i forgot.
  2. godbout
    i didn't have any issue. but yeah, you better keep another clean Xcode. also, at every Xcode update, you need to resign. a bit annoying yes. and the plugin is not the best Vim port out there. but still, i think it's the best workflow i've found till now.
  3. godbout
    i could put a stuff online later, but it's pretty barbaric. like there's a useless window that you're gonna have to hide, and the shortcut is set to cmd+escape and that's it. but there's quite a few moves working. yeah i tried `shortcat`, the idea is very nice. but when i tried it it kept crashing. i haven't been able to use it at all. i think i read later that it was because you can't use it on itself. might have been the issue, but haven't tried again. i use Vimac currently. different style, but still gets rid of the mouse: https://github.com/dexterleng/vimac yes i tried Karabiner also and used it for a while. but the main moves were never enough. and in some cases there was delay in the key presses. like in Karabiner i couldn't find an easy way to have stuff like "ciw" for example. have you tried XVim2? https://github.com/XVimProject/XVim2 you need a little trick to make it work, but it works. although not all the moves are there. also you may need another clean Xcode (that you didn't resigned) to push to the App Store, or do some other stuff that require your Developer ID etc. if i could spend all my time in ST i would do it, but the autocompletion in Xcode for, well, that static Swift thing is pretty good and useful.
  4. godbout
    actually it's pretty straightforward. there's two ways to do it. one is by using the Accessibility API and gather inputs' contents. that should allow for a more precise experience, but i haven't explored this yet. the way i did it is by creating a tap event. basically you insert a tap in the event stream and grab and redirect some of them (keyboard ones in my case). it was not hard to do, but (at the time at least) hard to test. haven't gone back to it yet. to enter the global command mode, it's just a keyboard shortcut. (personally i tried to use something related to escape, like a long press for command mode and normal press for normal escape or the opposite, but nothing felt right. so i use cmd+escape now (although it's more cmd+capslock; capslock mapped to escape)). probably the final app will be a mix of both methods. for text, it'll use the Accessibility API, to move in dropdowns, menus, etc..., a remapping of the keyboard.
  5. godbout
    was wondering until where i could push my bad humor. i guess limit reached 😂️😂️😂️ yeah i remember that. well, as usual, take my understanding with a grain of salt, but previous every year they would release a new major version, that means they'd break APIs for sure. seems that for the last recent years they mainly add new features. 5.4 should bring some asynchronous shits. so i'd say yes, it should be more stable. (you can quote me next time they break your projects.) actually it is. for developers that are used to Vim motions and commands in their favorite text editors, they can use the same bindings in all input fields on macOS, i.e. when they use an app, when they type bullshit on an Alfred forum, etc. at least this is how it started. now rather than purely making the bindings available to the macOS input fields only, i'm kinda tweaking it more, i don't know, conceptually? abstractly? like you usually use `j` and `k` do go up and down in your text editor. now you can use `j` and `k` to go up and down dropdowns, "lists", etc... macOS comes with the Emacs binding, so you can use Ctrl+n/Ctrl+p to go up and down rather than the arrow keys, but it doesn't work in a lot of apps, including Apple's own (like Xcode choose project dialog). with kindavim.app you can just go up and down everywhere without ever using the arrow keys and mainly keep your fingers on the home key. there's more to it but mainly that's the idea. i know at least one person very interested in this (me).
  6. godbout
    sorry what does `googling` mean? i'd be surprised if Apple and the bunch of people working on Swift would let it suck though? so i'd foresee more and more improvements. but maybe it's just wishful thinking. i've joined the bandwagon at a better time than you also. seems you were in when everything would be still slow and break at every update. i joined at 5.3, so things seem already quite stable and i don't see (yet) any performance bottlenecks. for myself? in the long term it's just kindavim.app. want to get Vim binding for the whole macOS, and provide this as a nice little app for US$1 a month. that's why i went for Swift. i have something working already that i use daily, but as usual i've built it only for my own needs first. the idea was to release it, and if there's some traction and people request other moves, i'll add them. the issue is that currently it's not properly build, and no test suite, so adding new moves tend to break old ones. wanted to get more knowledge and practice and with the macOS interpreter thing + slow PHP Workflows, decided to learn by doing some stuff for Alfred. i guess in the short/middle term it's going to be building stuff for Alfred. maybe also some small, very specific stuff later for my own needs. i like to build small, useful stuff, that do only one thing but do it greatly. with being tested properly so that i can keep them updated without much hassle. let's see where this will land. utopically i hope to be the next Steve Bobs.
  7. godbout
    if i remember/understood correctly i think they're getting copied only when necessary. so it's supposed to be Ultra Performant™. but of course as usual i might be completely wrong. at first i was dafuq, i want some part of a string and i can't even use that shit as a string itself??? but you actually just need to init a String with the substring like String(yourSubtring). the idea is as long as you don't need the substring, it takes no space. it's just a reference to the lower and upper bounds. after the initial dafuq i was like, nice, pretty smart. (as you can see by now i don't need much to find something smart.) nice. looking forward to see where this is gonna lead you. should be quite interesting.
  8. godbout
    ok i'm depressed now. i'm gonna give up Swift and will start developing my Workflows with this library: https://github.com/deanishe/awgo
  9. godbout
    makes sense. i do like this. it's just i think a matter of habit and of not knowing the language well enough yet. i like to have methods with only a few lines of code in them, but with Swift it's usually hard to do. might improve, or i might get used to it. do you think it's still the case with Swift 5? i thought `struct`s were there especially to handle performance issues. also there's stuff like `Substring`s that are a special type rather than `String`s themselves so that they get copied only when necessary. well it's always the same compromise right? or you stick to low level and it's performant but the APIs are usually hardcore, or you get a nice abstraction where you almost just type English but it comes with performance issues. personally when i build something (for other developers) i like to put priority on a nice API. then, for the performance, i can always figure things out later and refactor the internal organs. (hence the need for me of a good test suite.)
  10. godbout
    i like the language. you know it's new. it's like they took good practices from software development and baked them in. like the guard statements for returning early/happy paths. i like the named parameters too. i like to write APIs like i talk, and that helps a lot. the only thing i've struggled with (but it's a compiled VS interpreted thing) is the lack of dynamic(?) flexibility. like in PHP i can do crazy stuff like calling dynamically properties or methods and it takes two lines of code. in Swift everything needs to be stated clearly. currently it makes me feel that the code is extra verbose, not clean. but i haven't checked yet `KeyPaths` and other stuff that should help with that. man. you sure do know your stuff 😅️ i usually find the Swift APIs nice to work with, but i have no idea about performance. i was assuming it was good, actually.
  11. godbout
    thinking about it, that's probably due to the fact that you were not using this fantastic new Alfred Workflow ScriptFilter library 🙄️
  12. godbout
    ah, Alzheimer's. not remembering that you can't remember. sounds like the perfect recipe for happiness to me 😂️ well, not sure my "experience" is currently valuable to you. i was impressed by your SSH Workflow and the speed of what shows in the items subtitle while you're typing, so i knew sooner or later i'd have to switch to some compiled language, at least for some Workflows. personally i wanted to learn Swift for some other macOS software so that's a win. not having to force the user install PHP is another win. the speed compared to PHP is one more win, although in the case of Alfred KAT—the only one in Swift i have for now (next is gonna be same, TPB)—it doesn't reflect much as i need a delay and then it's just pulling pages from the web. so honestly for now it's all win, but if there's performances issues later that might be a problem, yes. i made some tests with the user input and i can still press enter too fast and crop the last letter. but it happens also on your SSH Workflow, although not as frequently i think. i'm curious, why bothering with Swift if you're already building stuff in Go?
  13. godbout
    yes, definitely fair. will remove for now and hopefully find a better phrasing tomorrow now that you've helped clarify my understanding. another day when i'll go to sleep less stupid than when i woke up. wondering when this is gonna stop though...
  14. godbout
    if my above understanding is correct, the Alfred Workflow ScriptFilter library supporting up to some OS and the Workflow built with it supporting up to some OS are two different things. the library supports up (down?) to Yosemite, but for the Workflow itself it will depend on what the developers want/do themselves.
  15. godbout
    hey deanishe, thanks for taking the time! this is what i got from Andrew end of January this year (i hope he doesn't mind me sharing our secret love affair): "Alfred won't ever be bundling binaries for languages such as php, so Alfred users will be using the built-in version of php in macOS sourced from /usr/bin/php, or will need to install custom runtimes." i took this as users will have to install their own interpreters if macOS doesn't provide. i might be wrong though? (anyways, not the primary reason why i went for Swift.) ah. thanks for catching this. i think both my phrasing and my understanding are wrong. my line of thought is: i started the library with no minimum requirement, then along the way i've used some APIs that were only available starting with Yosemite. so Yosemite become the lowest requirement. i expect (still) people to be able to use the library under Yosemite, and build a Workflow with it. now where my phrasing is misleading is using the library/building the Workflow vs using the Workflow. am i getting this correctly? hadn't touched compiled stuff for 20 years. way harder than interpreted. too much to my taste 😅️
  16. godbout
    to create Alfred ScriptFilter results in Swift. the code: https://github.com/godbout/AlfredWorkflowScriptFilter if you care about the why, a bad blog post: https://sleeplessmind.com.mo/news/alfred-workflow-scriptfilter-another-one/ it's probably missing some stuff as it's built mainly for my current needs, so don't hesitate to bitch and i'll see what i can do!
  17. godbout
    latest release version available here: https://github.com/godbout/AlfredKat working the same as the previous one, but no PHP interpreter needed. ✌🏼️
  18. godbout
    fantastic. thanks for the letting me know.
  19. godbout
    anybody cares giving it a try? https://www.dropbox.com/s/t4blftd0x160546/KAT.alfredworkflow?dl=0 to make sure there's no issue with Developer ID bullshit and some other libraries missing crap. thanks!
  20. godbout
    🙈️🙈️🙈️
  21. godbout
    there's a bug in Alfred that if sometimes you press command while choosing a result it will copy it to the clipboard. may be worth a try?
  22. godbout
    sooooo... got something working in Swift. i think i'm gonna rewrite the Alfred Workflow ScriptFilter in Swift and create my new Workflows (and maybe rewrite some old ones) in Swift. way faster, and i don't need users to have PHP on their mac. already having troubles with bundled PHP being an old version, before it disappears completely. ✌🏼️✌🏼️✌🏼️
  23. godbout
    excellent. time to go back to Alfred Kat now. so did you guys know that if you use the tag #xxx you can filter by pron?
  24. godbout
    here you go: https://github.com/godbout/binance-dash-docset basic TOC and formatting, but usable. you can download the tgz. if you want to modify yourself, you can fork and play! good luck.
  25. godbout
    well, you could edit the SQLite db that stores the entries, yes. and you could edit each HTML file to make them look like the way you want. all explained on the Dash site: https://kapeli.com/docsets#dashDocset but that's exactly what the dash-docset-builder does for you. basically with the dash-docset-builder you have only one file, where you do two things: 1) define a few constants that tells dash-docset-builder where to download the docs 2) tell the dash-docset-builder from what it should generate the Dash entries and how it should format the HTML. by default the dash-docset-builder will check your constants and will check if the docs have a sitemap. if yes, it'll download the doc following the sitemap. if no, it'll download from the URL you gave as a constant. if you need to fine-tune the download yourself, you can override the `grab` method and use whatever way you're comfortable with to download the docs exactly the way you need. then the dash-docset-builder will go through all the HTML files twice, calling two methods from your one file. one method to generate the Dash entries, one to format the HTML files. why twice rather than once? because you're not going to generate the Docset many times so the extra time is not an issue, but separating the two processes is much better for maintaining the code. the parts about generating the entries, and formatting the HTML, i provide a way to easily crawl the DOM, but you could use whatever you want. all is in the README (but it seems, not clear enough :D): https://github.com/godbout/dash-docset-builder
×
×
  • Create New...