[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] User definable terminfo support

From: Marco Gerards
Subject: Re: [PATCH] User definable terminfo support
Date: Mon, 02 Jan 2006 21:37:59 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Omniflux <address@hidden> writes:

> Marco Gerards wrote:
>>>  * term/terminfo.c: Replaced static vt100 definition with user
>>>definable definition support.
>> Is it possible to do this in a GRUB env. variable, like:
>> set TERM=vt100
>> And perhaps one variable or function to set the possible terminal
>> descriptions.  I think that would be easier for the user to do it this
>> way.
> This is possible, however...
> The reason I chose to use a linked list allowing multiple terminal
> definitions was so multiple entries could be defined at load time,
> and, ideally, the user could then choose the correct one at boot.
> This would be helpful in cases where the choice of definitions is
> unknown to the entity creating the configuration, such as a live CD
> distribution or a generalized system recovery disk for computers
> without video cards.

Understood.  But I think you misunderstood me.

What I had in mind is:

TERM=vt100, or whatever can be used to select the terminal.  People
are used to this from the UNIX commandline.  Besides that, we prefer
having variables in GRUB instead of commands.

I was wondering if it would be easier to set terminfo descriptions
using variables as well.  For example:

set vt100='cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J'
(I just used some random stuff, but I assume you get the idea)

After that:
set TERM=vt100

That will read and parse the vt100 variable.  We can add several
pre-defined variables.

Hopefully my explanation makes sense.

> As to using an env. variable to select which terminal definition to use,
> I have not looked at the env. code. I doubt I can tie into the
> env. code to tell when the variable has changed, so this would leave
> the problem of no immediate user feedback if an invalid definition
> name is set.

It's possible.  You can define a call-back function for when a variable
is read from or written to.  So you can provide feedback (although I
wonder if it is sane to do), change stuff, etc.

> If you can point to a good place to provide this feedback, I see no
> problem with changing the selection code to use an environment
> variable instead, but I would like to keep support for multiple
> terminfo definitions.

Multiple terminfo definitions is nice.  That's what this patch was all
about, so I definately have nothing against that. ;-)

> Did I interpret your comments correctly?

Partially. ;)

I'm sorry for my terrible English.

>> give will be more useful than the feedback above...  Can you provide a
>> ChangeLog entry so the patch can be reviewed and applied?  See the GNU
> Should this be provided as part of the patch, or separate, but with
> the patch email?

Separate in the same email.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]