kakoune/src/context.hh

244 lines
7.6 KiB
C++
Raw Normal View History

2011-11-26 19:32:57 +01:00
#ifndef context_hh_INCLUDED
#define context_hh_INCLUDED
#include "selection.hh"
#include "optional.hh"
2017-06-07 12:55:42 +02:00
#include "utils.hh"
2019-01-24 11:02:07 +01:00
#include <functional>
2011-11-26 19:32:57 +01:00
namespace Kakoune
{
class Window;
class Buffer;
2013-09-12 23:47:23 +02:00
class Client;
class Scope;
2013-11-14 19:09:15 +01:00
class InputHandler;
class DisplayLine;
2013-10-25 01:01:17 +02:00
class KeymapManager;
class AliasRegistry;
2013-01-28 13:48:34 +01:00
struct JumpList
{
void push(SelectionList jump, Optional<size_t> index = {});
const SelectionList& forward(Context& context, int count);
const SelectionList& backward(Context& context, int count);
void forget_buffer(Buffer& buffer);
friend bool operator==(const JumpList& lhs, const JumpList& rhs)
{
return lhs.m_jumps == rhs.m_jumps and lhs.m_current == rhs.m_current;
}
friend bool operator!=(const JumpList& lhs, const JumpList& rhs) { return not (lhs == rhs); }
size_t current_index() const { return m_current; }
ConstArrayView<SelectionList> get_as_list() const { return m_jumps; }
private:
using Contents = Vector<SelectionList, MemoryDomain::Selections>;
2016-10-11 00:20:05 +02:00
Contents m_jumps;
size_t m_current = 0;
};
using LastSelectFunc = std::function<void (Context&)>;
// A Context is used to access non singleton objects for various services
// in commands.
//
2014-03-20 09:10:31 +01:00
// The Context object links a Client, a Window, an InputHandler and a
// SelectionList. It may represent an interactive user window, a hook
// execution or a macro replay context.
2013-11-11 20:10:49 +01:00
class Context
2011-11-26 19:32:57 +01:00
{
2013-11-11 20:10:49 +01:00
public:
enum class Flags
{
None = 0,
Draft = 1,
};
friend constexpr bool with_bit_ops(Meta::Type<Flags>) { return true; }
Context(InputHandler& input_handler, SelectionList selections,
Flags flags, String name = "");
struct EmptyContextFlag {};
explicit Context(EmptyContextFlag);
~Context();
2012-09-26 14:27:23 +02:00
Context(const Context&) = delete;
2012-08-15 22:36:45 +02:00
Context& operator=(const Context&) = delete;
Buffer& buffer() const;
Allow to undo and redo selection changes From the issue: > It often happens to me that I carefully craft a selection with multiple > cursors, ready to make changes elegantly, only to completely mess it > up by pressing a wrong key (by merging the cursors for example). Being > able to undo the last selection change (even if only until the previous > buffer change) would make this much less painful. Fix this by recording selection changes and allowing simple linear undo/redo of selection changes. The preliminary key bindings are <c-h> and <c-k>. Here are some other vacant normal mode keys I considered X Y <backspace> <minus> # ^ = <plus> ' unfortunately none of them is super convenient to type. Maybe we can kick out some other normal mode command? --- This feature has some overlap with the jump list (<c-o>/<c-i>) and with undo (u) but each of the three features have their moment. Currently there's no special integration with either peer feature; the three histories are completely independent. In future we might want to synchronize them so we can implement Sublime Text's "Soft undo" feature. Note that it is possible to restore selections that predate a buffer modification. Depending on the buffer modification, the selections might look different of course. (When trying to apply an old buffer's selection to the new buffer, Kakoune computes a diff of the buffers and updates the selection accordingly. This works quite well for many practical examples.) This makes us record the full history of all selections for each client. This seems wasteful, we could set a limit. I don't expect excessive memory usage in practice (we also keep the full history of buffer changes) but I could be wrong. Closes #898
2022-08-15 22:21:53 +02:00
bool has_buffer() const { return not m_selection_history.empty(); }
Window& window() const;
bool has_window() const { return (bool)m_window; }
2013-09-12 23:47:23 +02:00
Client& client() const;
bool has_client() const { return (bool)m_client; }
2012-08-15 22:36:45 +02:00
2013-11-14 19:09:15 +01:00
InputHandler& input_handler() const;
bool has_input_handler() const { return (bool)m_input_handler; }
SelectionList& selections(bool update = true);
const SelectionList& selections(bool update = true) const;
2015-01-12 14:58:41 +01:00
Vector<String> selections_content() const;
// Return potentially out of date selections
SelectionList& selections_write_only();
Allow to undo and redo selection changes From the issue: > It often happens to me that I carefully craft a selection with multiple > cursors, ready to make changes elegantly, only to completely mess it > up by pressing a wrong key (by merging the cursors for example). Being > able to undo the last selection change (even if only until the previous > buffer change) would make this much less painful. Fix this by recording selection changes and allowing simple linear undo/redo of selection changes. The preliminary key bindings are <c-h> and <c-k>. Here are some other vacant normal mode keys I considered X Y <backspace> <minus> # ^ = <plus> ' unfortunately none of them is super convenient to type. Maybe we can kick out some other normal mode command? --- This feature has some overlap with the jump list (<c-o>/<c-i>) and with undo (u) but each of the three features have their moment. Currently there's no special integration with either peer feature; the three histories are completely independent. In future we might want to synchronize them so we can implement Sublime Text's "Soft undo" feature. Note that it is possible to restore selections that predate a buffer modification. Depending on the buffer modification, the selections might look different of course. (When trying to apply an old buffer's selection to the new buffer, Kakoune computes a diff of the buffers and updates the selection accordingly. This works quite well for many practical examples.) This makes us record the full history of all selections for each client. This seems wasteful, we could set a limit. I don't expect excessive memory usage in practice (we also keep the full history of buffer changes) but I could be wrong. Closes #898
2022-08-15 22:21:53 +02:00
void end_selection_edition() { m_selection_history.end_edition(); }
void undo_selection_change();
void redo_selection_change();
void change_buffer(Buffer& buffer, Optional<FunctionRef<void()>> set_selection = {});
void forget_buffer(Buffer& buffer);
2013-11-14 19:09:15 +01:00
void set_client(Client& client);
void set_window(Window& window);
2013-11-14 19:09:15 +01:00
Scope& scope() const;
OptionManager& options() const { return scope().options(); }
HookManager& hooks() const { return scope().hooks(); }
KeymapManager& keymaps() const { return scope().keymaps(); }
AliasRegistry& aliases() const { return scope().aliases(); }
FaceRegistry& faces() const { return scope().faces(); }
void print_status(DisplayLine status) const;
StringView main_sel_register_value(StringView reg) const;
const String& name() const { return m_name; }
void set_name(String name) { m_name = std::move(name); }
bool is_editing() const { return m_edition_level!= 0; }
void disable_undo_handling() { m_edition_level = -1; }
Allow to undo and redo selection changes From the issue: > It often happens to me that I carefully craft a selection with multiple > cursors, ready to make changes elegantly, only to completely mess it > up by pressing a wrong key (by merging the cursors for example). Being > able to undo the last selection change (even if only until the previous > buffer change) would make this much less painful. Fix this by recording selection changes and allowing simple linear undo/redo of selection changes. The preliminary key bindings are <c-h> and <c-k>. Here are some other vacant normal mode keys I considered X Y <backspace> <minus> # ^ = <plus> ' unfortunately none of them is super convenient to type. Maybe we can kick out some other normal mode command? --- This feature has some overlap with the jump list (<c-o>/<c-i>) and with undo (u) but each of the three features have their moment. Currently there's no special integration with either peer feature; the three histories are completely independent. In future we might want to synchronize them so we can implement Sublime Text's "Soft undo" feature. Note that it is possible to restore selections that predate a buffer modification. Depending on the buffer modification, the selections might look different of course. (When trying to apply an old buffer's selection to the new buffer, Kakoune computes a diff of the buffers and updates the selection accordingly. This works quite well for many practical examples.) This makes us record the full history of all selections for each client. This seems wasteful, we could set a limit. I don't expect excessive memory usage in practice (we also keep the full history of buffer changes) but I could be wrong. Closes #898
2022-08-15 22:21:53 +02:00
bool is_editing_selection() const { return m_selection_history.in_edition(); }
NestedBool& hooks_disabled() { return m_hooks_disabled; }
const NestedBool& hooks_disabled() const { return m_hooks_disabled; }
NestedBool& keymaps_disabled() { return m_keymaps_disabled; }
const NestedBool& keymaps_disabled() const { return m_keymaps_disabled; }
NestedBool& history_disabled() { return m_history_disabled; }
const NestedBool& history_disabled() const { return m_history_disabled; }
Flags flags() const { return m_flags; }
JumpList& jump_list() { return m_jump_list; }
void push_jump(bool force = false)
{
if (force or not (m_flags & Flags::Draft))
m_jump_list.push(selections());
}
template<typename Func>
void set_last_select(Func&& last_select) { m_last_select = std::forward<Func>(last_select); }
void repeat_last_select() { if (m_last_select) m_last_select(*this); }
Buffer* last_buffer() const;
private:
void begin_edition();
void end_edition();
int m_edition_level = 0;
size_t m_edition_timestamp = 0;
friend struct ScopedEdition;
Allow to undo and redo selection changes From the issue: > It often happens to me that I carefully craft a selection with multiple > cursors, ready to make changes elegantly, only to completely mess it > up by pressing a wrong key (by merging the cursors for example). Being > able to undo the last selection change (even if only until the previous > buffer change) would make this much less painful. Fix this by recording selection changes and allowing simple linear undo/redo of selection changes. The preliminary key bindings are <c-h> and <c-k>. Here are some other vacant normal mode keys I considered X Y <backspace> <minus> # ^ = <plus> ' unfortunately none of them is super convenient to type. Maybe we can kick out some other normal mode command? --- This feature has some overlap with the jump list (<c-o>/<c-i>) and with undo (u) but each of the three features have their moment. Currently there's no special integration with either peer feature; the three histories are completely independent. In future we might want to synchronize them so we can implement Sublime Text's "Soft undo" feature. Note that it is possible to restore selections that predate a buffer modification. Depending on the buffer modification, the selections might look different of course. (When trying to apply an old buffer's selection to the new buffer, Kakoune computes a diff of the buffers and updates the selection accordingly. This works quite well for many practical examples.) This makes us record the full history of all selections for each client. This seems wasteful, we could set a limit. I don't expect excessive memory usage in practice (we also keep the full history of buffer changes) but I could be wrong. Closes #898
2022-08-15 22:21:53 +02:00
friend struct ScopedSelectionEdition;
2018-07-25 12:57:47 +02:00
Flags m_flags = Flags::None;
SafePtr<InputHandler> m_input_handler;
SafePtr<Window> m_window;
SafePtr<Client> m_client;
Allow to undo and redo selection changes From the issue: > It often happens to me that I carefully craft a selection with multiple > cursors, ready to make changes elegantly, only to completely mess it > up by pressing a wrong key (by merging the cursors for example). Being > able to undo the last selection change (even if only until the previous > buffer change) would make this much less painful. Fix this by recording selection changes and allowing simple linear undo/redo of selection changes. The preliminary key bindings are <c-h> and <c-k>. Here are some other vacant normal mode keys I considered X Y <backspace> <minus> # ^ = <plus> ' unfortunately none of them is super convenient to type. Maybe we can kick out some other normal mode command? --- This feature has some overlap with the jump list (<c-o>/<c-i>) and with undo (u) but each of the three features have their moment. Currently there's no special integration with either peer feature; the three histories are completely independent. In future we might want to synchronize them so we can implement Sublime Text's "Soft undo" feature. Note that it is possible to restore selections that predate a buffer modification. Depending on the buffer modification, the selections might look different of course. (When trying to apply an old buffer's selection to the new buffer, Kakoune computes a diff of the buffers and updates the selection accordingly. This works quite well for many practical examples.) This makes us record the full history of all selections for each client. This seems wasteful, we could set a limit. I don't expect excessive memory usage in practice (we also keep the full history of buffer changes) but I could be wrong. Closes #898
2022-08-15 22:21:53 +02:00
class SelectionHistory {
public:
SelectionHistory(Context& context);
SelectionHistory(Context& context, SelectionList selections);
void initialize(SelectionList selections);
bool empty() const { return m_history.empty() and not m_staging; }
SelectionList& selections(bool update = true);
void begin_edition();
void end_edition();
bool in_edition() const { return m_in_edition; }
void undo();
void redo();
void forget_buffer(Buffer& buffer);
private:
enum class HistoryId : size_t { First = 0, Invalid = (size_t)-1 };
struct HistoryNode
{
HistoryNode(SelectionList selections, HistoryId parent) : selections(selections), parent(parent) {}
SelectionList selections;
HistoryId parent;
HistoryId redo_child = HistoryId::Invalid;
};
HistoryId next_history_id() const noexcept { return (HistoryId)m_history.size(); }
HistoryNode& history_node(HistoryId id) { return m_history[(size_t)id]; }
const HistoryNode& history_node(HistoryId id) const { return m_history[(size_t)id]; }
HistoryNode& current_history_node() { kak_assert((size_t)m_history_id < m_history.size()); return m_history[(size_t)m_history_id]; }
Context& m_context;
Vector<HistoryNode> m_history;
HistoryId m_history_id = HistoryId::Invalid;
Optional<HistoryNode> m_staging;
NestedBool m_in_edition;
};
SelectionHistory m_selection_history;
String m_name;
JumpList m_jump_list;
LastSelectFunc m_last_select;
NestedBool m_hooks_disabled;
NestedBool m_keymaps_disabled;
NestedBool m_history_disabled;
2011-11-26 19:32:57 +01:00
};
struct ScopedEdition
{
ScopedEdition(Context& context)
: m_context{context},
m_buffer{context.has_buffer() ? &context.buffer() : nullptr}
{ if (m_buffer) m_context.begin_edition(); }
~ScopedEdition() { if (m_buffer) m_context.end_edition(); }
Context& context() const { return m_context; }
private:
Context& m_context;
SafePtr<Buffer> m_buffer;
};
struct ScopedSelectionEdition
{
ScopedSelectionEdition(Context& context)
: m_context{context},
m_buffer{not (m_context.flags() & Context::Flags::Draft) and context.has_buffer() ? &context.buffer() : nullptr}
Allow to undo and redo selection changes From the issue: > It often happens to me that I carefully craft a selection with multiple > cursors, ready to make changes elegantly, only to completely mess it > up by pressing a wrong key (by merging the cursors for example). Being > able to undo the last selection change (even if only until the previous > buffer change) would make this much less painful. Fix this by recording selection changes and allowing simple linear undo/redo of selection changes. The preliminary key bindings are <c-h> and <c-k>. Here are some other vacant normal mode keys I considered X Y <backspace> <minus> # ^ = <plus> ' unfortunately none of them is super convenient to type. Maybe we can kick out some other normal mode command? --- This feature has some overlap with the jump list (<c-o>/<c-i>) and with undo (u) but each of the three features have their moment. Currently there's no special integration with either peer feature; the three histories are completely independent. In future we might want to synchronize them so we can implement Sublime Text's "Soft undo" feature. Note that it is possible to restore selections that predate a buffer modification. Depending on the buffer modification, the selections might look different of course. (When trying to apply an old buffer's selection to the new buffer, Kakoune computes a diff of the buffers and updates the selection accordingly. This works quite well for many practical examples.) This makes us record the full history of all selections for each client. This seems wasteful, we could set a limit. I don't expect excessive memory usage in practice (we also keep the full history of buffer changes) but I could be wrong. Closes #898
2022-08-15 22:21:53 +02:00
{ if (m_buffer) m_context.m_selection_history.begin_edition(); }
ScopedSelectionEdition(ScopedSelectionEdition&& other) : m_context{other.m_context}, m_buffer{other.m_buffer}
{ other.m_buffer = nullptr; }
Allow to undo and redo selection changes From the issue: > It often happens to me that I carefully craft a selection with multiple > cursors, ready to make changes elegantly, only to completely mess it > up by pressing a wrong key (by merging the cursors for example). Being > able to undo the last selection change (even if only until the previous > buffer change) would make this much less painful. Fix this by recording selection changes and allowing simple linear undo/redo of selection changes. The preliminary key bindings are <c-h> and <c-k>. Here are some other vacant normal mode keys I considered X Y <backspace> <minus> # ^ = <plus> ' unfortunately none of them is super convenient to type. Maybe we can kick out some other normal mode command? --- This feature has some overlap with the jump list (<c-o>/<c-i>) and with undo (u) but each of the three features have their moment. Currently there's no special integration with either peer feature; the three histories are completely independent. In future we might want to synchronize them so we can implement Sublime Text's "Soft undo" feature. Note that it is possible to restore selections that predate a buffer modification. Depending on the buffer modification, the selections might look different of course. (When trying to apply an old buffer's selection to the new buffer, Kakoune computes a diff of the buffers and updates the selection accordingly. This works quite well for many practical examples.) This makes us record the full history of all selections for each client. This seems wasteful, we could set a limit. I don't expect excessive memory usage in practice (we also keep the full history of buffer changes) but I could be wrong. Closes #898
2022-08-15 22:21:53 +02:00
~ScopedSelectionEdition() { if (m_buffer) m_context.m_selection_history.end_edition(); }
private:
Context& m_context;
SafePtr<Buffer> m_buffer;
};
2011-11-26 19:32:57 +01:00
}
#endif // context_hh_INCLUDED