Author Topic: Per project or per workspace formatting settings (again)  (Read 2369 times)

Zaphod

  • Junior Community Member
  • Posts: 9
  • Hero Points: 2
Per project or per workspace formatting settings (again)
« on: May 30, 2017, 04:12:44 pm »
Is there a way to have each workspace (or each project) store the "formatting" settings?  Specifically, Tools->Options->Languages->ApplicationLanguages->C/C++->Formatting.  I have several profiles defined with various combinations of spaces/tabs, tab settings, braces styles, etc., to match the various projects I work on.  Right now I need to remember when I've switched to a project that uses a different profile and then manually change formatting profiles.  Not a huge issue, but sure is a bother.  It would be nice to be able to save the formatting profile in the workspace/project file.

I found this post from 4 years ago:
https://community.slickedit.com/index.php/topic,8865.msg37903.html
which suggested creating project open hooks to change settings, but (back then) there was now way to change the profile, just individual settings.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5041
  • Hero Points: 418
Re: Per project or per workspace formatting settings (again)
« Reply #1 on: May 30, 2017, 04:55:29 pm »
Definitely worth doing. Now that the SlickEdit has a new layered configuration engine (.cfg.xml), we will need to move this up our todo list.

At the moment, you can tweak a few settings using the new .editorconfig support. It only supports a small subset of what the beautifier can do. You can change indent amount and whether to indent with tabs based on the directory the file is in.


mjdl

  • Senior Community Member
  • Posts: 142
  • Hero Points: 16
  • SE 24.0.0.8 hotfix 5 x64 Windows 10 x64 v1909
Re: .editorconfig support (Was: Per project or per workspace [...])
« Reply #2 on: June 01, 2017, 05:28:35 pm »
Last year I asked for details about .editorconfig support, particularly about how .editorconfig options and subsequent changes made in Slickedit options might be reconciled, and also if the .editorconfig file search algorithm and "root = true" property were part of the Slickedit implementation.

These questions were mostly answered (e.g. globbing), but since that time I haven't actually used the feature.

But maybe for the avoidance of all doubt and for future reference, can somebody who knows the feature well confirm that when the feature is enabled in General Editing settings:

1) Each time a file is opened or a new file created, any current .editorconfig settings for that file are searched for (using globbing and parent directories if necessary) and applied, and the equivalent settings in Slickedit Options are ignored;

2) Each time a file is opened, the search for .editorconfig settings starts in the file's directory and then moves up through parent directories until either the file system root is reached, or an .editorconfig file with the property "root = true" is reached.

makspyat

  • Junior Community Member
  • Posts: 3
  • Hero Points: 1
Re: Per project or per workspace formatting settings (again)
« Reply #3 on: June 04, 2017, 05:47:49 pm »
I also would like to ask SlickEdit developers to consider project formatting overrides. I also develop / maintain / contribute to multiple large projects and almost every project has its own coding conventions because people are well, so different :-)

In the meantime I am switching between few custom profiles when currently selected formatting rules get in a way (typically happens when I invoke auto completion).

It would be very nice to define it once and forget about all problems.
« Last Edit: June 04, 2017, 05:50:20 pm by makspyat »

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5041
  • Hero Points: 418
Re: Per project or per workspace formatting settings (again)
« Reply #4 on: June 09, 2017, 04:03:47 pm »
How best to implement beautifier profile overrides:

Implementing per project settings will likely be a performance problem since it could cause a fair bit of extra overhead when "edit" is called to open a file and it's called a ton. The issue is the time it takes to determine which project a file that is opened may be in and then fetch the settings. Also, a particular file could be in two different projects with two different settings. Worse yet, with a wildcard project, the wildcard file cache might not be up-to-date.

Here are a couple possibilities with pros and cons:

(not in any particular order).

Method A. Store beautifier profile overrides in the workspace

   Pros
       * Very simple for the user to configure
       * Very simple to Implement
   Cons
       * When a file is opened that is not in the current workspace, you will get the beautifier profile overrides when you don't want them.
       * When no workspace is open and you open a file from that workspace, you don't get your beautifier profile overrides
       * Not great if two projects in the workspace need different beautifier overrides.

      Note: There could be an option which only applies beautifier profile overrides for files under the workspace. This could help the Cons a little.

