Evan Aad

Hello. Which high-level programming languages have simple and consistent scoping rules, which can easily be described in a handful of words to people with no programming background such as tweens learning their first programming language?

@DanielN Seconly let's consider the case in which the overlay option was given to the tikzpicture environment. The environment maps the origin of its coordinate system to the bottom right of the last box that was positioned by the TeX typesetting algorithm, and the reports back to the TeX typesetting algorithm an empty box of size 0 width and 0 height.

@DanielN The algorithm treats this box as though it contained an alphabetic letter, determines the position of the box on the physical page accordingly, and reports the physical position of the box's bottom left corner back to the tikzpicture environment. This environment now maps the origin of its coordinate system to this physical point on the page, and draws the picture accordingly.

@DanielN First let's consider the case in which the overlay option was not given to the tikzpicture environment. The TikZ picture is drawn on a different, temporary page. Once drawn, the dimensions of the picture's bounding box are computed, and reported back to the TeX typesetting algorithm.

@DanielN After further thought and experimentation, I now have a theory as to why the overlay option causes a change of mapping of the local coordinate system to the physical page. My theory applies only to the case when the overlay option is passed to the tikzpicture environment; I don't know to explain the behavior when this option is passed to individual commands inside a tikzpicture environment. Here's the theory.

@samcarter_is_at_topanswers.xyz I've corrected the title.

@DanielN (continuing my last comment) This is why, when the overlay option is added to the tikzpicture environment in the code listed in my question, the red rectangle changes position: the overlay option changes the environment's local coordinate system, or more accurately, it changes the mapping of the environment's local coordinate system to absolute positions on the physical page.

@DanielN The million dollar question is: why does the overlay option cause this change of mapping? I don't have an answer to this question.

@samcarter_is_at_topanswers.xyz I've amended my question per your corrections. I hope now it's not misleading.

@DanielN And if the origins of these two systems of coordinates are mapped to two different points of the top level layer, then two distinct circles will get drawn.

@DanielN So, if you write \draw[overlay](0,0)circle(1cm); in two different tikzpicture environments, both circles will be drawn on the top layer, but possibly at different locations on the top layer: the first circle will be drawn about the point (0,0) w.r.t. the coordinate system set up locally by the first tikzpicture environment, whereas the second circle will be drawn about the point (0,0) w.r.t. the coordinate system set up locally by the second tikzpicture environment.

@DanielN What I think happens when you give the overlay option to a drawing command is that the command's drawing takes place in a layer that "sits" on top of all other layers. This layer is unique throughout a LaTeX document: if two commands in two different tikzpicture environments are given the overlay option, they both draw on the same top-level layer. However, different tikzpicture environments set up different systems of coordinates on this top layer. Those systems of coordinates are local to each tikzpicture environments.

@samcarter_is_at_topanswers.xyz Is every tikzpicture a pgfpicture?

@DanielN This trick changes the position of the red rectangle on the page. I don't wish the position of the TikZ picture to change. I simply want it to become visible in full.

Hi. I need help understanding a certain detail of a long proof in vol. 1 of Markushevich's "Theory of Functions of a Complex Variable". It's not something I can ask in a post, because that would require me repeating most of the proof, which is quite long. Is there anyone here who is familiar with this textbook who could help me?

@Manuel I don't always use the arg specs part (so I might define a function named \add rather than \add:nn for adding two literal integers), but when I do use arg specs, I always stick to the conventional meanings of the letters.

@JosephWright What am I supposed to learn from this example?

@JosephWright Ah yes. You're right. I see this now.

@JosephWright So any function that uses \group_begin: and \group_end: must be protected? This seems a tad harsh.

@JosephWright No I didn't know that. Thanks!

@JosephWright In reference to which question did you write "No", and in reference to which one did you write "Exactly"?

And defining a function as protected is tantamount to marking it with "no star", but there is no similar grammatical mechanism (such as a reserved word like protected) to mark a function with an unfilled or a filled star, right?

@JosephWright Thanks. I think I get it. So I can always define a function as protected, whatever functions it uses in its body, but only if uses only functions that are marked with either a filled or an unfilled star can I avoid defining it as protected (but I still can, if I want to). Right?

@JosephWright So if my function uses only functions that are marked with unfilled stars, should my function be protected or not? What if some of the functions are marked with unfilled stars, and some with a filled star (but all of them are marked with some kind of star)?

