&#62; The idea is nice, and probably a step in the right direction, but<br />
&#62; `org-at-table-p&#39; and `org-table-align&#39; are not lightweight functions. In<br />
&#62; some common situations, e.g., when the table is a bit large, or when it<br />
&#62; is located away from the start of a section, typing in the table may<br />
&#62; feel sluggish.<br />
&#62;<br />
&#62; Therefore, I wonder if Org should include it unless it is optimized in<br />
&#62; most situations.<br />
<br />
Apparently, the code is more like a proof of concept, not a fully<br />
optimized solution. I didn&#39;t mean it should be included as is, rather<br />
the concept itself is very promising and provides a better user<br />
experience. As some of the commenters put it on reddit this is how<br />
they expected Org tables to work in the first place and I feel the<br />
same way.<br />
<br />
As for org-at-table-p being slow storing the start and end position of<br />
the table could be a solution, so if point is between them then there<br />
is no need to check org-at-table-p again.<br />
<br />
org-table-align seemed fast enough for me when I tried the posted<br />
code, but if it&#39;s slower for large tables then the code could measure<br />
the time it takes to perform the alignment for the current table and<br />
if it&#39;s above a certain threshold then it could introduce a bit of<br />
idle delay for the update, so it doesn&#39;t hold back the user from<br />
typing, and if the alignment is fast then it could perform the update<br />
without delay.<br />
<br />
Anyway, I think if implemented properly then this feature could be a<br />
worthy addition to org, even as default if it works well, because it&#39;s<br />
a much better user experience and a much better first impression for<br />
new users, instead of the current default fragile table which falls<br />
apart during typing and fixed only when TAB is pressed.<br />
<br />
&#160;