Method B. Store beautifier profile overrides in directories with your source files (like .editorconfig files)
Sample (.seeditorconfig.xml file)

<options root="1">
   <language n="language.c" version="1">
      <beautifier_default_profile v="abc"/>
   </language>
</options>

   Pros
      * Since beautifier profile overrides are stored with your source files, it doesn't matter what workspace/project is open. You still get the correct settings.
      * The .seeditorconfig.xml files should be checked in with your source files. That way, all SlickEdit users automatically get the correct settings.

   Cons
      * Not as easy for the user to configure. We can put together a GUI for it but it will only help some. If you have a file "/a/b/c/d", there can potentially be multiple .seeditorconfig.xml files, one in each directory. The "root" attribute specifies whether to continue searching up the directory tree (like .editorconfig). "1" means stop.
      * Only allows overrides per directory/directory tree and not individual files. The workspace solution doesn't work for individual files either though.

We've rolled around other ideas but these seem to be the best two.

Note that these methods only store the beautifier profile name and not a copy of the beautifier profile itself. There are pros and cons for that. Since users doing any kind of serious dev should really have a copy of their companies standard beautifier settings, just storing the name and avoiding a ton of data redundancy makes more sense.
« Last Edit: June 09, 2017, 07:14:52 pm by Clark »

mjdl

  • Senior Community Member
  • Posts: 142
  • Hero Points: 16
  • SE 24.0.0.8 hotfix 5 x64 Windows 10 x64 v1909
Re: Per project or per workspace formatting settings (again)
« Reply #5 on: June 10, 2017, 02:53:12 am »
Given the potential conflicts of storing different per-project beautifier settings for the same file, the .editorconfig solution of specifying file formatting information in a separate settings file in the directory (or parent directory) where the edited file is found seems better.

As I wrote above in this thread, simply ensure that, once such  .editorconfig type files are made active in SE's Options, anything specified in those options file (or parent files) overrides equivalent general formatting options, and then everyone will be able more or less to keep track of what's going on.

Maybe to make sure users can easily find out what formatting options are being applied, a UI similar to the adaptive format statistics dialog would show them  and the .editorconfig file where they were found... assuming that the SE .editorconfig feature is implemented as described in the standard. (Is it?)

Those kind of .ini format files arealso easier to read than XML, and easier to manage visually in version control scenarios.

Just my 0.2 cents...

UPDATE: Clark's posting below invalidates what I wrote above. Lack of analysis of wider SE application context, etc., etc...
« Last Edit: June 11, 2017, 06:04:08 pm by mjdl »

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5041
  • Hero Points: 418
Re: Per project or per workspace formatting settings (again)
« Reply #6 on: June 10, 2017, 03:12:07 am »
Using .editorconfig has pros and cons.

.editorconfig
Pros
   * can support a file pattern
Cons
   * can't specify a language. Must specify each extension. This is a bad problem. It also makes any GUI we write much worse. Maybe even not worth doing.
   * Pattern can't support additional options (.i.e attributes). It will be very useful to specify a non-recursive match. That way, you can match a single file in a specific directory when necessary.
   * Pattern used by .editorconfig files is not exactly the same as SlickEdit's ant-like syntax. This is both good and bad. It's bad because there are additional wildcard characters (like { and }) and no way to escape them. Braced "or" expressions can be useful though. SlickEdit's ant-like syntax depends on the platform. For example, brackets are not supported on Windows so that any valid windows filename can be specified.

.seeditorconfig.xml (we would still support .editoconfig files)
Pros
   * just specify the language and the profile. No need to specify a tone of file extension patterns.
   * easier to write a descent GUI
   * xml is a much better file format.
Cons
   * At first, we wouldn't bother supporting a file pattern in a GUI. Could add that later though.
« Last Edit: June 11, 2017, 01:56:29 pm by Clark »

timur

  • Senior Community Member
  • Posts: 147
  • Hero Points: 3
