Ace: Compatibilidade IOS

Nós sabemos, e isso será resolvido em breve. Obrigado pela sugestão!

você poderia procurar o patch para nós?

Também estou interessado no suporte para iOS (e particularmente para iPad).
Estou ansioso para ouvir sobre seu progresso nessa frente.

Você pode verificar o ramo do ipad. Ainda não está perfeito, mas pelo menos a digitação funciona. Use dois dedos para rolar.

Excelente, não tinha reparado no branch ipad.
Obrigado, vou dar uma olhada nisso!

O teclado não apareceu usando a ramificação do ipad. Usando o branch master ele mostra, mas há um bug com o posicionamento do cursor. : /

Esqueça o que eu disse! É legal que o teclado não tenha aparecido! Você pode escrever seu próprio teclado, muito mais amigável para os programadores e menos ocupando espaço. : o)

Teste no iPad com iOS 4.3; mestre atual não mostra o teclado ou o ponto de inserção e não rola verticalmente (posso rolar horizontalmente com dois dedos, se o texto for mais largo do que a área disponível).

O branch do iPad não é atualizado desde 3 de fevereiro ... testando, vejo que a rolagem vertical funciona com dois dedos (yay!), mas é muito lenta. Posso colocar o foco no editor e abrir o teclado na tela, mas o ponto de inserção acaba voando para longe do editor quando a janela rola para cima para caber no teclado.

Tentar mexer no editor parece problemático; Posso meio que toque na linha que está sendo editada, mas tocar nas outras linhas acima parece _perder_ o foco e fecha o teclado. Só posso colocar o foco de forma confiável no final do documento.

Ao rolar verticalmente, o ponto de inserção parece pular para cima / para baixo uma linha por vez, mas quando eu começo a digitar, ele pula de volta para o final do documento para adicionar novos caracteres.

(O branch do iPad no Firefox 4 regular também tem problemas - parece fazer suposições sobre a posição de rolagem da janela, e clicar no editor acaba colocando o cursor na posição errada se eu rolei a _janela_ para baixo para ajustar o editor no espaço visível.)

alguma atualização no ramo ipad?

Infelizmente não. Este ramo não está atualmente em desenvolvimento ativo. Planejamos ressuscitá-lo, mas não temos estimativa de quando.

Desculpe ressuscitar um tópico morto, mas houve algum progresso no front do iOS?

Obviamente, existe um grande interesse nisso. Vou dar uma olhada e ver se posso ajudar

+1

Um componente baseado na web que não oferece suporte ao iPad não pode mais ser corretamente chamado de componente baseado na web, IMO.

Eu apoio isso. Estou escrevendo em um iPad agora, desejando estar usando o ACE para programar ...

1 preciso disso com bastante urgência também no iPad

+1 para a urgência

Eu também gostaria de suporte para iOS, e muito em breve. Se eu conseguir encontrar tempo, ficarei feliz em sentar e fazer isso sozinho. Portanto, se houver alguma indicação sobre onde devo começar no código e detalhes sobre como ele está dando errado, agradecemos.

Concordado - Eu contribuiria para um fundo de kickstarter para concluir isso, se necessário

No sábado, 7 de abril de 2012 às 14h53, Joe
[email protected]
escreveu:

Eu também gostaria de suporte para iOS, e muito em breve. Se eu conseguir encontrar tempo, ficaria feliz em sentar e fazer isso sozinho. Portanto, se houver alguma indicação sobre onde devo começar no código e detalhes sobre como ele está dando errado, agradecemos.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -5006423

Não há como trazer aquele maldito teclado para cima com javascript, polegar para cima para um teclado personalizado.

Não é verdade. Atribua um elemento como editável de conteúdo para dar a ele o foco, e o teclado deve aparecer. Você também pode fazer truques com áreas de texto e entradas de texto para fazê-lo funcionar.

O teclado também vem com a versão do Ace que estou usando no meu site, mas não pode ser usado.

@PlayMyCode Se eu não consigo chamar algo como ios.showKeyboard() então é verdade que não consigo abrir em javascript, isso que você disse são soluções rápidas ...

Simplesmente não funciona assim.

Se o conteúdo não for editável ou se não for uma entrada de texto, por que o teclado seria exibido? Os personagens não irão a lugar nenhum, você não receberá entrada do teclado.

As teclas precisam ir para algum lugar para que o teclado seja exibido. Se eles não tiverem para onde ir, ele não aparecerá. Se eles tiverem algum lugar para ir, ele aparecerá. Isso não é um hack, é apenas como funciona a entrada de texto.

@PlayMyCode - os caracteres não precisam necessariamente de uma entrada de texto para ir, eles podem apenas "ir" para o javascript - se você tivesse um conjunto de ouvintes de teclas, seria capaz de pegar os caracteres e colocá-los onde quisesse. ..

@hjwp está certo, mas, novamente, não é tão simples. Acredito que os elementos devem ser capazes de obter o foco, ou o navegador não enviará o evento para o elemento e muitos elementos não podem receber o foco. Por exemplo, a tela só ouvirá eventos importantes se você adicionar um índice de tabulação (ou pelo menos estou descobrindo isso agora no Chrome). O iOS também só abre o teclado para tela se você definir o conteúdo como editável.

Ou este é um argumento acadêmico. O suporte a iOS é o que é importante e não deve ser deixado de lado simplesmente porque uma solução se parece muito com um hack (a menos, é claro, que haja uma alternativa melhor).

Que tal colocar o foco em uma entrada de texto oculta e limpar isso ao pressionar a tecla?

Sim, é assim que funcionam muitos WYSIWYGs.

Em 09/04/2012, às 4:56, "André Fiedler"
[email protected]
escreveu:

Que tal colocar o foco em uma entrada de texto oculta e limpar isso ao pressionar a tecla?

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -5024068

As versões anteriores do Ace não posicionavam uma área de texto ou elemento de entrada sob entrada, originalmente? Essa abordagem trará o teclado.

As versões mais antigas do Ace não posicionavam uma área de texto ou elemento de entrada sob a entrada, originalmente

novas versões do ace fazem o mesmo.
textarea sai de sincronia com o cursor durante a rolagem, mas isso é fácil de corrigir
Eu não vi o ace no ipad, mas no android digitando e movendo o cursor funciona, só que não há como selecionar o texto.
mas mais importante

• ace no navegador Android é super lento, fennec é um pouco melhor, mas ainda inutilizável (talvez usar setTimeout aqui com um intervalo maior pode ajudar, mas não tenho certeza)
• O teclado padrão e as sugestões de preenchimento automático são completamente inúteis para a programação (portanto, fazer um teclado personalizado em vez de tentar mostrar o padrão parece uma boa ideia).
  no geral, não acho que o Ace possa ser útil em tablets ainda.

teclado personalizado parece bom!

