From mboxrd@z Thu Jan 1 00:00:00 1970 From: ndame Subject: Re: Automatic formatting of the table as you type Date: Fri, 27 Mar 2020 20:49:59 +0000 (GMT) Message-ID: References: <87sghtd3vw.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49088_1957578360.1585342199144" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39792) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jHvzF-0003Vw-VQ for emacs-orgmode@gnu.org; Fri, 27 Mar 2020 16:53:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jHvzE-0004Vi-Hz for emacs-orgmode@gnu.org; Fri, 27 Mar 2020 16:53:53 -0400 Received: from fmfe31.onbox.hu ([46.107.16.236]:32051 helo=web-out.onbox.hu) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jHvzE-0004UK-72 for emacs-orgmode@gnu.org; Fri, 27 Mar 2020 16:53:52 -0400 In-Reply-To: <87sghtd3vw.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: "emacs-orgmode@gnu.org" ------=_Part_49088_1957578360.1585342199144 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > The idea is nice, and probably a step in the right direction, but > `org-at-table-p' and `org-table-align' are not lightweight functions. In > some common situations, e.g., when the table is a bit large, or when it > is located away from the start of a section, typing in the table may > feel sluggish. > > Therefore, I wonder if Org should include it unless it is optimized in > most situations. Apparently, the code is more like a proof of concept, not a fully optimized solution. I didn't mean it should be included as is, rather the concept itself is very promising and provides a better user experience. As some of the commenters put it on reddit this is how they expected Org tables to work in the first place and I feel the same way. As for org-at-table-p being slow storing the start and end position of the table could be a solution, so if point is between them then there is no need to check org-at-table-p again. org-table-align seemed fast enough for me when I tried the posted code, but if it's slower for large tables then the code could measure the time it takes to perform the alignment for the current table and if it's above a certain threshold then it could introduce a bit of idle delay for the update, so it doesn't hold back the user from typing, and if the alignment is fast then it could perform the update without delay. Anyway, I think if implemented properly then this feature could be a worthy addition to org, even as default if it works well, because it's a much better user experience and a much better first impression for new users, instead of the current default fragile table which falls apart during typing and fixed only when TAB is pressed. =C2=A0 ------=_Part_49088_1957578360.1585342199144 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > The idea is nice, and probably a step in the right direction, but
> `org-at-table-p' and `org-table-align' are not lightweight functions. In
> some common situations, e.g., when the table is a bit large, or when it
> is located away from the start of a section, typing in the table may
> feel sluggish.
>
> Therefore, I wonder if Org should include it unless it is optimized in
> most situations.

Apparently, the code is more like a proof of concept, not a fully
optimized solution. I didn't mean it should be included as is, rather
the concept itself is very promising and provides a better user
experience. As some of the commenters put it on reddit this is how
they expected Org tables to work in the first place and I feel the
same way.

As for org-at-table-p being slow storing the start and end position of
the table could be a solution, so if point is between them then there
is no need to check org-at-table-p again.

org-table-align seemed fast enough for me when I tried the posted
code, but if it's slower for large tables then the code could measure
the time it takes to perform the alignment for the current table and
if it's above a certain threshold then it could introduce a bit of
idle delay for the update, so it doesn't hold back the user from
typing, and if the alignment is fast then it could perform the update
without delay.

Anyway, I think if implemented properly then this feature could be a
worthy addition to org, even as default if it works well, because it's
a much better user experience and a much better first impression for
new users, instead of the current default fragile table which falls
apart during typing and fixed only when TAB is pressed.

  ------=_Part_49088_1957578360.1585342199144--