Advanced tag completion concept
Are you missing a feature? Request its implementation here.
-
- Posts: 4
- Joined: Tue Mar 15, 2005 11:38 pm
Advanced tag completion concept
Hows this for an idea...
A delimiter specific function:
that monitors the progress of a tags completion.
ex: as you key in the tag name , the application is monitoring for certain character strokes like an '=' sign that you will obviously not have in a closing delimiter, hence the application will mark or close the closing delimiter appropriately with the '>' sign.
The actual process that will be watching the the opening delimiter as it is being created, will only have to cross reference a set library of character strokes, it should be a relatively simple job, as two processes could be run and one of them will be a conditional "if" statement, which you could accomplish with plain old "basic" programming syntax.
An equal to, or '=', precedes attributes, and we all know attributes and proporties, among a few other delimiter identification specific entities, will not be allowed in closing delimiters, so this is the hotspot.
A closing delimiter is severely more critical than an opening delimiter, because if the closing delimiter is not identically named to an openening delimiter, that delimiter is incorrect and so is the rest of the corresponding element, and document as well. This is the area which needs the greatest amount of attention, because it is the most obvious area and therefore, the most easily overlooked area.
Now as you change certain aspects of an opening delimiter, and/or a closing delimiter, a process should be able to identify as to whether or no a "tag" is an opener or closer delimiter and adjust accordingly...
- Looking for and finding a forward slash character in a tag obviously says that the delimiter in question is a closing tag, so any adjustments made to the delimiter name can be applied to the opening delimiter immediately, as the changes are being made to the closing delimiter.
- Now monitoring an opening delimiter will be a little more complicated than a closing delimiter, as the process in charge of monitoring changes, will have to be able to identify where the changes are being made in an opening delimiter...
The process will have to toggle, so to speak, let's say around my favorite key stroke, the equal to sign (=), determining quickly if the changes in progress are being made on the right or left side of the '='.
If the changes are to the right side of the '=', then no changes are made to the closing delimiter, because there are no attributes or properties and the like allowed in the closing delimiter in the first place.
The work comes in when changes are being made to the left of the'=' in an opening delimiter, because it is then that it is not so cut and dry...
The process monitoring for changes, recognizing that changes are being made to the opening delimiter all before the '=' will now have to look for colons (:) and the like to once again asses as to whether or not that changes are actually being implemented to the actual delimiter name of the opening tag.
Somewhere in this confusing mess I just typed lies the answer, I think, for a relatively intelligent and responsive automated delimiter completion system.
Good hunting and God's speed...
ROBB
A delimiter specific function:
that monitors the progress of a tags completion.
ex: as you key in the tag name , the application is monitoring for certain character strokes like an '=' sign that you will obviously not have in a closing delimiter, hence the application will mark or close the closing delimiter appropriately with the '>' sign.
The actual process that will be watching the the opening delimiter as it is being created, will only have to cross reference a set library of character strokes, it should be a relatively simple job, as two processes could be run and one of them will be a conditional "if" statement, which you could accomplish with plain old "basic" programming syntax.
An equal to, or '=', precedes attributes, and we all know attributes and proporties, among a few other delimiter identification specific entities, will not be allowed in closing delimiters, so this is the hotspot.
A closing delimiter is severely more critical than an opening delimiter, because if the closing delimiter is not identically named to an openening delimiter, that delimiter is incorrect and so is the rest of the corresponding element, and document as well. This is the area which needs the greatest amount of attention, because it is the most obvious area and therefore, the most easily overlooked area.
Now as you change certain aspects of an opening delimiter, and/or a closing delimiter, a process should be able to identify as to whether or no a "tag" is an opener or closer delimiter and adjust accordingly...
- Looking for and finding a forward slash character in a tag obviously says that the delimiter in question is a closing tag, so any adjustments made to the delimiter name can be applied to the opening delimiter immediately, as the changes are being made to the closing delimiter.
- Now monitoring an opening delimiter will be a little more complicated than a closing delimiter, as the process in charge of monitoring changes, will have to be able to identify where the changes are being made in an opening delimiter...
The process will have to toggle, so to speak, let's say around my favorite key stroke, the equal to sign (=), determining quickly if the changes in progress are being made on the right or left side of the '='.
If the changes are to the right side of the '=', then no changes are made to the closing delimiter, because there are no attributes or properties and the like allowed in the closing delimiter in the first place.
The work comes in when changes are being made to the left of the'=' in an opening delimiter, because it is then that it is not so cut and dry...
The process monitoring for changes, recognizing that changes are being made to the opening delimiter all before the '=' will now have to look for colons (:) and the like to once again asses as to whether or not that changes are actually being implemented to the actual delimiter name of the opening tag.
Somewhere in this confusing mess I just typed lies the answer, I think, for a relatively intelligent and responsive automated delimiter completion system.
Good hunting and God's speed...
ROBB
-
- Site Admin
- Posts: 2096
- Joined: Thu Jan 09, 2003 2:58 pm
Hi Robb,
What you describe seems to be the Rename element action that is already present in the contextual menu under the XML Refactory submenu. It can be activated when you have the caret either inside a start tag or in an end tag. The default shortcut is CTRL+ALT+R (ALT+META+R on Mac) but you can configure a different one from the Preferences dialog.
The end tag is automatically completed to match the start tag either when you enter it once you type the / or when you invoke content completion on request (CTRL+Space).
Oxygen knows exactly at any moment where the start and end tags are located otherwise it could not have the Outliner. We discussed about having the end tag and the start tag changed when either of the two is modified but we decided for the current Rename element action instead because when the start and end tags are not both visible at the same time changing the other when one of them is modified will be hidden to the user and may be unexpected for some users. Also having this in a specific action allowed us to add in some more funtionality like renaming also the sibling elements with the that name or all the elements with that name. Next release will also offer proposals for the new name similar with what we have now for the "Surround with..." action.
Best Regards,
George
Best Regards,
George
What you describe seems to be the Rename element action that is already present in the contextual menu under the XML Refactory submenu. It can be activated when you have the caret either inside a start tag or in an end tag. The default shortcut is CTRL+ALT+R (ALT+META+R on Mac) but you can configure a different one from the Preferences dialog.
The end tag is automatically completed to match the start tag either when you enter it once you type the / or when you invoke content completion on request (CTRL+Space).
Oxygen knows exactly at any moment where the start and end tags are located otherwise it could not have the Outliner. We discussed about having the end tag and the start tag changed when either of the two is modified but we decided for the current Rename element action instead because when the start and end tags are not both visible at the same time changing the other when one of them is modified will be hidden to the user and may be unexpected for some users. Also having this in a specific action allowed us to add in some more funtionality like renaming also the sibling elements with the that name or all the elements with that name. Next release will also offer proposals for the new name similar with what we have now for the "Surround with..." action.
Best Regards,
George
Best Regards,
George
Jump to
- Oxygen XML Editor/Author/Developer
- ↳ Feature Request
- ↳ Common Problems
- ↳ DITA (Editing and Publishing DITA Content)
- ↳ Artificial Intelligence (AI Positron Assistant add-on)
- ↳ SDK-API, Frameworks - Document Types
- ↳ DocBook
- ↳ TEI
- ↳ XHTML
- ↳ Other Issues
- Oxygen XML Web Author
- ↳ Feature Request
- ↳ Common Problems
- Oxygen Content Fusion
- ↳ Feature Request
- ↳ Common Problems
- Oxygen JSON Editor
- ↳ Feature Request
- ↳ Common Problems
- Oxygen PDF Chemistry
- ↳ Feature Request
- ↳ Common Problems
- Oxygen Feedback
- ↳ Feature Request
- ↳ Common Problems
- Oxygen XML WebHelp
- ↳ Feature Request
- ↳ Common Problems
- XML
- ↳ General XML Questions
- ↳ XSLT and FOP
- ↳ XML Schemas
- ↳ XQuery
- NVDL
- ↳ General NVDL Issues
- ↳ oNVDL Related Issues
- XML Services Market
- ↳ Offer a Service