Re: Several beginner-questions

[Marko Vojinovic]

On Wednesday 27 July 2011 06:40:30 Eli Zaretskii wrote:
> > From: Marko Vojinovic <vvmarko@gmail.com>
> > Date: Wed, 27 Jul 2011 03:57:05 +0100
> > 
> > I guess I wasn't clear enough. I have never used Emacs under DOS, and I
> > am not saying that there is any existing code to be backported. But I
> > did use other text editors under DOS (the rudimentary "Edit" editor
> > comes to mind), and most of them had the pull-down menus drawn in
> > ascii-art using various "graphics" characters (greater-than-128 codes of
> > ascii of the bios-provided font).
> 
> Emacs does as well, but only in its DOS build.  I was saying that
> someone should take that code and implement it for the Unix TTY.

Aha, ok. So I guess I was right to assume that this already exists, I just 
missed that it exists only for the DOS build. Understood. :-)

Unfortunately, as much as I would like to see those menus in Unix TTY, I don't 
think that I have enough knowledge to actually port the code. :-( Maybe one 
day...
 
> > I've never ever
> > seen any other text editor do that. Even the KMail composer that I'm
> > typing into right now counts the first column as "column 1"... I'm a bit
> > dissapointed that such a weird default counting was chosen
> 
> Most of the software you see today copycats Microsoft Windows GUI
> style, so it's no surprise they all look similar and different from
> Emacs.  Emacs predates all of them.  So if you want to talk about
> weird defaults, it's those other programs that are "weird" ;-)

Oh, but I didn't use "weird" in the "different from MS editors" sense, but in 
the "why would anyone want to count columns from zero?" sense. The fact that 
Emacs was designed before most other editors is something I appreciate, but it 
has nothing to do with the default being "weird" (tradition notwithstanding).

If it's too hard to reconfigure, then ok, I'll live with it, but... it's weird. 
;-)
 
> Take a look at tty-color-define, this is the function you want to
> use.  And please be sure to look more carefully the commentary and the
> code of the packages you are pointed to: they have all this
> information spelled out.  For example, term/xterm.el includes a
> function names xterm-register-default-colors, which shows how to
> associate color names with colors supported by the xterm.  You should
> do something similar, but with color names you want to use.

Ok, I think I resolved this issue. The point that I was missing was that the 
256 colors displayed by the terminal are not neccessarily RGB-equivalent to 
the 256 colors defined in the rgb.txt file.

So while color-name-rgb-alist variable contains the colors from rgb.txt, the 
list-colors-display doesn't display those colors, but the colors that the 
terminal actually supports, which might be different (and are, in my case). 
Those (actually used) colors are listed in tty-defined-color-alist, and I see 
that they have names like color-16, color-17, etc.

The problem is that those two sets of colors are different from each other, and 
the tty-colors.el infrastructure approximates the standard ones with the ones 
available. IOW, there is no unique way to rename "color-16" to the standard 
name from rgb.txt (what I was hoping to achieve), since this color isn't even 
defined there.

So, if I want to configure syntax highlighting using the colors that I actually 
see on the screen, it seems that the simplest way is to just stick to the 
"color-##" names and forget about rgb.txt. :-)

Thanks for the help, now I know what I'm doing. ;-)

Incidentally, the tty-colors.el is apparently already built in my default 
Emacs install, I didn't even need to load it separately. I just needed to 
understand that the colors I see on the screen are *not* the colors defined in 
rgb.txt. :-)

> > > See indent-tabs-mode and tab-width.
> > 
> > Ok, I have RTFM for those variables (and hopefully understood it), set
> > 
> > (setq-default indent-tabs-mode nil)
> > (setq-default tab-width 4)
> > 
> > in the .emacs, restarted Emacs, and when I press the TAB key in the
> > buffer, nothing happens.
> 
> What is your value of tab-always-indent?

If I set it to t, TAB does nothing. If I set it to nil, then it works as 
expected when I am in the middle of a line. However, if I am at the beginning 
of the line, I need to press it twice --- the first TAB is swallowed, the 
second TAB prints spaces.

So I guess nil is what I want. I'm just confused why it swallows the first TAB 
when it is at the beginning of the line? The description says:

If t, hitting TAB always just indents the current line.
If nil, hitting TAB indents the current line if point is at the left margin
or in the line's indentation, otherwise it inserts a "real" TAB character.

AFAICS, there is some 'procedure of indentation' that does nothing in my case, 
while inserting the "real" TAB character is replaced with the four spaces, as 
I wanted. So how is this indentation being done, if not by inserting tabs or 
spaces into a file? The first time I press TAB, the line is apparently just 
being internally "marked" as indented (without anything visible actually 
happening), and only then the second TAB actually inserts something into the 
buffer. Am I understanding this right?

Btw, sorry for spamming the list with these things, I'm just trying to learn 
some of this basic stuff... :-)

Best, :-)
Marko