From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1EtWT1-0005P9-UA for mharc-grub-devel@gnu.org; Mon, 02 Jan 2006 15:39:43 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EtWSz-0005OO-Lw for grub-devel@gnu.org; Mon, 02 Jan 2006 15:39:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EtWSx-0005Nf-BD for grub-devel@gnu.org; Mon, 02 Jan 2006 15:39:41 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtWSx-0005NY-4U for grub-devel@gnu.org; Mon, 02 Jan 2006 15:39:39 -0500 Received: from [194.109.24.34] (helo=smtp-vbr14.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EtWU3-0006Up-Fq for grub-devel@gnu.org; Mon, 02 Jan 2006 15:40:47 -0500 Received: from localhost.localdomain (mgerards.xs4all.nl [82.92.27.129]) by smtp-vbr14.xs4all.nl (8.13.3/8.13.3) with ESMTP id k02Kbw0k049865 for ; Mon, 2 Jan 2006 21:37:58 +0100 (CET) (envelope-from mgerards@xs4all.nl) Mail-Copies-To: mgerards@xs4all.nl To: The development of GRUB 2 References: <43B1DD7E.5090905@omniflux.com> <87y8219p48.fsf@xs4all.nl> <43B984C7.6070502@omniflux.com> From: Marco Gerards Date: Mon, 02 Jan 2006 21:37:59 +0100 In-Reply-To: <43B984C7.6070502@omniflux.com> (omniflux+lists@omniflux.com's message of "Mon, 02 Jan 2006 12:53:43 -0700") Message-ID: <87zmmeicwo.fsf@xs4all.nl> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [PATCH] User definable terminfo support X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 20:39:42 -0000 Omniflux 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