From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5613 invoked from network); 17 Dec 2022 21:33:34 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 17 Dec 2022 21:33:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date:Content-ID: Content-Type:MIME-Version:Subject:To:References:From:In-reply-to:cc:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=gYKuLSx3rbfqABf51mJKpx3JVp2p9shHG3lpqMla1Pw=; b=Aolwbq7K5SOt1K/hmleBUnM4hZ cYk01Ng0qSZDDbomgTfpAg7MeKgu7iZ0e/hx0PuXzqgP6gxKuenvJyMZo68/DfjbexQxCQ0BDT05b 2SwbwT0Yz1uGYY0S5ZUL1FD2aUPkRQFl2wuw+7lET1GAti+kxIdcQICp3eR0WVHRaOSPCtZNDt01e OmJCR44LXu6mbpGtVBAaQx/cJK8/kAurn4EJq3Y2d788q8fRvG80mjHj5wUkOj5J2L6+jX5f5EkFm AeDKyNy5Fpi0Jtkgje/0wBb7JuINm/AHVjq+dL7tPzfSxV5HM1Rdzr+bttr0HKiiH1Jo9wy4jPJOr 2L9Xsfuw==; Received: by zero.zsh.org with local id 1p6eoI-0006Ry-4d; Sat, 17 Dec 2022 21:33:34 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1p6eo7-0006Aa-AQ; Sat, 17 Dec 2022 21:33:23 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.95) (envelope-from ) id 1p6eo6-00024O-KZ; Sat, 17 Dec 2022 22:33:22 +0100 cc: zsh workers In-reply-to: <527664940.183302.1671208973242@mail.virginmedia.com> From: Oliver Kiddle References: <527664940.183302.1671208973242@mail.virginmedia.com> To: Peter Stephenson Subject: Re: zsh_error_db --- hash-based database of error messages MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7958.1671312802.1@hydra> Date: Sat, 17 Dec 2022 22:33:22 +0100 Message-ID: <7959-1671312802.630649@JJwt.SU5o.2T2j> X-Seq: 51237 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: Peter Stephenson wrote: > Following on from the retread of the discussion on error messages, > here's a very simply proof of concept for a hash-based database of > error messages. Even if it's adopted I don't intend the C code > to get much larger as the point is to allow it to be able to do > everything in shell code. > > Apart from more user-friendly messages which someone with no > access to the C code can dedicate their life to tweaking, > this is obviously a boon for internationalization (which If we want to address internationalisation, we might come to regret not just using the normal POSIX catgets(3) interface and catalogue files. What they do looks simple on the surface but there's probably hidden areas of complexity that we'd end up duplicating. I can see the value of allowing things to be done in shell code but the two are not mutually exclusive. While error messages encompass the majority of strings that zsh ever needs to print there are some strings that aren't error messages. > Apart from updating the error message to examine the hash, the > only change is to prefix the error message format string with > the code such as "E3" and a colon. This would obviously > be done universally. E and a number sounds fine. I'm not keen on trying to encode file names such as ZW for zle_word.c because we may want to move code from one file to another in the future. If there's a need to divide things up, perhaps do something like 1000s for history, 2000s for zle, etc like we have for test cases. Parsing the E-number out of the string may be less flexible than adding an extra parameter and/or having a macro to wrap it. If duplicates are a concern scripts can be written to do checking or maybe some clever use of X macros. The best example for easy error messages I've come across is the Rust compiler. This quotes your code with highlighting and colours and finishes with a message like: For more information about this error, try `rustc --explain E0463`. So there are two levels of detail about an error available. If the only way to get friendly error explanations is to autoload functions and enable plugins, the type of users that will benefit from them will likely not find out about them until they're knowledgeable enough not to want them. Perhaps prompting with the explain invocation needs to be enabled by default with a setopt to turn that off. For people that do turn it off, a special parameter could store the number of the last error that was printed so that explanations can still be accessed. > The signatures of the format strings, i.e. where the % escapes > live, is checked for, though if there are cases where > we have more than a single letter code it'll fall over. > There's no provision for reordering escapes, either, but I > wouldn't expect to do that in an initial implementation anyway. Reordering is quite common for internationalisation. Our printf builtin does handle that with things like %2$s so we already have an implementation of parsing printf formats but directed at a rather aifferent purpose. Oliver