-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add description of elision with apostrophe #40
Conversation
|
Arrrrrrrrrrrrggggggggggg! The xrefs in your commit were right, somehow the titles casing had been changed but when rebasing on master the diff tool show them capitalized. I have no idea why is that. Probably because your branch was based on a very old point in master history. This also means that I'll need to check how it compares to the latest version of the same doc. Ok, now I'll:
Sorry for the inconvenience. |
334a129
to
3f6d7a8
Compare
Ok, sorry for the inconvenient above, but the conflicts warning and the whole attempt to rebase lead me into confusion. Hopefully, no harm done. (still not sure what went wrong, probably during the rebase operation the diff tool was showing me some old version of the same doc on master, which still had the xrefs in all caps, mea culpa!). I've just fixed a typo and slightly edited a sentence:
Beside fixing the AN I've also changed it a little:
It's shorter and IMO more readable. Personally, I think that the original was far better:
for imparted is le mot juste in relation to commands (as they say ... you can make a cake 🍰, but baking one is always better). You can type all sort of things on the keyboard, including a command, but imparting is more specific (you can't impart a question, you can only type it or ask it). Why drop impart in favour of input in the first place? (there are not output commands anyhow — at least as of today we don't have IF works ordering us to do stuff 😜 — so commands are flowing in one direction only). |
Split paragraphs into one-sentence-per-line, as recommended in project guidelines.
Edit the new contents formatting to allowed typographic quotes and other formatting details. Also fix a couple of typos.
@thoni56, I couple of questions regarding merging these new contents... Beta7 Branch?Since the apostrophe elision is a new feature, currently only available in dev snapshots, and the Manual currently refers to Alan beta6, should the Alan version mentioned in the Manual be already changed to beta7? Or should we maybe create a new I've also noticed that some command line options have changed too, some probably when beta7 is released the section on command line switches might need revising before merging into master, and possibly some other parts of the document to. This last argument might confirm that having a dedicated What to you think? Extra NoteAlso, in this point of the text:
I would add a further clarification:
It's not a fundamental point (nor stricly realted to the topic) but it could be a good remainder of how all the different elements fall together in the larger picture. |
- Add entries for "apostrophe, contraction" and "apostrophe, elision". - Convert concealed index terms into flow terms.
I actually tried to rebase locally before pushing but somehow git didn't show anything, so I was quite surprised when I saw the conflict. Had I seen that earlier I probably would have tried other approaches to get in line with master. Sorry about that. I'm not sure about the "beta7" question. Maybe just let this PR live until beta 7 is another option? Although that would probably increase the number of conflicts going forward. I'm not so fond of branches either since the have the same drawback. But I agree (as I interpret you) that master should be in sync with the latest release. Perhaps scheduling this PR for an upcoming, yet un-created, milestone would be sufficient. (Milestones are like labels, but you probably new that...) |
Done!
We can just avoid editing Manual contents in master branch and start working on individual topics on branches, then merge them all into a temporary Hopefully then, the bump to the next Alan Beta could also mark the first official release of the new Manual.
As long as they are not long-standig branches it should be fine. Also, currently the ported Manual is still referring to Beta 5 anywhow.
I don't understand that either, and I start to think that since the MS acquisition the GitHub default for Continuous Integration might have changed, and that message might actually be something to do with CI. Still can't work out why when I was locally rebasing it picked an older version of that same chapter, with the old Section titles convention instead of picking the latest one in master (could be an issue with the Git GUI though). |
In view of the upcoming Alan 3.0 beta7 release, we shall do all changes to the Manual in this `beta7-prep` development branch, which we'll then squash into master once beta7 is publicly available. Merge branch `handle_elisions` into `beta7-prep` and resolve conflicts on Chapter 5 source by using "theirs" stategy. (See #40 for a discussion on this)
Dev Branch for Beta7In view of the upcoming Alan 3.0 beta7 release, I've created a new I propose that from now on we shall do all changes to the Manual in this I've found a few small things I'd like to fix in the Manual, but I'd rather fix them now in a dev branch than wait for Beta7 to be out, or to work on That is, unless we agree to just merge right now the Delete
|
I think that sounds like a good plan. I've had a quick look at the elision description and that seems fine. So go ahead a delete that branch. I'll remember to make any documentation updates in the beta7-prep branch. OT: I got some warnings from
|
Me too (didn't see them before because my "watch" script suppresses STDERR"). I can't believe it, those errors are back. I thought I had solved them before the conflict resolution. I'll look into that and try to amend the situation. It's a nightmare solving conflicts with AsciiDoc files, the diff output is barely readable. I'll have to keep the branch until this is solved. |
Fix some cross references that were wrongly cased due to the merge of `handle_elisions` branch which still used to old naming convention for Manual sections. (See #40)
Ok, solved. This was actually my fault because I had forgot that your edited document was based on an older version of the Manual which used the old naming convention for Alan keywords in section titles. During my many local attempts to solve the conflicts I had manually edited them, but then when I finally did the changes on the remote branch I must have forgot to redo them (one of those situations where having done something many times makes you believe you did it also in the last edit, which wasn't the case). Apart from those cross-references, your edited text seems fine. I've checked a few sample of the current document and compared them to versions in the commit history, and it seems to reflect the latest changes. But if you check it once more I'd feel safer. Let's keep this branch until we merge everything from Beta7 into master, just to be on the safe side. |
Check. |
In view of the upcoming Alan 3.0 beta7 release, we shall do all changes to the Manual in this `beta7-prep` development branch, which we'll then squash into master once beta7 is publicly available. Merge branch `handle_elisions` into `beta7-prep` and resolve conflicts on Chapter 5 source by using "theirs" stategy. (See #40 for a discussion on this)
Fix some cross references that were wrongly cased due to the merge of `handle_elisions` branch which still used to old naming convention for Manual sections. (See #40)
No Need to Merge: Was Already Done in The Past!I'm manually sifting through the changes of this PR, and the more I look into it the more I think the elision changes were already merged into I believe these changes were integrated in commit 60e1a1d. But since the My understanding is that the changes affected only the following fies:
I've compared the commits diffs of that branch to the current status of |
Yes, A draftable.com comparison shows that both the current HEAD of So I'm closing this PR. |
In view of the upcoming Alan 3.0 beta7 release, we shall do all changes to the Manual in this `beta7-prep` development branch, which we'll then squash into master once beta7 is publicly available. Merge branch `handle_elisions` into `beta7-prep` and resolve conflicts on Chapter 5 source by using "theirs" stategy. (See #40 for a discussion on this)
Fix some cross references that were wrongly cased due to the merge of `handle_elisions` branch which still used to old naming convention for Manual sections. (See #40)
This PR contains a couple of things which probably should have been separated for cleanliness, but the major contribution is a description of the new elision/contraction feature.
It tries to explain that if the author defines
l´
as a definite article andaqua
as a noun then the player will be able to typel´aqua
and it will do the right thing.Live Preview links
These links are branch based, and will work even after force-pushing to the PR: