From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.devel Subject: Re: Introducing Master of Ceremonies, a package for presentations Date: Wed, 4 Dec 2024 11:45:57 +0900 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a2f22f062868c890" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17503"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Psionic K To: Emacs developers , Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 04 03:47:09 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tIfPw-0004Lo-Hq for ged-emacs-devel@m.gmane-mx.org; Wed, 04 Dec 2024 03:47:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tIfP9-00020H-Nh; Tue, 03 Dec 2024 21:46:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIfP5-0001zo-8k for emacs-devel@gnu.org; Tue, 03 Dec 2024 21:46:16 -0500 Original-Received: from mail-yb1-xb2e.google.com ([2607:f8b0:4864:20::b2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tIfP0-0000JX-0U for emacs-devel@gnu.org; Tue, 03 Dec 2024 21:46:13 -0500 Original-Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-e396e33d47dso5606362276.0 for ; Tue, 03 Dec 2024 18:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1733280368; x=1733885168; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QlbQdpztf6/7Bci59lf6NbFsbflg0vCXjymqUIvJvGs=; b=E5i1yen38LP+Sp7NKJv8r6lpY6600j8xCQj2lhNrdN1ZWsXsneeR+hgPn8yPmr/XE2 FY/VHWsVWW1LRkFVR7Y+7x8JLMXqc8BUy4sOphqfhiwP6q6KJP1HiVcz8bMMMfPU+8Lb KggsS5r4U+gi5tvLQLmMlihMXoSVO8madTBLiuosH+DT+6Jc5X9LvVoJsmrgBmEMb3Cq o1gyasqP/6CPwsM6vX8se4OpFjsjAvOvpQe3v2rRkU0V3hQ6YKu6Rq4C3yyj9DglGFo9 IiKmvwPB0+nSLrLk3hdzSQVe5uwJzWvQJExzqd2PYfboBHeWLpi1QMHLlRUmZaQJLtot KfBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733280368; x=1733885168; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QlbQdpztf6/7Bci59lf6NbFsbflg0vCXjymqUIvJvGs=; b=G8SkAI7NlxBOxbTVTq99vr6tEG2ymgyg2eKHdMhRvvEa1xTwNosTEJnwpeC8o20AgC TFqC75BFCDLB+v/UuyOEPdZXR+ey80wgjemhub3o8qLEySvDfn6qGj2QdUzGWh30T5Q/ HmflQpVfGtzww+VM4T2z5y1ndxDXY7CDA/I7qK7S4+jYGjE0lc+niDA6W/xJ9GgFH+dT /F75wnUCEwTPmZ5xP+HswtMn8S3zN5SOVhbMH9NYew7W6Tz2rL6gRmj1Bo+XB2dd9q4D fY8cOxl+GNNQ0J5x+RVKQ7tXPBPkHTFW921nWzQNobEPb28uO77KO8tG6JAzcPAhjehI B3ZQ== X-Gm-Message-State: AOJu0Yxq/+rl6D+0pl6HtHRcVGh2H3aBBe99dm1OEG8xLvJwu6e2exLG Yg81Vx6gd1cN6ajl8+t2YO1YiPG+8K+xjK0B1iYRAGLY/AldXoZrvAu1EBP1cB1C/Sa5QsbneAa IuhQkmHZU+IN198Y09sXCZtkomjh9BDyLtnjVngWtBeMZXngxj9Y= X-Gm-Gg: ASbGncvL/PTCD7LI3nq7ANKhPAd7oPlq7OM2aIn+R50I77vwuVBo6srz0/Qbco4WVtc R6neyz7T8wlY3j00OBDxGSnjn1GRxfINiww== X-Google-Smtp-Source: AGHT+IFbCr3BMe9btlbHNUT6rUjP77B4Vc4K2w8tLkusUTAN449QI38LoWiEMzoIU9v+JchN8Qy+DUSLO73KeqjWXj4= X-Received: by 2002:a05:6902:1a45:b0:e39:8792:e8cd with SMTP id 3f1490d57ef6-e39d3e35d9amr6256597276.23.1733280368084; Tue, 03 Dec 2024 18:46:08 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::b2e; envelope-from=exec@positron.solutions; helo=mail-yb1-xb2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326013 Archived-At: --000000000000a2f22f062868c890 Content-Type: text/plain; charset="UTF-8" I intend to submit Master of Ceremonies to Non-GNU ELPA. I'm deciding what changes are necessary to facilitate that and looking for low-hanging fruit to improve user results. - I'm likely to change the package file name and consequent naming over to mc. Please understand when this breaks use-package expressions. - Autoloads are being made for 29.4 since there is no stable 30.x release to target right now - Mark several customize variables as safe local variables - Generate a manual just to point users towards likely entry points like `mc-focus' and `mc-present' - More stable API for `mc-focus' playback The following architecture and feature changes are planned (this is as much rubber ducking as it is communication): One disappointment of mine that affects both dslide and mc is the lack of sufficient multi-monitor detection on XFCE even when xrandr is present. The feature I want to implement is to display a frame or presentation fullscreen on the "other" monitor because in dslide, the comments in the base buffer are visible and can be used for narration. At present, it appears I would need to interpret xrandr itself since the high-level interface Emacs ships with appears not to distinguish the two physical monitors when they are treated as a single virtual screen. Since we need a new frame either way, I may just do that for now and later add customize support to "guess" the correct location and fullscreen parameter of the new frame. All region selection for `mc-focus' will be re-architectured to normalize onto the rectangle selection case. The non-rectangle case will be translated internally to work like the rectangle case. The reason is that I need to support trimming and to "do the right thing" when the user begins the selection with indentation. The rectangle case is more general to every consequent problem. This path may also adapt to handle visual lines better, injecting newlines when the column exceeds the window column width. I've realized a common mc workflow of mine is to hide some text completely rather than just highlight substrings. Subsequently, un-hiding creates the effect of building up a larger expression with all text remaining fixed in place, invaluable when presenting code. The playback features of MC almost assuredly need keyword arguments. Display can be affected by the string, its text properties, overlays, and invisibility specs. One option is to merge all of the properties and overlays. A more flexible option for interactive explanation of display itself is to toggle the invisibility spec and overlays on the fly. This is unsupported during playback without retaining the "redundant" information of unmerged properties and overlays etc. I need to add support for propagating overlay priorities. Reducing all overlays is an option, but the rules for overlays that are fully contained etc are a bit tricky and I don't want to emulate all of the behavior within MC. Images in theory can work. The size of the image needs to be adjusted according to the scale of the text overlay. There could be edge cases. Any specified space used for centering would need to be adjusted. That holds for text as well. --000000000000a2f22f062868c890 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I intend to submit Master of Ceremonies to Non-GNU EL= PA.=C2=A0 I'm deciding what changes are necessary to facilitate that an= d looking for low-hanging fruit to improve user results.

=
- I'm likely to change the package file name and consequent = naming over to mc.=C2=A0 Please understand when this breaks use-package exp= ressions.
- Autoloads are being made for 29.4 since there is no s= table 30.x release to target right now
- Mark several customize v= ariables as safe local variables
- Generate a manual just to poin= t users towards likely entry points like `mc-focus' and `mc-present'= ;
- More stable API for `mc-focus' playback
The following architecture and feature changes are planned (thi= s is as much rubber ducking as it is communication):

One disappointment of mine that affects both dslide and = mc is the lack of sufficient multi-monitor detection on XFCE even when xran= dr is present.=C2=A0 The feature I want to implement is to display a frame = or presentation fullscreen on the "other" monitor because in dsli= de, the comments in the base buffer are visible and can be used for narrati= on.=C2=A0 At present, it appears I would need to interpret xrandr itself si= nce the high-level interface Emacs ships with appears not to distinguish th= e two physical monitors when they are treated as a single virtual screen.= =C2=A0 Since we need a new frame either way, I may just do that for now and= later add customize support to "guess" the correct location and = fullscreen parameter of the new frame.

All = region selection for `mc-focus' will be re-architectured to normalize o= nto the rectangle selection case.=C2=A0 The non-rectangle case will be tran= slated=20 internally to work like the rectangle case.=C2=A0 The reason is that I need= =20 to support trimming and to "do the right thing" when the user beg= ins the selection with indentation.=C2=A0 The rectangle case is more general to ev= ery consequent problem.=C2=A0 This path may also adapt to handle visual=20 lines better, injecting newlines when the column exceeds the window=20 column width.

I've realized a common mc workfl= ow of mine is to hide some text completely rather than just highlight subst= rings.=C2=A0 Subsequently, un-hiding creates the effect of building up a la= rger expression with all text remaining fixed in place, invaluable when pre= senting code.

The playback features of MC almo= st assuredly need keyword arguments.=C2=A0 Display can be affected by the s= tring, its text properties, overlays, and invisibility specs.=C2=A0 One opt= ion is to merge all of the properties and overlays.=C2=A0 A more flexible o= ption for interactive explanation of display itself is to toggle the invisi= bility spec and overlays on the fly.=C2=A0 This is unsupported during playb= ack without retaining the "redundant" information of unmerged pro= perties and overlays etc.=C2=A0 I need to add support for propagating overl= ay priorities.=C2=A0 Reducing all overlays is an option, but the rules for = overlays that are fully contained etc are a bit tricky and I don't want= to emulate all of the behavior within MC.

Ima= ges in theory can work.=C2=A0 The size of the image needs to be adjusted ac= cording to the scale of the text overlay.=C2=A0 There could be edge cases.= =C2=A0 Any specified space used for centering would need to be adjusted.=C2= =A0 That holds for text as well.
--000000000000a2f22f062868c890--