about summary refs log tree commit diff stats
path: root/source_edit.lua
Commit message (Collapse)AuthorAgeFilesLines
* bugfix: restart search on backspaceKartik K. Agaram2024-10-281-0/+3
| | | | Ported from bugfix of 2024-06-23.
* bugfix in source editorKartik K. Agaram2024-09-101-1/+0
|
* explicitly state when operations manage undoKartik K. Agaram2024-08-311-2/+2
|
* clean up Drawing.before after creating undo eventKartik K. Agaram2024-08-311-0/+1
| | | | This isn't a bug here, but it led to a bug in lines 2.
* consistently schedule_save after all mutationsKartik K. Agaram2024-07-161-3/+3
|
* delete some seemingly redundant codeKartik K. Agaram2024-07-081-1/+0
| | | | | We're patching line_cache and then immediately clearing it using Text.redraw_all.
* purge obsolete term 'fragment'Kartik K. Agaram2024-07-081-7/+4
|
* use deepcopy where possibleKartik K. Agaram2024-06-231-2/+2
| | | | It's shorter and conveys intent better.
* stop caching startyKartik K. Agaram2024-06-111-8/+1
| | | | | This is quite useful because I used to have a long list of places in which to invalidate the cache.
* stop caching screen_bottom1Kartik K. Agaram2024-06-111-6/+2
| | | | | | | | | | | | | | | | | | | I'm not sure this is very useful. I had an initial idea to stop using screen_bottom1 in final_text_loc_on_screen, by starting from screen_top1 rather than screen_bottom1. But that changes the direction in which we scan for the text line in situations where there is somehow no text on screen (something that should never happen but I have zero confidence in that). Still, it doesn't seem like a bad thing to drastically reduce the lifetime of some derived state. Really what I need to do is throw this whole UX out and allow the cursor to be on a drawing as a whole. So up arrow or left arrow below a drawing would focus the whole drawing in a red border, and another up arrow and left arrow would skip the drawing and continue upward. I think that change to the UX will eliminate a whole class of special cases in the code.
* bugfix in source editor: don't clear selection on M-arrowKartik K. Agaram2024-06-091-1/+1
|
* bugfix in source editorKartik K. Agaram2024-06-091-6/+7
|
* ensure tapping on editor brings up soft keyboardKartik K. Agaram2024-02-161-0/+1
|
* fix yet another placeKartik K. Agaram2024-02-041-3/+3
|
* fix still more issues with the previous scenarioKartik K. Agaram2024-01-121-1/+1
| | | | | | | | | | | | - source editor always expects relative paths - refresh mocked data There's still one issue after this: the font size saved in the config file is the one we use in tests. More broadly, Editor_state is completely wrong. Ideally I'd just not save any settings for the source editor if the tests fail.
* moar bugfix X-(Kartik K. Agaram2023-12-291-1/+1
|
* bugfixKartik K. Agaram2023-12-291-1/+2
| | | | | | | | | scenario: run without config file, quit, run again expected: font size remains the same on second run Before this commit it was increasing on each run. It turns out the font height that you pass into love.graphics.newFont() is not the result of font:getHeight().
* pull font into editorKartik K. Agaram2023-12-291-5/+7
| | | | | Now it adjusts the current font for itself. And it's up to the caller to adjust the current font after.
* streamline button.luaKartik K. Agaram2023-12-161-1/+1
|
* clearing starty is redundant in mutationsKartik K. Agaram2023-12-031-5/+0
| | | | | | | | | We'll end up calling Text.redraw_all anyway, which will clear starty and much more besides. We'll still conservatively continue clearing starty in a few places where there's a possibility that Text.redraw_all may not be called. This change is riskier than most.
* mouse button state in source editorKartik K. Agaram2023-12-011-0/+2
|
* audit all assertsKartik K. Agaram2023-11-181-10/+3
| | | | | | | | | | | | | Each one should provide a message that will show up within LÖVE. Stop relying on nearby prints to the terminal. I also found some unnecessary ones. There is some potential here for performance regressions: the format() calls will trigger whether or not the assertion fails, and cause allocations. So far Lua's GC seems good enough to manage the load even with Moby Dick, even in some situations that caused issues in the past like undo.
* clearer API for drawing a buttonKartik K. Agaram2023-10-161-1/+1
| | | | | | Make it more obvious that the color passed in is just for the background. The icon will do the rest. r/g/b keys are more consistent with App.color().
* bugfix: clear selection when clicking above or below linesKartik K. Agaram2023-09-201-13/+27
| | | | | | | | | | | | | | | | | | | Matt Wynne pointed out that snap.love would crash when a node went off screen. While debugging it I noticed that selection1 was being set when it shouldn't be. Turns out I introduced a bug when I fixed the inscript bug back in June (commit 9656e137742). One invariant I want to preserve is: selection1 should be unset after a mouse click (press and release without intervening drag). This invariant was violated in my bugfix back in June. I was concerned only with selection back then, and I didn't realize I was breaking the mouse click case (in a fairly subtle way; you can have selection set, and when it's set identically to the cursor everything looks the same). I think there might still be an issue in snap.love after this fix. I noticed screen_bottom1.pos was nil, and as far as I recall that should never happen.
* indentKartik K. Agaram2023-09-161-8/+8
|
* port an old fix to source editorKartik K. Agaram2023-09-161-1/+11
|
* bugfix to the helper I added yesterdayKartik K. Agaram2023-09-161-0/+1
|
* hide line numbers from log browserKartik K. Agaram2023-09-151-4/+8
|
* bugfix: crash when using mouse wheelKartik K. Agaram2023-09-151-0/+2
| | | | | | | | | | | | | | | | | | All the Text functions assume the cursor is always on a text line. I was violating that invariant. * When scrolling up, I start the cursor at the top-most line below the screen top. * When scrolling down, I start the cursor at the top-most line below the screen bottom. I think it would feel slightly more natural for it to be the bottom-most line above the screen bottom. However, the Text functions maintain an invariant that the bottom-most line in a buffer will be text. There's no such invariant for the top-most line.
* change a helper slightlyKartik K. Agaram2023-09-151-7/+11
|
* always show line numbers in source editorKartik K. Agaram2023-09-141-1/+2
| | | | | | The drawing buttons are now absolutely positioned, which is a horrible hack. But for just the source editor it seems good enough. The alternative is to modify magic constants in all the tests :/
* make a few names consistent with snake_caseKartik K. Agaram2023-08-301-3/+3
|
* port inscript's bugfix to source editorKartik K. Agaram2023-06-041-12/+33
|
* enhance bugfix of commit a9aa3436f (Dec 2024)Kartik K. Agaram2023-04-081-1/+1
| | | | | | | | | | | | Scenario: * start out with some text on screen * select some text A, delete * select some more text B, delete * press C-z twice to restore A and B * press C-y twice Before this commit only the first C-y was having an effect (deleting B). The second was failing to delete A.
* switch source side to new screen-line-based renderKartik K. Agaram2023-04-031-2/+0
| | | | Also copy over the implementation of links from pensieve.love.
* update documentation on fragmentsKartik K. Agaram2023-04-011-1/+1
| | | | | | I see a path to at least maintain a single fragment per screen line. But can we do better? It even seems unnecessary to maintain two copies of the data, chopped up into lines and screen lines.
* no more Text allocationsKartik K. Agaram2023-04-011-1/+0
| | | | Is it just my imagination, or does the app feel lighter and more fluffy?
* App.width can no longer take a TextKartik K. Agaram2023-04-011-7/+0
| | | | | In the process I discovered the horrible fact that Text.x allocates a new Text. And it gets called (just once, thank goodness) on every single frame.
* update stale source X-(Kartik K. Agaram2023-03-261-11/+16
|
* update stale informationKartik K. Agaram2023-03-251-1/+1
|
* some minor cleanupKartik K. Agaram2023-03-231-1/+1
| | | | | I can't see the mouse wheel ever setting dx, but it's more obvious now that the editor doesn't support panning left/right.
* mouse wheel supportKartik K. Agaram2023-03-231-0/+14
|
* get rid of all bifold textKartik K. Agaram2023-03-171-76/+27
| | | | | | | | | | | | | | | It's just uneconomic to maintain given how little I've used it. I have a bug right now and no time to port the bugfix to all the complexities of the B side. I briefly considered tossing out the entire source editor. But I _have_ been using it to browse logs across sessions. The live editor doesn't quite cover all my use cases just yet. We now have duplication in the source editor only for: * syntax highlighting * hyperlinking [[WikiWords]] * ability to hide cursor (when showing file browser or Focus is in log browser)
* bring a few things in sync between run and sourceKartik K. Agaram2023-03-171-3/+5
|
* bugfix: disallow font size of 0Kartik K. Agaram2023-03-171-2/+4
| | | | Thanks Mikoláš Štrajt.
* state validation in source editor as wellKartik K. Agaram2023-03-171-2/+24
|
* bugfixKartik K. Agaram2023-02-091-0/+1
| | | | | | | | | | | scenario: press ctrl+f, type in a string hit down arrow if needed until the screen scrolls press enter click with the mouse somewhere Before this commit the app would crash because cursor was above screen top.
* bugfixKartik K. Agaram2022-12-241-1/+1
| | | | | | | | | | | Scenario: make some edits, select some text, make some more edits. Press ctrl-z. Before this commit, undo would stop at the point of selection and previous edits would become unreachable. After this commit, both ctrl-z and ctrl-y seem able to span the point of selection.
* typoKartik K. Agaram2022-12-241-1/+1
|
* consistent names in a few more placesKartik K. Agaram2022-12-231-4/+4
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-15 15:53:40 +0000