pgadmin-org
Query Tool adds unwanted, seemingly arbitrary indentation
Using pgAdmin4 v8.4.
In the query tool, when pressing [Enter], the next line sometimes starts with indentation. It seems to follow some undisclosed formatting guide. But it's also inconsistent. Sometimes indenting 3 spaces (my chosen tab witdh?), sometimes (much) more, sometimes not at all. I couldn't fully make sense of the logic, yet. It's tedious and confusing.
There should be no indentation unless explicitly requested (possibly with an option in the settings?).
May or may not be connected to https://github.com/pgadmin-org/pgadmin4/issues/7276
The indentation is useful and saves time when writing pgsql code. We can add a preference though.
An option to disable / enable the addition of indentation would be most welcome, obviously. It will be important to distinguish between normal interaction and SQL formatting on demand (the currently broken [ctrl][shift][k]) - with accordingly clear separation in the preference settings.
I am also experiencing this. It's pretty frustrating.
I'm using:
Linux (Debian 12) desktop app, postgres 16.
What I experience (version 8.5) is: a tab adds the number of spaces registered in "Tab size" In my perspective it should add a number of spaces up to the next tab-position instead.
Giving a heads up to determine the number of space to add with explanatory comment aside
WITH
params AS
(
SELECT 13 cursor_pos
, 4 tab_size
)
SELECT (
div(cursor_pos,tab_size) -- determine the number of tab-positions already covered
+ 1 -- add one to calculate next tab-position
)
* tab_size -- the next tab-position to fill up to with spaces
- cursor_pos -- subtract the current position to obtain the number of space left
FROM params
@casparsch I'm not sure what example you're making here, but if I were writing that query, it would look something like this:
-- Note: Horizontal space (SP) == ASCII codepoint 32 == hex 0x20 == oct 0o40
-- In Python: 32 == int("0o20", 16) == int("0o40", 8)
-- Note: Comments refer to line/object below them, as standard practice dictates.
WITH params AS (
-- 4 x SP from start of line.
SELECT
-- 4 x SP from start of line + 4 X SP for readability.
-- After pressing "Enter" on the prior line, I would expect the next line to
-- start an equal distance from the SELECT keyword, regardless of any additional
-- hitespace following the keyword.
-- I am less worried about spacing between the value and label, with or without AS.
13 AS cursor_pos
-- 4 x SP from start of line and 3 x SP from comma.
, 4 AS tab_size
)
SELECT
-- 4 x SP from start of line + 4 X SP for readability.
-- Not sure why you have parantheses around this expresson since it isn't required,
-- though an alias would do well here.
div(cursor_pos, tab_size)
FROM params
@MarkMoretto The thing I wanted to express is to calculate the number of spaces to add to the current/cursor position to get to the next tab-position. See also my quote: "... to determine the >number of space to add< ..." Your code calculates the number of tab-positions (every "Tab size") exceeded/already passed.
I added it to this issue as this was about indenting text. Also I did not see the use of making another (new) issue for it. It is, for me at least, in the same area: formatting text (while editing in query-tool).
So meant as a kind of note to the developer who is going to pick this one up in some next release.
@casparsch Hi. Here's the first two lines in my SQL example:
-- Note: Horizontal space (SP) == ASCII codepoint 32 == hex 0x20 == oct 0o40
-- In Python: 32 == int("0o20", 16) == int("0o40", 8)
If that's too technical, see this.
So, how did you come to this conclusion:
"Your code calculates the number of tab-positions (every "Tab size") exceeded/already passed"
And, why are you adding nascent parentheses to your SQL select statement? That would probably fail in most instances. Before suggesting how to format SQL, learn how to write it.
@ casparsch
What I experience (version 8.5) is: a tab adds the number of spaces registered in "Tab size" In my perspective it should add a number of spaces up to the next tab-position instead.
Seems to be the same as I just described under this related issue: https://github.com/pgadmin-org/pgadmin4/issues/7269#issuecomment-2052678962
This seems to be related to the upgrade of CodeMirror from 5 to 6 that is included in pgAdmin 8.4. The "plain text" mode of the query editor is also non-functional: the setting is ignored.
The setting proposed by @adityatoshniwal and welcomed by @brsa is to me also encouraged.
For the functional part I would define it as:
- If the setting: "indent-next-line" is off, the cursor goes to the beginning of the next line
- If the setting: "indent-next-line" is on, the cursor goes to the next line with the same leading whitespace (tabs and spaces) from the previous line. So basically copy the whitespace upto the first non-whitespace-character
In both cases putting whatever was left after the cursor position of the previous line -- so before the event of creating the newline ("enter") -- on the new line at the position resulting from the calculation above (setting "on" or "off").
In the examples below I'm using the notation: "><" to indicate the current position of the cursor.
Like this for setting "off": Before:
12345><hjkl;
hitting the "Enter" resulting in: After:
12345
><hjkl;
... and for setting being "on": Before:
12345><hjkl;
hitting the "Enter" resulting in: After:
12345
><hjkl;
I only used spaces in the example because TAB-key jumps to the next control-element/html-element
Issue fixed and verified on snapshot build: https://www.postgresql.org/ftp/pgadmin/pgadmin4/snapshots/2024-06-18/ Environment: OS: macOs ventura 13.5.1 Package: arm64
Was able to install new pgAdmin version 8.9. I'm very happy with this issue being resolved . :top: