Is Allman/BSD indentation style supported?

[pierre-rouleau]

Hi @HaraldJoerg, thanks for writing this!

Is cperl-mode currently supporting the Allman/BSD indentation style?

I realize that K&R indentation style is the norm/preferred/PBP style, but I need to edit code that uses Allman/BSD style and don't want to modify it when I reformat some code using cperl commands such as cperl-indent-exp.

I could use perltidy integration but I want to prevent having formatting bouncing back and forth beween the K&R style and the Allman/BSD style when I have to edit old code that uses Allman/BSD style.

If this is not supported, do you have a suggestion as to best support it? I'm starting to look at the elisp code and if it is not supported I would like to add the ability to support it. I would add some new user-option, allowing customization to select between the K&R (default) and Allman/BSD.

[HaraldJoerg]

Hello @pierre-rouleau,

Regarding indentation, I would recommend to try the version of cperl-mode.el which comes with Emacs 30. It is available from the Emacs repository and also from the "upstream" branch in this repository.

In cperl-mode, you can select between different indentation styles. Currently the style as defined by Damian Conway in the book "Perl Best Practices" is probably the most popular one. Selecting a style can be done globally with the command cperl-set-style which supports a value of "BSD". Current versions of cperl-mode (shipped with Emacs 29) also have a command and customizable variable cperl-file-style which I would recommend for your use case: This variable can be used as a directory variable so that it only applies to projects using BSD style.

So far I have never used BSD indentation and can't comment on whether the "BSD" style fits the Allman recommendation. In any case, the way to adjust it to your expectations would be to tune the values of cperl-style-alist: inspecting that variable should make it clear how to add a completely new style as well!

[pierre-rouleau]

Thanks for the information @HaraldJoerg . On several systems I have to use Emacs 29 or earlier, so I'll try this repo's "upstream" branch first. My understanding (from your repo's readme) is that "upsearm" branch corresponds to the official Emacs plus some fixes. Does it correspond to what is in Emacs 30?

On the master branch I see that the cperl-style-alist holds the following for "BSD:

("BSD"
  (cperl-indent-level . 4)
  (cperl-brace-offset . 0)
  (cperl-continued-brace-offset . -4)
  (cperl-label-offset . -4)
  (cperl-continued-statement-offset . 4))

When I tried that it still placed the opening brace at the end of the statements as opposed to the next line at indentation level. What I'd like to see for the Allman/BSD style is something like this for example:

sub somefunc
{
    do_this;
    do_that;
    #....
}

Instead after selecting BSD from cperl-set-style, reformatting the code with cperl-indent-exp I still get what looks like K&R style:

sub somefunc {
   do_this;
   do_that;
   #....
}

Is this expected?

BTW;

• I compared the code in the master and upstream branches, and I did not see differences in the handling of style.
• I see that the BPB style is being tested. Are the other styles tested as well?

I'm going through the code and familiarizing myself with the various features. If the Allman/BSD support is not complete I can try to add support for it.

[HaraldJoerg]

The "upstream" version of this repository will go into Emacs 30, but work with 27 and newer. I found that cperl-file-style does not work as intended in cperl-mode.el shipped with Emacs 29 (long story in Emacs bug report 17948), but "upstream" should be fine.

Regarding the indentation: Do you have a recipe to reproduce the unwanted reformatting? As far as I see cperl-mode does not reformat subroutine headings at all: It leaves braces where they were. There are, however, separate customization options cperl-extra-newline-before-brace and cperl-extra-newline-before-brace-multiline which affect conditionals and loops. Maybe it is good enough to include these in the settings for BSD style? They were added to cperl-mode but commented out for BSD style in 1998 with a comment of "???", two decades before I started working on cperl-mode...

Regarding the BTWs: Most of the indentation code is old and has dark corners I do not fully understand. I wrote some tests for the PBP style when I added it - but have not touched the other styles: I do not know the expected behavior well enough.

[pierre-rouleau]

I did try to modify the cperl-extra-newline-before-brace for BSD and noticed it had an impact for code inside the subroutine but not the sub-routine block itself. I will try to read the code and understand what it does a little.

I really appreciate that you have taken the time to answer my questions. Hopefully I will have enough time to help. I'd really like to get this going, it would help me maintain some old Perl code I now have to deal with.

[pierre-rouleau]

Hi @HaraldJoerg , my impression of the cperl code implementation and its support for the various indentation style was done when styles were not as formally named and crystallized as they are today (although it'll probably remain a moving target as new programming languages come up). I'm guessing that the cperl code is probably missing variables to describe some aspects of some styles, as the focus was probably always what is most popular and described in Perl books: K&R derived style.

So I though I would start by putting example of all styles together quickly and identify the various aspects of these styles, mapping them to the existing cperl variable/user-options to see if there are any missing. Once the analysis completed I would probably look at adding documentation of the various styles and building test code for them. And then adding the required code once I understand better the cperl code.

For now, I started documenting the styles in a PDF file built as a table part of my system and using the same mechanism I already use: https://raw.githubusercontent.com/pierre-rouleau/pel/master/doc/pdf/lang/indentation-styles.pdf .

I know, ideally this would be written in a markup language (I would probably use reStructuredText) but for the other PDF pages I wrote for my projects there's just too much markup and I did not find any markup that allowed me to express everything I use, so I ended up using macOS Numbers to create the tables.

I will use that to perform the analysis and will then check if extra variables are required to express the various styles.

[pierre-rouleau]

Hi @HaraldJoerg ,
I noticed that the number of variables-value pairs in the cperl-style-alist varies from style to style. The number varies and the order of the entries is not always the same.

• From what I can see, all values should probably be set because otherwise changing the style would leave some of the variables set according to the values they had to support the previous style (or the last style that did set that variable).
• I also think the order of the entries should be consistent, always the same. I don't think the order is significant, and if it is it is always the same; therefore I think the lists should be sorted by the keys, to help consistency, detect missing entries and increase probability to detect that the order is significant somewhere in the cperl-mode code (if that's the case).

Would you agree if I re-ordered them?

I'm also thinking of adding one new variable, cperl-current-style-name, a list of name of the used indentation style. It would be set by cperl-set-style and cperl-set-style-back: the first pushes the style name, the second pops it. This way the current style would be the car of the list. I would also transform the cperl-old-style variable to be a stack of the non-named styles (named "Current"). That would allow stacking styles and poping them. To make it obvious to users that the behaviour of the style management changed I would rename the "Indent style/Memorized" menu to "Indent style/Previous" and would make it available whenever either cperl-old-style or cprel-current-style-name has something inside it.

The #21 PR includes the described changes. I see that test fail on those but it seems to be caused by other aspects of the master branch code I assume you have fixed in the code in the branch for Emacs 30.

Note that currently this probably applies globally, to all cperl-mode buffers. I wonder if it would not also be a good idea to provide the ability to control the style per buffer. But that would be for later.

[pierre-rouleau]

I agree that local buffer values are important. That was my next step. However, in the code that I have to deal with, there's unfortunately mixes of styles, probably caused by various instances of cut/paste programming. Having the ability to activate a style temporarily and going back to the original would help me in some cases.
The other reason I used to push/pop was to be able to report the name of the currently used style and to help me test the various styles while investigating style management code and updating it to support the styles it does not currently support.

I agree that probably most users are just storing the style they want inside their Emacs init file.
The way I deal with it is to use customization. I built my entire system around customization and that allows me to quicky transport settings. And I deal with 2 set of customization: one for terminal-based and one for GUI Emacs. My next step was to look for a way to identify the default style as a customization user-variable (either inside cperl-mode or outside in my PEL system) and use the customized value to set up the original when the Perl buffer is opened. This way I'd have the ability to have a default for all Perl files and the ability to modify it for any buffer (as well as going back and forth). The price to pay for the stack as opposed to just one copy is minimal since most of time only one will be used.

I will read the logic of the other branch.

BTW, in my PEL system I often have a command that prints the content of several variables for a specific buffer, inside a special buffer. The variables end up being buttons that can be used to open help and potentially to customize the values. I wrote one for the Perl cperl-mode variables used in indentation style management, which helped me analyze and test the code. I will add a link to it very soon after I push it and will add a link here.

The command is: pel-perl-show-status at https://github.com/pierre-rouleau/pel/blob/master/pel-perl.el#L191C8-L191C28

[pierre-rouleau]

I see that the 'upstream' branch uses a defcustom to identify the default indentation style, (that was available on version 29.1 and later) and the cperl-mode activates it unless the default (nil) is selected by customization.
I also see that the code uses setq-default and set-default-top-level-value.

Is there any reason why the code does not declare the cperl-file-style variable with defvar-local setting the initial value to what the customized variable holds? Would it not remove the need to set it inside cperl-mode? I am curious because I never had to use set-default-top-level-value and want to make sure I did not miss something in some of my own code. (I'm not criticizing the cperl-mode.el code).

As per next comment, I agree that the upstream branch code is better and I will deal with the indent mode manually instead of push/pop. So I can cancel my PR. Let me know.

[pierre-rouleau]

Hi @HaraldJoerg , I tried the 'upstream' branch again. Last time I tried I had reverted to master branch, now I really used the proper instance of the file. The BSD mode works better here. At least the electric behaviour of '{' on a sub-routine works properly.

So, as you suggested, I will use that upstream version of the code.

Now, If I want to make modifications to that, can I produce a PR for it? Or must I first do something to comply with the license?

[HaraldJoerg]

Is there any reason why the code does not declare the cperl-file-style variable with defvar-local setting the initial value to what the customized variable holds?

It is totally possible that there are other possible ways to do it: My grasp of Emacs lisp is not that deep. That's what I intended: The use of set-default-top-level-value allows to set the global default value. Changing a buffer-local variable with other commands would only change the value for that buffer.

So, as you suggested, I will use that upstream version of the code.

The reason why I recommend upstream is that Emacs is continuously evolving, and the Emacs developers take care for deprecations / modernizations. I am afraid that I have neither the time nor the knowledge to keep that up in this repositiory's master branch, so it might eventually fail to work. It was useful as a playground to support non-core Perl extensions like Zydeco, but unfortunately the approach I have been using turned out to be a technical dead-end.

Now, If I want to make modifications to that, can I produce a PR for it? Or must I first do something to comply with the license?

Yes, getting code into the Emacs repository needs a bit of paperwork: The owners want you to transfer the copyright to the Free Software Foundation. Here's a quote taken from the CONTRIBUTE file in the Emacs repository:

Once the cumulative amount of your submissions exceeds a dozen or so
lines of non-trivial changes, we will need you to assign to the FSF
the copyright for your contributions. (To see how many lines were
non-trivially changed, count only added and modified lines in the
patched code. Consider an added or changed line non-trivial if it
includes at least one identifier, string, or substantial comment.)
In most cases, to start the assignment process you should download
https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
and return the completed information to the address at the top.
(There are other assignment options, but they are much less commonly used.)
If you have questions about the assignment process, you can ask the
address listed on the form, and/or [email protected].

[pierre-rouleau]

Thanks!

[pierre-rouleau]

@HaraldJoerg I have a question related to the upstream version of the code and the default value of `cperl-file-style'.

• The cperl-file-style variable is a customizable user-option.
• The cperl-set-style interactive function, which can be invoked through the "Default Indent styles..." menu, sets that customizable user-option.

My questions:

• Does set-default-toplevel-valuealso updates the customization file? The docstring of set-default-toplevel-value does not describe that, and I don't think it does. I can see, from the customization buffer, that the value 'CHANGED outside Customize' which means the value used by the session has changed but this modification has not been saved into the Emacs customization file.
• Should it not also be saved into the customization file? Otherwise the "Default Indent styles..." selection will only last for the current Emacs session, it will not persist. Is this the intent?

[HaraldJoerg]

set-default-toplevel-value does not update the customization file: It is equivalent to choosing "For this session only" in customize. This is indeed intentional: If you want it to persist, use the customize-variable interface of Emacs. In my opinion the customize interface of Emacs should be the preferred way to make persistent changes to user options.

[pierre-rouleau]

Thanks for confirming. And I agree, the customize interface is what I use normally.