It is not a good practice to keep a reference to the project's
directory object outside of the "core" module itself.
The TreeView was using such a reference in the cache item for each
file or directory entry. Replace the reference to the object with
the absolute name of the project directory.
Address issue:
https://github.com/lite-xl/lite-xl/issues/689
Attempt to provide a more accurate fix to commit:
59f64088e1
For this latter what happens is that any change inside a directory
cause the corresponding entry to be folded in the TreeView.
The new change is more accurate because we remove only the stale
entry corresponding to the delete event and we do not reset the
cache of the parent directory using the modify event.
Fix a problem introduced when fixing the dirty pixel problem, commit
cb08c5c. The node, when determining the layout was rounding the size
of the fixed-size view. In turns this latter was calling move_towards
to the default_size it wanted. If default_size was non-integer the
value vas never archieved because it was rounded during layout and
move_towars was keeping the editor busy by setting the
core.need_redraw flag.
The x size of the treeview plugin cannot really change expect if explicitly
resized.
The call to move_towards for x seems to raise a state where core.redraw is
always set to true and this prevent the application to go idle.
It is seen after the introduction of the dmon directory monitoring but it
is not clear why it wasn't seen before.
Some (probably lots) of people are used to tabbing through autocomplete.
now, tab is binded to autocomplete:cycle while enter is binded to
autocomplete:complete.
Before, if the indent wasn't fully detected, `detectindent` would try to
update every second. On files with very long lines this would cause
stutters.
Now the indent is updated only once after saving/reloading.
Brought form the 1.16.12 release.
It provides support for C++ using multi-part syntax patterns. Take
the priority over C language plugins for header files.
If the user manually set the desired scale by calling scale.set(1.60)
the scale_level was not set accordingly which meant that later doing
a Scale:Increase/Decrease command yielded incorrect scale amount.
Francesco Abbate
Adam Harrison
Guldoman
takase1121
Daniel Rocha
luarocks
jgmdev