Hoe `window-end` te krijgen wanneer het venster scrolt?

Vanuit het document van window-end functie:

Zelfs als de update niet-nul is, probeert het venster-einde niet over het scherm te schuiven als het punt van het scherm is verwijderd, zoals bij echte weergave. Dit heeft geen invloed op de startwaarde van het venster. In feite meldt het waar de weergegeven tekst zal eindigen als scrollen niet nodig is.

Aangezien de window-end alleen rapporteert waar de weergegeven tekst eindigt als scrollen niet nodig is , wat moet ik doen om het juiste window-end nadat ik volgende regel aan het einde van het huidige venster heb aangeroepen, waardoor het venster op één regel wordt weergegeven? Heb ik iets nodig dat het venster dwingt opnieuw weer te geven voordat ik de functie window-end kan gebruiken?

3
IIUC die je gewoon niet kunt (behalve misschien door eerst een redisplay te forceren, bijvoorbeeld met (redisplay) . Hoogstwaarschijnlijk als je meer uitlegt over wat je probeert te doen, kunnen we je een beter antwoord.
toegevoegd de auteur sds, de bron
Ik weet niet wat "een bepaalde functie" is en weet ook niet waarom het de start/het einde van het venster moet weten en nog minder waarom het het nodig heeft tijdens de uitvoering van de volgende regel.
toegevoegd de auteur sds, de bron
Dan hoeft u daarvoor geen windowstart en window-end te weten. In plaats daarvan wilt u fontification-functions gebruiken die wordt aangeroepen in elk gedeelte van de buffer dat wordt weergegeven. Meestal wordt dit niet direct gebruikt, maar in plaats daarvan gebeurt het via jit-lock-register .
toegevoegd de auteur sds, de bron
Zie nlinum-modus (in GNU ELPA) voor een voorbeeld.
toegevoegd de auteur sds, de bron
@Stefan Ik probeer enige functie te implementeren in het pakket. Het probleem is dat ik het up-to-date windowstart en window-end moet kennen om alle zichtbare lijnen te krijgen, maar wanneer next-line zorgt ervoor dat het venster scrolt, deze venster grenzen zijn niet correct.
toegevoegd de auteur Mahesh, de bron
@Stefan Ik heb geen geluk om jit-lock-register te gebruiken. Na het registreren van een eenvoudige functie die alleen de parameters ervan afdrukt, lijkt deze niet te worden opgeroepen wanneer ik volgende regel gebruik om door het venster te scrollen. Kun je wijzen op een code die er gebruik van maakt? EDIT: het is meerdere keren aangeroepen met verschillende parameters bij het eerste bezoek aan een buffer.
toegevoegd de auteur Mahesh, de bron
Het moet het window-start en window-end weten omdat ik de visuele lijnen wil labelen. Wanneer volgende regel ervoor zorgt dat het venster scrolt, worden de visuele lijnen gewijzigd, dus we moeten de overlay dienovereenkomstig wijzigen.
toegevoegd de auteur Mahesh, de bron

1 antwoord

De beste die een gebruiker kan bereiken - zonder een vertoning te forceren of zonder de C-broncode te wijzigen - is de window-end -functie gebruiken met het optionele tweede argument ingesteld op t in combinatie met de venster-scroll-functies -haak waarvoor twee argumenten nodig zijn - https://www.gnu.org/software/emacs /manual/html_node/elisp/Window- Hooks.html#Window- Hooks [OPMERKING: een nieuw scherm dwingen kan met het blote oog (voor een fractie van een seconde) een onafgewerkt product onthullen - misschien hebben de nieuwe overlays bijvoorbeeld nog niet verwijderd/geplaatst.]

CAVEAT:  Beware that the window-scroll-functions hook fires sometimes more than once during each command loop (while redisplay performs its job), and the first values for window-start and window-end win t are not always correct, and the last values are not always correct either -- e.g., when inserting/yanking, or when using goto. [Fn 1.] When the window-scroll-functions hook runs multiple times, the function attached to the hook can cause significant performance issues depending upon the complexity of said function. And, as mentioned, sometimes the user is simply out of luck -- i.e., correct values can never be obtained. Using pos-visible-in-window-p can be helpful as a workaround to set up some checks to prevent the function attached to the hook from fully running its course if point is not yet fully visible; and, a variable can be set up to test for whether the function has already fully run one time during that command loop (so that it doesn't keep running).

Ik heb een draft proof concept-patch geschreven naar de C-broncode die ik gebruik voor mijn eigen persoonlijke instellingen om altijd het juiste windowstart en window-end < em> tijdens opnieuw weergeven; het kan echter nooit zijn weg vinden naar de mainstream omdat ik geen programmeur ben en de enige persoon echt gemotiveerd ben: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22404 Dit wordt het venster-start-einde-haak genoemd - - maar het is alleen beschikbaar als een gebruiker wil experimenteren met de concept-patch en Emacs vanaf de bron wil bouwen. Mijn concept-patch werkt ongeacht het scrollen van het venster, het werkt bijvoorbeeld bij een verplaatsingspunt binnen het zichtbare venster; het werkt bij het gebruik van goto ; het werkt bij het invoegen/rukken; en, het werkt tijdens het scrollen. Iedereen die geïnteresseerd is in het ontwikkelen van dat concept, moet alsjeblieft gerust een bericht sturen naar functieverzoek 22404.


Zie ook deze gerelateerde onderwerpen:

Hoe start ik het venster opnieuw zonder het opnieuw weergeven aan te roepen?

https://stackoverflow.com/questions/23923371/ emacs-berekening-new-window-start-end-zonder-weer zichtbaar/24216247 # 24216247


NOTE:  Debugging functions that run during redisplay may require using a feature called trace-redisplay (after launching Emacs from the command line) that is available when building Emacs from source with options such as: ./configure --enable-checking='glyphs'.


[Fn. 1.]:  When working with Bug #22637, Eli Z. on the Emacs development team explained that the reason the window-scroll-functions hook does not yield correct results for inserting/yanking or goto is because it was never designed for those scenarios: "The reason window-scroll-functions aren't run in both of these test cases is that what happens there is not considered 'scrolling'. Scrolling is informally defined as either an explicit call to a function that scrolls the window, or a pseudo-scroll done by the display engine when it detects that some part of the window's previous display is still present, but in a different vertical position. Moving point to an arbitrary location is neither." https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22637#35

3
toegevoegd
Om eerlijk te zijn, denk ik dat moet een gemakkelijke en directe manier zijn om dit op te lossen, en Emacs zou dat moeten bieden. Ik ben nogal verbaasd om te zien hoe ingewikkeld dit probleem is. Dus ik laat het ook open. Bedankt voor uw antwoord en uw inspanningen bij het oplossen van dit probleem.
toegevoegd de auteur Mahesh, de bron
Bedankt! Ik heb gehoord dat de code voor opnieuw weergeven van Emacs echt gecompliceerd is. Hoe dan ook, je bericht en @ abo-abo's opmerkingen in de gerelateerde thread geven genoeg hints voor een tijdelijke oplossing. Moet ik dit laten zoals het is of het martelen als opgelost? Misschien kan iemand anders ook soortgelijke problemen tegenkomen.
toegevoegd de auteur Mahesh, de bron
Mag ik vragen waarom window-start en window-end worden uitgevoerd voordat opnieuw wordt weergegeven ? Het klinkt raar omdat window-start en window-end afhankelijk moeten zijn van het huidige visuele gebied, dat wordt bepaald door redisplay . Waarom worden ze eigenlijk teruggebracht voordat het visuele gebied is bepaald? (Ik ken geen innerlijke magie van Emacs ...)
toegevoegd de auteur Mahesh, de bron
Vanuit het oogpunt van een ontwikkelaar kan ik niet zien wat dit probleem blokkeert om te worden opgelost. We mogen verwachten dat het window-start en window-end altijd de juiste waarden kan teruggeven - dat is wat deze functies zouden moeten doen. Ik zal de methoden die je hebt genoemd en de aanpak van abo-abo proberen.
toegevoegd de auteur Mahesh, de bron
Ik weet niet dat @ abo-abo al een soortgelijke vraag heeft gesteld! Eigenlijk heb ik dezelfde vraag als hij. Ik heb je bericht in die thread gelezen en het lijkt erop dat er nog geen elegante oplossing is. window-start-end-hook is goed, maar hoe kunnen we het functieverzoek doorsturen?
toegevoegd de auteur Mahesh, de bron
Anders dan het indienen van een gelijktijdige e-mail naar Eli Z. en ook het weergeven van 22404 in uw inbreng, weet ik niet wat er nog meer kan worden gedaan om de functie te realiseren. John zei dat hij niet direct CO2-gekopieerd hoeft te hebben omdat hij alle bug-e-mails leest. [Ik zou het zeker op prijs stellen als ik een kopie van de functie 22404-gerelateerde e-mails zou ontvangen, als u het niet erg vindt (aangezien ik niet regelmatig de nieuwste gebeurtenissen bekijk).]
toegevoegd de auteur lawlist, de bron
Het venster-begin-einde-haak vuurt volledig (dat wil zeggen, voert alle code uit) wanneer het punt volledig zichtbaar is, maar het heeft een ingebouwde code die kan worden gewijzigd om volledig te ontbranden wanneer punt is gedeeltelijk zichtbaar. Sommige gebruikers willen dat gedeeltelijk zichtbare vermogen - zie de doc-string voor de ingebouwde variabele make-cursor-line-fully-visible die kan worden ingesteld op nul , maar de standaardwaarde is t . Met andere woorden, mijn draft proof concept is geen eindproduct (het kan nog steeds wat TLC gebruiken) - maar ik gebruik het al een paar weken in mijn eigen opstelling en ben er erg blij mee.
toegevoegd de auteur lawlist, de bron
Eli Z. is bezorgd dat het toestaan ​​van een gebruiker om Lisp opnieuw te introduceren, ervoor kan zorgen dat Emacs vastloopt of crasht; hij heeft me echter ook begeleid naar het gebruik van safe_call , waarvan ik denk dat die bezorgdheid oplost, omdat de Lisp-functie zal worden geannuleerd als er een fout optreedt tijdens het opnieuw weergeven. Eli Z. geeft de voorkeur aan een laatste haak die hij de voorgestelde post-herdisplay-hook noemt; echter, ik geloof dat mijn oplossing beter is, omdat het een gebruiker toestaat om Lisp te introduceren die de lay-out wijzigt (bijvoorbeeld, een punt verplaatst of een tekengrootte vergroot) en opnieuw weergeeft, zal het voorlopige resultaat opnieuw controleren en meer werk doen indien nodig.
toegevoegd de auteur lawlist, de bron
Het probleem is dat opnieuw wordt weergegeven wat de nieuwe waarden voor vensterstart en window-end uiteindelijk zullen zijn - dat is een deel van zijn taak. Functies zoals vensterstart en window-end uitvoeren voordat opnieuw weergeven begint zijn proces (wanneer die nieuwe prospectieve waarden zijn nog steeds onzeker en/of onbekend) - dus een oplossing aan het einde van het scherm is vereist. [Lisp-foutmeldingen zijn niet beschikbaar tijdens opnieuw tonen, daarom is er iets nodig als trace-redisplay voor het opsporen van fouten.]
toegevoegd de auteur lawlist, de bron
Bijvoorbeeld, de venster-scroll-functies hook en de pre-redisplay-functie kunnen beide functies bevatten die eraan zijn gekoppeld en die de weergave veranderen - bijv. Een verplaatsingspunt of een verhoging/lettergrootte verkleinen. Dus opnieuw weergeven moet extra werk doen om erachter te komen wat het nieuwe venster-start en window-end uiteindelijk zal zijn. Het nieuwe concept concept window-start-end-hook kan ook functies bevatten die het punt verplaatsen of de tekengrootte vergroten/verkleinen, resulterend in een verandering in de waarden van window-start en window-end . De normale Lisp-functies alle uitvoeren voordat opnieuw weergeven begint.
toegevoegd de auteur lawlist, de bron
Wat betreft waarom Emacs doet wat het doet, ben ik slechts een programmeer-hobbyist (niet door handel) die pas onlangs de taal van C begon te leren voor het primaire doel van het implementeren van mijn eigen nieuwe Emacs-functies en/of nieuwe functies en aanpassingen voorstellen aan het ontwikkelteam van Emacs. Het is mij echter duidelijk dat we zeker iets nodig hebben zoals het venster-begin-eind-haak of een post-herdisplay-hook .
toegevoegd de auteur lawlist, de bron
Ik hou van aandacht voor deze kwestie, die een passie van mij is. Als je aangeeft dat het is opgelost, verliezen mensen hun interesse. abo-abo liet zijn vraag open, vermoedelijk omdat hij niet tevreden was met het antwoord of omdat hij een nieuwe functie wilde of omdat hij meer aandacht wilde voor deze kwestie. Mijn persoonlijke voorkeur zou zijn om deze vraag als een niet-geaccepteerd antwoord te laten, zodat het de aandacht trekt. Maar de beslissing is aan u - het is uw vraag en u hebt het ultieme antwoord op de vraag of er een bevredigende oplossing is. Ik heb geen haast om een ​​vinkje te krijgen :)
toegevoegd de auteur lawlist, de bron