* lispref/text.texi @ 2006-07-01 23:56 Richard Stallman 2006-07-02 7:53 ` lispref/text.texi Andreas Roehler 0 siblings, 1 reply; 7+ messages in thread From: Richard Stallman @ 2006-07-01 23:56 UTC (permalink / raw) Would someone please check lispref/text.texi for accuracy? It is a somewhat large file. If you check just half of it, that would be good; then I could look for someone else to check the other half. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: lispref/text.texi 2006-07-01 23:56 lispref/text.texi Richard Stallman @ 2006-07-02 7:53 ` Andreas Roehler 2006-07-02 11:55 ` lispref/text.texi Thien-Thi Nguyen 0 siblings, 1 reply; 7+ messages in thread From: Andreas Roehler @ 2006-07-02 7:53 UTC (permalink / raw) Cc: emacs-devel Richard Stallman schrieb: > Would someone please check lispref/text.texi for accuracy? > > It is a somewhat large file. If you check just half of it, > that would be good; then I could look for someone else to > check the other half. > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel > > As the text info probably is referred to widely by less experienced people - as me - I could go on reading it from this in so far inevitable point of view. As such an endeavour easily may end up by reporting a lot of errors which are none, we could agree to simply ignore reports in that case. Than it starts with text.texi Line 30 "Keep in mind that point is always between two characters, and the cursor appears on the character after point." Is this remark indeed necessary at this point? I don't remember a text-related command, where this is important. (Or should be important conceiving a text editing facility as a tool, which hides such internals from the user, unless he wishes otherwise.) Given the group of users indicated, I fear a certian danger of distraction and/or confusion from it. __ Andreas Roehler ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: lispref/text.texi 2006-07-02 7:53 ` lispref/text.texi Andreas Roehler @ 2006-07-02 11:55 ` Thien-Thi Nguyen 2006-07-02 18:21 ` lispref/text.texi Andreas Roehler 2006-07-02 22:30 ` lispref/text.texi Richard Stallman 0 siblings, 2 replies; 7+ messages in thread From: Thien-Thi Nguyen @ 2006-07-02 11:55 UTC (permalink / raw) Cc: emacs-devel Andreas Roehler <andreas.roehler@easy-emacs.de> writes: > "Keep in mind that point is always between two > characters, and the cursor appears on the character > after point." > > Given the group of users indicated, I fear a certian > danger of distraction and/or confusion from it. if we drop this, we will see more questions than now; more confusion arises from forgetting this detail, which properly can be considered as relating to the design of emacs, not just its implementation. anyway, the "group of users indicated" is people who wish to program emacs using emacs lisp, for which even a small bit of implementation detail can sometimes be considered as design detail. (they are more likely to blur the line, being programmers, and thus Confused By Choice.) i will look at text.texi this week, as well, starting from the end and working backwards (but "accumulating" forwards :-). thi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: lispref/text.texi 2006-07-02 11:55 ` lispref/text.texi Thien-Thi Nguyen @ 2006-07-02 18:21 ` Andreas Roehler 2006-07-05 18:03 ` lispref/text.texi Kevin Rodgers 2006-07-02 22:30 ` lispref/text.texi Richard Stallman 1 sibling, 1 reply; 7+ messages in thread From: Andreas Roehler @ 2006-07-02 18:21 UTC (permalink / raw) Thien-Thi Nguyen schrieb: > Andreas Roehler <andreas.roehler@easy-emacs.de> writes: > > >> "Keep in mind that point is always between two >> characters, and the cursor appears on the character >> after point." >> >> Given the group of users indicated, I fear a certian >> danger of distraction and/or confusion from it. >> > > if we drop this, we will see more questions than now; > more confusion arises from forgetting this detail, > which properly can be considered as relating to the > design of emacs, not just its implementation. > > anyway, the "group of users indicated" is people who > wish to program emacs using emacs lisp, for which even > a small bit of implementation detail can sometimes be > considered as design detail. (they are more likely to > blur the line, being programmers, and thus Confused By > Choice.) > > i will look at text.texi this week, as well, starting > from the end and working backwards (but "accumulating" > forwards :-). > > thi So maybe we will meet somewhere in the middle of text.texi. :) OK. To be serious: Will reflect this further. In any case it seems nothing to be done quickly before the release. Just let me - while reading forward this day - give a more detailed description of this question (a suspected intermix of meanings of `current', `at', `before' and `after') nonetheless. ;;; Let's see the description of `(point)': ... "Return value of point, as an integer." Assume we got a value of 10. If we now speak of an integer `beyond' that value, everyone would think of 11, 12 and so on. AFAIU `beyond' excludes the present. If we are here, we are not `beyond'. Now reading the text.texi: Docu `split-line' declares: This command splits the current line, moving the portion of the line after point down. Here is mentioned `after point' i.e. indeed `beyond'. So if (point) returned 10, I would assume pos with value 11 is affected. But what happens at the visual scene?: Just the char the point is on - the char whose position-value was returned by `(point)' - i.e. 10 in this example - is moved by `split-line.' I assume there are reasons to put it that way and also that there is no way to have all the benefits of this world united. Nonetheless I'm dreaming of a text-editing-world where `before' means `before visible point', the position lower than the value returned of (point) `after' a position greater than the value returned of (point) while `at' means just the position/char the visible point (cursor) is on. __ Andreas Roehler PS. Would be great to see an example where the point being in reality before the shown position matters - as far as text-editing functions are concerned. (As already written, my idea was to exclude that from this level or docu-part, but may be wrong here.) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: lispref/text.texi 2006-07-02 18:21 ` lispref/text.texi Andreas Roehler @ 2006-07-05 18:03 ` Kevin Rodgers 2006-07-05 18:46 ` lispref/text.texi Andreas Roehler 0 siblings, 1 reply; 7+ messages in thread From: Kevin Rodgers @ 2006-07-05 18:03 UTC (permalink / raw) Andreas Roehler wrote: > PS. Would be great to see an example where the point > being in reality before the shown position matters - as > far as text-editing functions are concerned. When point is at the beginning or end of the buffer, i.e. before the first character or after the last character, so that you can insert text before or after those characters resp. If text was always inserted before or after the character point was on [sic], you'd need a special way to handle the beginning and end of the buffer. -- Kevin ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: lispref/text.texi 2006-07-05 18:03 ` lispref/text.texi Kevin Rodgers @ 2006-07-05 18:46 ` Andreas Roehler 0 siblings, 0 replies; 7+ messages in thread From: Andreas Roehler @ 2006-07-05 18:46 UTC (permalink / raw) Kevin Rodgers schrieb: > Andreas Roehler wrote: >> PS. Would be great to see an example where the point >> being in reality before the shown position matters - as >> far as text-editing functions are concerned. > > When point is at the beginning or end of the buffer, i.e. before the > first character or after the last character, so that you can insert > text before or after those characters resp. If text was always inserted > before or after the character point was on [sic], you'd need a special > way to handle the beginning and end of the buffer. > Thanks responding this question. ,---- | File: text, Node: Insertion | | Inserting Text | ============== | | "Insertion" means adding new text to a buffer. The inserted text goes | at point--between the character before point and the character after point. `---- Understand from here, that the way to insert doesn't change. Only the location of the point after insertion - before or after inserted text - differs. So far still in the dark. __ Andreas Roehler ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: lispref/text.texi 2006-07-02 11:55 ` lispref/text.texi Thien-Thi Nguyen 2006-07-02 18:21 ` lispref/text.texi Andreas Roehler @ 2006-07-02 22:30 ` Richard Stallman 1 sibling, 0 replies; 7+ messages in thread From: Richard Stallman @ 2006-07-02 22:30 UTC (permalink / raw) Cc: andreas.roehler, emacs-devel > "Keep in mind that point is always between two > characters, and the cursor appears on the character > after point." > > Given the group of users indicated, I fear a certian > danger of distraction and/or confusion from it. This will not be changed, so please let's not discuss the issue. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-07-05 18:46 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-07-01 23:56 lispref/text.texi Richard Stallman 2006-07-02 7:53 ` lispref/text.texi Andreas Roehler 2006-07-02 11:55 ` lispref/text.texi Thien-Thi Nguyen 2006-07-02 18:21 ` lispref/text.texi Andreas Roehler 2006-07-05 18:03 ` lispref/text.texi Kevin Rodgers 2006-07-05 18:46 ` lispref/text.texi Andreas Roehler 2006-07-02 22:30 ` lispref/text.texi Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.