mdBook icon indicating copy to clipboard operation
mdBook copied to clipboard

add option -no-indent to remove indentation

Open Salka1988 opened this issue 3 years ago • 16 comments

In this PR, I have added support for the new LinkType::IncludeNoIndent. This feature can be utilized with the Anchor syntax, such as {{#include file.rs:anchor_name:-no-indent}}, or with the Range syntax, {{#include file.rs::20:-no-indent}}.

Parsing is done in the same way as with the Range(LineRange) type. This means that if we use {{#include file.rs::20: 30}}, the command will not work until the whitespace between 20 and 30 is removed, resulting in 20:30. The same applies to the -no-indent command, {{#include file.rs::20: -no-indent}} will not work, while {{#include file.rs::20:-no-indent}} does.

The parsing process begins in the parse_include_path function where we check for the presence of the -no-indent command. Based on this, we return LinkType::IncludeNoIndent or only LinkType::Include.

If we have returned LinkType::IncludeNoIndent, the take_format_remove_indent function will find the part of the code closest to the left margin and move it to the left by that much space. The format of the code remains the same, with only the indentation being removed.

{{#include file.rs::20:30}}

Screenshot from 2023-01-23 14-16-07

{{#include file.rs::20:30:-no-indent}}

Screenshot from 2023-01-23 14-15-47

{{#include ../../../examples/providers/src/lib.rs:setup_test_blockchain}}

Screenshot from 2023-01-23 14-16-51

{{#include ../../../examples/providers/src/lib.rs:setup_test_blockchain:-no-indent}}

Screenshot from 2023-01-23 14-17-14

Salka1988 avatar Jul 14 '22 13:07 Salka1988

https://github.com/rust-lang/mdBook/issues/1601 https://github.com/FuelLabs/fuels-rs/issues/388

Salka1988 avatar Jul 17 '22 18:07 Salka1988

ehuss Hello, Hello :)

Salka1988 avatar Jul 20 '22 13:07 Salka1988

hi thanks. just give us some time we will review this :)

Dylan-DPC avatar Jul 20 '22 13:07 Dylan-DPC

Hi, I'm also having this problem - did this get merged?

Is the idea to remove all indentation from code snippets or only "extra" indentation? Hopefully, the latter.

sanity avatar Oct 24 '22 15:10 sanity

Hi, I'm also having this problem - did this get merged?

Is the idea to remove all indentation from code snippets or only "extra" indentation? Hopefully, the latter.

No.

Salka1988 avatar Nov 03 '22 18:11 Salka1988

Hi, I'm also having this problem - did this get merged? Is the idea to remove all indentation from code snippets or only "extra" indentation? Hopefully, the latter.

No.

Do you mean that it will remove all indentation, ie.

   fn test() {
      cat.foo();
   }

Becomes:

fn test() {
cat.foo();
}

Or (what I'm hoping):

fn test() {
   cat.foo();
}

sanity avatar Nov 03 '22 18:11 sanity

Hi, I'm also having this problem - did this get merged? Is the idea to remove all indentation from code snippets or only "extra" indentation? Hopefully, the latter.

No.

Do you mean that it will remove all indentation, ie.

   fn test() {
      cat.foo();
   }

Becomes:

fn test() {
cat.foo();
}

Or (what I'm hoping):

fn test() {
   cat.foo();
}

Second option. What you need too :)

Salka1988 avatar Nov 03 '22 18:11 Salka1988

Just pinging this thread to say that I've also run into this problem and would find this PR really useful when merged

rachitnigam avatar Dec 02 '22 18:12 rachitnigam

Do we expect this to get merged soon? If not I may create a fork to use in the meantime, this would solve some headaches.

sanity avatar Dec 13 '22 06:12 sanity

If you can test it and ensure that it works as ~~indented~~ intended, it will make it easier for us to review & merge :)

Dylan-DPC avatar Dec 13 '22 06:12 Dylan-DPC

🤣 I'll try to find some time.

sanity avatar Dec 13 '22 06:12 sanity

I would prefer to avoid adding an option for this. I would expect there to be one true behavior.

There's also PRs and issues about indentation (#1564, #1565, #1718). Whatever solution is taken, I would like to see a clear description of the issue and why a particular solution was chosen. This particular PR doesn't have much of a description.

Another thing to consider is the behavior around hidden lines.

ehuss avatar Dec 13 '22 13:12 ehuss

@ehuss @sanity @Dylan-DPC I added some description! Can you take a look?

Salka1988 avatar Jan 24 '23 08:01 Salka1988

Can you respond to the questions raised in https://github.com/rust-lang/mdBook/pull/1856#issuecomment-1348532278? Would it be possible to avoid requiring an option to determine the indentation behavior? Why choose this behavior over the other PRs?

ehuss avatar Jan 24 '23 13:01 ehuss

I think that in these PR (https://github.com/rust-lang/mdBook/issues/1564, https://github.com/rust-lang/mdBook/pull/1565, https://github.com/rust-lang/mdBook/pull/1718) indent commands are not optional. What will we do if the user likes the way MdBook currently formats the text? That's why I added a new option that is easy to use. There is an option to expand Include(PathBuf, RangeOrAnchor, "/ indent/no_indent /").

@ehuss

Salka1988 avatar Jan 24 '23 15:01 Salka1988

@salka1988 - thank you for working on this :)

Opt-in makes sense from the perspective of not breaking existing code, although for me I would prefer a way to set this flag globally for all {{#include}}s rather than for each individually.

Still, this would be a big improvement over not having this functionality.

This means that if we use {{#include file.rs::20: 30}}, the command will not work until the whitespace between 20 and 30 is removed, resulting in 20:30. The same applies to the -no-indent command, {{#include file.rs::20: -no-indent}} will not work, while {{#include file.rs::20:-no-indent}} does.

I understand there may be internal reasons for it, this is definitely going to generate bug reports without a helpful error message :)

sanity avatar Jan 24 '23 15:01 sanity

Just to add my opinion as a user here. The behaviour described in #1564 and #1626 is clearly incorrect so shouldn't require an option on the part of the user to get correct behaviour. The PR at #1718 implements exactly the solution that #1626 describes. So, if it were up to me, (which it clearly isn't :smile: ) I'd do the following:

  • Close #1626 as a duplicate of #1564; the latter is just a subset of the case described in the former
  • Close this PR in favour of #1718; as mentioned that PR requires no options and also includes test cases.

mattburgess avatar Sep 11 '23 19:09 mattburgess

Any progress on this PR?

julio4 avatar Dec 13 '23 14:12 julio4