Re: Per project or per workspace formatting settings (again)
« Reply #7 on: November 12, 2018, 10:52:32 pm »
Has this feature been implemented in Slickedit 2018?  I also am forced to deal with multiple projects where no one can agree on how to write or manage code, so sometimes my C code is indented 4 spaces and sometimes it's indented with tab characters.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5041
  • Hero Points: 418
Re: Per project or per workspace formatting settings (again)
« Reply #8 on: November 12, 2018, 11:06:46 pm »
.seeditorconfig.xml has been implemented. Tools>Beautify>Beautifier Profile Overrides.

timur

  • Senior Community Member
  • Posts: 147
  • Hero Points: 3
Re: Per project or per workspace formatting settings (again)
« Reply #9 on: November 20, 2019, 08:55:32 pm »
I'm having trouble understanding how to use Beautifier Profile Overrides.  Can you give me an example of how I can create a profile for a single Project with different indentation settings than the standard C/C++ profile?

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5041
  • Hero Points: 418
Re: Per project or per workspace formatting settings (again)
« Reply #10 on: November 20, 2019, 09:14:03 pm »
I’m out of town this week. Otherwise I’d post a sample. When I get back, I’ll post a sample.

Zaphod

  • Junior Community Member
  • Posts: 9
  • Hero Points: 2
Re: Per project or per workspace formatting settings (again)
« Reply #11 on: November 21, 2019, 03:42:29 pm »
Hey, this thread popped back up, so I tried the beautifier override.  Maybe I don't understand how this is supposed to work, but it doesn't appear to do what I expected it to do.

I have in my top project/workspace level directory the following .seeditorconfig.xml, created via the GUI from Tools->Beautify->Beautifier Profile Overrides (hand typed here because the XML is on a non-networked PC):
Code: [Select]
<options>
  <language n="language.c">
    <beautifier_default_profile v="Allman Modified Tabs4"/>
  </language>
</options>
The default C/C++ formatting is set to "Allman Modified Tabs3" as that is what most of my projects use. 

I've closed the workspace and closed SE.  I open SE and then the project with the .seeditorconfig.xml file in its root.  Tabs still show as 3 not 4 spaces.  The Tools->Beautify defaults to "Allman Modified Tab3", though I can certainly use the "Beautify With" option to use the "Tabs4" variant.  I expected to open the project and have all (existing) tabs be 4 spaces.  Closing and re-opening the file makes no difference.  Typing new lines still uses the "Tabs3" settings.

SE version 24.0.0.6, 64-bit, Brief emulation (if it matters), 64-bit Win10.

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1201
  • Hero Points: 115
Re: Per project or per workspace formatting settings (again)
« Reply #12 on: November 21, 2019, 05:18:12 pm »
I can't reproduce that.  In the Tools -> Options dialog, under Editing -> General, and double check to make sure "Apply editorconfig and .seeditorconfig.xml settings" and make sure that using the seeditorconfig is enabled.   I believe that is off by default.

timur

  • Senior Community Member
  • Posts: 147
  • Hero Points: 3
Re: Per project or per workspace formatting settings (again)
« Reply #13 on: November 21, 2019, 05:53:15 pm »
I figured out how to create a formatting profile, but I don't see an option on how to apply that profile to a specific project.  For example, in one project code is indented with 4 spaces, whereas in another project it's indented with 8-space tabs.  I know I can switch profiles manually when I switch projects, but I'm hoping to avoid that.

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1201
  • Hero Points: 115
Re: Per project or per workspace formatting settings (again)
« Reply #14 on: November 21, 2019, 06:01:50 pm »
The profile applies to the files recursively underneath the location you saved the .seeditorconfig.xml file.   So if I've got a directory structure like this:
Code: [Select]
   src/
      main.cpp
   vendor/
      xlib/
         atom.c

If I created the .seeditorconfig.xml file under the vendor/ directory, then the overrides in that editor config file only occur for any source files from vendor/ and below.  In the src/ directory, the default profile is still used.  So main.cpp would use the default profile, and atom.c would use whatever overrided profile is specified in the seeditorconfig.xml.