@JosephWright: Thanks. This is a very helpful tip. I was actually going to post a question about it. What about functions that are marked with an unfilled star? How do they affect this best practice guideline?

@JosephWright So the best practice is to always define a function as protected if it contains an assignment?

@Manuel: I don't understand what the problem is. For instance, suppose I wish to define a variable of type int, what problems might occur if I name it \amount_paid rather than \l_amount_paid_int?

@JosephWright: The problem with the \cs... functions is that I cannot assign to a variable of type cs an argument that is a control sequence that may not be defined. So in the above example, I couldn't make \f a variable of type cs.

@Manuel: I don't actually use ..._new inside functions. I use my own version, which is more like ..._clear_new but with a value assignment.

@Manuel: Because I like it better like this. I'll tell you another secret: I also don't follow the naming guidelines for functions and variable. I'm a real rascal!

@patrix I've found the solution! I'll post it as an answer to my original post.

Sorry for the delayed reply. On both computers echo $DISPLAY gives me /private/tmp/com.apple.launchd.---/org.macosforge.xquartz:0 where --- stands for a seemingly random combination of letters and digits. This combination is different on the "well-behaved" computer from the one obtained on the "rogue" computer.

@patrix I've installed XQuartz from xquartz.org . The "rogue" computer now has a /opt/X11 path. Unfortunately, as far as running Emacs from the Terminal there's no change. Emacs still starts inside the Terminal window as a console application.

@patrix The "well behaved" mac has /opt/X11. The "rogue" mac does not have /opt, let alone /opt/X11.

@patrix It works the same if I create a new user account (i.e. the Emacs GUI does not launch). The two macs probably don't have the exact same software installed. TeX is installed on both. As for X11, how can I tell if it is installed?

@patrix: If I run emacs & the Emacs process keeps running. It does not seem to terminate on its own after some time. It does not show up in the Cmd-Tab list. It is listed on the Activity Monitor list, but consumes 0.00 CPU time. It does not work if I run emacs -q & nor if I run emacs -Q &. If I execute emacs as a foreground process in the Terminal of the other, "well-behaved", computer, the Emacs GUI launches.

@patrix: Emacs starts inside the Terminal window as a console application.

@patrix: .emacs is the same: I've just copied it from the "well-behaved" computer to the "troublesome" computer.

@patrix: The result is emacs is /usr/local/bin/emacs on both systems.

@JosephWright: So the answer to my quesiton is "By convention", right? Because the variable will still be globally declared even if I do so inside a macro. So it's a matter of taste, not of grammar, whether I choose to declare the variable inside a function's body or not. The effect will be the same either way.

@Manuel: Why don't you declare new things inside macros? Is it by convention, or is there a more fundamental reason? Because I find it much more sensible to declare local variables inside the functions where the variables are expected to be used.

@egreg: I've added an example to my post. As for other languages, then, yes: in C# there are delegates, in C++ there are function pointers, in Perl there are function references, in Python any variable can later be set to a function object, likewise in Lisp, etc. etc.

@egreg: Yes. For instance, consider a LaTeX3 function \f:nN that expects two arguments: an integer, and a function. I'd like to give these parameters a name. So I start the function by declaring variables of type integer and control-sequence, and then I initialize them with the values passed as arguments.

@JosephWright: The problem with your suggestion is that (a) it doesn't look like the template for declaring and setting token lists, etc. (b) it necessitates defining a parameter list and a body, even if empty; which seems redundant. (c) You cannot use it with a construct like \tl_clear_new to avoid reporting an error in case the control-sequence is already defined.

@JosephWright: The same place that I'm going when I create a variable of type token list, or string, or sequence, or integer, and later set its value.

@egreg: Simply "control-sequence", then.

@JosephWright Since LaTeX3 programming is intended to supersede TeX/LaTeX2e programming entirely, it needs to be able to meet the needs of ad-hoc 'shortcuts' programming as well.

@JosephWright: If expl3 becomes a format, it will be impractical to use it to write regular documents because of the way whitespace is dealt with.

@DavidCarlisle: The problem is: it's not simply strings; it's strings embedded with commands, and I contend that it's not unusual, but rather very common, since the whole TeX/LaTeX language revolves around this very paradigm of text intermixed with commands, with the ability to extend the vocabulary of commands with user-defined commands.

@JosephWright: It doesn't make sense to me that I need to write a wrapper to a function that already exists. If this is indeed how LaTeX3 is supposed to be used, then these wrappers should be supplied by LaTeX3 itself to make it uniform and easy to use.