[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:
>>>terminfo-definition-support.diff
>>> * 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.
Thanks,
Marco