Estou cético em relação a um teclado personalizado. Construir um teclado bom e polido não é trivial e vale a pena ser um grande projeto por si só. Eu também esperaria que um teclado HTML puro fosse mais lento do que o embutido.

Também precisaria funcionar bem em diferentes tamanhos de tela e diferentes orientações de layout. Por exemplo, eu não gostaria de usar o teclado do iPad no iPhone, e não é legal usar o teclado do iPhone no iPad. Eles têm teclados diferentes por um motivo. Acima de tudo, isso significa que tudo no iPad e no iPhone usa um teclado, exceto o Ace. Resumindo, os usuários já têm um teclado que esperam e, em muitos casos, ele é personalizado (como a configuração de um teclado dividido).

Minha recomendação seria apenas fazer o teclado funcionar, pois eu esperava que isso fosse menos trabalhoso do que construir um teclado personalizado. Em seguida, preocupe-se em construir um teclado personalizado no futuro como um problema separado. Também permitiria que você opcionalmente usasse o teclado do sistema operacional como alternativa a um teclado personalizado, como se não funcionasse bem em um determinado dispositivo.

Este site também diz que você pode desativar o preenchimento automático e a capitalização automática em entradas específicas: http://davidbcalhoun.com/tag/javascript

Um teclado personalizado também não será capaz de usar a largura da tela inteira se o Ace for colocado em um iframe.

Isso pode soar como um caso secundário, mas tanto JSFiddle quanto JS.do.it permitem que você incorpore editores a iframes em outros sites, e é algo que eu gostaria de fazer sozinho.

@PlayMyCode - Secundado: um teclado personalizado seria uma ideia extremamente ruim por muitos dos motivos que você mencionou e outros.

@PlayMyCode - Concordo, o teclado personalizado parece perigoso. Também suspeito que aqueles que sugeriram isso têm pouca ou nenhuma experiência em trabalhar com APIs do iOS. Mas posso estar errado, estou apenas seguindo o que @cranic disse sobre ios.showKeyboard() , as APIs nativas não têm nada equivalente a isso ... O mais próximo seria chamar becomeFirstResponder em um UITextInput controle ... mas estou divagando.

Isso deve ser inteiramente factível, provavelmente com pouco esforço. Suponho que seja no sentido de dar foco a um elemento que tem contenteditable definido. No iOS 5.0, contenteditable é compatível, consulte o final de Criação de conteúdo da web compatível

Há um JavaScript para editar o código dentro de um navegador que ativa um teclado no iOS: CodeMirror, consulte, por exemplo, http://codemirror.net/mode/r/index.html para uma demonstração (funciona no iPhone) e codemirror.net para geral. Então, talvez haja algo em seu código que possa ajudar a suportar iOS no Ace?

@bertoltmeyer , CodeMirror é baseado em áreas de

@cranic na verdade Codemirror2 é muito semelhante ao ace e usa, que usa o mesmo textareas
se Codemirror2 funciona no ipad, consertar o ace, para funcionar da mesma maneira não deve ser difícil

Estou escrevendo da perspectiva de um estatístico R que, como milhares de outros, usa o RStudio para codificação. RStudio é o IDE mais popular para R e é construído no ace. Se o ace suportasse iOS, o RStudio Server também. Nesse mundo ideal, eu poderia simplesmente acessar nosso servidor RStudio do meu iPad e fazer toda a minha codificação a partir dele. Eu (e milhares de outros caras do R) não precisaríamos mais usar meu laptop. Então, falando sério, a falta de suporte de Ace para iOS é a _única_ razão pela qual ainda estou carregando um laptop e tenho certeza de que há muitas outras pessoas como eu por aí. Então, se eu falasse javaScript, o que não falo, estaria trabalhando nisso com prioridade. Mas como não consigo codificar em js, tudo o que posso realmente dizer é por favor, por favor, alguém pode tentar consertar isso. Suspirar. Eu (e outros) realmente apoiaríamos um kickstarter nesta questão, se necessário.

Ei, dei uma olhada rápida no código, mas tudo que vejo é div s; onde está o canvas ?

O ace nunca usou um canvas , era o melhor

com 2f6a6ce7e0992a2eccbb8a517aa2d6f4954f1214 não será rolado para fora da visualização.

por falar nisso. mais uma razão para fazer teclado virtual

Eu concordo com

Adoraria ver isso funcionando em um iPad também - habilitaria _muito_ de funcionalidade em aplicativos downstream (eu também vim aqui por meio do RStudio, mas acabei de perceber que o ACE está em uso em algumas outras ferramentas da web que uso esporadicamente, então para mim isso resolveria muitos problemas diferentes).

Como podemos levantar um kickstarter de projeto semelhante para isso? Estou disposto a
coloque $ 100 no pote agora
No lado das interfaces - Prompt no iOS (um cliente ssh) tem um ótimo teclado
que é mais adequado para administrador de sistema / programação do que o layout padrão do iOS.

Na quinta-feira, 10 de maio de 2012 às 5h34, Rui Carmo <
[email protected]

escreveu:

Adoraria ver isso funcionando em um iPad também - habilitaria um _lot_
de funcionalidade em aplicativos downstream (eu também vim aqui por meio de
RStudio, mas acabei de perceber que o ACE está em uso em algumas outras ferramentas da web.
usar esporadicamente, então para mim isso resolveria muitos problemas diferentes).

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -5612400

@velniukas Boa ideia com o kickstarter, eu não ficaria surpreso se algumas pessoas (como eu) fizessem doações para tal projeto.

Infelizmente, não posso me comprometer em nenhum momento com o desenvolvimento de uma correção
agora, mas estou disposto a ajudar a configurar um projeto como este com
alguns colaboradores.

Na quinta-feira, 10 de maio de 2012 às 8:01, Mike Lawrence <
[email protected]

escreveu:

@velniukas Boa ideia com o kickstarter, eu não ficaria surpreso se um
poucas pessoas (como eu) doariam para tal projeto.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -5615069

Eu também adicionaria pelo menos 200 dólares a um projeto kickstarter para compatibilidade com o iOS. Tenho certeza de que conseguiríamos arrecadar bastante dinheiro para isso com a comunidade R. Não posso contribuir com a codificação porque não falo js o suficiente, mas estou disposto a ajudar na arrecadação de fundos na comunidade R se alguém conseguir um kickstarter. @velniukas , você seria capaz de identificar potenciais colaboradores e contatá-los a respeito da implementação de tal projeto?

Vou fazer - qualquer pessoa interessada em ajudar a configurar um kickstarter - mande-me um pm

Felicidades
Steve
10xEngineer.me

Na quinta-feira, 10 de maio de 2012 às 14h59, Bertolt Meyer <
[email protected]

escreveu:

Eu também contribuiria com pelo menos 200 dólares para um projeto kickstarter para ace iOS
compatibilidade. Tenho certeza de que conseguiríamos levantar bastante
dinheiro para isso da comunidade R. Eu sou incapaz de contribuir para o
codificação porque não falo js o suficiente, mas estou disposto a ajudar com o
arrecadação de fundos na comunidade R se alguém conseguir um kickstarter.
@velniukas , você seria capaz de identificar potenciais colaboradores e
contatá-los com relação à criação de tal projeto?

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -5619266

Não é uma questão de dinheiro, mas sim de ter capacidade de desenvolvimento suficiente para isso.

Eu sei - mas às vezes o dinheiro pode ajudar as pessoas a serem motivadas para liberar capacidades. ;-)

O fato é que esse é um trabalho árduo e todos têm prioridades. Faça isso da maneira certa, contratando grandes talentos. É um pequeno preço entre todos nós.

Enviado do meu iPhone

Em 10 de maio de 2012, às 22:18, Jan [email protected] escreveu:

Não é uma questão de dinheiro, mas sim de ter capacidade de desenvolvimento suficiente para isso.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -5626268

Uma opção seria postar uma descrição do que precisa ser feito no vWorker.com e solicitar lances para que possamos ter uma ideia de quantos desenvolvedores estariam disponíveis para isso e com que taxas.

Meu Deus, como eu gostaria de poder cancelar a assinatura de atualizações neste tópico ...

@Gozala acho que você está procurando por uma antena na parte inferior da página

pode alguém que tem um teste de ipad http://c9.io/nightwing/ace/workspace/kitchen-sink.html
é apenas uma melhoria para o ime, mas deve melhorar a digitação no ipad também

O teclado

@nightwing Oh, obrigado: D Você fez o meu dia!

@nightwing Talvez eu traga isso para @fjakobs quando ele vier a San Francisco esta semana. Fazer com que o teclado apareça no iOS 5 é extremamente fácil: http://c9.io/gjtorikian/ace/workspace/build/kitchen-sink.html Basta adicionar contenteditable ao corpo, pronto .

A navegação não funciona, o que é obviamente mais difícil. Apenas fica em {row: 0, column: 0} . Eu acho que tem a ver com o <textarea> que é o primeiro filho de ace_editor que parece agir como uma espécie de cursor.

+1 para compatibilidade com iOS

Observe o commit de 15 de janeiro de 2011 no fork do @javruben , talvez funcione?
https://github.com/javruben/ace/commits/master

@Gozala Você pode cancelar a assinatura de notificações no final desta página com o link "desativar notificações para este problema"

Em referência aos comentários anteriores de membros da comunidade R, instalei o servidor R-Studio versão 0.96.228 no Ubuntu e usei o Wireshark para examinar o tráfego de rede de entrada. Eu loguei no servidor R-Studio no iPad com sucesso usando o Safari. O teclado aparece bem agora, tanto nas caixas de texto (por exemplo, para pesquisa) quanto no painel do navegador que contém o R-console. O problema surge quando você pressiona Return ao digitar no painel que contém o console R: o navegador do iPad está enviando FIN, ACK, o que faz com que o aplicativo de servidor R-Studio reinicie a sessão. Alguma ideia do que causa isso?

Quaisquer atualizações sobre isso - eu sou a favor de oferecer uma recompensa por esse recurso - se pudermos encontrar desenvolvedores adequados que entendam o problema.

Você pode adicionar outro nome à lista de pessoas que gostariam de ver o ACE funcionar com navegadores móveis, em particular tablets. Dito isso, tenho certeza de que não é uma tarefa trivial. O que aqueles de nós que estão interessados ​​em ver isso acontecer, mas que não têm os recursos de JavaScript para fazer isso podem fazer para ajudar a que isso aconteça? Eu colocaria dinheiro em um projeto Kickstarter se isso ajudasse.

/ cc @javruben

A última vez que trabalhei nisso (reconhecidamente há um ano), testei no iphone e fiz o teclado aparecer. A digitação funcionou, mas o cursor foi deslocado e acredito que inserir um \ n inseriria dois.

Existem os seguintes problemas para resolver:

1. Teclado para aparecer
2. Qualquer interação de digitação precisa ser testada
3. Seleção com eventos de toque
4. Para que a rolagem seja rápida, um novo renderizador deve ser implementado sem uma janela de visualização virtual
5. Possivelmente adicione um teclado falso para acesso mais rápido às teclas usadas pelo modo de idioma (dinâmico)

Por favor, comente se você deseja e é capaz de ajudar em uma dessas tarefas. Vou ver que outros recursos posso reunir.

Ruben,

Não tenho um desenvolvedor iOS disponível - mas um dos meus caras da web deveria ser
capaz de ajudar em um futuro não muito distante, assim que lançarmos o próximo lançamento em
cerca de 2-3 semanas.

Cumprimentos
Steve

Na Quarta, 1 ° de agosto de 2012 à 1h09, Ruben Daniels <
[email protected]

escreveu:

A última vez que trabalhei nisso (reconhecidamente há um ano (s?)), Testei no
iphone e eu pedi para mostrar o teclado. A digitação funcionou, mas o cursor estava
compensado e acredito que inserir um \ n inseriria dois.

Existem os seguintes problemas para resolver:

1. Teclado para aparecer
2. Qualquer interação de digitação precisa ser testada
3. Seleção com eventos de toque
4. Para que a rolagem seja rápida, um novo renderizador deve ser implementado sem um
   janela de visualização virtual
5. Possivelmente adicione um teclado falso para acesso mais rápido às teclas usadas pelo
   modo de linguagem (dinâmico)

Por favor, comente se você deseja e é capaz de ajudar com um destes
tarefas. Vou ver que outros recursos posso reunir.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -7404954

Boas notícias! Eu só quero dizer que ainda estamos assistindo e animados com
isto. Vejo oportunidades incríveis de suporte ao iPad. Eu realmente não
tenho necessidade de desenvolver código na nuvem quando tenho um mac no meu
ponta dos dedos. Estou muito apegado ao meu conjunto de ferramentas. Mas a capacidade de desenvolver
usar meu iPad muda tudo. Obrigado por ficar por dentro disso e
fazendo algo incrível! Me diga se posso ajudar.

Na terça, 31 de julho de 2012 às 20h02, velniukas <
[email protected]

escreveu:

Ruben,

Não tenho um desenvolvedor iOS disponível - mas um dos meus caras da web deveria ser
capaz de ajudar em um futuro não muito distante, assim que lançarmos o próximo lançamento em
cerca de 2-3 semanas.

Cumprimentos
Steve

Na Quarta, 1 ° de agosto de 2012 à 1h09, Ruben Daniels <
[email protected]

escreveu:

A última vez que trabalhei nisso (reconhecidamente há um ano (s?)), Testei no
iphone e eu pedi para mostrar o teclado. A digitação funcionou, mas o cursor
foi
compensado e acredito que inserir um \ n inseriria dois.

Existem os seguintes problemas para resolver:

1. Teclado para aparecer
2. Qualquer interação de digitação precisa ser testada
3. Seleção com eventos de toque
4. Para que a rolagem seja rápida, um novo renderizador deve ser implementado sem
   uma
   janela de visualização virtual
5. Possivelmente adicione um teclado falso para acesso mais rápido às teclas usadas pelo
   modo de linguagem (dinâmico)

Por favor, comente se você estiver disposto e for capaz de ajudar com um dos
esses
tarefas. Vou ver que outros recursos posso reunir.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -7404954

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ajaxorg/ace/issues/37#issuecomment -7414813

Rusty Zarse
http://LeVo.us
[email protected]
m: 404-510-1134

Eu também estou ansioso por isso. Criar um aplicativo que requer edição de código na web. Essa é a única coisa que está me impedindo de enviá-lo para o mundo real.

@velniukas alguma atualização sobre isso? Parece que há muitas pessoas solicitando esse recurso e muitas pessoas dispostas a ajudar. Vamos nos organizar e fazer!

@tzikis +1

Este deve ser o recurso número um 'obrigatório'. Por quê? Porque sem a compatibilidade do iPad, a credibilidade do ACE fica completamente prejudicada e sujeita a projetos concorrentes que podem e oferecem esse nível de suporte. Como empresa, já estamos pensando em mudar. Afinal, essa questão foi levantada pela primeira vez há mais de 2 anos e não deu sinais de que iria desaparecer.

@emeraldspy Agradeço a

https://c9.io/site/blog/2012/09/the-ace-editor-hits-v1-0/

e a lista de problemas mencionados no blog:

https://github.com/ajaxorg/ace/issues?milestone=2&state=open

Resposta? Zilch. Enquanto nós da Cloud9 conduzimos o projeto, não podemos nos dedicar a esse esforço em tempo integral. Só podemos fazer melhorias graduais. Então o que nós podemos fazer? O que você faria nesta situação? Esperávamos que, ao criar uma licença mais aberta, isso trouxesse mais contribuições para o suporte móvel, mas isso ainda está para acontecer.

Achamos que o ACE é um projeto realmente especial e queremos que muitos mais desenvolvedores no futuro se beneficiem de seu desempenho excepcional e conjunto de recursos sofisticados. Mas não podemos _forçar_ outros a simplesmente contribuir com suporte móvel. Portanto, apresentamos algumas ideias que podem funcionar:

• Organize um hackathon de fim de semana dedicado à implementação desses recursos
• Trabalhe diretamente com outra empresa que usa ACE e pode dedicar recursos de desenvolvimento
• Retrabalhe nossos materiais promocionais (como ace.ajax.org) para levar essa tarefa a mais pessoas

Este projeto pode estar sofrendo do "efeito espectador". Ou seja, há um nível tão alto de interesse no ACE que alguém presumirá que outros irão implementar a nova solicitação de recurso. A realidade é: apenas algumas pessoas contribuem. Claro que amamos essas contribuições e correções de bugs! Mas essas contribuições não se somam ao suporte móvel de ponta a ponta. Atualmente, apenas o Android funciona bem.

Se todos vocês que estão lendo isso têm ideias, por favor, contribua com elas aqui. Não queremos que essa missão morra em um gemido silencioso de "outra pessoa vai cuidar disso". Estamos motivados, simplesmente não temos recursos para fazermos tudo sozinhos. Portanto, precisamos do seu apoio !

Então, vamos começar a agir já! E se você quiser me enviar um e-mail diretamente sobre como dedicar seus próprios desenvolvedores a esse esforço, faça o seguinte: meu e-mail é [email protected]. E quase sempre estou no #ace em irc.freenode.net. Vamos lá!

Matt

Fizemos algumas análises do trabalho necessário e chegamos a alguns
conclusões que colocam isso mais tarde em nosso roteiro:

1. A navegação vai ser complicada
2. O manuseio do DOM é difícil e lento no celular
3. Os teclados na tela do tablet não estão bem configurados para tarefas de programação
4. O celular não era tão necessário quanto antes - com mac airs e ultrabooks, um
   muito mais pessoas estão carregando computadores completos em vez de um tablet e
   um teclado, para tarefas de programação

Estávamos pensando que, se desenvolvêssemos por esse caminho, um aplicativo híbrido poderia
ser necessário para contornar alguns desses problemas.
Você pode entrar em contato comigo diretamente para discutir como levar isso em frente?

Cumprimentos
Steve
http://10xEngineer.me
skype: steve_messina

Na quarta-feira, 3 de outubro de 2012 às 3h48, Matt [email protected] escreveu:

@emeraldspy https://github.com/emeraldspy Agradeço a honestidade morta
você está levando com esta situação. A realidade é: você está certo! Móvel
o suporte no ACE é obrigatório. Na verdade, ligamos para a comunidade 2 semanas
atrás para dar suporte a este esforço:

https://c9.io/site/blog/2012/09/the-ace-editor-hits-v1-0/

e a lista de problemas mencionados no blog:

https://github.com/ajaxorg/ace/issues?milestone=2&state=open

Resposta? Zilch. Enquanto nós da Cloud9 conduzimos o projeto, não podemos
nos dedicamos a esse esforço em tempo integral. Nós só podemos fazer graduais
melhorias. Então o que nós podemos fazer? O que você faria nesta situação?
Esperávamos que, ao criar uma licença mais aberta, fosse possível obter mais
contribuições para o suporte móvel, mas isso ainda não aconteceu.

Achamos que o ACE é um projeto realmente especial e queremos muitos mais desenvolvedores
no futuro para se beneficiar de seu desempenho excepcional e sofisticado
conjunto de características. Mas não podemos _forçar_ outros a simplesmente contribuir para celular
Apoio, suporte. Portanto, apresentamos algumas ideias que podem funcionar:

• Organize um hackathon de fim de semana dedicado à implementação desses recursos
• Trabalhe diretamente com outra empresa que usa ACE e pode dedicar o desenvolvimento
  Recursos
• Retrabalhe nossos materiais promocionais (como ace.ajax.org) para trazer este
  tarefa para mais olhos

Este projeto pode estar sofrendo do "efeito espectador". Ou seja, ali
é um nível de interesse tão alto no ACE, que alguém vai assumir outros
implementará a nova solicitação de recurso. A realidade é: apenas algumas pessoas
contribuir. Claro que amamos essas contribuições e correções de bugs! Mas aqueles
as contribuições não somam o suporte móvel de ponta a ponta. Atualmente
apenas o Android funciona bem.

Se todos vocês que estão lendo isto têm ideias, por favor, contribua com elas
aqui. Não queremos que esta missão morra em silêncio "alguém vai
cuidar disso "choramingar. Estamos motivados, mas não temos o
recursos para fazermos tudo isso nós mesmos. Portanto, _precisamos do seu apoio_!

Então, vamos começar a agir já! E se você quiser me enviar um e-mail diretamente
sobre dedicar seus próprios desenvolvedores a esse esforço, então faça: meu
o e-mail é [email protected]. E quase sempre estou no #ace em irc.freenode.net.
Vamos lá!

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/ajaxorg/ace/issues/37#issuecomment -9084281.

Obrigado Steve! Eu adicionei você no Skype. Para todos os interessados ​​nos resultados de nossa conversa (e em quaisquer conversas futuras que tenhamos com outras pessoas que desejam contribuir), postaremos atualizações em um fórum público (prob GitHub).

@mattpardee , certifique-se de postar quaisquer atualizações. Em nome da equipe do codebender, estávamos interessados ​​em participar de um hackathon como você sugeriu em sua resposta a @emeraldspy

Vamos apenas fazer isso

@tzikis Awesome. Estamos discutindo opções com Steve, mas um hackathon do Google Hangout em um fim de semana internacional parece a maneira perfeita de fazer isso. Estamos procurando opções. Fique ligado!

atualização: para ser mais claro sobre o que estamos discutindo, Steve fez algumas pesquisas sobre o desempenho do suporte móvel e estamos avaliando o desempenho de um cliente móvel.

Se fizermos este hackathon de fim de semana, terei de forjá-lo nas próximas duas semanas, enquanto o ferro está quente. Idealmente, iremos coordenar com @nightwing e @fjakobs para fornecer algumas orientações sobre as melhores práticas. Espere ver mais sobre isso em breve.

Estou usando o ACE apenas como um marcador de sintaxe de arquivos XML (somente leitura, sem edição).
Tudo funciona bem, mas a rolagem em dispositivos móveis.

Resolver esse problema deve ser um começo. A rolagem é um grande problema no ACE devido à renderização parcial das linhas de código.
Pelo menos todo o resto está funcionando para mim em um dispositivo iOS (mais ou menos).
Caso contrário, você pode fornecer uma maneira de renderizar as linhas inteiras (pelo menos para arquivos pequenos a médios)
e tente resolver o problema.

Também estou aberto para colaborar em um hackaton. Vamos fazer isso!

Apenas um aviso. Um hackathon será um evento não trivial. Será uma
uma ou três semanas, pelo menos, dependendo de quem conseguirmos embarcar.
Questões para disputar:

• Simplificar a estrutura div para melhorar o desempenho
• Trazendo o teclado / teclado personalizado
• Navegação

Possivelmente indo para uma solução híbrida com um teclado nos moldes do
O excelente iOS Prompt pode ser a melhor opção.

Na quinta-feira, 4 de outubro de 2012 às 21h30, avillegasn [email protected] escreveu:

Estou usando o ACE apenas como um marcador de sintaxe de arquivos XML (somente leitura, não
edição).
Tudo funciona bem, mas a rolagem em dispositivos móveis.

Resolver esse problema deve ser um começo. A rolagem é um grande problema no ACE
devido à renderização parcial das linhas de código.
Pelo menos todo o resto está funcionando para mim em um dispositivo iOS (mais ou menos).
Caso contrário, você pode fornecer uma maneira de renderizar as linhas inteiras (pelo menos para
arquivos pequenos a médios)
e tente resolver o problema.

Também estou aberto para colaborar em um hackaton. Vamos fazer isso!

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/ajaxorg/ace/issues/37#issuecomment -9141191.

Olá @velniukas.

Estamos no processo de criar um local em SF para coordenar o hackathon; estamos estimando em cerca de 4 semanas a partir de agora. Estou reunindo materiais de orientação de @nightwing e @fjakobs e desenvolvendo um site para promovê-lo. Estamos buscando a ideia de mantê-lo por alguns dias. O primeiro dia é dedicado a obter o máximo de recursos cobertos e o segundo a reunir essas mudanças em uma peça coesa.

Até agora, temos desenvolvedores de Hong Kong, Amsterdã, Grécia, Armênia e SF interessados. Portanto, estamos promovendo essa ideia como um Hackathon Internacional (talvez o primeiro desse tipo?).

@nightwing tem ideias sobre como podemos obter uma implementação móvel com melhor desempenho, que seria uma parte distinta da maneira como os navegadores de desktop lidam com o renderizador virtual. Manteremos todos informados de sua orientação e finalizaremos um fim de semana muito em breve.

Minha equipe de 5 a 7 desenvolvedores está em: SF, Praga, Ucrânia, Rússia, Índia, Moscou, HK. 4
semanas a partir de agora é perfeito para nós. Além disso, vou reunir o desenvolvedor de inicialização local
comunidade aqui em Hong Kong, se conseguirmos definir uma agenda e tarefas difíceis
pelo menos 2 semanas antes. Provavelmente pode patrocinar um dos espaços de co-working
por esta.

Steve
http://10xEngineer.me

Na sexta-feira, 5 de outubro de 2012 às 12h35, Matt [email protected] escreveu:

Olá @velniukas https://github.com/velniukas.

Estamos em processo de criação de um local em SF para coordenar o
hackathon; estamos estimando em cerca de 4 semanas a partir de agora. Estou juntando
materiais de orientação de @nightwing https://github.com/nightwing e
@fjakobs https://github.com/fjakobs e desenvolver um site para promover
isto. Estamos buscando a ideia de mantê-lo por alguns dias. O primeiro
dia dedicado a obter o máximo de recursos cobertos, e o segundo dia a trazer
essas mudanças juntas em uma peça coesa.

Até agora, temos desenvolvedores de Hong Kong, Amsterdã, Grécia, Armênia e
SF interessado. Portanto, estamos promovendo essa ideia como um Hackathon Internacional
(talvez o primeiro de seu tipo?).

@nightwing https://github.com/nightwing tem ideias sobre como podemos obter um
implementação móvel de maior desempenho que seria uma parte distinta de
a maneira como os navegadores de desktop lidam com documentos. Vamos manter todos informados
de sua orientação e fechar um fim de semana muito em breve.

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/ajaxorg/ace/issues/37#issuecomment -9147909.

Fantástico, Steve! Isso pode se transformar em um evento marcante. Dados os fusos horários, eu preferiria começar bem tarde na sexta-feira, no início do sábado PST e continuar por 24 horas. O site em que estou trabalhando gerenciará equipes para escolher tarefas específicas para que ninguém duplique o trabalho. Se alguém já fez isso antes ou tem ideias de como isso pode ser _melhor_, me avise.

Ainda estou juntando os detalhes deste evento. Cimentação de datas, montagem de um local, envio de e-mail para as equipes em potencial e construção do site. Quando eu tiver mais informações interessantes postarei aqui. Estamos ansiosos para fazer isso acontecer!

Isso seria ótimo. Atualmente estou tendo que usar o codemirror para necessidades móveis. Adoraria usar o ace para todas as necessidades.

