public inbox for [email protected]help / color / mirror / Atom feed
Autoformatting 6+ messages / 3 participants [nested] [flat]
* Autoformatting @ 2017-02-13 21:35 Raffi Holzer <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Raffi Holzer @ 2017-02-13 21:35 UTC (permalink / raw) To: pgadmin-hackers Hi Hackers, We are looking into auto formatting SQL text in the SQL editor. However, some users have expressed that this can be done in different ways. Are there preferences in this community fo rhow autoformatting should be done? -- Raffi Holzer Product Manager Pivotal Labs ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Autoformatting @ 2017-02-14 10:53 Dave Page <[email protected]> parent: Raffi Holzer <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Dave Page @ 2017-02-14 10:53 UTC (permalink / raw) To: Raffi Holzer <[email protected]>; +Cc: pgadmin-hackers Hi On Mon, Feb 13, 2017 at 9:35 PM, Raffi Holzer <[email protected]> wrote: > Hi Hackers, > We are looking into auto formatting SQL text in the SQL editor. However, > some users have expressed that this can be done in different ways. Are there > preferences in this community fo rhow autoformatting should be done? I think that really depends on the specific feature being discussed. For example, auto-indentation is very handy, and whilst it (and most formatting features) should be configurable, I suspect many people will leave it turned on. On the other hand, something like auto-upper-casing of keywords may be either automatic, or shortcut initiated, e.g. hit Ctrl+U to upper-case the word under the cursor. Perhaps you should start by listing the specific features? For reference, here's what pgAdmin 3 had: * The auto-indent feature will automatically indent text to the same depth as the previous line when you press return. * Block indent text by selecting two or more lines and pressing the Tab key. * Block outdent text that has been indented using the current tab settings using Shift+Tab. * Comment out SQL by selecting some text and pressing the Control+K. * Uncomment SQL by selecting some text starting with a comment and pressing Control+Shift+K. * Shift the selected text to upper case by pressing Control+U. * Shift the selected text to lower case by pressing Control+Shift+U. pgAdmin 4 currently has: * Auto-indent (not currently possible to disable it) I'd definitely like to see the rest (and anything else that seems useful) added, and made configurable where appropriate. I suspect the only ones that should be truly automatic are auto-indent and and upper-casing of keywords. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Autoformatting @ 2017-02-14 15:02 Raffi Holzer <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Raffi Holzer @ 2017-02-14 15:02 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: pgadmin-hackers Hi Dave, When we were talking about auto formatting we were actually referring to a single button press doing all of these things to a large block of text. The use case here would be if you receive a large illegible query and paste it into the query editor it would either automatically auto-format or you would press a button and it would auto-format. We are trying to determine a few things. One, are there preferred formatting guidelines and two, how should this autoformatting be implemented? On a button press? Upon pasting in the text? On Tue, Feb 14, 2017 at 5:53 AM, Dave Page <[email protected]> wrote: > Hi > > On Mon, Feb 13, 2017 at 9:35 PM, Raffi Holzer <[email protected]> wrote: > > Hi Hackers, > > We are looking into auto formatting SQL text in the SQL editor. However, > > some users have expressed that this can be done in different ways. Are > there > > preferences in this community fo rhow autoformatting should be done? > > I think that really depends on the specific feature being discussed. > For example, auto-indentation is very handy, and whilst it (and most > formatting features) should be configurable, I suspect many people > will leave it turned on. On the other hand, something like > auto-upper-casing of keywords may be either automatic, or shortcut > initiated, e.g. hit Ctrl+U to upper-case the word under the cursor. > > Perhaps you should start by listing the specific features? For > reference, here's what pgAdmin 3 had: > > * The auto-indent feature will automatically indent text to the same > depth as the previous line when you press return. > * Block indent text by selecting two or more lines and pressing the Tab > key. > * Block outdent text that has been indented using the current tab > settings using Shift+Tab. > * Comment out SQL by selecting some text and pressing the Control+K. > * Uncomment SQL by selecting some text starting with a comment and > pressing Control+Shift+K. > * Shift the selected text to upper case by pressing Control+U. > * Shift the selected text to lower case by pressing Control+Shift+U. > > pgAdmin 4 currently has: > > * Auto-indent (not currently possible to disable it) > > I'd definitely like to see the rest (and anything else that seems > useful) added, and made configurable where appropriate. I suspect the > only ones that should be truly automatic are auto-indent and and > upper-casing of keywords. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Raffi Holzer Product Manager Pivotal Labs ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Autoformatting @ 2017-02-15 09:37 Dave Page <[email protected]> parent: Raffi Holzer <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Dave Page @ 2017-02-15 09:37 UTC (permalink / raw) To: Raffi Holzer <[email protected]>; +Cc: pgadmin-hackers Hi On Tue, Feb 14, 2017 at 3:02 PM, Raffi Holzer <[email protected]> wrote: > Hi Dave, > When we were talking about auto formatting we were actually referring to a > single button press doing all of these things to a large block of text. The > use case here would be if you receive a large illegible query and paste it > into the query editor it would either automatically auto-format or you would > press a button and it would auto-format. Oh, OK. > We are trying to determine a few > things. One, are there preferred formatting guidelines Hmm, it seems I missed SQL when I wrote our (basic) coding standards: https://www.pgadmin.org/docs4/1.x/coding_standards.html By default (in my opinion), we should have 4 character indents, new lines for logically distinct objects (e.g. columns or constraints on a table), commas etc. at the end of the line, keywords in upper case, e.g. SELECT a, b, FROM t ORDER BY a, b; However, that obviously becomes unwieldy in some cases, so common sense is needed: SELECT a, b, FROM t ORDER BY a, b; There should of course be a limit on the number of columns listed per line - but should the limit be a count or max width in chars? With a CREATE TABLE statement I think it's clear that each column should be on it's own line: CREATE TABLE t ( a serial NOT NULL PRIMARY KEY, b text ); In other words, we need to define (or adopt) a formal standard for this, and then write a parser/formatter - which seems like a decidedly non-trivial amount of work (FYI, I tried the Python format-sql module, and it failed on ~80% of my tests - probably either because it doesn't understand COPY or pl/pgsql). > and two, how should > this autoformatting be implemented? On a button press? Upon pasting in the > text? Definitely not on pasting - if you drop in a large script, it could take far too long, plus you may not care, or be looking at the original source in another tool and trying to mentally reconcile lines or statements to each other. I would say it should be a button/shortcut. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Autoformatting @ 2017-02-15 14:39 Raffi Holzer <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Raffi Holzer @ 2017-02-15 14:39 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: pgadmin-hackers Thanks Dave! We came to the same conclusion about a button press. And thank you for the SQL guidelines. On Wed, Feb 15, 2017 at 4:37 AM, Dave Page <[email protected]> wrote: > Hi > > On Tue, Feb 14, 2017 at 3:02 PM, Raffi Holzer <[email protected]> wrote: > > Hi Dave, > > When we were talking about auto formatting we were actually referring > to a > > single button press doing all of these things to a large block of text. > The > > use case here would be if you receive a large illegible query and paste > it > > into the query editor it would either automatically auto-format or you > would > > press a button and it would auto-format. > > Oh, OK. > > > We are trying to determine a few > > things. One, are there preferred formatting guidelines > > Hmm, it seems I missed SQL when I wrote our (basic) coding standards: > https://www.pgadmin.org/docs4/1.x/coding_standards.html > > By default (in my opinion), we should have 4 character indents, new > lines for logically distinct objects (e.g. columns or constraints on a > table), commas etc. at the end of the line, keywords in upper case, > e.g. > > SELECT > a, > b, > FROM > t > ORDER BY > a, > b; > > However, that obviously becomes unwieldy in some cases, so common > sense is needed: > > SELECT > a, b, > FROM > t > ORDER BY > a, b; > > There should of course be a limit on the number of columns listed per > line - but should the limit be a count or max width in chars? With a > CREATE TABLE statement I think it's clear that each column should be > on it's own line: > > CREATE TABLE t ( > a serial NOT NULL PRIMARY KEY, > b text > ); > > In other words, we need to define (or adopt) a formal standard for > this, and then write a parser/formatter - which seems like a decidedly > non-trivial amount of work (FYI, I tried the Python format-sql module, > and it failed on ~80% of my tests - probably either because it doesn't > understand COPY or pl/pgsql). > > > and two, how should > > this autoformatting be implemented? On a button press? Upon pasting in > the > > text? > > Definitely not on pasting - if you drop in a large script, it could > take far too long, plus you may not care, or be looking at the > original source in another tool and trying to mentally reconcile lines > or statements to each other. I would say it should be a > button/shortcut. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Raffi Holzer Product Manager Pivotal Labs ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Autoformatting @ 2017-02-16 17:19 Shirley Wang <[email protected]> parent: Raffi Holzer <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Shirley Wang @ 2017-02-16 17:19 UTC (permalink / raw) To: Raffi Holzer <[email protected]>; Dave Page <[email protected]>; +Cc: pgadmin-hackers Hello! Attached are current designs for SQL autoformatting. This feature is not developed yet, only mockups of a potential solution so technical implementation is still being discussed. Style guide for autoformatting doesn't yet exist either, what's shown is manually formatted by another person. When a user highlights a section of text, a menu option appears below with the option to autoformat text. Not included in this current design: - other options available when highlighting multiple sections of text - compacting queries We're currently testing this design with pgAdmin3 users. Looking to validate with a few more before developing the feature. Let us know your thoughts! *1. Query pasted into text editor* [image: 16- unformatted query.png] *2. Query highlighted and autoformat option appears* [image: 17- query highlighted.png] *3. Query formatted* [image: 18- formatted query.png] On Wed, Feb 15, 2017 at 9:40 AM Raffi Holzer <[email protected]> wrote: > Thanks Dave! We came to the same conclusion about a button press. And > thank you for the SQL guidelines. > > On Wed, Feb 15, 2017 at 4:37 AM, Dave Page <[email protected]> wrote: > > Hi > > On Tue, Feb 14, 2017 at 3:02 PM, Raffi Holzer <[email protected]> wrote: > > Hi Dave, > > When we were talking about auto formatting we were actually referring > to a > > single button press doing all of these things to a large block of text. > The > > use case here would be if you receive a large illegible query and paste > it > > into the query editor it would either automatically auto-format or you > would > > press a button and it would auto-format. > > Oh, OK. > > > We are trying to determine a few > > things. One, are there preferred formatting guidelines > > Hmm, it seems I missed SQL when I wrote our (basic) coding standards: > https://www.pgadmin.org/docs4/1.x/coding_standards.html > > By default (in my opinion), we should have 4 character indents, new > lines for logically distinct objects (e.g. columns or constraints on a > table), commas etc. at the end of the line, keywords in upper case, > e.g. > > SELECT > a, > b, > FROM > t > ORDER BY > a, > b; > > However, that obviously becomes unwieldy in some cases, so common > sense is needed: > > SELECT > a, b, > FROM > t > ORDER BY > a, b; > > There should of course be a limit on the number of columns listed per > line - but should the limit be a count or max width in chars? With a > CREATE TABLE statement I think it's clear that each column should be > on it's own line: > > CREATE TABLE t ( > a serial NOT NULL PRIMARY KEY, > b text > ); > > In other words, we need to define (or adopt) a formal standard for > this, and then write a parser/formatter - which seems like a decidedly > non-trivial amount of work (FYI, I tried the Python format-sql module, > and it failed on ~80% of my tests - probably either because it doesn't > understand COPY or pl/pgsql). > > > and two, how should > > this autoformatting be implemented? On a button press? Upon pasting in > the > > text? > > Definitely not on pasting - if you drop in a large script, it could > take far too long, plus you may not care, or be looking at the > original source in another tool and trying to mentally reconcile lines > or statements to each other. I would say it should be a > button/shortcut. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > > > -- > Raffi Holzer > Product Manager > Pivotal Labs > Attachments: [image/png] 16- unformatted query.png (216.5K, 3-16-%20unformatted%20query.png) download | view image [image/png] 17- query highlighted.png (227.6K, 4-17-%20query%20highlighted.png) download | view image [image/png] 18- formatted query.png (224.1K, 5-18-%20formatted%20query.png) download | view image ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2017-02-16 17:19 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2017-02-13 21:35 Autoformatting Raffi Holzer <[email protected]> 2017-02-14 10:53 ` Dave Page <[email protected]> 2017-02-14 15:02 ` Raffi Holzer <[email protected]> 2017-02-15 09:37 ` Dave Page <[email protected]> 2017-02-15 14:39 ` Raffi Holzer <[email protected]> 2017-02-16 17:19 ` Shirley Wang <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox