Skip to content

Support numbering custom nodes (Refactor numfig feature)#2317

Closed
tk0miya wants to merge 5 commits intosphinx-doc:masterfrom
tk0miya:1858_numbering_custom_elements
Closed

Support numbering custom nodes (Refactor numfig feature)#2317
tk0miya wants to merge 5 commits intosphinx-doc:masterfrom
tk0miya:1858_numbering_custom_elements

Conversation

@tk0miya
Copy link
Member

@tk0miya tk0miya commented Feb 14, 2016

I refactored numfig feature and improved it as a enumeration framework.
I introduced a new Sphinx API: Sphinx.add_enumerable_node. It is able to add new node which behaves as enumerable elements like figures.

This is instead of #1858. The differences between the PRs are:

  • Give an implicit API instead of node structure
  • Improve flexibility of obtaining the title of node (developers can specify its getter function)
  • Make numref implementation simple (repeated codes are unified)

I'm going to merge this in a few days. But I need reviews from anybody (because the change is little large).

Thanks,

@tk0miya tk0miya added type:enhancement enhance or introduce a new feature domains:std labels Feb 14, 2016
@tk0miya tk0miya added this to the 1.4 milestone Feb 14, 2016
@tk0miya tk0miya changed the title 1858 numbering custom elements Support numbering custom nodes (Refactor numfig feature) Feb 14, 2016
@shimizukawa shimizukawa self-assigned this Feb 14, 2016
@shimizukawa
Copy link
Member

OK, I'll take a look. (and please fix test failure)


Register a Docutils node class as a numfig target. Sphinx numbers the node
automatically. And then the users can refer it using :rst:role:`numref`.
figure, table or code-block. And then the node is numbered automatically.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that the last line is not needed.

@tk0miya tk0miya force-pushed the 1858_numbering_custom_elements branch from 03d6b55 to 281ec9a Compare February 14, 2016 04:12
return type.lname

def is_enumerable_node(self, node):
return node.__class__ in self.enumerable_nodes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to avoid derived enumerable nodes?
If we accept derived nodes, isinstance is good solution.

return isinstance(node, self.enumerable_nodes.keys())

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I understand. It must be intended.

@tk0miya tk0miya force-pushed the 1858_numbering_custom_elements branch from 281ec9a to 6330657 Compare February 14, 2016 05:39
@tk0miya
Copy link
Member Author

tk0miya commented Feb 14, 2016

@shimizukawa Thanks, I updated the docs :-)

@shimizukawa shimizukawa assigned tk0miya and unassigned shimizukawa Feb 14, 2016
@shimizukawa
Copy link
Member

LGTM!! image

@tk0miya
Copy link
Member Author

tk0miya commented Feb 14, 2016

Thank you for reviewing, I merged manually now.

@tk0miya tk0miya closed this Feb 14, 2016
@tk0miya tk0miya deleted the 1858_numbering_custom_elements branch February 14, 2016 05:53
@Jellby
Copy link
Contributor

Jellby commented Feb 14, 2016

That's great, thank you. Any change in usage with respect to #1858?

@tk0miya
Copy link
Member Author

tk0miya commented Feb 14, 2016

This does not refer figtype attribute on the nodes. The developers have to register them as enumerable nodes using Sphinx.add_enumerable_node.
After that, no special actions are required.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

domains:std type:enhancement enhance or introduce a new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants