Currently, Equake tab information is largely encoded in the buffer name (in the form "EQUAKE[monitor-name]tabnumber%tabname" (e.g. EQUAKE[LVDS1]0%vterm01) with the order of Equake tabs stored in equake-tab-list (as a list of lists, where each inner list has its car the name/identifier of the display followed by integers representing the order of the tabs on that display). It might be desirable to implement a more sophisticated method of storing information about Equake tabs where all information (including tab order) was stored in a single location.
(E.g., one minor issue with the current representation is that user-assigned tab names which include % have weird behaviour since % is currently used as a 'field'-separator in the buffer-name representation of tab information.)
However, given that Equake tabs are buffers, and the user can interact with buffers outside of Equake (including deleting buffers which are Equake tabs), there is a sense in the current Equake information representation method. Though even now, updates to Equake-related buffers is handled through a hook equake-shell-after-buffer-change-hook attached to the built-in buffer-list-update-hook, so this could also be utilised for a theoretical new method of storing Equake tab information.
Currently, Equake tab information is largely encoded in the buffer name (in the form "EQUAKE[
monitor-name]tabnumber%tabname" (e.g.EQUAKE[LVDS1]0%vterm01) with the order of Equake tabs stored inequake-tab-list(as a list of lists, where each inner list has itscarthe name/identifier of the display followed by integers representing the order of the tabs on that display). It might be desirable to implement a more sophisticated method of storing information about Equake tabs where all information (including tab order) was stored in a single location.(E.g., one minor issue with the current representation is that user-assigned tab names which include
%have weird behaviour since%is currently used as a 'field'-separator in the buffer-name representation of tab information.)However, given that Equake tabs are buffers, and the user can interact with buffers outside of Equake (including deleting buffers which are Equake tabs), there is a sense in the current Equake information representation method. Though even now, updates to Equake-related buffers is handled through a hook
equake-shell-after-buffer-change-hookattached to the built-inbuffer-list-update-hook, so this could also be utilised for a theoretical new method of storing Equake tab information.