OK, todos assistindo a este problema. Demos um primeiro passo na direção certa com o suporte para iOS _scrolling_. Antes de testar o link abaixo, existem algumas ordens de operação e advertências a serem observadas:

1. Espere o arquivo inteiro carregar
2. Depois que o arquivo for carregado, clique na caixa de seleção "Modo móvel" no canto inferior esquerdo
3. Não mude a orientação.
4. Comece a rolar
5. Eu testei isso no iPad v1 e no iPhone 5. O iPhone teve um desempenho brilhante, mas o iPad 1 foi péssimo. Mais sobre isso em um segundo.

https://c9.io/c9developer/ace/workspace/kitchen-sink.html

Como isso foi alcançado

• Criei um div que se sobrepõe ao editor com o seguinte CSS:

#scroll_div {
     -webkit-overflow-scrolling: touch;
     overflow-y: scroll;
     pointer-events: none;
}

A regra 1 é necessária para a rolagem suave com base no toque e a regra 3 é permitir que a sobreposição fique por cima, mas não receba nenhum dos eventos que desejamos enviar aos elementos abaixo. Isso deixa aberta a oportunidade de fornecer suporte de digitação preciso no futuro.

• Construiu um algoritmo de inércia personalizado. Este é o algoritmo mais simples que eu poderia conceber que ficou "perto o suficiente" do que o iOS faz nativamente. Ele simplesmente itera em um intervalo de 24 ms e diminui a velocidade em 94,9% para cada intervalo. A velocidade inicial é definida com base na distância em pixels entre o último toque e o penúltimo toque (a matemática disso provavelmente poderia ser melhorada incorporando também a quantidade de ms entre os dois últimos toques).
• Sempre que a posição mais recente do intervalo muda, a sobreposição com rolagem por toque também é atualizada. Isso ocorre para que o algoritmo personalizado tenha precedência sobre o algoritmo do iOS e os divs não fiquem fora de sincronia.

Influências

Joe Hewitt explorou essas mesmas ideias extensivamente durante seu trabalho de rolagem, conforme blogado aqui: http://joehewitt.com/2011/10/05/fast-animation-with-ios-webkit

Por que não usei a capacidade de rolagem em primeiro lugar? Ace depende de uma janela de visualização virtual e Joe acabou usando animações de webkit. Os dois não são compatíveis. Eu tenho que definir a posição "scrollTop" do Ace, que então tem que atualizar o renderizador virtual para mudar a posição. Eu poderia ter hackeado o código de Joe para o div rolável e depois aplicado os resultados de suas transformações 3D à camada Ace, mas eh - a aventura foi mais divertida :-)

Futuro

Conforme observado, isso é apenas para rolar. Ainda precisamos obter suporte de digitação preciso lá.

Para dispositivos iOS mais modernos que podem lidar com a velocidade, essa abordagem funciona muito bem. Mas definitivamente há otimizações que podem ser feitas. Continuaremos explorando opções em hardware novo e antigo.

Como se trata apenas de uma demonstração e não faz parte da base de código Ace principal, a próxima etapa é colocá-lo no núcleo.

Estou ansioso para obter a experiência de seus rapazes em diferentes dispositivos e feedback sobre como isso pode ser melhorado. Saúde ~

Ei Matt,

Fico feliz em relatar que isso é muito mais estável no meu iPad4 hoje mais do que ontem. Bom trabalho! Eu também testei no meu Samsung Galaxy Nexus rodando Android 4.2 e ele está bonito. (Por favor, não vamos criar uma solução que seja apenas iOS.) A inserção de texto também funcionou perfeitamente no Android, enquanto meu iPad tinha um problema estranho de cursor duplo (mas eu ainda conseguia digitar.)

@mattpardee Isso é incrível!

Infelizmente, parece interromper completamente o suporte do navegador Android (Android v4.1.1) e do Chrome Mobile (v18.0, novembro de 2012). Esses navegadores tinham pequenos problemas antes, mas agora eu acabei de obter um grande div branco no lugar do Ace.

Impressionante!!

@lennartcl qual dispositivo você está usando? E isso só acontece quando você marca a opção Modo Móvel?

@mattpardee Isso está no Galaxy S3, e aconteceu independentemente da opção móvel. Mas na verdade tentei novamente hoje e agora parece funcionar como antes em ambos os navegadores.

Excelente! Agora posso continuar com a dominação mundial.

Eu estava experimentando a pia da cozinha do mestre no simulador iOS com ipad iOS v5 e parece que não começa a editar.

Quando eu estava batendo na pia da cozinha do site ao vivo com meu ipad 3 iOS 5.1, ele editou, mas sempre tenta capitalizar as letras. Parece que está continuamente em um modo de seleção com os botões azuis de início e parada de cópia.

Este código mais recente está no master ou devemos olhar para um branch ou pull request?

Ei Jeff,

Verifique o branch feature / ioscroll.

https://github.com/ajaxorg/ace/tree/feature/ioscroll

Isso deve pelo menos permitir a rolagem no editor (e você não precisa selecionar nenhuma opção para ativá-la).

@mattpardee Sim, isso habilitou a rolagem no simulador do iOS, mas não consegui descobrir uma maneira de abrir o editor para permitir a edição. Acho que ainda está em andamento?

Sim, ainda estou trabalhando, embora eu reconheça que não sei se tenho a capacidade de fazer isso funcionar sozinho. Algumas delas estão relacionadas a eventos de toque para chamar o foco ou desfoque na textarea subjacente, mas a maior parte do trabalho árduo seria com a atualização do manipulador do cursor. A distância do deslocamento do cursor em relação à sua verdadeira posição de edição se acumula no final da linha, portanto, há algo básico sobre a matemática que ele está fazendo.

Esperar que alguém esteja à altura do desafio!

OK. obrigado pela atualização.

Existe uma maneira de pelo menos eu poder detectar se o navegador tem os requisitos mínimos para executar o ACE do navegador para que eu possa voltar para textarea?

@jfromaniello você poderia usar o Modernizr

Modernizr is a JavaScript library that detects HTML5 and CSS3 features in the user’s browser.

@faceleg sim, mas quais recursos o ACE precisa. Por exemplo, o iOS tem muitos recursos, mas o teclado na tela não mostra.

Alguma atualização na posição do cursor? A rolagem parece boa.

Alguém ainda está trabalhando ativamente nisso?

@MarkMurphy Para ser honesto, acho que não. Veja o comentário de @mattpardee acima para o último estado.

Com relação à rolagem, e o contrário?
Como criar um div grande o suficiente, como height: 10000px; e percorrê-lo dentro de outro div menor. Não é perfeito, embora a rolagem nativa seja preferível em vez de usar recursos extras para emulá-la. Veja a postagem no blog de Dylan "Fazendo o Ace Editor preencher o espaço disponível"

Pelo menos agora sabemos como o teclado virtual deve ser e se comportar como: http://www.textasticapp.com/

Só por curiosidade: qual era a situação disso? Ainda é um problema não resolvido para iOS?

Se alguém está motivado para trabalhar nisso, tenho uma dica e uma possível solução alternativa. O problema parece ser que o teclado não aparece quando o ace textarea é selecionado pelo toque. No entanto, ele surge quando a textarea faz parte de um formulário e é selecionada usando os botões "Próximo" ... "Anterior" fornecidos pelo iOS. Eu acho que...

Percebi isso há algum tempo, mas não consegui encontrar tempo para verificar. Então YMMV.

minha página tem uma seleção para alterar o modo de idioma do editor.

quando carrego a página pela primeira vez, a palavra-chave soft não será acionada quando eu tocar no editor,
MAS, depois de alterar manualmente o idioma da seleção, toque no editor para acionar o teclado.

espero que isso ajude.

Bug downstream para o uso do Ace pela Wikipedia para editar módulos de código de modelo: https://bugzilla.wikimedia.org/show_bug.cgi?id=55345

Como solução alternativa, podemos colocar o Ace na lista negra no iOS e usar uma área de texto simples por enquanto.

CodeAcademy.com está usando o Ace e o tem totalmente funcional no iPad, completo com seleções. Eu posso dar uma olhada nisso.

Alguma novidade sobre isso?

Este bug também está quebrando o IDE Cloud9 no iOS . : +1: para este problema chamar alguma atenção!

ola pessoal, tem alguem ai fora?

+1 também tem problemas com o editor no ipad

+1 - Estamos usando o modo Markdown para o editor e copiar / colar é uma grande coisa que falta no Ace no iOS.

Não é possível usar c9.io por causa desse bug. A demonstração da pia da cozinha também não rola (http://ace.c9.io/build/kitchen-sink.html). Acontece no ipad e no meu Android Transformer (o que é incrível para necessidades de desenvolvimento leve).

Para meu aplicativo da web, eu costumava usar CodeMirror. No entanto, recentemente mudei para o ace por causa da abundância de modos e recursos. A falta de suporte móvel está me fazendo reconsiderar minha escolha.

Algum progresso foi feito para permitir a rolagem em dispositivos móveis? Não funciona em nenhum dispositivo iOS ou Android que experimentei.

@ mkaminsky11 +1. Também estou decidindo entre CodeMirror ou Ace, e o suporte a iOS é o que está me segurando.

Como @jakesankey disse, codeacademy.com usa ace. Tentei examinar o código para ver como eles faziam funcionar com dispositivos móveis, mas sem sucesso. Entrar em contato com eles e pedir ajuda seria uma solução viável?

Atendemos Orion no celular na Codecademy.

Está consertado agora?

Funciona muito bem no meu Asus Transformer, se eu "Solicitar Versão Desktop". É uma pena que o navegador não se lembre dessas configurações.

+1

Olá, apenas para referência, uso o Ace para o meu projeto. O problema do teclado virtual é problemático e acabo fazendo o editor ter o tamanho do conteúdo. Pode haver um problema de desempenho.

https://github.com/dai-shi/codeonmobile

Isso ainda é um problema, visto em http://3v4l.org/

Esse problema também está bloqueando o PlayCanvas.com (iPad Air iOS 8), o que é uma pena, porque o resto se o editor for totalmente compatível com o iPad e, no geral, é uma vitrine insana do que o HTML5 pode ser!

+1. atualmente investigando uma solução alternativa envolvendo a criação manual de alguns botões de rolagem para sentar ao lado do editor, usando scrollBy http://ace.c9.io/#nav = api & api = virtual_renderer

1 para problemas de rolagem.

+1 para problemas de rolagem

1 para problemas de rolagem.

1 para problemas de rolagem.

Olá pessoal, não sou bom / paciente o suficiente para consertar o editor em si, já que todo o conceito de touch vs. mouse é diferente. Mas com o script abaixo, você pode obter o editor ACE para rolar em dispositivos de toque (IOS / Android). Basta colocá-lo na seção de configuração do editor (onde o editor é declarado e as opções são adicionadas).

http://pastebin.com/1Rh7UDea

@ iq77 O que esse código deve fazer? Estou tentando e até agora não faz diferença? Eu sou uma das pessoas que realmente gostaria que isso funcionasse normalmente em dispositivos de toque ...

@tluyben em "touchstart" salva as coordenadas x / y do evento de toque. On "touchmove" calcula a diferença entre o início e o fim, então passa os valores x / y para o "renderizador" do ACE. O renderizador faz a rolagem. Funciona no meu script, mas talvez você precise adaptar alguns nomes de classes, etc., às suas necessidades. Também há algum jQuery lá, você pode ter que substituí-lo.

Este é um ótimo tópico, mas achei difícil dizer (a) qual é a natureza do "problema de rolagem", (b) quais dispositivos / versões do sistema operacional são afetados e (c) quais soluções alternativas estão disponíveis. Se alguém estivesse disposto a resumir onde eles estão, isso seria excelente.

Acabei de testar a pia da cozinha no [iPad Air 2 executando iOS 8 e Safari 8] e [Nexus 10 executando Android 5.1 e Chrome 40] e consegui rolar horizontal e verticalmente (em paisagem; não testei com dispositivos em orientação retrato). Etapas para reprodução:
1) Navegue até http://ace.c9.io/build/kitchen-sink.html
2) Adicione um monte de linhas (linhas em branco funcionam bem) no painel do editor até que haja mais linhas do que cabem na tela.
3) Se necessário, diminua o zoom para visualizar o navegador completo. (Editar o conteúdo do painel do editor pode aumentar o zoom automaticamente, tornando difícil dizer se você está rolando o painel ou apenas movendo a visualização ampliada.)
4) Deslize para cima / para baixo na extremidade direita do painel do editor. Nenhuma barra de rolagem aparecerá, mas o conteúdo do painel do editor deve rolar conforme o esperado.
5) Para testar o hscroll, crie uma longa sequência de caracteres mais larga do que caberá na tela; diminuir o zoom, se necessário; deslize para a esquerda / direita na extremidade inferior do painel do editor. Vejo uma barra de rolagem esmaecendo no Android, mas nenhuma barra de rolagem no iOS ... mas hscrolling funciona em ambos, independentemente.

Estive pesquisando os problemas e pelo que posso descobrir, este é o tópico definitivo sobre 'tudo relacionado ao toque'. Corrija-me se eu estiver errado e continuarei pesquisando / arquivando um novo problema.

Aparentemente, o iOS touch é incapaz de abrir o menu de contexto em um contexto Ace (significativamente, isso permite cortar + colar). Normalmente, isso pode ser acionado tocando no cursor, mas o Ace substitui esse comportamento para mover o cursor um caractere para a frente.

@barneycarroll , este parece ser o tópico relacionado ao toque. Tenho trabalhado recentemente tentando obter pelo menos algum suporte de toque implementado para rolagem. Agora, você pode rolar se você rolar apenas sobre a área direita na extremidade direita ou inferior do espaço de visualização do editor (onde as barras de rolagem estariam). Mas essa não é uma solução viável.

Acho que estou no caminho certo com a implementação de algum suporte de toque, que está funcionando no simulador do iOS. Verifique o fork (https://github.com/AStoker/ace), você atualmente precisa construí-lo para compilar (já que esse é o código-fonte), mas se você seguir as instruções de construção no reino, é fácil. Eu adoraria alguma ajuda com quaisquer melhorias, já que não parece que o suporte ao toque seja uma alta prioridade no momento (mas esse é o benefício do código aberto, podemos consertá-lo nós mesmos). Se tudo estiver certo, farei uma solicitação pull para implementá-lo.

+1 para copiar / colar no iOS. O problema é o manuseio do cursor personalizado? Qual seria um plano de ataque para resolver isso?

IPhone 6 mais iOS 9.2 beta público parece funcionar bem agora com o ace. A rolagem funciona e a edição funciona como se estivesse no computador.

Precisa apenas de melhorias para copiar e colar.

É possível colar e copiar, mas é muito difícil de fazer.

Http://www.apus.com
Em 19 de novembro de 2015 10:52, "paladox" [email protected] escreveu:

IPhone 6 mais iOS 9.2 beta público parece funcionar bem agora com o ace.
A rolagem funciona e a edição funciona como se estivesse no computador.

Precisa apenas de melhorias para copiar e colar.

É possível colar e copiar, mas é muito difícil de fazer.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Tenho problemas com as setas do teclado do meu iPad. O teclado funciona bem em todos os ambientes, mas se eu me conectar ao meu Cloud 9 Server e começar a programar, as teclas de seta serão ignoradas. Posso adicioná-los em algum lugar ou como isso pode ser corrigido? Eu preciso da flecha com frequência durante a codificação.

<div id="editor" class="page-content" contenteditable="true"></div>

Faz o truque no iOS. Simplesmente não consigo fazer o realce da sintaxe assembly_x86 funcionar.

Onde devo incluir este código? Achei que deveria estar em user.settings, mas não tem partes HTML

HTML dentro de um WebView.

Não consigo fazer funcionar dentro de um UIWebView 👎 Começa bem, mas assim que tento mover o cursor, tudo falha. Não consigo escrever, ou com a solução @ jcss-org-il ( <div id="editor" class="page-content" contenteditable="true"></div> ) o cursor se move para fora do editor.

Alguém pode me ajudar a resolver um mistério? O editor de código online GitHub, supostamente baseado no Ace (https://github.com/blog/905-edit-like-an-ace), é incrível. Funciona perfeitamente no iPad, incluindo um teclado Bluetooth, as teclas de seta funcionam (incluindo Ctrl-Seta para a esquerda, Alt-Seta para a esquerda, etc) e o desempenho é ótimo, etc.

Aqui está uma captura de tela de uma sessão de edição de iPad do arquivo README.md deste repositório: (https://github.com/ajaxorg/ace/edit/master/Readme.md)

E ainda, todos neste tópico (eu incluído), não conseguem fazer o Ace rodar em um iPad sem problemas (por exemplo, as teclas de seta não funcionam). (Tenho os mesmos problemas relatados aqui: https://github.com/ajaxorg/ace/issues/37#issuecomment-195258878)

O GitHub está executando uma versão personalizada do Ace? Essa versão está disponível publicamente? Eu adoraria executar o que quer que eles estejam executando! (Captura de tela do inspetor DOM confirmando que parece estar executando o Ace na parte inferior.)

Muito obrigado!
G

@realgenekim da captura de tela, parece que o github usa uma área de texto no ipad

@nightwing Teoria fascinante! Mas, se você olhar para o controle do editor, verá que existem números de linha, recursos do tipo Ace que parecem não ser apenas uma área de texto HTML padrão, como largura de tabulação, quebra de texto ...

Após uma inspeção mais detalhada, tenho certeza de que é algo mais exótico do que textarea!

Os números das linhas

@nightwing Caramba . Isso é tão intrigante - acho que você está absolutamente correto. Vou tentar obter alguma confirmação disso de alguém no GitHub ...

Acho que isso significa que tentarei fazer a mesma coisa. Ou seja, detecte em tempo de execução se é um iPad e não carregue o editor Ace e, em vez disso, apenas use uma área de texto.

Tão insatisfatório, mas pelo menos poderá ser usado até que alguém apareça com uma boa solução para o iPad ...

😦

Acabei de testar isso no meu iPad Pro e basicamente mostra um textarea básico. Talvez com crescimento automático.

É algo inteligente como uma textarea com opacidade 0 e uma instância do editor ace posicionada imediatamente atrás dela? Imagino que com o desempenho do iPad moderno seria possível manter o estado (rolagem interna e conteúdo) quase instantaneamente em cada evento de entrada ...

@barneycarroll Não, pelo menos em meus testes eu estava editando dentro de uma área de texto normal sem números de linha etc.

Ei pessoal! Acabei de criar uma solicitação de pull que corrige alguns dos problemas no iOS. Ele fornece uma boa experiência ao usuário, se você tiver um teclado externo.

Se você gostar, posso pensar em consertar os problemas restantes :)

Você pode vê-lo em ação em https://ipad-undo.gomix.me

Aproveitar!

Apenas usando sua demonstração e estou vendo um problema com o ponto de inserção. Crie um par de aspas, por exemplo, coloque o cursor entre elas e comece a digitar. Ele pula aleatoriamente para o final da linha. Não tenho certeza se essa mudança introduz esse problema ou se ele estava lá inicialmente.

Oh, obrigado @IamNaN , esse bug foi relatado no PR agora :) Acho que sei como consertá-lo ... fique ligado na demonstração :)

EDIT: demo fixed :)

@etamponi Isso parece incrível! Funciona com:

1. Conectar como vim e emac?
2. Suporte IME com CKJ？

Atualmente, parece que bagunça quando você liga o IME.

@episodeyang Lamento muito ter deixado você em espera nisso.

Infelizmente, não tive tempo de continuar trabalhando no PR ... Felizmente, outra pessoa assumiu o meu trabalho e o terminou, agora ele foi mesclado como # 3310, se bem me lembro :)

vim já não era compatível com iOS, e o PR não adiciona suporte para ele. Não sei o suficiente sobre o IME para saber com certeza se meu PR o afetou de alguma forma, desculpe!

Colocar o cursor no meio da palavra por meio de um toque parece acertar ou errar (iOS 11.2, Safari) no demo fornecido por @etamponi - Existe uma maneira de tornar isso mais confiável?

Atualmente o ace funciona bem o suficiente no IOS para fechar este problema sobre a compatibilidade básica. Se você encontrar algum bug ou recurso ausente, abra um novo problema.